[cfe-dev] {u}int_fastN_t Types and Preprocessor Defines

[Craig Topper via cfe-dev]

I think for X86, clang's stdint.h is ignored due to this part of stdint.h.
You'll get different sizes if you pass -ffreestanding.

/* If we're hosted, fall back to the system's stdint.h, which might have
 * additional definitions.
 */
#if __STDC_HOSTED__ && __has_include_next(<stdint.h>)

~Craig


On Mon, Jun 1, 2020 at 5:09 PM Sam Elliott via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi cfe-dev!
>
> I am currently investigating an ABI incompatibility for RISC-V between
> Clang and GCC.
>
> GCC defines `{u}int_fast8_t` and `{u}int_fast16_t` to be the same sizes as
> `{u}int32_t` or `{u}int64_t`, depending on the underlying hardware register
> length (RISC-V has a 32-bit architecture and a 64-bit architecture). This,
> to me, makes sense, as there are no sub-registers in the architecture. The
> `{u}int_least8_t` and `{u}int_least16_t` match their bitwidths.
>
> However, in Clang, I believe we cannot have `{u}int_fastN_t` different
> from the equivalent `{u}int_leastN_t`, as the codebase currently stands,
> due to both `DefineFastIntType` and the definitions in
> `clang/lib/Headers/stdint.h`.
>
> Point one is while investigating this, Luis discovered that on x86 these
> types *do* differ in size: https://godbolt.org/z/rrNGPa
> I cannot work out how x86 manages this, because my reading of stdint.h and
> the clang codebase do not show any codepaths where this would work. Any
> help to shed light on how this is done would be useful.
>
> Point two is that I have started a patch to add a `getFastIntTypeByWidth`
> hook for Clang, which by default defers to `getLeastIntTypeByWidth`, to
> match the current behaviour. The comment in `DefineFastIntType` points to
> me having to update `stdint.h` to ensure these match, and any guidance
> about doing so would be appreciated. The patch is here:
> https://reviews.llvm.org/D80963
>
> I know psABIs are a minefield (to say nothing of preprocessors ;) ), so
> I'm keen to see if we can add this functionality for RISC-V without
> breaking any other architectures. psABIs are hard enough to verify at the
> best of times.
>
> Thanks In Advance,
>
> Sam
>
> --
> Sam Elliott
> Software Team Lead
> Senior Software Developer - LLVM and OpenTitan
> lowRISC CIC
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200601/a676b208/attachment.html>