[Bug middle-end/89270] [9/10 regression] AVR ICE: verify_gimple failed

[Bug middle-end/89270] [9/10 regression] AVR ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.3                         |9.4

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 9.3.0 has been released, adjusting target milestone.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |saaadhu at gcc dot gnu.org

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 91354 has been marked as a duplicate of this bug. ***

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

[rguenth at gcc dot 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.

[Bug c/89270] [11/12/13/14 regression] AVR ICE: verify_gimple failed

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:4dd02d62abd76a69f65d9f3fed6febeed53fc90a

commit r14-6134-g4dd02d62abd76a69f65d9f3fed6febeed53fc90a
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Dec 4 14:03:37 2023 +0100

    c/89270 - honor registered_builtin_types in type_for_size

    The following fixes the intermediate conversions inserted by
    convert_to_integer when facing address-spaces and converts
    to their effective [u]intptr_t when they are registered_builtin_types
    by considering those also from c_common_type_for_size and not
    only from c_common_type_for_mode.

            PR c/89270
    gcc/c-family/
            * c-common.cc (c_common_type_for_size): Consider
            registered_builtin_types.

    gcc/testsuite/
            * gcc.target/avr/pr89270.c: New testcase.

[Bug target/89270] [11/12/13 regression] AVR ICE: verify_gimple failed

[rguenth at gcc dot 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|rguenth at gcc dot gnu.org         |unassigned at gcc dot gnu.org
      Known to work|                            |14.0
             Status|ASSIGNED                    |NEW
            Summary|[11/12/13/14 regression]    |[11/12/13 regression] AVR
                   |AVR ICE: verify_gimple      |ICE: verify_gimple failed
                   |failed                      |
          Component|c                           |target

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.  Joseph correctly mentioned that iff AVR would define
__int24 using INT_N in avr-modes.def the issue would have been mitigated as
well
(that's a comparatively "modern" way of registering additional integer types).

So it's really also a target issue.

I'm not planning to backport this frontend change given a more targeted fix
would be available.