Georg-Johann Lay via Gcc <[email protected]> writes: > Am 05.05.26 um 19:05 schrieb Richard Biener: >> On Tue, May 5, 2026 at 5:41 PM Georg-Johann Lay via Gcc <[email protected]> >> wrote: >>> >>> In the avr backend there is a static variable avr_no_call_main_p that >>> is set in TARGET_INSERT_ATTRIBUTES and used in TARGET_ASM_FILE_END. >>> >>> This works as expected in non-LTO compilations, with LTO however, >>> TARGET_INSERT_ATTRIBUTES runs in cc1[plus] but TARGET_ASM_FILE_END >>> is run by lto1, hence the variable is not set as expected. >>> >>> What's the recommended way to handle such a situation? >> Without looking too closely I assume there's an actual attribute >> somewhere >> (on the main function decl?). Instead of using a global variable you'd >> check for the presence of the attribute. Now - the question is whether >> the TARGET_ASM_FILE_END behavior is only required in the TU with >> the main() definition? In that case this should work. > > What works is to attach a new attribute to main when the conditions are > right, then check for that attribute in, say, > TARGET_DECLARE_FUNCTION_NAME and set a variable accordingly, and then > check for that var in TARGET_ASM_FILE_END. > > What's a bit ugly is that it requires a new target attribute that's only > for internal usage and should not to be set by the user. Maybe not > document it is okay then. > > Is there some policy for such internal-use-only function attributes?
I believe we do " name". > > Johann > >> I see you emit a special symbol conditional so what you can also do is >> create that as a global variable in the symbol table and rely on the >> middle-end >> to output it.
signature.asc
Description: PGP signature
