[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #1 from uecker at gcc dot gnu.org --- Created attachment 58246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58246=edit patch Candidate patch by setting TYPE_CANONICAL based on the underlying type.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #7 from uecker at gcc dot gnu.org --- PATCH v2 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652109.html
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #6 from uecker at gcc dot gnu.org --- But it shows that the logic is still not right for the case where all the final types should be int.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #5 from uecker at gcc dot gnu.org --- Right, included the wrong test... The conversion seems right, if we have a predefined type. For enums with fixed underlying type we then have a constraint violation if the value does not fit. This may have been the intention also here, but it is not entirely clear. I made an -Woverflow warning for now, so it behaves similar to other initialization of constants and a warning is all that is required here. If the final value ends up the same, the types are compatible so this part is then fine.
[Bug analyzer/114896] analyzer: false-positive with VLA (analyzer-out-of-bounds, CWE-121)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114896
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--- Comment #3 from uecker at gcc dot gnu.org ---
Minimal example:
void foo(void*);
int main(void)
{
unsigned int n;
foo();
int e[n] = { };
return e[n - 1];
}
https://godbolt.org/z/hYPqahYY8
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #2 from uecker at gcc dot gnu.org --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652093.html
[Bug c/114831] typeof doesn't evaluate expression when it has variably modified type in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114831 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-18 CC||uecker at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from uecker at gcc dot gnu.org --- Confirmed. We need to propagate C_TYPE_VARIABLY_MODIFIED correctly for address of an array-to-pointer-decay.
[Bug c/114927] [14/15 Regression] ICE when building Emacs with -std=c23 -flto (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927 uecker at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114574 --- Comment #3 from uecker at gcc dot gnu.org --- Seems something still needs to be done regarding function types when the TYPE_CANONICAL is set when completing the struct, see PR114574
[Bug c/114361] ICE with c23 related to completion of incomplete structure types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from uecker at gcc dot gnu.org --- Fixed.
[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #16 from uecker at gcc dot gnu.org --- Your example program is indeed not conforming and violates a constraint because you pass a pointer of type that can not be assigned to the type of the argument. So a diagnostic is required and a C compiler could also reject it. GCC is generous regarding differences in signedness in this case in default mode, but you would get a warning when mixing long* and int* for example. You need to pass "-pedantic" to get all warnings required by the C standard.
[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #13 from uecker at gcc dot gnu.org --- A couple of comments: In principle, those warnings are not false positives. The design of _Generic requires that the non-taken branches are valid in C, so some warnings are required by the C standard. We can tweak warnings (which we already did for some), but I do not think it is possible to solve all issues in this wa. There are different ways to work around this: One can work around using explicit casts and/or temporary values so that the code of all branches is always valid. It may be helpful to flatten multi-level _Generic to one level by matching an artificial function pointer type: #define foo(a, b) _Generic((void(*)(typeof(a), typeof(b)))0, void(*)(int, int): ...) In my opinion, and extension such as _Generic(x, int i: ... i ...); where i then has type int inside the branch would be useful.
[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 --- Comment #9 from uecker at gcc dot gnu.org --- x is - according to the C standard - always whatever it is in the controlling expression. Some warnings are then even required to be standard compliant. Note that this also does not have to be an identifier, but could be a complex expression. So there seems no simply algorithm for a compiler to do the right thing in general regarding warnings.
[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 --- Comment #7 from uecker at gcc dot gnu.org --- The fix suppresses certain warnings which are guarded by a flag, but it is not always clear whether a specific warning should be suppressed or not in dead code. You could also always add a cast. Fundamentally, the program is that _Generic is not ideally designed for this use case. One could consider an extension _Generic(x, int i: f(i), long l: g(l)); that allows referring to the first argument with the type it would have in each branch.
[Bug c/90253] no warning for cv-qualified selectors in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90253 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-14 CC||uecker at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from uecker at gcc dot gnu.org --- Confirmed. Note that typeof preserves qualifiers in C23. Clang has an extension for _Generic that allows the use of a typename, which allows testing for qualifiers more easily: https://godbolt.org/z/K5hGP9cYn
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #28 from uecker at gcc dot gnu.org --- I do not fully understand yet what happens for may_alias, but it if we later complete the struct with the may_alias attribute it seems we would also need to update the previously created pointer so that it has TYPE_REF_CAN_ALIAS_ALL. Setting TYPE_STRUCTURAL_EQUALITY for incomplete structs also for pre-C23 seems to fix the assertion failure, but I am not sure if this fixes the underlying bug.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #26 from uecker at gcc dot gnu.org ---
Note that not updating the types seems wrong also pre C23. PR114493 could be an
example of this:
typedef struct a a;
int c;
int f(a **);
struct __attribute__((__may_alias__)) a {};
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #10 from uecker at gcc dot gnu.org --- Yes, this makes sense. I will try this. (I tried this approach already but I did not get this work, probably because something I missed). Otherwise one could try setting TYPE_CANONICAL only based on the tag, which would then never need to change, but this would lose a lot of information. What consequences does it have to have the wrong TYPE_CANONICAL on pointers? I am asking because the current behavior also seems wrong because now TYPE_CANONICAL for complete and incomplete types may turn out to be different. Or am I missing something?
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #8 from uecker at gcc dot gnu.org --- If we do not care too much about TYPE_CANONICAL being correct in this case anyway, we could turn off the test and add a condition flag_isoc23 as a precaution in the FE to not risk any other regressions for pre C23. Otherwise we could revert the fix to PR114361 but this also does not seem ideal. diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc index f2083b9d96f..efdbe1a3bde 100644 --- a/gcc/c/c-decl.cc +++ b/gcc/c/c-decl.cc @@ -9722,7 +9722,8 @@ finish_struct (location_t loc, tree t, tree fieldlist, tree attributes, C_TYPE_VARIABLE_SIZE (x) = C_TYPE_VARIABLE_SIZE (t); C_TYPE_VARIABLY_MODIFIED (x) = C_TYPE_VARIABLY_MODIFIED (t); C_TYPE_INCOMPLETE_VARS (x) = NULL_TREE; - TYPE_CANONICAL (x) = TYPE_CANONICAL (t); + if (flag_isoc23) + TYPE_CANONICAL (x) = TYPE_CANONICAL (t); } /* Update type location to the one of the definition, instead of e.g. diff --git a/gcc/ipa-free-lang-data.cc b/gcc/ipa-free-lang-data.cc index 16ed55e2e5a..0b75f05fab3 100644 --- a/gcc/ipa-free-lang-data.cc +++ b/gcc/ipa-free-lang-data.cc @@ -254,8 +254,11 @@ fld_incomplete_type_of (tree t, class free_lang_data_d *fld) else first = build_reference_type_for_mode (t2, TYPE_MODE (t), TYPE_REF_CAN_ALIAS_ALL (t)); + // FIXME: temporarily decativated because of PR114493 +#if 0 gcc_assert (TYPE_CANONICAL (t2) != t2 && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); +#endif if (!fld->pset.add (first)) add_tree_to_fld_list (first, fld); return fld_type_variant (first, t, fld);
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #7 from uecker at gcc dot gnu.org --- What is strange is that not updating TYPE_CANONICAL also seems wrong even before C23, because then it seems we should be able to get pointers with different TYPE_CANONICAL which are compatible (to the incomplete and to the completed struct). But apparently this never did cause problems...
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #6 from uecker at gcc dot gnu.org ---
Hm, this is enough:
const struct S * x;
struct S {};
void f(const struct S **);
The TYPE_CANONICAL of the pointer type depends on TYPE_CANONICAL of the target.
So it seems if I set it for completed types the new pointer get a new
TYPE_CANONICAL while old pointers to the incomplete struct are not updated
which then somehow triggers the assertion (and is wrong).
[Bug c/114361] ICE with c23 related to completion of incomplete structure types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||uecker at gcc dot gnu.org Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #6 from uecker at gcc dot gnu.org --- Fixed for 14
[Bug c/46116] Allow passing of anonymous aggregates when signature matches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46116 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #5 from uecker at gcc dot gnu.org --- It requires a tag though as WG14 did not want to allow this for anonymous structs.
[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878 --- Comment #8 from uecker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) > (In reply to uecker from comment #6) > > My idea would be to explicitly add either traps or __builtin_unreachable > > whenever there is UB that can be checked for in the C FE, and not add > > sanitizer calls (that may return). Just a lightweight tool for safety that > > needs no run-time and and be activated in production because it is optimized > > well. > > Something that traps is -fsanitize=undefined -fsanitize-trap=undefined (or > selected sanitizers), that doesn't need any runtime. And it is still very > costly, it isn't lightweight, and it severely prevents optimizations. > Something that would add conditional __builtin_unreachable would be useless, > that is already implied from the operations. Sure, but -fsanitize=undefined -fsanitize-trap=undefined does optimize much worse than directly adding the overflow checks (as this and other examples show) and also sometimes does not have quite the ideal semantics because of upstream sanitizer library dependency. I wouldn't mind if it could be fixed but its complexity seems to make it unnecessary hard.
[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878 --- Comment #6 from uecker at gcc dot gnu.org --- My idea would be to explicitly add either traps or __builtin_unreachable whenever there is UB that can be checked for in the C FE, and not add sanitizer calls (that may return). Just a lightweight tool for safety that needs no run-time and and be activated in production because it is optimized well.
[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878 --- Comment #4 from uecker at gcc dot gnu.org --- Would it make sense to add the instrumentation earlier? Then it could be optimized as usual which may give better results. Just adding a test explicitly shows that this works: https://godbolt.org/z/av15nheTG Anyway, I am generally not super convinced about how the sanitizers (bloated library, unfortunate interaction with warnings, missing cases, poor optimization...) I am somewhat tempted to try putting a light-weight instrumentation directly into the C FE. That does not seem to hard and would avoid all those problems. But I am probably missing something And I have no idea whether something like this would be acceptable to GCC.
[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #2 from uecker at gcc dot gnu.org --- How does -fwrapv make sense if it is supposed to catch the overflow?
[Bug c/113688] verify_type fails for compatible structs with FAM in C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688 uecker at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-01-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c/113438] ICE (segfault) in dwarf2out_decl with -g -std=c23 on c23-tag-composite-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438 uecker at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from uecker at gcc dot gnu.org --- I filed PR113688 for the verify_type failures with -g. This bug is fixed on trunk.
[Bug c/113688] verify_type fails for compatible structs with FAM in C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688 uecker at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113438
[Bug c/113688] New: verify_type fails for compatible structs with FAM in C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688 Bug ID: 113688 Summary: verify_type fails for compatible structs with FAM in C23 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: uecker at gcc dot gnu.org Target Milestone: --- Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438#c1 FAIL: gcc.dg/gnu23-tag-1.c (internal compiler error: 'verify_type' failed) FAIL: gcc.dg/gnu23-tag-4.c (internal compiler error: 'verify_type' failed) FAIL: gcc.dg/gnu23-tag-alias-1.c (internal compiler error: 'verify_type' failed)
[Bug c/113492] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 uecker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/113438] ICE (segfault) in dwarf2out_decl with -g -std=c23 on c23-tag-composite-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438 --- Comment #4 from uecker at gcc dot gnu.org --- Created attachment 57194 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57194=edit preliminary patch
[Bug c/113438] ICE (segfault) in dwarf2out_decl with -g -std=c23 on c23-tag-composite-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438 uecker at gcc dot gnu.org changed: What|Removed |Added Target|aarch64-*-* | --- Comment #3 from uecker at gcc dot gnu.org --- Not aarch64 specific.
[Bug c/113492] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 --- Comment #11 from uecker at gcc dot gnu.org --- Created attachment 57175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57175=edit patch Untested patch.
[Bug c/113492] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 --- Comment #10 from uecker at gcc dot gnu.org --- Removing the assertion is enough to fix it. But the cause is strange. We somehow get two unsigned types in DECL_BIT_FIELD_TYPE which should be the same but are not, e.g: constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f6dad774738 precision:32 min max > constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f6dad622690 precision:32 min max pointer_to_this >
[Bug c/113492] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 --- Comment #9 from uecker at gcc dot gnu.org --- No need to dig it up, I believe you. I was just wondering.
[Bug c/113492] [14 Regression] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 --- Comment #6 from uecker at gcc dot gnu.org --- The point is that no existing code is broken by this because it was rejected previously and now this only affects very new C23 code using bit-fields in different structs that a declared in different ways and then only when using together -funsigned-bitfields. So it is an obscure corner case of an obscure corner case... But I will fix it anyway, soon I was just wondering why many similar bugs have a different rating... If this is just because nobody came around to categorize it, this makes sense.
[Bug c/113492] [14 Regression] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 --- Comment #4 from uecker at gcc dot gnu.org --- Yes, it is just weird because similar bugs for other new language features, e.g. an ICE for BitInt are not labeled as a regression and are P3.
[Bug c/113492] [14 Regression] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #2 from uecker at gcc dot gnu.org --- I agree that "int:3" with -funsigned-bitfields should produce a type which is compatible to one with "unsigned:3" and that forming a composite type has to work. I am not entirely sure this should be considered a regression as this C23 feature did not exist before (but was rejected and did not ICE). Anyway, I will look at this and post a patch. Thanks for reporting.
[Bug c/88737] RFE: Track ownership moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88737 --- Comment #10 from uecker at gcc dot gnu.org --- I would say it is rather likely that C will get something like this at some point. BTW: Any use of the pointer value after free as in comment #2 is UB.
[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939 uecker at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 CC||uecker at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/102558] missing warning comparing T[static N] to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from uecker at gcc dot gnu.org --- .
[Bug c/102558] missing warning comparing T[static N] to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558 uecker at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 CC||uecker at gcc dot gnu.org --- Comment #2 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/112840] feature request: warn on incorrect tagged union value access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112840
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--- Comment #2 from uecker at gcc dot gnu.org ---
I would go for a more generic feature where one can specify some invariant /
condition that needs be true when a member of a struct / union is accessed.
struct S {
enum T t;
union U {
int i [[gnu::guard(.t == I)]];
float f [[gnu::guard(.t == f)]];
} u;
};
[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 uecker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug lto/112716] LTO optimization with struct with variable size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #7 from uecker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #6)
> On Mon, 27 Nov 2023, muecker at gwdg dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
> >
> > --- Comment #5 from Martin Uecker ---
> > It works (and is required to work) for other types, e.g.
> >
> > [[gnu::noinline,gnu::noipa]]
> > int foo(void *p, void *q)
> > {
> > int n = 5;
> > int (*p2)[n] = p;
> > (*p2)[0] = 1;
> > bar(q);
> > return (*p2)[0];
> > }
> >
> > void bar(void* q)
> > {
> > int n = 5;
> > int (*q2)[n] = q;
> > (*q2)[0] = 2;
> > }
> >
> > One could argue that there is a weaker requirement for having an object of
> > type
> > int[n] present than for struct { int x[n]; } because we do not access the
> > array
> > directly but it decays to a pointer. (but then, other languages have array
> > assignment, so why does the middle-end care about this C peculiarity?)
>
> So in theory we could disregard the VLA-sized components for TBAA
> which would make the access behaved as if it were a int * indirect access.
> I think if you write it as array as above that's already what happens.
What does "disregard the VLA-sized component" mean?
For full interoperability I think one either has to assign
equivalence classes for structs by ignoring the sizes of all
fields of array type (not just VLA) and also the offsets
for the following struct members, or, alternately, one has
to give alias set 0 to structs with VLA fields. The later
seems preferable and is what I have included in the current
version of my patch for C23 for structs with VLA fields
(but we could also decide to not support full ISO C rules for
such structs, of course)
>
> Note that even without LTO when you enable inlining you'd expose two
> different structures with two different alias-sets, possibly leading
> to wrong-code (look at the RTL expansion dump and check alias-sets).
Yes, for pre C23 this is true for all structs even without VLA.
But for C23 this changes.
The main case where the GNU extension is interesting and useful is
when the VLA field is at the end. So at least for this case it would
be nice to have a solution.
>
> As said, for arrays it probably works as-is since these gets the alias
> set of the component.
>
> > There is also no indication in documentation that structs with variable size
> > follow different rules than conventional structs. So my preference would
> > be
> > to fix this somehow. Otherwise we should document this as a limitation.
>
> Local declared structs in principle follow the same logic (but they
> get promoted "global" due to implementation details I think).
[Bug lto/112716] LTO optimization with struct of variable ssize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #2 from uecker at gcc dot gnu.org --- . Inside the same TU there are different types. But note that this is across TUs where the structs with same tag and and compatible members are supposed to be compatible (they could come from a shared header). I would assume these rules hold also for the GNU extension. In C23 the structs will be compatible also inside a TU (without GNU extensions, but I I think the same rules should then also apply to structs with the GNU extension).
[Bug c/112571] ICE with nested redefinition of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571
--- Comment #1 from uecker at gcc dot gnu.org ---
Another example:
enum X : typeof(enum X { A });
[Bug c/112571] New: ICE with nested redefinition of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571
Bug ID: 112571
Summary: ICE with nested redefinition of enum
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: uecker at gcc dot gnu.org
Target Milestone: ---
The following code ICEs on trunk but not on 13.2 with -std=c2x
typedef __SIZE_TYPE__ size_t;
enum h : typeof (enum h { D }) { D };
https://godbolt.org/z/cd1o75M3W
[Bug testsuite/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 --- Comment #4 from uecker at gcc dot gnu.org --- I was a bit busy. My idea would have been to split the file up into warnings for Wnonnull and Wstringop. Your patch should work though (but I can't approve).
[Bug c/107557] [12/13/14 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #13 from uecker at gcc dot gnu.org --- I think we should backport these changes to 12 and 13. But there is a case which now breaks with these in GCC 14 (PR112488). So I would like to look at this and fix it first.
[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488
--- Comment #7 from uecker at gcc dot gnu.org ---
And this example also fails with this fix:
extern void abort(void);
int test(int *n, struct T { char a[*n], b[*n]; }*) {
return sizeof(struct T) - sizeof(struct T);
}
void f1(int *p) {
if (test(p, 0)) abort();
}
[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 --- Comment #6 from uecker at gcc dot gnu.org --- So adding back the DECL_EXPR ( TYPE_DECL (t) ) in finish_struct fixes it, but I am not sure this is completely correct...
[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 --- Comment #5 from uecker at gcc dot gnu.org --- Oh well, more to fix. I wonder whether we could validate the trees created by the front-end FE somehow.
[Bug c/110815] [static] not as useful as the nonnull attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||uecker at gcc dot gnu.org --- Comment #4 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/112428] Wnonnull outputs wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from uecker at gcc dot gnu.org --- Fixed on trunk because the specific incorrect warning version is removed and replaced by the more generic but correct version using the nonnull attribute.
[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Bug 95507 depends on bug 112428, which changed state. Bug 112428 Summary: Wnonnull outputs wrong type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 uecker at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98541 Last reconfirmed||2023-11-07 Status|UNCONFIRMED |NEW --- Comment #1 from uecker at gcc dot gnu.org --- Confirmed. I think adding -Wstringop-overflow= to the test might fix it. It is just some test which is wrong for 32 bit targets and somehow this problems appeared now due to an unrelated change. I will try this and submit a patch.
[Bug c/98541] warning with -Wnonnull for array parameter with bound > 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98541 uecker at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.0 Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |14.0 CC||uecker at gcc dot gnu.org --- Comment #5 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/112377] Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 uecker at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/112377] Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 uecker at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-11-04 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from uecker at gcc dot gnu.org --- Confirmed. But this change would not be enough. The warning is implemented in the C front-end which which is separate from the C++ FE. Possibly, the code for the warning could be shared, but I do not know.
[Bug c/105660] [12 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105660 uecker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||uecker at gcc dot gnu.org Resolution|--- |FIXED --- Comment #15 from uecker at gcc dot gnu.org --- fixed for 12.4 (and 13)
[Bug c/110703] Incorrect "-Wfloat-conversion" diagnostic with _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110703 uecker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||uecker at gcc dot gnu.org Known to fail||4.9.0 Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #4 from uecker at gcc dot gnu.org --- fixed on trunk.
[Bug c/109450] VLA struct definition vs use in the function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from uecker at gcc dot gnu.org --- fixed on trunk.
[Bug c/109450] VLA struct definition vs use in the function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org Target Milestone|--- |14.0 --- Comment #5 from uecker at gcc dot gnu.org --- fixed on trunk.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 109970, which changed state. Bug 109970 Summary: -Wstringop-overflow should work with parameter forward declarations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c/109970] -Wstringop-overflow should work with parameter forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970 uecker at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 CC||uecker at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from uecker at gcc dot gnu.org --- fixed on trunk.
[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |14.0 Status|NEW |RESOLVED Known to fail||6.0 --- Comment #10 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/91038] ICE with VLA type and statement expression (gimplify_var_or_parm_decl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91038 uecker at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Known to fail||10.0 CC||uecker at gcc dot gnu.org Target Milestone|--- |12.4 Status|NEW |RESOLVED --- Comment #5 from uecker at gcc dot gnu.org --- Fixed.
[Bug c/68193] _Generic -Woverflow false alarm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193 uecker at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||uecker at gcc dot gnu.org Known to fail||4.9.0 Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #9 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 uecker at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 Known to fail||4.9.0 CC||uecker at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/101604] [meta-bug] bogus/missing -Wvla-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604 Bug 101604 depends on bug 98536, which changed state. Bug 98536 Summary: warning with -Wvla-parameter for unspecified bound getting specified later https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98536 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c/98536] warning with -Wvla-parameter for unspecified bound getting specified later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98536 uecker at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.1.0 Target Milestone|--- |14.0 CC||uecker at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/84510] C front-end does not utilise -Wuseless-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84510 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED CC||uecker at gcc dot gnu.org Known to fail||5.4.0 --- Comment #4 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/111708] Calling external global function instead of local static function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||uecker at gcc dot gnu.org Known to work||14.0 Resolution|--- |FIXED Target Milestone|--- |14.0 Known to fail||4.1.2 --- Comment #10 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug ipa/96503] attribute alloc_size effect lost after inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-11-03
