[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