* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
@ 2021-03-17 12:08 ` sebastiano.vigna at unimi dot it
2021-03-17 12:08 ` sebastiano.vigna at unimi dot it
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 12:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #1 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
Created attachment 50407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50407&action=edit
Output of gcc with -O2
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
2021-03-17 12:08 ` [Bug c/99623] " sebastiano.vigna at unimi dot it
@ 2021-03-17 12:08 ` sebastiano.vigna at unimi dot it
2021-03-17 12:19 ` zeccav at gmail dot com
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 12:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #2 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
Created attachment 50408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50408&action=edit
Source
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
2021-03-17 12:08 ` [Bug c/99623] " sebastiano.vigna at unimi dot it
2021-03-17 12:08 ` sebastiano.vigna at unimi dot it
@ 2021-03-17 12:19 ` zeccav at gmail dot com
2021-03-17 12:23 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: zeccav at gmail dot com @ 2021-03-17 12:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Vittorio Zecca <zeccav at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zeccav at gmail dot com
--- Comment #3 from Vittorio Zecca <zeccav at gmail dot com> ---
Where is prb.h ?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
` (2 preceding siblings ...)
2021-03-17 12:19 ` zeccav at gmail dot com
@ 2021-03-17 12:23 ` jakub at gcc dot gnu.org
2021-03-17 12:59 ` sebastiano.vigna at unimi dot it
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-17 12:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
` (3 preceding siblings ...)
2021-03-17 12:23 ` jakub at gcc dot gnu.org
@ 2021-03-17 12:59 ` sebastiano.vigna at unimi dot it
2021-03-17 13:00 ` sebastiano.vigna at unimi dot it
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 12:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #5 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
Created attachment 50409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50409&action=edit
Source
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
` (4 preceding siblings ...)
2021-03-17 12:59 ` sebastiano.vigna at unimi dot it
@ 2021-03-17 13:00 ` sebastiano.vigna at unimi dot it
2021-03-17 13:22 ` sebastiano.vigna at unimi dot it
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 13:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #6 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
Created attachment 50410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50410&action=edit
Source
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
` (5 preceding siblings ...)
2021-03-17 13:00 ` sebastiano.vigna at unimi dot it
@ 2021-03-17 13:22 ` sebastiano.vigna at unimi dot it
2021-03-17 13:40 ` sebastiano.vigna at unimi dot it
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 13:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Sebastiano Vigna <sebastiano.vigna at unimi dot it> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
` (6 preceding siblings ...)
2021-03-17 13:22 ` sebastiano.vigna at unimi dot it
@ 2021-03-17 13:40 ` sebastiano.vigna at unimi dot it
2021-03-17 13:53 ` sebastiano.vigna at unimi dot it
2021-03-17 14:24 ` sebastiano.vigna at unimi dot it
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 13:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #8 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
` (7 preceding siblings ...)
2021-03-17 13:40 ` sebastiano.vigna at unimi dot it
@ 2021-03-17 13:53 ` sebastiano.vigna at unimi dot it
2021-03-17 14:24 ` sebastiano.vigna at unimi dot it
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 13:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #9 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
Finally solved: the problematic statement
if (h == NULL) h = (struct prb_node *)&tree->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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/99623] Code behaves differently at -O2 optimization
2021-03-17 12:07 [Bug c/99623] New: Code behaves differently at -O2 optimization sebastiano.vigna at unimi dot it
` (8 preceding siblings ...)
2021-03-17 13:53 ` sebastiano.vigna at unimi dot it
@ 2021-03-17 14:24 ` sebastiano.vigna at unimi dot it
9 siblings, 0 replies; 11+ messages in thread
From: sebastiano.vigna at unimi dot it @ 2021-03-17 14:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #10 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread