https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
Sam James changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot
gnu.org
R
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=117490
--- Comment #10 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:8b02cc9a4f2b8db48da2a3460655b062eaa147ba
commit r15-5470-g8b02cc9a4f2b8db48da2a3460655b062eaa147ba
Author: Martin Uecker
Date:
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=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=117490
--- Comment #7 from uecker at gcc dot gnu.org ---
Created attachment 59568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59568&action=edit
patch for pre-C23
Use C23 TYPE_CANONICAL logic also for earlier language modes. There a couple of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #6 from uecker at gcc dot gnu.org ---
Created attachment 59567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59567&action=edit
patch for C23
Tentative patch to fix this for C23.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #5 from Martin Uecker ---
Am Freitag, dem 08.11.2024 um 14:22 + schrieb rguenth at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
>
> Richard Biener changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #3 from uecker at gcc dot gnu.org ---
Ah, your are right. The declared type rules makes it valid. I forgot about it
because it is never explicitly used for anything, but here it makes a
difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #2 from keinfluegeltier at posteo dot de ---
The aliasing rule in ยง6.5.1 does not forbid the access if the lvalue used has
"_a type compatible with the effective type of the object_".
The effective type of `x` is the declared one, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #1 from uecker at gcc dot gnu.org ---
I believe the optimization is valid because what is relevant are the types used
for the accesses in 'f2' so 's1' and 's2_alt' which are not compatible with
each other. The type in the other TU is
12 matches
Mail list logo
