Defining __uint24

[Georg-Johann Lay]

Am 15.01.25 um 20:41 schrieb Jonathan Wakely:
> On Wed, 15 Jan 2025 at 17:17, Georg-Johann Lay via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> What's the recommended way to built-in define types like __uint24 ?
>>
>> Since v4.8, the avr backend has:
>>
>> avr-modes.def:
>>     FRACTIONAL_INT_MODE (PSI, 24, 3);
>>
>> avr.cc:
>>     tree int24_type  = make_signed_type (GET_MODE_BITSIZE (PSImode));
>>     tree uint24_type = make_unsigned_type (GET_MODE_BITSIZE (PSImode));
>>     lang_hooks.types.register_builtin_type (int24_type, "__int24");
>>     lang_hooks.types.register_builtin_type (uint24_type, "__uint24");
>>
>> Which
>>
>> 1) Doesn't support [un]signed __int24.
>>
>> 2) May run into ICEs like:
>>     FAIL: gcc.target/avr/torture/int24-mul.c   -O3 -g
>>     (internal compiler error: in add_dwarf_attr, at dwarf2out.cc:4483)
>>     FAIL: gcc.target/avr/torture/pr109907-2.c   -O3 -g
>>     (internal compiler error: in decompose, at rtl.h:2312)
>>
>> 3) __GLIBCXX_TYPE_INT_N_0 isn't defined (or has to be done by hand).
>>     Though libc++ relies on 1).
>>
>>
>> Using
>>
>> avr-modes.def:
>>     FRACTIONAL_INT_MODE (PSI, 24, 3);
>>     INT_N (PSI, 24);
>>
>> solved at least 1) and 3), however it adds new FAILs due to:
>>
>> 4) error: ISO C does not support '__int24' types [-Wpedantic]
> 
> This pedwarn is correct, so I'm not sure why it's a problem. If you
> don't want warnings about non-standard extensions, don't use
> -pedantic-errors.

The point is that I don't pedwarn explicitly, that's how the
testsuite works.  What I am seeing is that with INT_N, many
tests in, say, avr.exp are failing which didn't fail with the
old definition of __int24.  Similar will happen in user land,
which I'd like to avoid.

Johann


>> Is there a backwards compatible way to provide [un]signed __inz24
>> that also works with older revisions of C without raising 4) ?
> 
> This has nothing to do with "older revisions of C", does it?