https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #7 from Petr ---
The simplified test case looks good except for a missing return :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #3 from Petr ---
Maybe marking it as confirmed would be appropriate then?
I think as a workaround it would be better to not constant fold code that GCC
cannot compute properly - that would mean properly calculating the values at
run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Bug ID: 116738
Summary: Constant folding of _mm_min_ss and _mm_max_ss is wrong
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #17 from Petr ---
Guys thanks a lot for your feedback.
Is the may_alias annotation guaranteed to behave as expected in the future
versions of GCC too, or it's just too much UB that it's better to do unaligned
reads with memcpy?
Wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #15 from Petr ---
Unfortunately GCC doesn't report any issues even with `-Wstrict-aliasing=1`.
BTW now I know I must use the may_alias attribute to my satisfaction, and this
is what I'm gonna do, however, from user perspective I'm n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #12 from Petr ---
Is there a way to diagnose this? To tell GCC to report transformations that
basically cause wrong results returned?
In my code base, I have unaligned memory loads/stores abstracted, so I can
implement whatever comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #10 from Petr ---
Well, the problem is, that when you compile it with "-fsanitize=undefined" - it
won't report any undefined behavior, and the function would return the expected
value.
I even tried to make everything constexpr - and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #8 from Petr ---
My only problem is that A returns a different value compared to B, C, and D:
uint32_t test_u32_a() {
char array[16] {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
writeU64be(array + 6, 0xAABBCCDDEEFF1213);
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #6 from Petr ---
For now I have disabled unaligned load/store optimizations in my projects when
dealing with GCC 11 and upwards.
I still think that GCC is wrong in this case regardless of strict aliasing. The
code in func_u32() is e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #4 from Petr ---
Additional test case:
#include
#include
typedef uint32_t __attribute__((__aligned__(1))) UnalignedUInt32;
typedef uint64_t __attribute__((__aligned__(1))) UnalignedUInt64;
uint32_t byteswap32(uint32_t x) noexcep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #3 from Petr ---
BTW this almost seems like an optimizer bug, because if you compile the code
without optimizations with GCC 11 (or with -O1) it also returns the expected
value - only optimized compilation with GCC 11 returns the wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #2 from Petr ---
If you compile this with clang the function test_u32() will corretly return the
expected 0xBBCCDDEE and not 0x0708090A.
If you compile with older GCC, like GCC 10, the test would also return
0xBBCCDDEE. Only GCC-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
Bug ID: 103699
Summary: Reading or writing unaligned integers is wrongly
optimized (GCC-11 and up)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287
--- Comment #6 from Petr ---
Yes, the code is not really doing anything useful, I only wrote it to
demonstrate the spills problem. Clang actually outsmarted me by removing half
of the code :)
I think this issue can be closed, I cannot repro this
14 matches
Mail list logo
