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=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=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=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=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=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=116082
--- Comment #12 from uecker at gcc dot gnu.org ---
You are mistaken. Why not just try? https://godbolt.org/z/sEcxvMjG6
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 #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=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=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=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=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=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 #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 #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=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=118141
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
CC||uecker at gcc dot gnu.org
---
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=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=116082
--- Comment #6 from uecker at gcc dot gnu.org ---
This is not about padding. The string literal has a final NUL character and
yours then has two. The warning is about truncation of the final NUL character
in the string literal. So I think the wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119980
Bug ID: 119980
Summary: wrong aliasing decision with structure acces
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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=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=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 #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=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=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=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=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
--- 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=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=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=118061
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
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=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=120326
--- Comment #3 from uecker at gcc dot gnu.org ---
Those should not get the same TYPE_CANONICAL. tagged_types_tu_compatible_p
should be changed to detect this case which is due to different packing of bit
fields. It works correctly for this:
stru
201 - 240 of 240 matches
Mail list logo
