https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #34 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a39983bf58d3097c472252f6989d19b60909dd9a
commit r14-10045-ga39983bf58d3097c472252f6989d19b60909dd9a
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #33 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #32)
> Ah, but get_alias_set has quite special handling of pointers, it finds the
> ultimately pointed type and uses TYPE_MAIN_VARIANT for it, so it actually
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #32 from Jakub Jelinek ---
Ah, but get_alias_set has quite special handling of pointers, it finds the
ultimately pointed type and uses TYPE_MAIN_VARIANT for it, so it actually
ignores TYPE_CANONICAL of the pointer type itself for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #31 from Jakub Jelinek ---
I've tried to construct a wrong-code testcase, but so far haven't been
successful.
In e.g.
struct S { int s; } s;
struct T { long l; } t;
const struct S *
foo (const struct S **p, const struct T **q)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #30 from Martin Uecker ---
Am Donnerstag, dem 18.04.2024 um 11:57 + schrieb jakub at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
>
> --- Comment #29 from Jakub Jelinek ---
> (In reply to uecker from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #29 from Jakub Jelinek ---
(In reply to uecker from comment #28)
> 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
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=114574
--- Comment #27 from Jakub Jelinek ---
(In reply to uecker from comment #26)
> 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
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 #25 from Jakub Jelinek ---
Created attachment 57935
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57935=edit
gcc14-pr114574.patch
What about this patch then? So far just make check-gcc -j32 checked (though in
a version that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #23 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:8057f9aa1f7e70490064de796d7a8d42d446caf8
commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #22 from Jakub Jelinek ---
BTW, wonder if it wouldn't be desirable to revert the PR114361 patch until this
is sorted out, or at least limit the effects of that patch to flag_isoc23 and
using multiple types with the same tag and same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #21 from Jakub Jelinek ---
Why? That is already set by
TYPE_CANONICAL (t) = *e;
else
{
TYPE_CANONICAL (t) = t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #20 from Martin Uecker ---
(In reply to Martin Uecker from comment #18)
> >
> > + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> > As has been discussed, this is wrong, it should have been
> > TYPE_CANONICAL (x) =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #19 from Jakub Jelinek ---
(In reply to Martin Uecker from comment #18)
> I am just looking at a version that would have changed the condition to:
>
> if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #18 from Martin Uecker ---
>
> + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> As has been discussed, this is wrong, it should have been
> TYPE_CANONICAL (x) = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS
> (x));
> or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #17 from Jakub Jelinek ---
Some comments:
+ else
+{
+ TYPE_CANONICAL (t) = t;
+}
The formatting here is wrong, TYPE_CANONICAL is indented too much, but we also
don't put a single statement between {}s, so just
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Martin Uecker changed:
What|Removed |Added
Attachment #57874|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #15 from Martin Uecker ---
Created attachment 57874
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57874=edit
patch
Tentative patch for the fix that makes the incomplete types have structural
equivalence at the beginning and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #14 from Martin Uecker ---
(In reply to Jakub Jelinek from comment #12)
> Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
> TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
> seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #12 from Jakub Jelinek ---
Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
seems c-typeck.cc doesn't actually use that, so it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Richard Biener changed:
What|Removed |Added
Keywords||lto
--- Comment #11 from Richard
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=114574
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
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 #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 #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 #5 from Jakub Jelinek ---
Oops, return stmt missing:
struct S foo (const struct S *);
struct S {};
struct S bar (const struct S **) { return (struct S) {}; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #4 from Jakub Jelinek ---
Slightly cleaned up testcase:
struct S foo (const struct S *);
struct S {};
struct S bar (const struct S **) {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Summary|[14 regression]
34 matches
Mail list logo
