[PATCH] D117717: [clang] Ignore -fconserve-stack

Wed Jan 19 14:03:13 PST 2022

nathanchance added a comment.

In D117717#3256180 <https://reviews.llvm.org/D117717#3256180>, @MaskRay wrote:

> Clang has a long list of ignored options but most were added during the catch-up phase when Clang strove to be a competitor compiler.
> I think for new ignored options there needs to be some higher standard.
> From Debian Code Search https://codesearch.debian.net/search?q=fconserve-stack&literal=0&page=2 and internal code search, I believe this is a fairly obscure option.
> Shall we fix the projects instead?

I'll give a little background:

The Linux kernel has a `make` macro called `cc-option` that invokes the compiler with a flag and if the flag is supported, it adds it to the kernel's CFLAGS variable. Nick recently went through and cleaned up the use of this macro, as it can slow down build times if it is used excessively, especially with incremental compiles because this macro runs during each invocation of `make`: https://git.kernel.org/linus/7d73c3e9c51400d3e0e755488050804e4d44737a. This flag was one of the ones that was cleaned up; it was moved into a block that is only built when GCC is used as the compiler because we know this flag is not supported with `clang` so there is no point in testing for it. However, this caused issues with `scan-build`, as GCC is used as the compiler but `clang` is invoked after it with all the `-f` options that GCC was.

The kernel can add back the `cc-option` call (and likely will to workaround this problem) but all that is going to do is drop this flag during the `scan-build` process, which may result in higher stack usage.

Should we just tell people to run `scan-build` only with `clang`? How `ccc-analyzer` works seems weird to me but I assume some of the flag machinery that is present here is for that reason?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117717/new/

https://reviews.llvm.org/D117717