[llvm-bugs] [Bug 42554] New: __BIGGEST_ALIGNMENT__ not the same as gcc for AVX and later
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Jul 9 07:10:44 PDT 2019
https://bugs.llvm.org/show_bug.cgi?id=42554
Bug ID: 42554
Summary: __BIGGEST_ALIGNMENT__ not the same as gcc for AVX and
later
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangbugs at nondot.org
Reporter: clang at gmch.uk
CC: blitzrakete at gmail.com, dgregor at apple.com,
erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
richard-llvm at metafoo.co.uk
When compiled -march=native (on znver1) with gcc and clang I get the following:
* gcc 9.1.1 20190503 (Red Hat 9.1.1-1)
alignof(max_align_t)=16 __BIGGEST_ALIGNMENT__=32 malloc() align=16
__SSE__ __AVX__ __AVX2__
* clang 8.0.0 (Fedora 8.0.0-1.fc30)
(4.2.1 Compatible Clang 8.0.0 (Fedora 8.0.0-1.fc30))
alignof(max_align_t)=16 __BIGGEST_ALIGNMENT__=16 malloc() align=16
__SSE__ __AVX__ __AVX2__
When compiled without -march=native, both give:
alignof(max_align_t)=16 __BIGGEST_ALIGNMENT__=16 malloc() align=16
__SSE__
My guess is that clang's __BIGGEST_ALIGNMENT__ for -march=native is a bug...
except that gcc v4.2.1 predates AVX ???
FWIW: in all cases glibc malloc() aligned to 16. My reading of the glibc code
tells me that its alignment is 2*sizeof(size_t), which is in fact the same as
alignof(max_align_t), but is in no way related.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190709/20fe40d8/attachment.html>
More information about the llvm-bugs
mailing list