And what about with this option: Code Gen Options (Using the GNU Compiler Collection (GCC)) ?
The software supply chain can only move at the rate of the slowest link. The longer you stick with old tools, the longer they’ll need to be around, and the longer you’ll be subject to the security vulnerability.
Edit: I just checked on SLES 15
> gfortran --version
GNU Fortran (Spack GCC) 14.2.0
...
> gfortran optim.f90
/usr/bin/ld: warning: /tmp/cccpkks1.o: requires executable stack (because the .note.GNU-stack section is executable)
> gfortran -ftrampoline-impl=heap optim.f90
>
One can verify that the routines to allocate the trampoline on the heap (i.e. __gcc_nested_func_ptr_*) are now used:
> gfortran -ftrampoline-impl=stack optim.f90
/usr/bin/ld: warning: /tmp/ccxoR5pl.o: requires executable stack (because the .note.GNU-stack section is executable)
> nm -u a.out
U _gfortran_set_args@GFORTRAN_8
U _gfortran_set_options@GFORTRAN_8
w __gmon_start__
U __libc_start_main@GLIBC_2.34
> gfortran -ftrampoline-impl=heap optim.f90
> nm -u a.out
U __gcc_nested_func_ptr_created@GCC_14.0.0
U __gcc_nested_func_ptr_deleted@GCC_14.0.0
U _gfortran_set_args@GFORTRAN_8
U _gfortran_set_options@GFORTRAN_8
w __gmon_start__
U __libc_start_main@GLIBC_2.34
To verify you can also look into the ELF binary with the command readelf -l <binary>,
With gfortran -ftrampoline-impl=stack:
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RWE 0x10
RWE for Read,Write,Execute
With gfortran -ftrampoline-impl=heap
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
The E is gone now.
With ifx I get no linker warning, and readelf -l shows:
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
Same for nagfor, no linker warning, and only read,write:
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10