This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug admin/19543] documentation: X32 ABI port and portable test for X32


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]