Per arch(7), __ILP32__ is canonical on our 32-bit platforms and __LP64__ on our 64-bit platforms. GCC9 correctly defines __LP64__ on amd64 native builds. However, in '-m32' mode, it does not define either constant. This is incorrect. As a workaround (for other people encountering the same issue), __SIZEOF_LONG__ (4 or 8) is defined in both modes, in both Clang and GCC, and can be used for a similar purpose.
Compare: $ [cc|gcc9] [-m32|] -x c -dM -E /dev/null | grep "LP"
(In reply to Conrad Meyer from comment #0) > Per arch(7), __ILP32__ is canonical on our 32-bit platforms and __LP64__ > on our 64-bit platforms. This invokes memories of the Hitchhiker's Guide and how the Vogons went about their plans re planet Earth. :-| > However, in '-m32' mode, it does not define either constant. This is incorrect. I checked and it's the same on Linux. Looking at the code, __ILP32__ is only defined for x32 (-mx32), not -m32. Either that is a deliberate choice or nobody really pushed for it for 15+ years? This is code I don't know at all, but I have an idea and will see what upstream thinks.
It’s a bit odd it’s defined for x32 mode and not conventional i386. Thanks for looking into it.
A commit references this bug: Author: gerald Date: Fri May 15 09:21:20 UTC 2020 New revision: 535279 URL: https://svnweb.freebsd.org/changeset/ports/535279 Log: Update to the 20200510 snapshot of GCC 11.0.0 as stage 1 proceeds. This includes a little upstream contributions of mine that defines __ILP32__ on all 32-bit x86 targets. [1] PR: 246288 [1] Changes: head/lang/gcc11-devel/Makefile head/lang/gcc11-devel/distinfo
Nice, thanks! https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=13a46321516e2efd3bbb1f1899c539c6724240a9
(In reply to Conrad Meyer from comment #3) > It’s a bit odd it’s defined for x32 mode and not conventional i386. > Thanks for looking into it. Yes, I agree. I believe this simply was on nobody's radar and when the Intel guys comparatively recently added x32 support they then saw a need for their use case (but did not tackle "native" 32-bit while there for some reason).(In reply to Conrad Meyer from comment #5) (In reply to Conrad Meyer from comment #5) > Nice, thanks! > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; h=13a46321516e2efd3bbb1f1899c539c6724240a9 You're welcome! I backported that to the GCC 10 release branch, so the most recent snapshot (which I'll update lang/gcc10-devel to shortly) also has this addition. And GCC 10.2 will also carry it. I am considering a backport to the GCC 9 release branch. Do you see a need there, too?
I believe I was trying to use this macro in a patch file for a port using USE=gcc. So if 10 is the default GCC, or will become so soon, I think there's no need to try and backport to 9. (I worked around the immediate issue with SIZEOF_LONG.) I have been working with the Sparse pseudo-compiler lately and humorously, it had the exact same x86 / x32 ILP32 definition issue: https://github.com/cemeyer/sparse/commit/f70abb47b11d52497a1a3453c5c2b948a64e97c1 Thanks!
A commit references this bug: Author: gerald Date: Tue May 26 10:04:30 UTC 2020 New revision: 536603 URL: https://svnweb.freebsd.org/changeset/ports/536603 Log: Update to the 20200523 snapshot of GCC 10.1.1. This includes an upstream contribution of mine that defines __ILP32__ on all 32-bit x86 targets. [1] It also brings a fix for the aarch64 back end and five for x86, plus two for the middle end/optimizers and Fortran, each, and four for the C++ standard library. PR: 246288 [1] Changes: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo
(In reply to Conrad Meyer from comment #7) > I believe I was trying to use this macro in a patch file for a port using > USE=gcc. So if 10 is the default GCC, or will become so soon, I think there's > no need to try and backport to 9. Those major version upgrades for GCC always tend to be more laborsome and slower than we'd hope, so I went ahead and backported my patch to the GCC 9 branch as well. GCC mainline (which will become GCC 11 next year) - lang/gcc11-devel - and the GCC 10 and 9 branches -- lang/gcc10-devel and lang/gcc9-devel - now have this (or will within a week). lang/gcc10 and lang/gcc9 will get it with the next release of each. > I have been working with the Sparse pseudo-compiler lately and humorously, > it had the exact same x86 / x32 ILP32 definition issue: History likes to repeat itself. :->
A commit references this bug: Author: gerald Date: Sun Jun 7 07:50:48 UTC 2020 New revision: 538147 URL: https://svnweb.freebsd.org/changeset/ports/538147 Log: Update to the 20200605 snapshot of GCC 9.3.1. This includes an upstream contribution of mine that defines __ILP32__ on all 32-bit x86 targets. [1] It also adds Zeus support for aarch64 and two aarch64 fixes, plus two for gcov, and one for the Fortran front end. PR: 246288 [1] Changes: head/lang/gcc9-devel/Makefile head/lang/gcc9-devel/distinfo
Thanks again, Gerald!