* [Bug c/108439] incorrect optimization with -O2, -O3, -Os
2023-01-17 21:17 [Bug c/108439] New: incorrect optimization with -O2, -O3, -Os georgmueller at gmx dot net
@ 2023-01-17 21:22 ` georgmueller at gmx dot net
2023-01-17 21:25 ` georgmueller at gmx dot net
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: georgmueller at gmx dot net @ 2023-01-17 21:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #1 from Georg Müller <georgmueller at gmx dot net> ---
Created attachment 54293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54293&action=edit
reduced test case to give a compile warning, which seems to be incorrect
While trying to reduce the problem and reducing the array size of lb_key to ony
one member (t_crap8-1u64.c), it gives a compile error with -O2, -O3 and -Os
even if the only member gets initialized all the time with the line "lb_key[0]
= 0x1234;".
Also, this compiler warning and execution error is removed by compiling with
-fno-strict-aliasing, but again, this does not look right.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/108439] incorrect optimization with -O2, -O3, -Os
2023-01-17 21:17 [Bug c/108439] New: incorrect optimization with -O2, -O3, -Os georgmueller at gmx dot net
2023-01-17 21:22 ` [Bug c/108439] " georgmueller at gmx dot net
@ 2023-01-17 21:25 ` georgmueller at gmx dot net
2023-01-17 21:32 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: georgmueller at gmx dot net @ 2023-01-17 21:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #2 from Georg Müller <georgmueller at gmx dot net> ---
Just a small additional note: The dependency on argc in the loop filling the
array in main() is only there to avoid early optimization.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/108439] incorrect optimization with -O2, -O3, -Os
2023-01-17 21:17 [Bug c/108439] New: incorrect optimization with -O2, -O3, -Os georgmueller at gmx dot net
2023-01-17 21:22 ` [Bug c/108439] " georgmueller at gmx dot net
2023-01-17 21:25 ` georgmueller at gmx dot net
@ 2023-01-17 21:32 ` pinskia at gcc dot gnu.org
2023-01-17 21:33 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-17 21:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Use -fno-strict-aliasing, mayalias attribute, memcpy, etc as you are violating
C/C++ aliasing rules.
You do a store via uint64_t:
lb_key[0] = 0x1234;
And then do loads via uint32_t:
const uint32_t m = 0x83d2e73b, n = 0x97e1cc59, *key4 = (const uint32_t
*)key;
...
c8mix(key4[0]) c8mix(key4[1]) key4 += 2;
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/108439] incorrect optimization with -O2, -O3, -Os
2023-01-17 21:17 [Bug c/108439] New: incorrect optimization with -O2, -O3, -Os georgmueller at gmx dot net
` (2 preceding siblings ...)
2023-01-17 21:32 ` pinskia at gcc dot gnu.org
@ 2023-01-17 21:33 ` pinskia at gcc dot gnu.org
2023-01-17 21:44 ` georgmueller at gmx dot net
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-17 21:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Georg Müller from comment #1)
> Also, this compiler warning and execution error is removed by compiling with
> -fno-strict-aliasing, but again, this does not look right.
Why do you think that is not correct? The aliasing violation causing undefined
behavior is obvious from the stores and loads that happen from the source.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/108439] incorrect optimization with -O2, -O3, -Os
2023-01-17 21:17 [Bug c/108439] New: incorrect optimization with -O2, -O3, -Os georgmueller at gmx dot net
` (3 preceding siblings ...)
2023-01-17 21:33 ` pinskia at gcc dot gnu.org
@ 2023-01-17 21:44 ` georgmueller at gmx dot net
2023-01-17 21:51 ` pinskia at gcc dot gnu.org
2023-01-18 9:01 ` georgmueller at gmx dot net
6 siblings, 0 replies; 8+ messages in thread
From: georgmueller at gmx dot net @ 2023-01-17 21:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #5 from Georg Müller <georgmueller at gmx dot net> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Georg Müller from comment #1)
> > Also, this compiler warning and execution error is removed by compiling with
> > -fno-strict-aliasing, but again, this does not look right.
>
> Why do you think that is not correct? The aliasing violation causing
> undefined behavior is obvious from the stores and loads that happen from the
> source.
main() only works with its own lb_key array. It is only modified before giving
it to crap8() - it does not handle the internals of the hashing function.
crap8() takes the key as a void pointer - no assumptions about what it gets and
only converts void* to uint32_t*, what should be fine, or?
Why is there a warning of lb_key not being initialized in the second example,
even though its only member gets initialized twice? Via the same reference...
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/108439] incorrect optimization with -O2, -O3, -Os
2023-01-17 21:17 [Bug c/108439] New: incorrect optimization with -O2, -O3, -Os georgmueller at gmx dot net
` (4 preceding siblings ...)
2023-01-17 21:44 ` georgmueller at gmx dot net
@ 2023-01-17 21:51 ` pinskia at gcc dot gnu.org
2023-01-18 9:01 ` georgmueller at gmx dot net
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-17 21:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Aliasing rules are NOT a local thing and they are not about what the type of
the pointer is, rather than they are about the access after the casting. They
are also global ...
GCC used to have strict aliasing warnings which might warn during optimizations
but it had many false positives so it was tuned down a lot.
The rules are simple in most cases (there are complex parts to it when dealing
with unions and structures but more complex in the implementation of the
compiler).
Some reading on this subject:
https://developers.redhat.com/blog/2020/06/02/the-joys-and-perils-of-c-and-c-aliasing-part-1
https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8
There are many more papers about C/C++ aliasing rules if you want to go read up
on why GCC is doing the "correct" thing here.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/108439] incorrect optimization with -O2, -O3, -Os
2023-01-17 21:17 [Bug c/108439] New: incorrect optimization with -O2, -O3, -Os georgmueller at gmx dot net
` (5 preceding siblings ...)
2023-01-17 21:51 ` pinskia at gcc dot gnu.org
@ 2023-01-18 9:01 ` georgmueller at gmx dot net
6 siblings, 0 replies; 8+ messages in thread
From: georgmueller at gmx dot net @ 2023-01-18 9:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #7 from Georg Müller <georgmueller at gmx dot net> ---
Ok, but then why isn't there a single warning - even with -Wstrict-aliasing=1
and a completely misleading error message for the second, reduced test?
^ permalink raw reply [flat|nested] 8+ messages in thread