https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #15 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:dbaabd06aaf4a1b0f2a20671c39148a0bd6ccf0e
commit r12-7452-gdbaabd06aaf4a1b0f2a20671c39148a0bd6ccf0e
Author: Qing Zhao
Date: Wed Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #4 from Kees Cook ---
The kernel keeps gaining more of these cases, so it'll be important to get this
fixed:
https://lore.kernel.org/lkml/200fe5cb203ad5cc00c5c60b7ded2cd85c9b85ea.ca...@perches.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Andrew Pinski changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #6 from Richard Biener ---
It's difficult, see the recent discussion on introducing explicit live-in
markers for the purpose of stack slot sharing and exactly these case of
testcases.
The "simplest" suggestion was to promote the var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> If we just want to avoid the warning in cases like that (there is nothing
> wrong in the testcases themselves, the warning just warns about an
> impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #9 from qinzhao at gcc dot gnu.org ---
having a patch in my local tree, under testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #10 from rguenther at suse dot de ---
On Mon, 14 Feb 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
>
> Jakub Jelinek changed:
>
>What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #10)
> I think it definitely makes sense to diagnose that we are not
> following -ftrivial-auto-init-var=X for a decl. Maybe we should
> do that wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #12 from qinzhao at gcc dot gnu.org ---
I will go with the following solution:
1. avoid emitting switch-unreachable warnings for -ftrivial-auto-var-init;
2. adding a new option -Wtrivial-auto-var-init to emit warnings for the
switch-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #13 from rguenther at suse dot de ---
On Tue, 15 Feb 2022, qinzhao at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
>
> --- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to rguent...@sus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #14 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also
> avoid warnings on:
> 1) call to .DEFERRED_INIT
> 2) call to __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #2 from Alexander Monakov ---
That -ftrivial-auto-var-init places an initialization at the point of the
declaration is an implementation detail: there's no initializer in the testcase
itself, so it is valid C and C++ (spelling this o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #3 from
16 matches
Mail list logo