[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

Tue May 10 04:12:35 PDT 2022

aaron.ballman added a comment.

In D125142#3502732 <https://reviews.llvm.org/D125142#3502732>, @MaskRay wrote:

> This cannot be committed as is. In particular, @rsmith's "We do not want to create or encourage the creation of language dialects and non-portable code," concern on https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/2 (shared by someone else) will be affected, I'd like to see that they lift their concerns.

I'd also like to hear from them, but at the time those comments were made, GCC did not have support for this feature. Now that GCC does, the dialect exists in the wild and we can either choose to support the dialect or not. Given our historical interest in GCC compatibility, I think we need to reweigh the comments in the RFC against the new reality.

>> GCC 12 has been released and contains unconditional support for
>
> -ftrivial-auto-var-init=zero: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>
>> Maintain compatibility with GCC, and remove the -enable flag for "zero" mode. The flag is left to generate an "unused" warning, though, to not break all the existing users. The flag will be fully removed in Clang 17.
>
> I think this is insufficient justification.

Why? It's not been insufficient for many other things in Clang and we go out of our way to document that we want driver-level compatibility (https://clang.llvm.org/docs/DriverInternals.html#gcc-compatibility). Given that we already have this feature, I don't see justification for why we should be driver-compatible but not expose the functionality to users (that would be user-hostile).

> People's objection should be addressed (either they are now completely fine without the long option, or they accept the compromise) before proceeding. The summary needs to mention this point.

I agree that we should still take the feedback from the RFC seriously. Also, if this is for GCC compatibility, I think we need to be very sure that our semantics match GCC's -- it would be even worse to expose the same flag but it initializes a different set of objects between the compilers. I'm not certain if we have the test coverage demonstrating that.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142