[Bug target/40647] New: 32-bit pointers on 64-bit operating systems

[Bug target/40647] New: 32-bit pointers on 64-bit operating systems

[tkoenig at gcc dot gnu dot org]

Just passing on a request from Donald Knuth,
from http://www-cs-faculty.stanford.edu/~knuth/news08.html ,
A Flame About 64-bit Pointers

# It is absolutely idiotic to have 64-bit pointers when I compile a program
# that uses less than 4 gigabytes of RAM. When such pointer values appear
# inside a struct, they not only waste half the memory, they effectively
# throw away half of the cache.

# The gcc manpage advertises an option "-mlong32" that sounds like what I want.
# Namely, I think it would compile code for my x86-64 architecture, taking 
# advantage of the extra registers etc., but it would also know that my
# program is going to live inside a 32-bit virtual address space.

# Unfortunately, the -mlong32 option was introduced only for MIPS computers,
# years ago. Nobody has yet adopted such conventions for today's most popular
# architecture. Probably that happens because programs compiled with this
# convention will need to be loaded with a special version of libc.

# Please, somebody, make that possible.


-- 
           Summary: 32-bit pointers on 64-bit operating systems
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tkoenig at gcc dot gnu dot org
GCC target triplet: x86_64-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2009-07-04 10:07 -------
Very naive question: is it not what -m32 should do?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[tkoenig at gcc dot gnu dot org]

------- Comment #2 from tkoenig at gcc dot gnu dot org  2009-07-04 10:16 -------
(In reply to comment #1)
> Very naive question: is it not what -m32 should do?

The gcc info page states

`-m32'
`-m64'
     Generate code for a 32-bit or 64-bit environment.  The 32-bit
     environment sets int, long and pointer to 32 bits and generates
     code that runs on any i386 system.

So, -m32 doesn't use the new, extended register set.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-07-04 11:02 -------
Right, a new 32bit ABI would need to be defined with all its problems of
introducing another multilib variant.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-07-04 11:02:27
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[tkoenig at gcc dot gnu dot org]

------- Comment #4 from tkoenig at gcc dot gnu dot org  2009-07-04 11:34 -------
This would be something like Intel's -mcmodel=small, see

http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/copts/common_options/option_mcmodel.htm


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[joseph at codesourcery dot com]

------- Comment #5 from joseph at codesourcery dot com  2009-07-04 11:54 -------
Subject: Re:  32-bit pointers on 64-bit operating systems

The natural analogy would be with MIPS n32 (an ILP32 ABI for 64-bit MIPS 
hardware), which also indicates the directory names (/lib32) to use.

There would certainly be a lot of work in ABI design, binutils, compiler, 
glibc and kernel to implement this, but I think such an ABI would be 
useful.  One thing to consider would be whether it would be possible to 
avoid having three different syscall ABIs (which probably means making the 
new ABI use the same syscall ABI as LP64 code); the MIPS n32 syscall ABI 
has been a frequent cause of trouble.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-07-04 13:50 -------
No, we have -mcmodel as well, but that only specifies the maximum size of the
data and code segments and does not change the size of pointers (-mcmodel=small
is the default btw).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[hjl dot tools at gmail dot com]

------- Comment #7 from hjl dot tools at gmail dot com  2009-07-04 18:56 -------
I think icc has an option to limit pointer size to 32bit.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2009-07-04 19:00 -------
i guess this is a dup.

*** This bug has been marked as a duplicate of 34764 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[hjl dot tools at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]



------- Comment #9 from hjl dot tools at gmail dot com  2009-07-04 19:03 -------
/Qauto-ilp32 (-auto-ilp32): Specifies that the application cannot exceed
a 32-bit address space, which allows the compiler to use 32-bit pointers
whenever possible.

To use this option, you must also specify /Qipo [value] (-
ipo[value]). Using the ¨Cauto-ilp32 option on programs that can
exceed 32-bit address space (2**32) may cause unpredictable
results during program execution. This option has no effect on
systems with Intel 64 unless the /QaxP (-axP), /QxP (-xP),
/QaxT (-axT), or /QxT (-xT) option is also used.
Note: For IA-32 processors, this option is not supported


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647

[Bug target/40647] 32-bit pointers on 64-bit operating systems

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2009-07-04 19:18 -------
"/Qauto-ilp32 (-auto-ilp32): Specifies that the application cannot exceed
a 32-bit address space, which allows the compiler to use 32-bit pointers
whenever possible."
^^^^^^^^^^^^^^^

so it does in fact not change the ABI?  I don't see how this will be useful
without kernel / libc support.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647