[Bug middle-end/89270] [11/12/13/14 regression] AVR ICE: verify_gimple failed

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.