nickdesaulniers wrote: Hey, sorry for [suggesting](https://github.com/llvm/llvm-project/pull/174892#issuecomment-3753254069) we elide `-fdiagnostics-show-inlining-chain`, i.e.
> In that case, @JustinStitt WDYT about just attaching the note about > -gline-directives-only to WarningAttr (and thus eliding the addition of > -fdiagnostics-show-inlining-chain? _then stepping away from upstream reviews here for over 2 months_. I'm back at Google now, managing Android's LLVM team, so I should have more time for reviews now (famous last words). > but otherwise I want it off by default. Understandable; don't pay for what you don't use. I guess I didn't consider that perspective enough when I made my above sugguestion. In that case, we'd need to _go back to having an explicit flag (`-fdiagnostics-show-inlining-chain`)_ that we could keep off by default, then the Linux kernel could enable explicitly via feature detecting support for the command line flag. >> I think ~1% memory overhead is acceptable given the benefits >> I think these attributes are used outside of the kernel too. > A large fraction of those uses are using it in a way that doesn't benefit > from this patch. I agree with @efriedma-quic here; the point is really to help someone writing code that calls libc standard library functions that have a _particular implementation of FORTIFY_SOURCE_. It's conceivable that other libc implementations don't have FORTIFY_SOURCE, or their implementation wouldn't benefit from this. Also conceivable that these inline hints are helpful for other diagnostics than `-Wwarning`/`-Werror`, but that's a stretch. --- So, again, sorry for derailing this with a half baked suggestion, then running off. Perhaps if @efriedma-quic and @AaronBallman could agree with us going back to having an explicit off-by-default `-fdiagnostics-show-inlining-chain` and @JustinStitt doesn't mind going back to that version, then that would be a compromise that makes everyone happy, so that we can unstick this, and we can better help Linux kernel developers better spot their known at compile time bounds overflows? https://github.com/llvm/llvm-project/pull/174892 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
