[llvm-bugs] [Bug 25688] New: Clang defines __ILP32__ when using `-arch i386` on an x86_64 Intel

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=25688

            Bug ID: 25688
           Summary: Clang defines __ILP32__ when using `-arch i386` on an
                    x86_64 Intel
           Product: clang
           Version: 3.6
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: noloader at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

We caught a bug report from a user who attempted to compile our library on OS X
under Xcode 6. The user provided a CXXFLAG that included -arch i386. We were
able to duplicate it with OS X 10.8 and Clang 3.6.

The same code compiles fine under, say, a Red Hat X32 server or a Debian 8 X32
Port (https://wiki.debian.org/X32Port) using GCC.

*****

First, here is the reduced case offending code:

  $ cat cpuid.cxx
  // #include <cstdint>
  #include <stdint.h>

  #if defined(__ILP32__) || defined(_ILP32)
  # define BOOL_X32 1
  #endif

  #if defined(__x86_64__) || defined(_x86_64)
  # define BOOL_X64 1
  #endif

  int main(int argc, char* argv[])
  {
    uint32_t output[4];

    asm volatile
    (
     // save ebx in case -fPIC is being used
  # if BOOL_X32 || BOOL_X64
     "pushq %%rbx; cpuid; mov %%ebx, %%edi; popq %%rbx"
  # else // BOOL_X86
     "push %%ebx; cpuid; mov %%ebx, %%edi; pop %%ebx"
  # endif
     : "=a" (output[0]), "=D" (output[1]), "=c" (output[2]), "=d" (output[3])
     : "a" (0), "c" (0)
    );

    return output[0];
  }

*****

Second, here is the error it is producing:

  $ clang++ -arch i386 cpuid.cxx -o cpuid.exe
  cpuid.cxx:20:4: error: register %rbx is only available in 64-bit mode
     "pushq %%rbx; cpuid; mov %%ebx, %%edi; popq %%rbx"
     ^
  <inline asm>:1:8: note: instantiated into assembly here
          pushq %rbx; cpuid; mov %ebx, %edi; popq %rbx
                ^~~~~
  cpuid.cxx:20:4: error: register %rbx is only available in 64-bit mode
     "pushq %%rbx; cpuid; mov %%ebx, %%edi; popq %%rbx"
     ^
  <inline asm>:1:42: note: instantiated into assembly here
          pushq %rbx; cpuid; mov %ebx, %edi; popq %rbx
                                                ^~~~
  2 errors generated.

*****

Third, here is what Clang is defining. Its worth noting Apple/OS X does not
define the X32 platform:

  $ clang++ -arch i386 -dM -E - < /dev/null | egrep -i "(86|64|ilp)"
  #define _ILP32 1
  #define __ILP32__ 1
  ...
  #define __i386 1
  #define __i386__ 1
  #define i386 1

  $ uname -a
  Darwin riemann.local 12.6.0 Darwin Kernel Version 12.6.0: Wed Mar 18
  16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 x86_64

  $ clang++ --version
  clang version 3.6.0 (tags/RELEASE_360/final)
  Target: x86_64-apple-darwin12.6.0
  Thread model: posix

*****

I cannot find provenance for the combination of __ILP32__ and __i386__. The "OS
X ABI Function Call Guide" [0] does not discuss it, and often defers to the
System V guides.

The "System V Application Binary Interface, AMD64 (With LP64 and ILP32
Programming Models)" [1] states we should see either (1) __ILP32__ alone; or
(2) both __ILP32__ and __x86_64__ (some hand waiving).

The "SYSTEM V APPLICATION BINARY INTERFACE for Intel 386" [2] does not discuss
it, and does not mention __ILP32__.

[0]
http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/Mac_OS_X_ABI_Function_Calls.pdf
[1] http://sites.google.com/site/x32abi/documents/abi.pdf
[2] http://www.sco.com/developers/devspecs/abi386-4.pdf

*****

Finally, if both __ILP32__ and __i386__ are intentional, then we need to be
able to push/pop 64-bit registers and values because that's how we have to
interact with the stack on x86_64 system, even under the ILP32 model.

-- 
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/20151201/06d4c2f4/attachment.html>