https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Sat, 9 Nov 2024, iains at gcc dot gnu.org wrote: > 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]. With LTO there might be the need to support mixed operation - ideally we'd have a per-call way of specifying the trampoline type. The ABI on the callee side isn't necessarily the same between the two though (is it on x86?), so it might be more like a function attribute of the nested function [type] itself.
