[Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[sjames at gcc dot gnu.org]

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

            Bug ID: 114930
           Summary: ICE in fld_incomplete_type_of when building libwebp
                    with -std=c23 -flto
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58093&action=edit
libwebpdecode_la-vp8l_dec.i.xz

```
$ gcc -c libwebpdecode_la-vp8l_dec.i -std=c23 -flto
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
In function ‘CopySmallPattern8b’:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:908:10:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  908 |   while ((uintptr_t)dst & 3) {
      |          ^
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
In function ‘CopySmallPattern32b’:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:977:7:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  977 |   if ((uintptr_t)dst & 4) {           // Align 'dst' to 8-bytes
boundary.
      |       ^
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
In function ‘CopyBlock32b’:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:994:36:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  994 |   if (dist <= 2 && length >= 4 && ((uintptr_t)dst & 3) == 0) {
      |                                    ^
during IPA pass: *free_lang_data
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
At top level:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:1744:1:
internal compiler error: in fld_incomplete_type_of, at
ipa-free-lang-data.cc:257
 1744 | }
      | ^
0x5564762f6448 fld_incomplete_type_of
       
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:257
0x5564778ff8fd fld_simplified_type
       
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:344
0x5564778ff8fd free_lang_data_in_type
       
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:439
0x556477fd53b0 free_lang_data_in_cgraph
       
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1072
0x556477fd53b0 free_lang_data
       
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1109
0x556477fd53b0 execute
       
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

[Bug ipa/114930] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[sjames at gcc dot gnu.org]

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

--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
reduced:
```
typedef struct WebPPicture WebPPicture;
typedef int (*WebPProgressHook)(const WebPPicture *);
WebPProgressHook progress_hook;
struct WebPPicture {
} WebPGetColorPalette(const struct WebPPicture *);
```

[Bug ipa/114930] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=114927

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sam James from comment #1)
> reduced:
> ```
> typedef struct WebPPicture WebPPicture;
> typedef int (*WebPProgressHook)(const WebPPicture *);
> WebPProgressHook progress_hook;
> struct WebPPicture {
> } WebPGetColorPalette(const struct WebPPicture *);
> ```

This looks almost the same issue as PR 114927.

[Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in                      |[14/15 regression] ICE in
                   |fld_incomplete_type_of when |fld_incomplete_type_of when
                   |building libwebp with       |building libwebp with
                   |-std=c23 -flto              |-std=c23 -flto

--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
c2x in GCC 13 was fine

[Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-checking,
                   |                            |ice-on-valid-code
   Target Milestone|---                         |14.0

[Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |14.2

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.

[Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

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

--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
This one is still an issue (unlike PR114927 which is fixed).

[Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Likely an issue in fld_incomplete_type_of with how C23 lays out types and/or
how we set up their canonical types.  What we try to do for LTO is to
turn pointer types to pointer types to pointer to "incomplete" type variants,
thus for arrays to [] and for structs to structs with no fields.

Somebody needs to see how it goes wrong, the assert makes sense and is required
for correctness.

[Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[uecker at gcc dot gnu.org]

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

uecker at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|ipa                         |c

--- Comment #7 from uecker at gcc dot gnu.org ---


This is a C FE bug because the update logic for c_update_type_canonical uses
check_qualified_type that - for some reason - decides that certain types are
not qualified versions of the original. This seems related to TYPE_DECLS. The
new verification code in the FE also detects these problems in similar
examples.

[Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-12
             Status|UNCONFIRMED                 |NEW

[Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:777cc6a01d1cf783a36d0fa67ab20f0312f35d7a

commit r15-1597-g777cc6a01d1cf783a36d0fa67ab20f0312f35d7a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jun 25 08:35:56 2024 +0200

    c: Fix ICE related to incomplete structures in C23 [PR114930]

    Here is a version of the c_update_type_canonical fixes which passed
    bootstrap/regtest.
    The non-trivial part is the handling of the case when
    build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x))
    returns a type with NULL TYPE_CANONICAL.  That should happen only
    if TYPE_CANONICAL (t) == t, because otherwise c_update_type_canonical
should
    have been already called on the other type.  c, the returned type, is
usually x
    and in that case it should have TYPE_CANONICAL set to itself, or worst
    for whatever reason x is not the right canonical type (say it has
attributes
    or whatever disqualifies it from check_qualified_type).  In that case
    either it finds some pre-existing type from the variant chain of t which
    is later in the chain and we haven't processed it yet (but then
    get_qualified_type moves it right after t in:
            /* Put the found variant at the head of the variant list so
               frequently searched variants get found faster.  The C++ FE
               benefits greatly from this.  */
            tree t = *tp;
            *tp = TYPE_NEXT_VARIANT (t);
            TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (mv);
            TYPE_NEXT_VARIANT (mv) = t;
            return t;
    optimization), or creates a fresh new type using build_variant_type_copy,
    which again places the new type right after t:
      /* Add the new type to the chain of variants of TYPE.  */
      TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
      TYPE_NEXT_VARIANT (m) = t;
      TYPE_MAIN_VARIANT (t) = m;
    At this point we want to make c its own canonical type (i.e. TYPE_CANONICAL
    (c) = c;), but also need to process pointers to it and only then return
back
    to processing x.  Processing the whole chain from c again could be costly,
    we could have hundreds of types in the chain already processed, and while
    the loop would just quickly skip them
      for (tree x = t, l = NULL_TREE; x; l = x, x = TYPE_NEXT_VARIANT (x))
        {
          if (x != t && TYPE_STRUCTURAL_EQUALITY_P (x))
    ...
          else if (x != t)
            continue;
    it feels costly.  So, this patch instead moves c from right after t
    to right before x in the chain (that shouldn't change anything, because
    clearly build_qualified_type didn't find any matches in the chain before
    x) and continues processing the c at that position, so should handle the
    x that encountered this in the next iteration.

    We could avoid some of the moving in the chain if we processed the chain
    twice, once deal only with x != t && TYPE_STRUCTURAL_EQUALITY_P (x)
    && TYPE_CANONICAL (t) == t && check_qualified_type (t, x, TYPE_QUALS (x))
    types (in that case set TYPE_CANONICAL (x) = x) and once the rest.  There
    is still the theoretical case where build_qualified_type would return
    a new type and in that case we are back to the moving the type around and
    needing to handle it though.

    2024-06-25  Jakub Jelinek  <jakub@redhat.com>
                Martin Uecker  <uecker@tugraz.at>

            PR c/114930
            PR c/115502
    gcc/c/
            * c-decl.cc (c_update_type_canonical): Assert t is main variant
            with 0 TYPE_QUALS.  Simplify and don't use check_qualified_type.
            Deal with the case where build_qualified_type returns
            TYPE_STRUCTURAL_EQUALITY_P type.
    gcc/testsuite/
            * gcc.dg/pr114574-1.c: Require lto effective target.
            * gcc.dg/pr114574-2.c: Likewise.
            * gcc.dg/pr114930.c: New test.
            * gcc.dg/pr115502.c: New test.