[Bug c/105539] New: -ftrivial-auto-var-init=zero happening too late?

[Bug c/105539] New: -ftrivial-auto-var-init=zero happening too late?

[kees at outflux dot net]

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

            Bug ID: 105539
           Summary: -ftrivial-auto-var-init=zero happening too late?
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kees at outflux dot net
  Target Milestone: ---

It looks like some pass is being run before the initializers are added:

int x (int z) {
    int y;
    if (z)
        y = 10;
    return y;
}

under "gcc -ftrivial-auto-var-init=zero -Wuninitialized -O2" does not test "z":

$ gcc -ftrivial-auto-var-init=zero -Wuninitialized -O2 -S x.c -o -
...
        movl    $10, %eax
        ret
...

This should be testing "z", e.g.:

        testl   %edi, %edi
        movl    $10, %eax
        cmovel  %edi, %eax
        retq

[Bug c/105539] -ftrivial-auto-var-init=zero happening too late?

[kees at outflux dot net]

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

--- Comment #1 from Kees Cook <kees at outflux dot net> ---
(Also this doesn't warn about y being used uninitialized.)

[Bug c/105539] -ftrivial-auto-var-init=zero happening too late?

[kees at outflux dot net]

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

--- Comment #2 from Kees Cook <kees at outflux dot net> ---
https://godbolt.org/z/99Pdro9Te

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Not really, Fre considers the defered init as being uninitialized still and
then does optimization based on that.

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
it does do the job in preventing uninitialized stack slots.  It does not
prevent optimization to occur based on the undefined behavior.

I think that was exactly the constraints you outlined - it does _not_ make
uninit uses well-defined?

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qinzhao at gcc dot gnu.org

--- Comment #5 from qinzhao at gcc dot gnu.org ---
I am a little confused:

with gcc -Wuninitialized -O1 (without -ftrivial-auto-var-init=zero), there are
two issues:

1. the early uninitialized analysis didn't catch the uninitialized usage of y;


2. the ccp optimization deletes the if (z) statement completely:

[opc@qinzhao-aarch64-ol8 105539]$ cat t.c.034t.ccp1

;; Function x (x, funcdef_no=0, decl_uid=3591, cgraph_uid=1, symbol_order=0)

Removing basic block 3
Merging blocks 2 and 4
int x (int z)
{
  int y;

  <bb 2> :
  return 10;

}

are the above two bugs?

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[qinzhao at gcc dot gnu.org]

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #5)
> I am a little confused:
> 
> with gcc -Wuninitialized -O1 (without -ftrivial-auto-var-init=zero), there
> are two issues:
> 
> 1. the early uninitialized analysis didn't catch the uninitialized usage of
> y;
> 
> 
> 2. the ccp optimization deletes the if (z) statement completely:
> 
> [opc@qinzhao-aarch64-ol8 105539]$ cat t.c.034t.ccp1
> 
> ;; Function x (x, funcdef_no=0, decl_uid=3591, cgraph_uid=1, symbol_order=0)
> 
> Removing basic block 3
> Merging blocks 2 and 4
> int x (int z)
> {
>   int y;
> 
>   <bb 2> :
>   return 10;
> 
> }
> 
> are the above two bugs?

Is this because that "y" is uninitialized, so the behavior of this program is
undefined? then the above 2 is okay, but 1 is still an issue?

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[kees at outflux dot net]

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

--- Comment #7 from Kees Cook <kees at outflux dot net> ---
Right, perhaps I should rename this bug? The much more surprising thing is the
lack of warning about the uninit use. With or without -ftrivial-auto-var-init,
I'd want to have the diagnostic that a UB may have happened.

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to qinzhao from comment #5)
> I am a little confused:
> 
> with gcc -Wuninitialized -O1 (without -ftrivial-auto-var-init=zero), there
> are two issues:
> 
> 1. the early uninitialized analysis didn't catch the uninitialized usage of
> y;

It's a conditional uninit use which we do not warn on early by design
(for the fear of too many false positives, that is).

> 2. the ccp optimization deletes the if (z) statement completely:
>
> [opc@qinzhao-aarch64-ol8 105539]$ cat t.c.034t.ccp1
> 
> ;; Function x (x, funcdef_no=0, decl_uid=3591, cgraph_uid=1, symbol_order=0)
> 
> Removing basic block 3
> Merging blocks 2 and 4
> int x (int z)
> {
>   int y;
> 
>   <bb 2> :
>   return 10;
> 
> }

That's expected from optimistic lattice propagation which merges TOP with
the constant.

> are the above two bugs?

Well, it works as designed.  But sure, that we fail to diagnose the uninit
use is unfortunate and there exist bugs for this specific issue already.

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

[qing.zhao at oracle dot com]

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

--- Comment #9 from Qing Zhao <qing.zhao at oracle dot com> ---
> It's a conditional uninit use which we do not warn on early by design
> (for the fear of too many false positives, that is).
Okay. 
> 
>> 2. the ccp optimization deletes the if (z) statement completely:
>> 
>> [opc@qinzhao-aarch64-ol8 105539]$ cat t.c.034t.ccp1
>> 
>> ;; Function x (x, funcdef_no=0, decl_uid=3591, cgraph_uid=1, symbol_order=0)
>> 
>> Removing basic block 3
>> Merging blocks 2 and 4
>> int x (int z)
>> {
>>  int y;
>> 
>>  <bb 2> :
>>  return 10;
>> 
>> }
> 
> That's expected from optimistic lattice propagation which merges TOP with
> the constant.

If y is initialized to 0 at declaration site, the “if z” statement is NOT
deleted by CCP. 

However, per design of -ftrivial-auto-var-init, we intent to not treat

y = .DEFERRED_INIT (4, 2, &"y"[0]);
Same as
y= 0 

In order to keep -Wuninitialized warning analysis working as expected.

So, yes, I agree that this issue is unavoided based on the current design. 

> 
>> are the above two bugs?
> 
> Well, it works as designed.  But sure, that we fail to diagnose the uninit
> use is unfortunate and there exist bugs for this specific issue already.