https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119842
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
--- Comment #13 from uecker at gcc dot gnu.org ---
FWIW, when I restore my patch on GCC-14 and add the size check to
useless_type_conversion_p, this then fixes the Ada test case.
diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
index 0477c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
--- Comment #11 from uecker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #10)
> On Tue, 15 Apr 2025, uecker at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
> >
> > --- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
--- Comment #9 from uecker at gcc dot gnu.org ---
If the problem is that useless_type_conversion_p should not return true for
certain types with the same TYPE_CANONICAL, shouldn't we simply add back the
test for the size of the FAM here to usel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
--- Comment #6 from uecker at gcc dot gnu.org ---
Maybe something like that will do?
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 8c420f22976..fb1216fe808 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -10303,6 +10303,7 @@ finish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #35 from uecker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #34)
> > Those aliasing bugs are very annoying though and I think one reason people
> > who care about correctness / reliability tend to use -fno-strict-al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #33 from uecker at gcc dot gnu.org ---
Those aliasing bugs are very annoying though and I think one reason people who
care about correctness / reliability tend to use -fno-strict-alasing. It would
be nice to get this sorted out inste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #32 from uecker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #31)
> On Mon, 14 Apr 2025, ebotcazou at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
> >
> > --- Comment #30 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #28 from uecker at gcc dot gnu.org ---
I am not sure alias set zero is a solution because it seems you would have to
make many types have set zero to be correct. Capturing the equivalence classes
using TYPA_CANONICAL seems a sound a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #29 from uecker at gcc dot gnu.org ---
Note that this is not directly related to C23 changes. C23 changes reuse the
across TU rules also inside TU. But here the problem is that the across TU
aliasing was already broken in some corne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #19 from uecker at gcc dot gnu.org ---
We could add an optional flag and see? There are also many users who would like
to have this as they use volatile to suppress unwanted code motion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #22 from uecker at gcc dot gnu.org ---
Or in other words, the correct way is to set TYPE_CANONICAL to the same type
for all types in the same equivalence classes of compatible types. If
compatible is not an equivalence relationship,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #21 from uecker at gcc dot gnu.org ---
(In reply to uecker from comment #20)
> This was based on a discussion with Richard. TYPE_CANONICAL is used for
> aliasing decisions and the FE must set it to from equivalence classes for
> type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #20 from uecker at gcc dot gnu.org ---
This was based on a discussion with Richard. TYPE_CANONICAL is used for
aliasing decisions and the FE must set it to from equivalence classes for types
that are
compatible. In C, the types
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #17 from uecker at gcc dot gnu.org ---
(BTW: Any idea why the preceding commit does not appear in bugzilla?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #15 from uecker at gcc dot gnu.org ---
It fixes a regression (but maybe I should have kept this in the title until the
release). Still, if it causes too much trouble, we can revert it. But let me
understand the issue first. What i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93010
uecker at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2025-04-12
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93010
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
--- Comment #12 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680232.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
uecker at gcc dot gnu.org changed:
What|Removed |Added
Attachment #61004|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
--- Comment #10 from uecker at gcc dot gnu.org ---
... or actually, it is wrong in a subtle way ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
--- Comment #7 from uecker at gcc dot gnu.org ---
You also need to add -std=gnu23. The test as written does not fail.
In any case, I add those assertions to make some assumptions that are made in C
FE explicit. That this occasionally brings som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
uecker at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
--- Comment #3 from uecker at gcc dot gnu.org ---
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index aaf8e54416a..cfe72028c6d 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -1813,10 +1813,13 @@ tagged_types_tu_compatible_p (const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
--- Comment #2 from uecker at gcc dot gnu.org ---
add_decl_expr adds these TYPE_DECLS, I think it is sufficient to relax the
assertion for this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119585
Bug ID: 119585
Summary: counted_by in redefined structs.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
Bug 114723 depends on bug 113688, which changed state.
Bug 113688 Summary: verify_type fails for compatible structs with FAM in C23,
builtin-sprintf-warn-1.c and gnu23-tag-1.c with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119173
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119526
uecker at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119526
Bug ID: 119526
Summary: standard attributes should be preserved in
redeclarations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117806
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70930
uecker at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116284
uecker at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117245
uecker at gcc dot gnu.org changed:
What|Removed |Added
Summary|[13/14 Regression] ICE: |[13 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117145
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #19 from uecker at gcc dot gnu.org ---
(In reply to Hime Haieto from comment #17)
> I'm not entirely sure what I should be doing/commenting on at the moment
> considering that the current patches are clearly marked as being
> temporar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
uecker at gcc dot gnu.org changed:
What|Removed |Added
Attachment #60628|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119416
Bug ID: 119416
Summary: spurious store with null sanitizer
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118061
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118061
uecker at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from ue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #15 from uecker at gcc dot gnu.org ---
PATCH 1: https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677746.html
PATCH 2: https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677747.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119251
--- Comment #5 from uecker at gcc dot gnu.org ---
Maybe a more targeted warning would make sense, e.g. taking the address of a
compound literal inside ({ }). Maybe even checking whether it escapes? And/or
only inside macros?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119251
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119173
Bug ID: 119173
Summary: Documentation for -Wzero-as-null-pointer-constant
should move to Warning Options
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #13 from uecker at gcc dot gnu.org ---
Yes thanks, I need to analyze this a bit more but I narrowed the problem down
to this.
What do you mean by "my non-toy sources compiles/works correctly now"? There
should be no existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #11 from uecker at gcc dot gnu.org ---
Created attachment 60628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60628&action=edit
patch
Tentative fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118061
--- Comment #3 from uecker at gcc dot gnu.org ---
Created attachment 60627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60627&action=edit
patch
Patch adding checking for errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #9 from uecker at gcc dot gnu.org ---
Test case:
typedef struct q { int x; } q_t;
struct q { int x; };
typedef struct q { int x; } q_t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #3 from uecker at gcc dot gnu.org ---
Note that rules for unions were changed after N3037.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118729
--- Comment #2 from uecker at gcc dot gnu.org ---
A broken read should be fine, as write would only access the part that was
read. I agree that for I/O it probably does not matter, but for other cases it
might.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118729
Bug ID: 118729
Summary: dead store elimination with function attributes for
read / write and similar functions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866
uecker at gcc dot gnu.org changed:
What|Removed |Added
Summary|[15 regression] Confusing |Confusing 'expected ... but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118325
Bug ID: 118325
Summary: ICE with nested function and non-local jump
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
--- Comment #5 from uecker at gcc dot gnu.org ---
I am not sure Martin S still reads these emails.
I also do not understand the code fully, but you could try something like this:
/* Use the SSA_NAME_VAR that was determined above to see if it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866
--- Comment #6 from uecker at gcc dot gnu.org ---
Created attachment 59852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59852&action=edit
patch
preliminary patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117652
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
uecker at gcc dot gnu.org changed:
What|Removed |Added
Summary|[14/15 Regression] |[14] verify_type fails for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115424
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116194
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112840
--- Comment #4 from uecker at gcc dot gnu.org ---
*** Bug 116194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117806
--- Comment #6 from uecker at gcc dot gnu.org ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117828
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117828
uecker at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from ue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117828
--- Comment #3 from uecker at gcc dot gnu.org ---
A check is needed in tagged_tu_types_compatible_p.
In C23 the following needs to be rejected:
struct foo {
struct {
int Reserved : 32;
}
};
struct foo {
struct {
int Reserved;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117810
--- Comment #3 from uecker at gcc dot gnu.org ---
Not sure what this has to do with constexpr, but allowing expressions should be
possible. WG21 is working on contracts to specify pre-. and postprocessing, but
I am not sure advanced this is.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117810
uecker at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
--- Comment #6 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669873.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
--- Comment #5 from uecker at gcc dot gnu.org ---
Preliminary patch (but does not cover all similar cases):
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 1da06c7d4e9..453b56cc37c 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -13977,6 +13977,9 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
--- Comment #4 from uecker at gcc dot gnu.org ---
This seems to be the same underlying issue with FAMs now exposed by the fix to
PR117490.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117719
Bug ID: 117719
Summary: Wdangling-pointer false positive for store to heap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #11 from uecker at gcc dot gnu.org ---
Fixed on trunk and for C23 only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059
--- Comment #12 from uecker at gcc dot gnu.org ---
I filed PR117687 for the other cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117687
--- Comment #1 from uecker at gcc dot gnu.org ---
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059#c10 the
warning should be enhanced to cover these cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117687
Bug ID: 117687
Summary: Wzero-as-nullpointer-constant should warn for zeros of
type bool, enum, and _BitInt
Product: gcc
Version: unknown
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
uecker at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-11-16
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #8 from uecker at gcc dot gnu.org ---
Hm, although in this case
```
struct S{int x,y[1];}*a;
int main(void){
struct S{int x,y[];} *b; // Add = a to get an error;
}
```
the types are not compatible but we still run into this i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117548
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117548
--- Comment #3 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668998.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #13 from uecker at gcc dot gnu.org ---
Tests were fixed in PR115545
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117548
--- Comment #2 from uecker at gcc dot gnu.org ---
Created attachment 59599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59599&action=edit
patch
Tentative patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117548
uecker at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059
--- Comment #5 from uecker at gcc dot gnu.org ---
While I personally would like to have this warning in -Wall, and also want to
see 0 as null pointer constant be deprecated, I think it is too early. At this
time, it is not deprecated (I have a d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419
uecker at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://linaro.atlassian.ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #8 from uecker at gcc dot gnu.org ---
Some tests for pointers to struct w and w/o tag and also with one incomplete
struct.
https://godbolt.org/z/ePcoTTeMq
#if 1
#define tag
#endif
int f2(void *x, void *y)
{
typedef struct tag { i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
--- Comment #12 from uecker at gcc dot gnu.org ---
UBSan and Wstringop-overflow have completely separate implementations (I wish
there was a more sysematic approach...).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059
uecker at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from ue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
1 - 100 of 235 matches
Mail list logo
