[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #9 from Qing Zhao ---
> 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;
>>
>> :
>> 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.
[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #8 from Richard Biener ---
(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;
>
>:
> 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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539 --- Comment #7 from Kees Cook --- 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?
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;
>
>:
> 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?
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;
:
return 10;
}
are the above two bugs?
[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- 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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539 --- Comment #3 from Andrew Pinski --- Not really, Fre considers the defered init as being uninitialized still and then does optimization based on that.
