https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #8) > 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: > > > > 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. AFAIU, we do not allow a nested function pointer to escape from the function in which it is defined - to do so would break the assumptions of nested model, I think, right? So the model used would be Tu-local already; if there's a way in which LTO could cause the nested fn ptr to effectively escape from its containing fn then that needs some extra thinking?
