Re: is there a 2GB limit on amd64 link?

2020-02-06 Thread j

Yes, that (-mcmodel=medium) is the solution.  Thanks!


John

On 2020-02-05 22:03, Philip Guenther wrote:

On Wed, Feb 5, 2020 at 7:38 PM  wrote:


I am encountering a linker error when compiling with ports-gcc
Fortran:

ld: error: lbug2.f90:(function MAIN__: .text+0x80): relocation
R_X86_64_PC32 out o
f range: 2456507324 is not in [-2147483648, 2147483647]

The code has several large arrays, the total size of which exceeds
2GB.

Is this a linker issue, a gcc fortran issue, or a pebkac?


It's at least a gnu fortran issue: it needs to generate object code in
a larger "model" than it currently is.  I've never used gnu fortran,
but it might accept the -mcmodel=medium option like gcc and generate
code sequences for data symbols that don't limit them to the bottom
2GB (or to within 2GB of the involved code, depending on gcc's choices
in implementing the model).

If it doesn't accept that option, then you'll need to work with the
the docs, mailling lists, etc of the upstream gnu fortran project
about how to have it generate code for the medium or large data models
per the amd64 ABI.

Philip Guenther




Re: is there a 2GB limit on amd64 link?

2020-02-05 Thread Philip Guenther
On Wed, Feb 5, 2020 at 7:38 PM  wrote:

> I am encountering a linker error when compiling with ports-gcc Fortran:
>
> ld: error: lbug2.f90:(function MAIN__: .text+0x80): relocation
> R_X86_64_PC32 out o
> f range: 2456507324 is not in [-2147483648, 2147483647]
>
> The code has several large arrays, the total size of which exceeds 2GB.
>
> Is this a linker issue, a gcc fortran issue, or a pebkac?
>

It's at least a gnu fortran issue: it needs to generate object code in a
larger "model" than it currently is.  I've never used gnu fortran, but it
might accept the -mcmodel=medium option like gcc and generate code
sequences for data symbols that don't limit them to the bottom 2GB (or to
within 2GB of the involved code, depending on gcc's choices in implementing
the model).

If it doesn't accept that option, then you'll need to work with the the
docs, mailling lists, etc of the upstream gnu fortran project about how to
have it generate code for the medium or large data models per the amd64 ABI.


Philip Guenther


is there a 2GB limit on amd64 link?

2020-02-05 Thread j
I am encountering a linker error when compiling with ports-gcc Fortran:

ld: error: lbug2.f90:(function MAIN__: .text+0x80): relocation R_X86_64_PC32 
out o
f range: 2456507324 is not in [-2147483648, 2147483647]

The code has several large arrays, the total size of which exceeds 2GB.

Is this a linker issue, a gcc fortran issue, or a pebkac?

$ cat lbug1.f90
program lbug
  implicit none
  save

realr3(ng,ng,ng)

  print *,'hello bug'
  ! essential:
  call someexternal(r3,3)
  print *,r3(3,3,3)
endprogram

$ cat lbuge.f90
subroutine someexternal(a,b)
endsubroutine

$ echo $(( 4* 850*850*850 ))
245650
$# the memory use of array r3 exceeds 2^31 bytes
$ egfortran -cpp -Dng=850 lbug1.f90 -c
$ egfortran -c lbuge.f90
$ egfortran lbug1.o lbuge.o
o66$ ./a.out
 hello bug
   0.

The object files are linked into separate files so we can examine with

$ objdump --syms lbug1.o | grep -B 1 -A 2 r3
 l F .text  0116 MAIN__
 l O .bss   926b3720 r3.3768
0030 l O .rodata001c options.2.3777
 ld  .eh_frame   .eh_frame

$ cat lbug2.f90
program lbug
  implicit none
  save

realr3(ng,ng,ng)
complex c3(ng/2,ng,ng)

  print *,'hello bug'
  ! essential:
  call someexternal(r3,c3)
  print *,r3(3,3,3), ubound(r3)
endprogram

$ egfortran -cpp -Dng=850 lbug2.f90 -c
$ egfortran -cpp -Dng=850 lbuge.f90 -c
$ egfortran lbug2.o lbuge.o
ld: error: lbug2.f90:(function MAIN__: .text+0x80): relocation R_X86_64_PC32 
out of range: 2456507324 is not in [-2147483648, 2147483647]

$ objdump --syms lbug2.o | grep -B 1 -A 2 r3
926b3720 l O .bss   926b3720 c3.3768
 l O .bss   926b3720 r3.3770
0028 l O .rodata000c A.2.3775
0040 l O .rodata001c options.4.3783

It seems the compiler generates 64-bit offsets but the linker limits itself
to 32-bit offsets.  Is this correct? Is there a fix?

John

Environment:

$ sysctl kern.version
kern.version=OpenBSD 6.6 (GENERIC.MP) #0: Sat Oct 26 08:08:07 MDT 2019

r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ sysctl hw
hw.machine=amd64
hw.model=Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz
hw.ncpu=2

$ pkg_info | grep g95
g95-8.3.0p4 GNU compiler collection: f95 compiler