[PATCH] init/Kconfig: remove CONFIG_GCC_ASM_GOTO_OUTPUT_WORKAROUND

Linus Torvalds torvalds at linux-foundation.org
Thu Jul 18 09:59:39 PDT 2024


On Thu, 18 Jul 2024 at 05:07, Mark Rutland <mark.rutland at arm.com> wrote:
>
>  config CC_HAS_ASM_GOTO_OUTPUT
> +       # Fixed in GCC 14, 13.3, 12.4 and 11.5
> +       # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
> +       default n if CC_IS_GCC && GCC_VERSION < 110500
> +       default n if CC_IS_GCC && GCC_VERSION >= 120000 && GCC_VERSION < 120400
> +       default n if CC_IS_GCC && GCC_VERSION >= 130000 && GCC_VERSION < 130300
>         def_bool $(success,echo 'int foo(int x) { asm goto ("": "=r"(x) ::: bar); return x; bar: return 0; }' | $(CC) -x c - -c -o /dev/null)

I'll edit this all a bit, because I don't love complicated config entries.

Let's keep the "which gcc versions are scrogged" as a separate config
entry, and then have this just as a

     default n if CC_IS_GCC && GCC_NO_ASM_GOTO_OUTPUTS

because we've been here before with the whole "gcc version tests", and
it got ugly, and we have that whole "CC_NO_ARRAY_BOUNDS" where we went
back and forth on different gcc versions, and it was just really
annoying.

So then we learnt our lesson, and for the stringop overflow code we do

  # Currently, disable -Wstringop-overflow for GCC globally.
  config GCC_NO_STRINGOP_OVERFLOW
          def_bool y

so that we can make any possible future "this gcc version is good /
bad" in one clear place, and we have

  config CC_NO_STRINGOP_OVERFLOW
          bool
          default y if CC_IS_GCC && GCC_NO_STRINGOP_OVERFLOW

which is readable and understandable and if clang - or some other
compiler - were to add their own issues, it would still be readable
and understandable, and not some complicated mess.

Of course, once we _did_ learn our lesson about gcc versions, that
-Wstringop-overflow hasn't actually gotten any more complex
afterwards, so the *one* place we do this right didn't actually need
it. Yet.

              Linus



More information about the linux-arm-kernel mailing list