[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 --- Comment #10 from Sebastiano Vigna --- Ahem no, my correction goes in the opposite direction it should go. I'll ask suggestions to the library authors. I really apologize for all the noise.
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 --- Comment #9 from Sebastiano Vigna --- Finally solved: the problematic statement if (h == NULL) h = (struct prb_node *)>prb_root; should just be if (h == NULL) h = tree->prb_root->prb_link[0]; The position in memory of the two pointers is the same, but the second access has the right type. I guess the GNU libavl author wanted to save an indirection, but did not realize the possible dangers. For the user, this behavior of the optimizer remains very confusing tho.
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 --- Comment #8 from Sebastiano Vigna --- I'm sorry, I did the test on the wrong file. No, you cannot eliminate the &, even if the type is correct, and h can be NULL at that point. I'll ask the libavl maintainers their opinion. We can compile with that option but other people might incur in the same problem.
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 Sebastiano Vigna changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Sebastiano Vigna --- Thank you for the prompt answer. It is all very weird, and certainly unexpected, but this could be a problem with GNU libavl. The four assignments marked by -Wstrict-aliasing=2 are completely wrong: there is an additional & that shouldn't be there. Since this is a GNU library with two decades of development behind, we did not check in particular the code we did not change. If we remove the &, the warnings go away and the problem disappears. Adding some assertions we established that the nonsensical assignment are, simply, never executed. This is why, in spite of being nonsensical, they do not cause any harm. But their very existence, even if they are not executed, appears to trigger the problem we faced with -O2. I guess that once you have undefined statements all bets are off, so this is not a gcc bug. We will report the problem to the libavl authors.
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 --- Comment #6 from Sebastiano Vigna --- Created attachment 50410 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50410=edit Source
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 --- Comment #5 from Sebastiano Vigna --- Created attachment 50409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50409=edit Source
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Goes away with -fno-strict-aliasing and -Wstrict-aliasing=2 warns about it:
bug.c: In function ‘prb_probe’:
bug.c:105:42: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c:139:42: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c: In function ‘myprb_probe’:
bug.c:251:44: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c:285:44: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c: In function ‘compare’:
bug.c:375:9: warning: format ‘%d’ expects argument of type ‘int’, but argument
2 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
bug.c:375:9: warning: format ‘%d’ expects argument of type ‘int’, but argument
3 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
I bet the program is invalid, just don't have time to prove it now.
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #3 from Vittorio Zecca --- Where is prb.h ?
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 --- Comment #2 from Sebastiano Vigna --- Created attachment 50408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50408=edit Source
[Bug c/99623] Code behaves differently at -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623 --- Comment #1 from Sebastiano Vigna --- Created attachment 50407 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50407=edit Output of gcc with -O2
