Incorrect ABI Used for Intellisense with some GCC Compilers

[SEL-Jeremie-Pope]

Bug type: Language Service

Describe the bug

• OS and Version: Windows 10 (10.0.19043.1052)
• VS Code Version: 1.57.1
• C/C++ Extension Version: 1.4.1
• Other extensions you installed (and if the issue persists after disabling them):

Extension	Version	Persists when Disabled
akiramiyakoda.cppincludeguard	1.4.0	YES
eamodio.gitlens	11.5.1	YES
ms-vscode-remote.remote-wsl	0.56.5	YES

• If using SSH remote, specify OS of remote machine: N/A
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).

The project is aimed at a multi-core, multi-architecture embedded custom platform using the ARM GCC AArch64 ELF Bare-Metal toolchain, version 8.3 (2019-03) windows hosted compiler (i686-mingw32). Compilation, debugging, and other services outside of code navigation and intellisense are not handled by vscode, however several tools ensure that build flags, configurations, and other metadata are provided to vscode for navigation.

The repository is a large, multi-root construct which has most of the file management done outside of vscode. Conan is the primary code storage utility which delivers modifications to the workspace via an outside application through direct manipulation of the c_cpp_properties.json and *.code-workspace files. c_cpp_properties.json is then replicated from the primary root directory to any configured secondary roots for appropriate intellisense configuration.

This issue appears to be separate from any complicated workspace configurations and is present both with the described workspace setup and the minimal setup shown below.

Steps to reproduce

1. Using a ARM GCC A-profile compiler for windows-hosted machines, configure your c/c++ properties with -mabi=LP64 as a compiler option.
2. Attempt to use any compiler intrinsics, e.g. sizeof(...), in a constexpr statement.
3. Bask in the nonconformant values

Expected behavior
The reported sizes and values of all types should match the configured ABI, not just the default.

Code sample and logs

• Code sample

#include <cstdint>

// None of these should fail if we are in LP64 mode
namespace ARM_LP64_Checks
{

constexpr static std::size_t _char      = sizeof(char);
static_assert(_char == 1,               "CHAR was malformed");

constexpr static std::size_t _short     = sizeof(short);
static_assert(_short == 2,              "SHORT was malformed");

constexpr static std::size_t _int       = sizeof(int);
static_assert(_int == 4,                "INT was malformed");

constexpr static std::size_t _long      = sizeof(long);
static_assert(_long == 8,               "LONG was malformed");

constexpr static std::size_t _long_long = sizeof(long long);
static_assert(_long_long == 8,          "LONG LONG was malformed");

constexpr static std::size_t _size      = sizeof(std::size_t);
static_assert(_size == 8,               "SIZE was malformed");

constexpr static std::size_t _pointer   = sizeof(void*);
static_assert(_pointer == 8,            "POINTER was malformed");

} // ARM_LP64_Checks

• Configurations in c_cpp_properties.json

{
    "env": {
        "conan": "C:/Users/jerepope/.conan/data",
        "compiler": "${env:conan}/gcc-aarch64-elf/8.3.0/arm/approved/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/bin"
    },
    "configurations": [
        {
            "name": "4xx Standard",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "cStandard": "c17",
            "cppStandard": "c++14",
            "intelliSenseMode": "windows-gcc-arm64",
            "compilerPath": "${env:compiler}/aarch64-elf-g++.exe",
            "compilerArgs": [
                "-mabi=lp64",
                "-march=armv8-a+crc+simd+crypto",
                "-mcpu=cortex-a53+crypto"
            ]
        }
    ],
    "version": 4
}

• Logs from running C/C++: Log Diagnostics from the VS Code command palette
  diagnostics.log

• Logs from the language server logging
  language_server.log

Screenshots

Additional context
Other errors due to size incompatibility will crop up from time to time as intellisense can't match standard functions with the malformed type sizes. Most peculiarly, when using placement new the parser will fail as the resulting types for the memory size, in this case unsigned long long, cannot be aliased to the library interface which expects size_t, which gets aliased to unsigned long.

Looking into the language server diagnostics, it appears that the defaults are being generated without the compiler arguments. Later the compiler query is performed again but this time with the compiler arguments. Looking at the output of that call, all sizes are appropriate. It appears that the language server is ignoring arguments when deducing the defaults for a compiler as adding the flag to the compilerPath rather than the compilerArgs produces the same results.

The code compiles and otherwise behaves as expected.

[Colengms]

Hi @SEL-Jeremie-Pope . Could you try changing the IntelliSenseMode to linux-gcc-arm64 ? I believe due to indicating windows, the Windows default of 4-byte longs is being used. A standard header for that compiler is likely associating size_t with long, so that would explain why both are incorrect.

[SEL-Jeremie-Pope]

@Colengms, changing intellisense to the requested mode seems to fix the reported sizing issue. A tad confusing being that we aren't using a linux system, just have a similar ABI.

I don't know where the previous values are being pulled from, though. Looking at all searched directories, those defines are always a product of the ABI selected, which intellisense seems to ignore. Are those values hardcoded to the particular operating systems?

There will be cases where differing ABI will have to be selected for particular projects, is there any way currently that we can specify an ABI for use? I don't believe ILP64 is a model used by any configuration of the big three operating systems.

[Colengms]

Hi @SEL-Jeremie-Pope . Currently, the size of long is determined based on the IntelliSenseMode. When targeting Windows, most compilers use 32-bit longs. There are some exceptions, such as certain versions of MinGW which reflect the sizes used in Linux when targetting Windows. And Cygwin (though technically Cygwin targets a unix compatibility layer and not Win32). Often, we can determine the target platform/architecture/compiler of the compiler based on defines that it returns when we query it, and can correct the IntelliSenseMode to match the results of querying the compilerPath. In your case, that correction is not happening, likely because the compiler is not returning any of the platform indications we look for. So, it's falling back to the platform specified by IntelliSenseMode (which defaults to the host platform). It looks like it might be possible for us to detect more appropriate settings based on the compiler args (i.e. -mabi) or queried defines, though this is a potentially unbounded issue due the variety of compilers available.

We currently have #4653 tracking the need for Platform/Architecture/Compiler -agnostic IntelliSense modes.

We have #6931 tracking the need for a more robust solution that would allow users to provide support for non-standard and uncommon compilers.

We also have #7355 which would involve using compiler defines to determine type sizes (instead of IntelliSenseMode), when available.

[SEL-Jeremie-Pope]

Thanks for the quick reply, seems that anything that'd be added by this issue has already been replicated. I'll close this issue then as #7355 seems to already touch on anything I was investigating for diagnostics.