--- Comment #9 from falk at debian dot org 2007-07-25 08:24 ---
(In reply to comment #8)
> You may only access union members through the union, not through other
> pointers.
Where is this documented? I thought it should be in extend.texi, but I couldn't
find it...
--
http://gcc.gnu
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-24 12:09 ---
You may only access union members through the union, not through other
pointers.
GCC is perfectly valid in caching n->next in the first example. So, for
comment #4, it is true that &u.a.n.next == &u.b.n.prev, but yo
--- Comment #7 from falk at debian dot org 2007-07-23 14:17 ---
(In reply to comment #6)
> This program demonstrates the problem, it creates different output depending
> on
> if compiled with or without optimisation.
This does not demonstrate the problem, since your code has undefined
--- Comment #6 from vogel at pi2 dot physik dot uni-erlangen dot de
2007-07-23 10:08 ---
This program demonstrates the problem, it creates different output depending on
if compiled with or without optimisation.
Without optimisation, n->next is not cached:
n->next = 0xbfb01af0
n->next =
--- Comment #5 from falk at debian dot org 2007-07-22 23:19 ---
Well, certainly not legal in C, since there you may only access the element of
a union last written to. However, in GNU C, other accesses are allowed.
--
falk at debian dot org changed:
What|Removed
--- Comment #4 from felix-gcc at fefe dot de 2007-07-22 23:08 ---
Falk:
union {
struct {
void* unused;
struct node n;
} a;
struct node b;
} u;
Then &u.a.n.next == &u.b.n.prev;
Artificial? Sure. But legal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from falk at debian dot org 2007-07-22 23:01 ---
Can you give an example how n->next->next->prev and n->next might be at the
same address? I don't see any legal way to achieve that.
And FWIW, DEC C also optimizes like gcc does.
--
falk at debian dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |middle-end
h
