<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Clang defines __ILP32__ when using `-arch i386` on an x86_64 Intel"
href="https://llvm.org/bugs/show_bug.cgi?id=25688">25688</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Clang defines __ILP32__ when using `-arch i386` on an x86_64 Intel
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.6
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>MacOS X
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Driver
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>noloader@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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 (<a href="https://wiki.debian.org/X32Port">https://wiki.debian.org/X32Port</a>) 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]
<a href="http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/Mac_OS_X_ABI_Function_Calls.pdf">http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/Mac_OS_X_ABI_Function_Calls.pdf</a>
[1] <a href="http://sites.google.com/site/x32abi/documents/abi.pdf">http://sites.google.com/site/x32abi/documents/abi.pdf</a>
[2] <a href="http://www.sco.com/developers/devspecs/abi386-4.pdf">http://www.sco.com/developers/devspecs/abi386-4.pdf</a>
*****
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>