--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-22 22:02
---
Fixed in 4.4.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from felix dot nawothnig at t-online dot de 2006-07-16
14:23 ---
Don't know much about GCC internals but shouldn't this be a very trivial
enhancement? I know that this is FOSS so not to annoy anyone, just wondering
why it's still open after 1 year.
(In case someone is
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-07-16 20:36 ---
You could try it yourself. But - do you have a testcase that shows how macros
and inline functions come into play here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-05 21:30 ---
(In reply to comment #2)
This is not a bug. You need IPA to figure out that y is never changed. For
example:
int x, y = x, z;
int bar() { y = z; }
This actually does:
*y = z; and not y = z;
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-05
15:14 ---
Consider these two TUs:
extern int *y, x, z;
int foo();
extern C void abort();
int main()
{
foo();
if (*y!=42)
abort();
if (y!=x)
abort();
y = z;
foo ();
if (*y!=42)
abort();
if
--- Additional Comments From felix dot nawothnig at t-online dot de
2004-12-05 19:10 ---
Diagnostics? Both files are 100% valid C++ - but since the C++ standard doesn't
enforce implementation of references as pointers they cause ABI-defined (?)
behaviour at/after linkage, just as...
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-05
19:15 ---
(In reply to comment #5)
Diagnostics? Both files are 100% valid C++ - but since the C++ standard
doesn't
enforce implementation of references as pointers they cause ABI-defined (?)
behaviour at/after
