https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24332
Bug 24332 depends on bug 25140, which changed state.
Bug 25140 Summary: aliases, including weakref, break alias analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24332
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24332
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-09 16:51 ---
If we'd have a symbol table we could detect the clash and emit a diagnostic.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-26 11:30 ---
Undefined / invalid.
There is no sensible way to deal with aliasing here without pessimizing every
legitimate use.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #2 from wilson at gcc dot gnu dot org 2005-10-12 23:22 ---
It isn't true that variable i and variable j have the same symbol name. The
asm means that the symbol name of j will be "i" always. However, the symbol
name of i will be the string "i" with various target dependent
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-12 16:08 ---
This is a weird case as both are in common space.
If we do the following:
int j asm("i") = 0;
int i = 0;
We cannot assemble the source at all.
I don't know what to say about this case. Someone else will have to c
