https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 11 Nov 2024, iains at gcc dot gnu.org wrote: > 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? 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? I was thinking of inlining the callers of nested functions from two TUs into the same function. Dependent of whether the choice of stack vs. heap trampoline is already reflected into the IL during nested function lowering or only at RTL expansion time this might or might not be an "interesting" setup (we can of course chose to not inline functions with nested function call ABI differences into the same function). That is, I was wondering whether having a per-function -ftrampoline-impl= flag would work without any other changes - currently it's a TU wide flag but we do not enforce it to be the same during LTO options processing (lto-wrapper.cc:merge_and_complain), so the "first" TU wins in setting the LTRANS stages flag. Richard.
