Skip to main content
added 36 characters in body
Source Link
TooTea
  • 207
  • 1
  • 5

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

foo_:
…
        mov     DWORD PTR [rax], 5
…
.LC0:
        .long   1
MAIN__:
…
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_
…

Of course, the constant will be placed into the read only data section on anymost modern platformplatforms (except for those lacking an MMU). The write in foo() is thus going to trigger a segmentation fault at runtime.

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

foo_:
…
        mov     DWORD PTR [rax], 5
…
.LC0:
        .long   1
MAIN__:
…
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_
…

Of course, the constant will be placed into the read only data section on any modern platform. The write in foo() is thus going to trigger a segmentation fault at runtime.

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

foo_:
…
        mov     DWORD PTR [rax], 5
…
.LC0:
        .long   1
MAIN__:
…
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_
…

Of course, the constant will be placed into the read only data section on most modern platforms (except for those lacking an MMU). The write in foo() is thus going to trigger a segmentation fault at runtime.

added 8 characters in body
Source Link
TooTea
  • 207
  • 1
  • 5

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

.LC0foo_:
        .long   1
MAIN__:
    mov    push DWORD PTR [rax], rbp5
   …
.LC0:
     mov   .long  rbp, rsp1
MAIN__:
…
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_

Of course, the constant will be placed into the read only data section on any modern platform. The write in foo() is thus going to trigger a segmentation fault at runtime.

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

.LC0:
        .long   1
MAIN__:
        push    rbp
        mov     rbp, rsp
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_

Of course, the constant will be placed into the read only data section on any modern platform. The write in foo() is thus going to trigger a segmentation fault at runtime.

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

foo_:
        mov     DWORD PTR [rax], 5
…
.LC0:
        .long   1
MAIN__:
…
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_

Of course, the constant will be placed into the read only data section on any modern platform. The write in foo() is thus going to trigger a segmentation fault at runtime.

Source Link
TooTea
  • 207
  • 1
  • 5

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

.LC0:
        .long   1
MAIN__:
        push    rbp
        mov     rbp, rsp
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_

Of course, the constant will be placed into the read only data section on any modern platform. The write in foo() is thus going to trigger a segmentation fault at runtime.