Repository navigation
Add support for armcc compiler #6677
Description
Type: LanguageService
I'm using CMake Tools extension as configurationProvider for cpptools, CMake files are correctly parsed and ARM Compiler toolchain is selected (via my Toolchain.cmake file).
However, it seems cpptools extension does not support ARM Compiler.
This is ARM Compiler -> link (it's proprietary ARM compiler, a license is needed to use the compiler, but I could provide whatever compiler output you may need).
Describe the bug
- OS and Version: Windows 10
- VS Code Version: 1.52.0
- C/C++ Extension Version: v1.1.3
- Other extensions you installed (and if the issue persists after disabling them): CMake Tools
After configuration has been provided via CMake Tools, cpptools gives the following C/C++ Configuration Warning:
[17/12/2020, 09:34:04] Unable to resolve configuration with compilerPath "c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe". Using "cl.exe" instead.
The path to ARM Compiler is correct, the executable is there.
Steps to reproduce
You cannot reproduce without an active ARM Compiler license.
Expected behavior
C/C++ extension also supports ARM proprietary compilers.
Logs
Insert logs here.
Screenshots
Additional context
Here you can find more details about compiler defines/includes. (I already supported a similar work for an Eclipse IDE plugin some time ago).
Quotes from above link:
For built-in macros and includes, I provide here armcc case as an example:
Built-in macros are provided by the compiler with
armcc --list_macros dummy.c(dummy.ccan be empty). I could just feed your Parser with this command, whose output is like the following:#define __STDC__ 1 #define __STDC_VERSION__ 199409L #define __EDG__ 1 #define __EDG_VERSION__ 407 #define __EDG_SIZE_TYPE__ unsigned int #define __EDG_PTRDIFF_TYPE__ int #define __sizeof_int 4 #define __sizeof_long 4 #define __sizeof_ptr 4 #define __ARMCC_VERSION 5060422 #define __TARGET_CPU_ARM7TDMI 1 #define __TARGET_FPU_SOFTVFP 1 #define __CC_ARM 1 #define __arm 1 #define __arm__ 1 #define __TARGET_ARCH_4T 1 #define __TARGET_ARCH_ARM 4 #define __TARGET_ARCH_THUMB 1 #define __TARGET_ARCH_A64 0 #define __TARGET_ARCH_AARCH32 1 #define __TARGET_FEATURE_HALFWORD 1 #define __TARGET_FEATURE_THUMB 1 #define __TARGET_FEATURE_MULTIPLY 1 #define __TARGET_FEATURE_EXTENSION_REGISTER_COUNT 0 #define __a32__ 1 #define __OPTIMISE_SPACE 1 #define __OPT_SMALL_ASSERT 1 #define __OPTIMISE_LEVEL 2 #define __SOFTFP__ 1There is no armcc command line argument to get the list of include directories. The only include directory is fixed, and it is simply
../include(relative to the location of armcc executable). I could feed your Built-in parser with this path.
Luckily, I see that everything seems well documented. You can find all info starting from the link to the docs I provided above. Moreover, I can suggest other specific links of interests (you can easily find them navigating through docs by yourself):
- Link to Compiler command-line options and search paths (you can also see
../includethere);- Link to Factors influencing how the compiler searches for header files;
- Link to Compiler search rules and the current place;
- Link to The ARMCC5INC environment variable.
Additionally, I want to point out that I'm using version 5 of the ARM compiler, but there is version 6 also. With version 6, ARM seems to switch to clang-compatible compiler. I provide also a link to version 6 command line options here.
Here in section 1.1 Support level definitions they say:
Arm Compiler 6 is built on LLVM technology and preserves the functionality of that technology where possible. This means that there are additional features available in Arm Compiler that are not listed in the documentation. These additional features are known as community features. For information on these community features, see the documentation for the Clang/LLVM project.
Activity
sean-mcmanus commentedon Dec 17, 2020
Thanks for the info on armcc. This sounds like a duplicate of #4269 .
gentooise commentedon Dec 17, 2020
I'm sorry, I forgot I had already opened a similar issue.
Anyway, I think we may close that one and leave this opened, because I updated my settings in order to use just the
configurationProvider(CMake Tools) in favor of the oldcompileCommandsmechanism.Please let me know if I did well.
Thanks
gentooise commentedon Dec 22, 2020
Any news about this? Do you have any workaround? It doesn't seem possible to manually override compilerPath when using CMake Tools... any idea? Sean McManus (@sean-mcmanus) Bob Brown (@bobbrow)
Thanks
sean-mcmanus commentedon Dec 22, 2020
Yeah, there isn't a way to override the compilerPath with CMake Tools. Looks like this issue is being tracked in CMake Tools at microsoft/vscode-cmake-tools#1096 and the recommended workaround is to use compileCommands, which allows the compilerPath to be overwritten.
gentooise commentedon Dec 22, 2020
Thank you for the info Sean McManus (@sean-mcmanus)
And to override just system include paths and defines (ignoring error on compilerPath), instead? Not possible either?
sean-mcmanus commentedon Dec 22, 2020
If the configurationProvider is set, then our extension will use the includePath/defines from the configuration provider and there's not currently an override mechanism, other than modifying the open source code to allow such an override.
Colengms commentedon Jan 21, 2021
Hi gentooise . Could you set
"C_Cpp.loggingLevel": "Debug", and check the C/C++ output for the command lines that are being used to query the compiler? We will actually invoke the compiler up to 4 times:I'm curious which of these fail. If the issue is only that the result of -dumpmachine is not recognized, that would be relatively simple to fix. Or, the issue may be with how to compose one of the other command lines.
gerhardol commentedon Feb 3, 2021
I have the same problem using the WindRiver compiler.
The options to the WindRiver compiler is different from gcc family, CMake overridden.
Similar with other compilers (ARMCC among others)
We could configure the required information manually instead of quering the compiler.
First part of output
12 remaining items
Wetmelon commentedon Feb 11, 2021
I have the same problem with
tricore-gcc. It was working fine until a few versions ago (yes, even querying standard include paths based on , which I understand is the original intent of this entry), now I get a stupid dialog box with a warning the first time I open a C or C++ file in VSCode. The compiler's a bog standard GCC aimed at the TriCore target, there should be no reason for this. If it works with arm-none-eabi-gcc, it should work with tricore-gcc. At the very least just stop the console from popping up every time, it's driving me nuts. Make it a squiggle-line error in the .json like the inability to resolve the path to the compiler maybe?sean-mcmanus commentedon Feb 11, 2021
Paul Guenette (@Wetmelon) Your issue might be fixed by #6898 ? Colen Garoutte-Carson (@Colengms) Do you know if that's the same issue?
Wastus commentedon Feb 16, 2021
I'm a bit confused right now and not sure which issue is the correct one to post to, I'm just pretty certain, that I don't need to open another one.
We are using the IAR EWARM compiler, which really doesn't behave like gcc at all, so the query fails (
-xis not a valid option for example).The current solution is to provide all defines and include paths in
c_cpp_properties.json. As there are keywords, which are not supported I've created a header file which uses#defineto get rid of those keywords. Additionally the system includes need some defines to be present to be parsed correctly (like the compiler version). This header is included with theforcedIncludeoption.It is a bit ugly to maintain the include paths and defines in several places, so after moving to CMake, I tried using the
compile_commands.json, because all information like the include directories is contained in there. The defines and include directories follow the typical-D -Ischeme, so they get parsed correctly. I've explicitly mentioned the system include directory in myCMakeLists.txt, so they are also recognized as include directory.But still to parse the system headers correctly my header for Intellisense must be included (but only for Intellisense). Sadly, the
forcedIncludeoption gets ignored as described in #1842 whencompile_commands.jsonis used (and I guess thedefinesas well, but that wouldn't be too bad after I learned that_INTELLISENSE_is defined if Intellisense is used). I guess I could change theCMakeLists.txtsomehow to include that header, but we are aiming at safety critical systems, so I really don't want to inject some header just to make a coding tool (even a very nice one) working.So #6909 sounds like it would provide a solution for this, but #6931 would also provide a (more general) solution.
A colleague wrote a small utility to fake the compiler query output, but that has no interface to CMake, so suffers from the same drawbacks as writing everything manually in
c_cpp_properties.json, so I'd like to get a better native solution working.gentooise commentedon Feb 16, 2021
Hi all, I'm glad this issue received a lot of visibility.
I would live well with #6909 solution in the meantime, but I'm really hoping for something like the proposal in #6931: that would be great.
Anyway, just to reply to Colen Garoutte-Carson (@Colengms):
here's your output (private paths omitted):
If you need, I can query armcc compiler by hand with any command you like and provide the output to you.
github-actions commentedon Apr 18, 2021
This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog.
github-actions commentedon May 6, 2021
This feature request has received enough votes to be added to our backlog.
LittleDeD commentedon Apr 27, 2026
I’m running into a problem using the extension with a proprietary compiler (Green Hills) in a CMake-based embedded project. I think this should be the issue to post this.
I’m using CMake Tools as the configuration provider together with a compile_commands.json. Since the compiler isn’t supported, I tried disabling compiler querying by setting compilerPath to an empty string (""). However, the extension still attempts to query the compiler for double the amount of files I have in compile_commands.json.
This causes a couple of issues:
What I don’t understand is:
In my case, I would prefer either fully disabling compiler queries, relying purely on compile_commands.json without attempting to probe the compiler or, as I saw in other issues, a mechanism to have some settings that will let us define how the query happens or give directly the systemDefines. The main issue is that every time I open the project I must wait for half an hour to let it finish the query so the intellisense would work, even if the compiler path points to msvc or another detected compiler. If I let only the configuration provider to be cmake tools, the query is not happening, but it usually has poor results (taking 1-2 minutes to find a header/define or simply cancel the search when it can't find it, even if it exists in a included header; some compile options like a forced include or derivative macro impact the compilation of some files and the intellisense would not see them, even if I placed them in the defines section of c_cpp_properties etc.).
I’ll attach logs and configuration details below.
c_cpp_properties.json
settings.json
c_cpp_log.txt