https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105660
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110703
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
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|
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
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|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84510
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target
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
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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
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/bugzilla/show_bug.cgi?id=112377
uecker at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-11-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377
uecker at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |enhancement
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|---
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://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
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
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
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.
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
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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|
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
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
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
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/bugzilla/show_bug.cgi?id=113492
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=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
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
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.
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.
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.
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
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>
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).
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
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 });
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...
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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.
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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|
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
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
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
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
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 {};
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
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
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|
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
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
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.
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.
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
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
76 matches
Mail list logo
