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?
