https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Torbjorn SVENSSON from comment #9) > Lets consider that my vendor provided toolchain comes with newlib compiled > with -flto -ffat-lto-objects (and that the function calling main is written > in C using the `int main(int,char**)` signature). > > In my application, I'm using the signature `int main()`. > > When I build my application, everything goes well (no warning at least) as > long as I do not use -flto. If I decide to enable LTO using the -flto > compiler option, then I suppose the warning is generated as the signature > for "main" in my application differs from what was included in the library > (newlib in this scenario). > > Is this scenario supposed to work or fail? And you misunderstood my point. You either have a hosted env where main is the start function or your have a freestanding env where it is implement defined (in the case of GCC/GNU LD, it can be named anything aka a custom start function). If you have freestanding env, then main is just a name of a normal function and unrelated to a hosted env. So it becomes undefined behavior if you call main with a different argument types than what it is defined as. So basically the start function can't be in LTO because otherwise it becomes known to the compiler and main is just a normal function then.
