https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
CC| |jsm28 at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2023-12-04
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We have a NOP_EXPR from the 24bit pointer __memx address-space
to long int (32bit). That's an extension and we don't know how to do that
since POINTERS_EXTEND_UNSIGNED is not defined for AVR. Note that
for GIMPLE verification the exception would be
#if defined(POINTERS_EXTEND_UNSIGNED)
|| (TYPE_MODE (rhs1_type) == ptr_mode
&& (TYPE_PRECISION (lhs_type)
== BITS_PER_WORD /* word_mode */
|| (TYPE_PRECISION (lhs_type)
== GET_MODE_PRECISION (Pmode))))
#endif
but that's currently written without address-spaces in mind (because
POINTERS_EXTEND_UNSIGNED is defined without address-spaces in mind).
I think the "bug" is that the C frontend emits
extern const <address-space-7> unsigned char __data_load_end;
__uint24 top = (__uint24) (long int) &__data_load_end;
so it inserts the widening to 'long int' here. And that's the fault of
convert.cc:convert_to_integer_1 which does
/* Convert to an unsigned integer of the correct width first, and from
there widen/truncate to the required type. Some targets support the
coexistence of multiple valid pointer sizes, so fetch the one we need
from the type. */
if (!dofold)
return build1 (CONVERT_EXPR, type, expr);
expr = fold_build1 (CONVERT_EXPR,
lang_hooks.types.type_for_size
(TYPE_PRECISION (intype), 0),
expr);
return fold_convert (type, expr);
using type_for_mode would have yielded the __int24 type here.
The code is more or less present since the original version of convert.c
I'd argue the most correct way to deal with this is to _remove_ the
intermediate conversion done by convert.c since it only papers over
possible user errors? The C standard says the only supported conversion
is to/from [u]intptr_t, that's probably what the above tried to do.
But then it looks like it doesn't achieve its intent.
Now, c_common_type_for_size doesn't handle registered_builtin_types
like c_common_type_for_mode does, so extending that to cover these
fixes the issue as well.
