https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #37 from David C. Partridge
---
(In reply to Jonathan Wakely from comment #34)
> __m512 means something different depending on the compiler options. It's a
> different type, with different alignment, it just has the same name.
>
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #36 from David C. Partridge
---
> you shouldn't be doing that
One needs to do that to create code that will run as one executable that
supports both AVX and non-AVX processors. The AVX code needs to be compiled
with one set of opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #32 from David C. Partridge
---
I believe that you are choosing not to understand what I am saying here.
It is totally WRONG to set different alignments for this data type depending on
compiler options - the alignment requirement f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #29 from David C. Partridge
---
And somehow macOS g++ gets it (almost) correct:
amonra@lethe m512 % g++ --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
Instal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
David C. Partridge changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #27 from David C. Partridge
---
You can't change the alignment for a type depending on compile options!
Different bits of our cod eneed to be compiled with different compiler options
so that the same code can run on both AVX (gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #26 from David C. Partridge
---
The actual production code was compiled with 13.1 with options:
`-mavx;-mavx2;-mfma;-mssse3;-msse4.2`
but was crashing with a SEGV in the intrinsics code because the data was
incorrectly aligned. Wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #24 from David C. Partridge
---
I don't beleive that you diagnosis is correct - the issue is that on 13.1
running on Linux, alignof is set to 16 not 64.
On later versions (from what others have said) alignof returns 64 not 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #17 from David C. Partridge
---
So the problem would appear to be (if I read this right) that the default
alignment in 13.1 was 16 and that changed in later versions to 64 - is that a
correct interpretation of the results the people
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #12 from David C. Partridge
---
I assure you the it is necessary to align to 64 bytes to avoid SIGSEGV faults.
I can reproduce that all day long.
David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #13 from David C. Partridge
---
(In reply to Richard Biener from comment #10)
> I think this is at most a C++ std library QOI issue - IIRC you have to use a
> different allocator for types requiring bigger alignment than any of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #5 from David C. Partridge
---
Confirmed that macOS/x64 is also OK, so the problem is just Linux/x64 AFAICT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #4 from David C. Partridge
---
I was incorrect there's no problem on macOS/ARM
I'll check macOS/x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #3 from David C. Partridge
---
(In reply to Andrew Pinski from comment #2)
> (In reply to David C. Partridge from comment #1)
> > This also applies to arm64 / Neon
>
> Do you have an example there because I think the problems are 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #1 from David C. Partridge
---
This also applies to arm64 / Neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
Bug ID: 120895
Summary: AVX data types default alignment is not correct
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
16 matches
Mail list logo
