[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #18 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- I have found that tree-fre, tree-pre and tree-dse have to be disabled in order to generate correctly working code at all optimization levels (both C and FORTRAN). I'm happy with this workaround, so thank you for all suggestions.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #11 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- I'm not going to discuss whether my example is a valid C code or not, but in FORTRAN it goes a similarly wrong way. The compiler treats incorrectly the one-element array in a common.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #12 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Created attachment 30740 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30740action=edit Example of failing FORTRAN code, with assembler output from gfortran 4.6.4
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #14 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Marking the report as invalid doesn't solve the real problem. I changed the common to unnamed and the situation is still the same. main.f: C Compile and link this file with buggy.f, using gfortran 4.6 (and probably C any newer version), with optimization enabled (at least -O1). C Run with: echo 1 2 3 | ./a.out C expected (correct) result: 1. 2. 2. program main integer*4 i1,i2,i3 real*8 dmem common dmem(3) read (*,*) i1,i2,i3 call buggy(i1,i2,i3) write (*,*) dmem(1),dmem(2),dmem(3) end buggy.f: subroutine buggy(i1, i2, i3) integer*4 i1, i2, i3 real*8 dmem common dmem(1) dmem(i1)=1. dmem(i2)=2. dmem(i3)=2. return end Better?
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #16 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Dear Dominique, I cannot agree with you. You are interpreting the code that may access the array beyond declared bounds as invalid, which is simply not true. As you pointed it out before, unnamed common block may be declared larger elsewhere, so writing the dmem array beyond its first element may be a design decision and therefore may be perfectly legal. The compiler has no clue about real size of unnamed common while compiling buggy.f and bounds checking is optional. I would also like to point it out that interpreting things this way you do, you exclude some older FORTRAN77 software (for example: quantum chemistry GAMESS), in which the lack of dynamic memory allocation was overcome using the trick we are discussing here (mixing with C was needed). BTW, change the size of dmem to 2 in buggy.f and things start to work correctly, although out of bounds memory accesses still do happen. The problem occurs only if dmem is of size 1. Of course you (developers) may decide to ignore this problem anyway, so if you do so, feel free to close this bug. I'm not going to reopen it again, because I'm out of arguments. I'm also not competent enough to tamper with the compiler.
[Bug c/58270] New: Wrong code accessing array elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 Bug ID: 58270 Summary: Wrong code accessing array elements Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: strasbur at chkw386 dot ch.pwr.wroc.pl Host: i386-pc-linux Target: i386-pc-linux Created attachment 30717 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30717action=edit Isolated code giving wrong results Array elements are accessed incorretly, if the array is passed in a global structure. This bug exists in 4.6 and 4.7 up to 4.7.2, no info about newer 4.7, 4.8 and development.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #2 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- 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-translated FORTRAN77 code (it is cleared from f2c references). It was a normal practice to mix C with FORTRAN for dynamic memory allocation. The memory allocated via malloc() was referenced to a small (one-element) static array. There was nothing illegal with this. And how can the compiler assume freely that both i1 and i2 are zeros, if they are passed as actual arguments?
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #3 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- 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 competent enough even to suggest a solution.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #4 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- 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.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #5 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Created attachment 30719 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30719action=edit Second example, not working also with -fno-tree-dse -fno-dse
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #6 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Created attachment 30720 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30720action=edit File containing main() for the second example
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #8 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- 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, i2 and i3 may be set to something 0 at runtime. If it would be so much strict about declarations, it wouldn't also allow to modify mem.dmem[1] - everything would go into mem.dmem[0]. However, it writes mem.dmem[1] only (!) if compiled without -fno-tree-dse and mem.dmem[0] plus mem.dmem[1] with -fno-tree-dse. The problem is that the compiler does not work predictably. BTW, correct size of the mem structure (global variable) is ensured by the linker: $ nm buggy.o T buggy 000c C loc 0008 C mem I would also expect that if the compiler is instructed explicitly to release some constraints, then these will be released.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #10 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- 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 different story. I examined the assembler outputs and I think that the real problem is that the compiler treats one-element array (dmem) in buggy.c as ordinary variable. somewhere. If dmem is declared as two-element array (so that nobody can assume blindly to which element data should go), then everything works correctly, regardless how it is declared elsewhere. It is an overoptimization IMHO, but I'm just a user.
