https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|ld warning about executable |Nested function use gives a
|stack, follows from PR |ld warning about executable
|117434 |stack, after binutils 2.39
Depends on|117434 |
Keywords| |diagnostic
Component|fortran |target
Target| |x86_64-linux
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=117434
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
Actually,
* this is not specifically a fortran issue - the effect repeats complete with
a standard C nested function test:
./gcc/xgcc -Bgcc ../../test/nested/nest.c -o nc
/home/iains/gcc-master/gcc-15-0-0/x86_64-pc-linux-gnu/bin/ld: warning:
/tmp/ccyi2jqH.o: requires executable stack (because the .note.GNU-stack section
is executable)
* neither does it depend on 117434. although that does show the effect (I
would expect other fortran tests could quite easily use nested function
support).
=====
To make heap-based trampolines the default for a platform needs the platform
maintainers to agree that's the right course of action (and support to be
written if it's not already there). Apart from Darwin, where we had no choice,
that's also out of my pay grade.
======
But local to gfortran, you have some immediate options:
1. You could just add the appropriate flags to the test-case(s) to suppress
the warning (having decided, perhaps that fixing it is outside the purview of
gfortran).
2. you could decide to do (1) for every Fortran build by adding the relevant
option to the gfortran link specs. (would have to to be a configure-determined
action).
3. you could apply -ftrampoline-impl=heap instead of suppressing the warning
(on platforms that support it) - again this would need some configure-time
discovery if you wanted to add it to the link spec. [either to specific tests
or generally for gfortran].
(1) is clearly the least invasive solution - but it does mean that end-users
might well see the warning when building similar Fortran.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
[Bug 117434] [F08] gfortran rejects actual argument corresponding to procedure
pointer dummy argument
