* [Bug ipa/114930] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
@ 2024-05-03 1:40 ` sjames at gcc dot gnu.org
2024-05-03 1:41 ` pinskia at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-05-03 1:40 UTC (permalink / raw)
To: gcc-bugs
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 *);
```
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug ipa/114930] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
2024-05-03 1:40 ` [Bug ipa/114930] " sjames at gcc dot gnu.org
@ 2024-05-03 1:41 ` pinskia at gcc dot gnu.org
2024-05-03 2:55 ` [Bug ipa/114930] [14/15 regression] " sjames at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-03 1:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
2024-05-03 1:40 ` [Bug ipa/114930] " sjames at gcc dot gnu.org
2024-05-03 1:41 ` pinskia at gcc dot gnu.org
@ 2024-05-03 2:55 ` sjames at gcc dot gnu.org
2024-05-03 6:32 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-05-03 2:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
` (2 preceding siblings ...)
2024-05-03 2:55 ` [Bug ipa/114930] [14/15 regression] " sjames at gcc dot gnu.org
@ 2024-05-03 6:32 ` rguenth at gcc dot gnu.org
2024-05-07 7:46 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-03 6:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
` (3 preceding siblings ...)
2024-05-03 6:32 ` rguenth at gcc dot gnu.org
@ 2024-05-07 7:46 ` rguenth at gcc dot gnu.org
2024-05-18 15:44 ` sjames at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-07 7:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
` (4 preceding siblings ...)
2024-05-07 7:46 ` rguenth at gcc dot gnu.org
@ 2024-05-18 15:44 ` sjames at gcc dot gnu.org
2024-05-21 8:50 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-05-18 15:44 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
` (5 preceding siblings ...)
2024-05-18 15:44 ` sjames at gcc dot gnu.org
@ 2024-05-21 8:50 ` rguenth at gcc dot gnu.org
2024-06-02 10:16 ` [Bug c/114930] " uecker at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-21 8:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
` (6 preceding siblings ...)
2024-05-21 8:50 ` rguenth at gcc dot gnu.org
@ 2024-06-02 10:16 ` uecker at gcc dot gnu.org
2024-06-12 14:25 ` sjames at gcc dot gnu.org
2024-06-25 6:37 ` cvs-commit at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: uecker at gcc dot gnu.org @ 2024-06-02 10:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
` (7 preceding siblings ...)
2024-06-02 10:16 ` [Bug c/114930] " uecker at gcc dot gnu.org
@ 2024-06-12 14:25 ` sjames at gcc dot gnu.org
2024-06-25 6:37 ` cvs-commit at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-06-12 14:25 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
2024-05-03 1:19 [Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto sjames at gcc dot gnu.org
` (8 preceding siblings ...)
2024-06-12 14:25 ` sjames at gcc dot gnu.org
@ 2024-06-25 6:37 ` cvs-commit at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-06-25 6:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread