This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug admin/19543] documentation: X32 ABI port and portable test for X32
- From: "noloader at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 01 Feb 2016 10:26:32 +0000
- Subject: [Bug admin/19543] documentation: X32 ABI port and portable test for X32
- Auto-submitted: auto-generated
- References: <bug-19543-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19543
--- Comment #2 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Andreas Schwab from comment #1)
> > Clang defines __ILP32__ for any 32-bit platform, including ARM and possibly
> > ARM64/AARCH64 platforms. They don't limit use of __ILP32__ to Intel 64-bit
> > platforms.
>
> Same for GCC.
I don't believe its so for GCC (Fedora 23/i686):
$ g++ -dM -E - < /dev/null | egrep -i "(amd|86|ilp)"
#define __i686 1
#define __i686__ 1
#define __i386 1
#define __i386__ 1
#define i386 1
> So what exactly is the issue?
The way things are worded makes it sound like __LP64__ and __ILP32__ are
mutually exclusive:
* x86-64 C/C++ compiler predefines macro __LP64__ while
x32 C/C++ compiler predefines macro __ILP32__
You can use __ILP32__ to test for X32 under GCC and ICC. You cannot use it with
some other compilers, like Clang.
Someone who reads the statement and arrives at mutual exclusion will have
trouble under other compilers. In fact, I believe this happened on Debian's
X32-port wiki page. That is, the Debian folks advised to use __ILP32__ as the
test, and specifically stated not to use __LP64__. I believe it came from the
Glibc wiki page.
I don't believe its GNU's intentions to cross-up someone so their code breaks
under other compilers.
--
You are receiving this mail because:
You are on the CC list for the bug.