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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to