https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #21 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:3f3246eb16f554c70c5ce87ad2c785f83adb4625
commit r12-7411-g3f3246eb16f554c70c5ce87ad2c785f83adb4625
Author: Qing Zhao
Date: Mon Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #20 from Qing Zhao ---
> On Feb 21, 2022, at 1:56 AM, rguenth at gcc dot gnu.org
> wrote:
>>
>> my question is, is the "info" in __builtin_clear_padding(&info) a REAL use
>> of "info"? is it correct to report the uninitialized use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #19 from Richard Biener ---
(In reply to qinzhao from comment #18)
> One question here, for the following testing case:
>
> [opc@qinzhao-ol7u9 104550]$ cat t1.c
> struct vx_audio_level {
> int has_monitor_level : 1;
> };
>
> void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #18 from qinzhao at gcc dot gnu.org ---
One question here, for the following testing case:
[opc@qinzhao-ol7u9 104550]$ cat t1.c
struct vx_audio_level {
int has_monitor_level : 1;
};
void vx_set_monitor_level() {
struct vx_audio_le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #17 from qinzhao at gcc dot gnu.org ---
So, based on the discussion so far, I'd like to take the following steps:
1. In GCC12, I will take a conservative solution to fix this bug, i.e:
mark the load "MEM" as not needing a warning du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #16 from rguenther at suse dot de ---
On Thu, 17 Feb 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
>
> --- Comment #15 from Jakub Jelinek ---
> (In reply to qinzhao from comment #11)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #15 from Jakub Jelinek ---
(In reply to qinzhao from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > Even in that case, filling the memory with pattern & mask instead of filling
> > the memory with pattern + __builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #14 from Qing Zhao ---
> On Feb 17, 2022, at 1:54 AM, rguenther at suse dot de
> wrote:
>>
>> If padding clearing is exposed too late till RTL expansion, some tree
>> optimization will not be able to be applied on the expanded sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #13 from rguenther at suse dot de ---
On Wed, 16 Feb 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
>
> Jakub Jelinek changed:
>
>What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #12 from rguenther at suse dot de ---
On Wed, 16 Feb 2022, qinzhao at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
>
> --- Comment #7 from qinzhao at gcc dot gnu.org ---
> (In reply to rguent...@suse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)
> Even in that case, filling the memory with pattern & mask instead of filling
> the memory with pattern + __builtin_clear_padding afterwards seems l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #10 from Jakub Jelinek ---
Even in that case, filling the memory with pattern & mask instead of filling
the memory with pattern + __builtin_clear_padding afterwards seems like a win.
Sure, in some cases combine etc. will be able to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Well, for the .DEFERRED_INIT case if the var ends up in memory, I really
> don't see the point in any clear_padding, .DEFERRED_INIT expansion should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #6)
> > --- Comment #4 from Andrew Pinski ---
> > Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct
> > vx_audio_level *)&info]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #6 from rguenther at suse dot de ---
> Am 15.02.2022 um 22:38 schrieb pinskia at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
>
> Andrew Pinski changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #5 from Qing Zhao ---
> On Feb 15, 2022, at 3:38 PM, pinskia at gcc dot gnu.org
> wrote:
> Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct
> vx_audio_level *)&info]" as not needing a warning.
>
This sound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #4 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #3 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is due to the new call to __builtin_clear_padding
added by -ftrivial-auto-var-init=pattern, this is treated as a use of the
uninitialized variable during early uninit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-02-15
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #1 from qinzhao at gcc dot gnu.org ---
Kees reported the following issue with -ftrivial-auto-var-init=pattern. the
testing case was reduced from Kernel building.
$ cat warns.i
struct vx_audio_level {
int has_monitor_level : 1;
};
22 matches
Mail list logo
