On Fri, 10 Feb 2023 12:32:28 -0500, Tony Harminc wrote: >On Fri, 10 Feb 2023 at 12:25, Paul Gilmartin wrote: > ... >> when the functions are inlined there is no entry point for them, no FPB or >> FEPM compiler control data generated for them, etc. >> > ... >> That's just wrong. Even if the compiler intends to generate inline code >> for calls to a function, it >> should generate an externally callable entry name, perhaps to an inline >> code body, regardless of >> optimization level. > >Really? What would that be useful for? Pretty much by definition inlined >code doesn't have documented calling conventions (indeed they may well vary >each time the inlined code is emitted depending on context). I suppose it >would be good for there to be an external name for the places the inlined >function is called (an ER style entry), but surely not for the actual >inlined code. > My [mis-]understanding was that when you coded the function, not specified "inline", you intended that it be callable from external translation units, but the compiler frustrated this by willy-nilly making it purely inline.
I would expect that if you declared the function in standard fashion (was there a prototype?), the compiler would generate one externally callable instance then generate inline code for calls ad lib. This is similar to the POSIX specification that an implementer may code a standard functions as shell builtins but there must still be instances callable by the exec() family of functions. (Frequently those are implemented as "system( "sh -c " argv[ 0 ] )".) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
