[cfe-dev] making -ftrivial-auto-var-init=zero a first-class option

[Michael Kruse via cfe-dev]

Am Di., 21. Apr. 2020 um 18:42 Uhr schrieb Richard Smith via cfe-dev
<cfe-dev at lists.llvm.org>:
> A major part of the purpose of point 4 of the policy is to prevent creation of language dialects, such as have unfortunately been created by (for example) the -fno-exceptions and -fno-rtti flags. If people can rely on uninitialized variables behaving as if initialized to zero, then they will write code that assumes that to be the case, and such code will not work in compilers / compilation modes that don't provide that language dialect. If people cannot rely on uninitialized variables behaving as if initialized to zero, then we mitigate the risk of creating a language dialect.

The compiler can do anything it wants for something the specification
says is undefined behavior. If the programmer wants to write a
portable program, they should not rely such behavior and diagnostics
such as compiler warnings and the sanitizers may assist with the goal.

If you argue that it is possible to write programs that compile fine
with one compiler, but miscompiles with another, this has always been
the case To quote Chris Lattner [1]:

> It is also worth pointing out that both Clang and GCC nail down a few behaviors that the C standard leaves undefined. The things I'll describe are both undefined according to the standard and treated as undefined behavior by both of these compilers in their default modes.

I don't think we can (or should) prevent users to shoot themselves
into the foot.
The one concern I would have that we introduce another "compile mode"
that yields different output. But so is -O0, -O1, O2, -O3, -Oz, -Os,
-g, -march, -fno-unroll-loops, -fno-vectorize, ... and we never seemed
to have an issue with those.

Michael


[1] http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html