http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #12 from Krzysztof Strasburger ---
Created attachment 30740
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30740&action=edit
Example of failing FORTRAN code, with assembler output from gfortran 4.6.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
Krzysztof Strasburger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|IN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #10 from Krzysztof Strasburger ---
Jakub,
I do not care about C++ (never understood it), but commons are just commons. I
see them from linker's perspective. How does the compiler treat variables
belonging to that common - this is a dif
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #8 from Krzysztof Strasburger ---
Mikael,
I cannot agree. Do not look at main.c, as the compiler doesn't know anything
about it while compiling buggy.c (this is the reason for which I keep main()
separately) and doesn't know that i1, i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #7 from Mikael Pettersson ---
Your examples are invalid C. In one module you present the compiler with a
specific declaration, and complain when it utilizes constraints derived from
that declaration. Then in another module you have a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #6 from Krzysztof Strasburger ---
Created attachment 30720
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30720&action=edit
File containing main() for the second example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #5 from Krzysztof Strasburger ---
Created attachment 30719
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30719&action=edit
Second example, not working also with -fno-tree-dse -fno-dse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #4 from Krzysztof Strasburger ---
Unfortunately, this is not the end of story. I'm going to attach a little more
complicated example, for which even using -fno-dse -fno-tree-dse does not help.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #3 from Krzysztof Strasburger ---
The compiler option -fno-tree-dse does the job for me. Florian - thank you for
using the term "dead store" ;). I'm not sure whether it should be enabled by
default for a C compiler, but I'm not compete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #2 from Krzysztof Strasburger ---
OK, I'm not and expert, but mem is a global structure and it can be of
different size in other object file. The linker should assume the biggest of
all, correct?
The example I posted comes from f2c-tra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #1 from Florian Weimer ---
The compiler is free to assume that both i1 and i2 are zero and the first store
is dead (because this is the only valid array index). So if the buggy()
function stores a value of 1.0 at mem.dmem[0] unconditi
12 matches
Mail list logo
