[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

[qinzhao at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210

--- Comment #6 from qinzhao at gcc dot gnu.org ---
So, based on the previous discussion on the LLVM option 
-ftrivial-auto-var-init=[uninitialized|pattern|zero]

we can see:
-ftrivial-auto-var-init=pattern 

might not be a good idea due to the following:

1. performance data is not good;
2. doesn't really help improve the general situation. People see it as a
debugging tool, not a "improve code quality and improve the life of kernel
developers" tool. (Per Linus)

On the other hand,
-ftrivial-auto-var-init=zero

might be helpful to improve code quality and improve the life fo kernel
developers. 

At the same time, a new variable attribute might be needed at the same time
along with -ftrivial-auto-var-init=zero:

__attribute((uninitialized) 

to mark variables that are uninitialized intentionally for performance purpose.

In a summary, in GCC, we should provide:
1. add a new GCC option: -ftrivial-auto-var-init to initialize trivial auto
variable to zero.
2. provide a new attribute for variable: __attribute((uninitialized) to mark
variables that are uninitialized intentionally for performance purpose.

[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210

Andrew Pinski  changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #5 from Andrew Pinski  ---
*** Bug 94855 has been marked as a duplicate of this bug. ***

[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

[glider at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210

Alexander Potapenko  changed:

   What|Removed |Added

 CC||glider at google dot com

--- Comment #4 from Alexander Potapenko  ---
To give an update, upstream Clang now supports force initialization of stack
variables under the -ftrivial-auto-var-init flag.

-ftrivial-auto-var-init=pattern initializes local variables with a 0xAA pattern
(actually it's more complicated, see https://reviews.llvm.org/D54604)

-ftrivial-auto-var-init=zero provides zero-initialization of locals. This mode
isn't officially supported yet and is hidden behind an additional
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang flag.
This is done to avoid creating a C++ dialect where all variables are
zero-initialized.

Starting v5.2, Linux kernel has a CONFIG_INIT_STACK_ALL config that performs
the build with -ftrivial-auto-var-init=pattern. This one isn't widely adopted
yet, partially because initializing locals with 0xAA isn't fast enough.

Linus Torvalds is quite positive about zero-initializing the locals though, see
https://lkml.org/lkml/2019/7/30/1303

So having a flag similar to -ftrivial-auto-var-init=zero in GCC will be
appreciated by the Linux kernel community.

[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

[pjp at fedoraproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210

--- Comment #3 from P J P  ---
Similar options under review for LLVM
  -> https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html

[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210

--- Comment #2 from joseph at codesourcery dot com  ---
On Mon, 3 Sep 2018, pjp at fedoraproject dot org wrote:

> As from the reply, it would be nice to have four options/features available
> from the compiler, from least to most performance impact:
> 
>  - initialize padding to zero when static initializers are used (this would 
>make foo = { .field = something }; identical to memset(, 0, 
>sizeof(foo)); foo.field = something for all structures, but now, any 
>structures with padding _must_ use the latter to be safe, which is highly 
>error-prone).

Presumably that sort of thing would need to come with a guarantee that 
SRA, structure assignment etc. preserve padding (rather than padding 
contents potentially being lost if a structure is subject to SRA)?

(Both are effectively treating padding like additional named fields for 
the purposes of code generation but without affecting what fields the 
front end associates initializers with.  I'd expect the performance costs 
of such guarantees associated with padding to be small.)

[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210

--- Comment #1 from Andrew Pinski  ---
http://wiki.c2.com/?TheKenThompsonHack