alexfh wrote: > Just out of curiosity, could implementing this warning to be LTO only solve > this? Anything requiring whole-program analysis sounds like a task to be done > during LTO. IIRC GCC has some warnings that are only made possible by LTO.
I don't think this would be the right direction. First of all, LTO is inherently a more expensive build mode, which (in my surroundings at least) is mostly used for releases, but not in the normal development cycle. Making this diagnostic LTO-only will shift the moment when the corresponding issues are found from development to release build, breaking the latter without showing up earlier. If the release builds are performed automatically on a certain schedule, this will be a very unfortunate moment for the first detection of these problems. I personally think that relying on explicit `[[noreturn]]` attributes and the `-Wmissing-noreturn` diagnostic to suggest annotating functions that never return should be a more robust approach with less undesired surprises. https://github.com/llvm/llvm-project/pull/145166 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits