FORTRAN on X86 : problems with assigned goto

[joukj]

Hi All,

I found that "assigned goto" statements cause a crash on X86 (see below). No problems on AXP/IA64)

Code: Select all

rumba-jj) f90/ver
VSI Fortran X8.5-0004 (GEM 50X6F) for X86 systems
rumba-jj) ty test.f90
program test
  integer next
  real x
!
  read(*,*) x
  if (x > 0.0 ) then
    assign 30 to next
  else
    assign 50 to next
  endif
!
  write(*,*) 'crash on next line'
  goto next,(30, 50)
!
30 write(*,*) '30'
  stop 'end'
50 write(*,*) '50'
!
end
  12-JUL-2023 15:53:47
rumba-jj) f90 test.f90
rumba-jj) link test
rumba-jj) run test
1.0
crash on next line
%SYSTEM-F-ACCVIO, access violation, reason mask=15, virtual address=FFFFFFFF8000
0135, PC=000000007A881908, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000015
                                 FFFFFFFF80000135
                                 000000007A881908
                                 000000000000001B
    Register dump:
    RAX = 0000000000000000  RDI = 000000007A881920  RSI = FFFFFFFF80000135
    RDX = 0000000000002004  RCX = 000000007A8818B0  R8  = 000000008259B300
    R9  = 000000007FF8BE18  RBX = 000000007A881F00  RBP = 000000007A881950
    R10 = 00000000000091E8  R11 = FFFFFFFFFFFFFFF5  R12 = 000000007A8819A8
    R13 = 0000000000000000  R14 = 0000000000000003  R15 = 0000000579D34606
    RIP = 000000007A881908  RSP = 000000007A8818B0  SS  = 000000000000001B

regards
Jouk

[jonesd]

Make next an integer*8. The code psects on x86 are in P2 space (except for special P0 vector that lets functions still have 32 bit addresses).

Added in 47 minutes 39 seconds:
If you don't want to change the code, link/segment_attributes=code=p0

[arne_v]

Both INTEGER*8 and /segment_attributes=code=p0 of course fixes it.

But this issue raises a question: should the Fortran compiler give an error or at least a warning when assigning a label to an INTEGER*4. I think so. It will likely result in an application crash.

BTW, I am afraid that the problem may be my fault. As I remember it then I was part of the field test program for the first 64 bit Fortran compiler 3 decades ago and one of the things I complained about what that assigning a label to an INTEGER*4 did not work (I used it for my recursion free quick sort by stuffing labels into an INTEGER*4 array). And Steve Lionel fixed it. But with what we know now, then he should have refused and told me to change the code to use INTEGER*8.

[joukj]

Thanks, the helped.

I agree that the compiler should signal this as an error.

[jonesd]

Thanks, the helped.

I agree that the compiler should signal this as an error.

It's not necessarily an error as the compiler doesn't know ahead of time where the linker will place the code. I think a MAYLOSEDATA warning is more appropriate. Any fortran source that is using assigned goto is probably a very dusty deck that you don't want to fiddle with, so effectively keeping it 32-bit is probably a better solution.

[joukj]

Ofcourse this came form "dusty" code, The mathematical libraries from NETLIB contain a lot of code written a very very long time ago.. They work so you do not want to fiddle around with them.

In the case I has at hand (ODEPACK), The solution to set the variable to integer*8 did the trick.

[jreagan]

A solution would be for the compiler to ask the linker/image-activator to put the address of those target labels in the GOT (which lives in 32-bit space) and then jump indirect thru the GOT. For now, we'll certainly put something into the release notes and look at a compiler message but we don't know if you'll link with /SEGMENT=CODE=P0 so we'd be making noise in your build for no reason.

[hb]

A solution would be for the compiler to ask the linker/image-activator to put the address of those target labels in the GOT (which lives in 32-bit space) and then jump indirect thru the GOT. For now, we'll certainly put something into the release notes and look at a compiler message but we don't know if you'll link with /SEGMENT=CODE=P0 so we'd be making noise in your build for no reason.

I tried the test program on Linux:

Code: Select all

$ f95 -o test test.f90
test.f90:7:21:

    7 |     assign 30 to next
      |                     1
Warning: Deleted feature: ASSIGN statement at (1)
test.f90:9:21:

    9 |     assign 50 to next
      |                     1
Warning: Deleted feature: ASSIGN statement at (1)
test.f90:13:12:

   13 |   goto next,(30, 50)
      |            1
Warning: Deleted feature: Assigned GOTO statement at (1)
$
$ f95 -std=legacy -o test test.f90
$ ./test
1.0
 crash on next line
 30
STOP end
$ 

With ASLR enbled and -pie (the default) they should have the same problem. I have no idea how they solved it.

Anyway, I personally prefer noise to SYSTEM-F-ACCVIO. /SEGMENT=CODE=P2 is the default on x86. The user should be warned, if the program will not not work with the defaults. Maybe it's enough to generate a warning based on the options specified in /WARNING. I know, everyone uses /WARNING=ALL all the time

FWIW, the ACCVIO can also be produced on IA64:

Code: Select all

$ f90 test/nooptimize/warning=all
$ link test/segment=code=p2
$ r test
1.0
crash on next line
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=FFFFFFFFFFE0000D, PC=0000000080000200, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000000
                                 FFFFFFFFFFE0000D
                                 0000000080000200
                                 000000000000001B
...

[arne_v]

I tried the test program on Linux:

Code: Select all

$ f95 -o test test.f90
test.f90:7:21:

    7 |     assign 30 to next
      |                     1
Warning: Deleted feature: ASSIGN statement at (1)
test.f90:9:21:

    9 |     assign 50 to next
      |                     1
Warning: Deleted feature: ASSIGN statement at (1)
test.f90:13:12:

   13 |   goto next,(30, 50)
      |            1
Warning: Deleted feature: Assigned GOTO statement at (1)
$
$ f95 -std=legacy -o test test.f90
$ ./test
1.0
 crash on next line
 30
STOP end
$ 

With ASLR enbled and -pie (the default) they should have the same problem. I have no idea how they solved it.

It also works with gfortran on Windows.

But I think they are doing something funky.

If I print the variable next then I see zero.

And if I assign next to another variable and try to go to that one, then I get an error "variable has not been assigned a target label".

Based on this my guess is that gfortran internally have 2 variables: a 4 byte integer and a 8 byte address both called next and that the compiler picks either the integer or the address based on context.

Added in 1 minute 38 seconds:

FWIW, the ACCVIO can also be produced on IA64:

Code: Select all

$ f90 test/nooptimize/warning=all
$ link test/segment=code=p2
$ r test
1.0
crash on next line
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=FFFFFFFFFFE0000D, PC=0000000080000200, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000000
                                 FFFFFFFFFFE0000D
                                 0000000080000200
                                 000000000000001B
...

No surprise. Stuffing a 64 bit address (with high 32 bits not zero) into a 32 bit variable just can't work.

[arne_v]

A solution would be for the compiler to ask the linker/image-activator to put the address of those target labels in the GOT (which lives in 32-bit space) and then jump indirect thru the GOT. For now, we'll certainly put something into the release notes and look at a compiler message but we don't know if you'll link with /SEGMENT=CODE=P0 so we'd be making noise in your build for no reason.

Do you have any free psect flags available?

If you have then add a couple: PUT_WHEREVER and MUST_BE_ACCESSIBLE_VIA_32BIT_POINTERS, have the linker use those and in case like this have the compiler put a MUST_BE_ACCESSIBLE_VIA_32BIT_POINTERS flag on the code psect.