On Wed, 2022-02-02 at 17:14 +0000, Qing Zhao wrote:
> Hi, David,
> 
> Thank you for fixing this issue!
> 
> > On Feb 2, 2022, at 9:06 AM, David Malcolm via Gcc-patches <
> > gcc-patches@gcc.gnu.org> wrote:
> > 
> > GCC 12 has gained two features for dealing with uninitialized
> > variables:
> > 
> > (a) a new -Wanalyzer-use-of-uninitialized-value warning within
> > -fanalyzer
> > for interprocedural path-sensitive detection of ununit uses, and
> > 
> > (b) a new -ftrivial-auto-var-init option for mitigating some uses
> > of
> > uninit variables
> > 
> > It turns out that using (b) was thwarting (a), as it led to
> > -fanalyzer
> > seeing calls to IFN_DEFERRED_INIT, which -fanalyzer wasn't
> > special-casing, thus treating it as initializing the variables in
> > question, and thus silencing -Wanalyzer-use-of-uninitialized-value
> > on
> > them.
> > 
> > invoke.texi says:
> > 
> > "GCC still considers an automatic variable that doesn't have an
> > explicit
> > initializer as uninitialized, @option{-Wuninitialized} will still
> > report
> > warning messages on such automatic variables."
> > 
> > and thus -Wanalyzer-use-of-uninitialized-value ought to as well.
> 
> Then should we updated the invoke.texi to include this as well?

Good point; I've taken the liberty of pushing the following to trunk
as a followup (as r12-7007-gfb45d8e692d41d)

Thanks
Dave

gcc/ChangeLog:
        PR analyzer/104270
        * doc/invoke.texi (-ftrivial-auto-var-init=): Add reference to
        -Wanalyzer-use-of-uninitialized-value to paragraph documenting that
        -ftrivial-auto-var-init= doesn't suppress warnings.

Signed-off-by: David Malcolm <dmalc...@redhat.com>
---
 gcc/doc/invoke.texi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index cfd415110cd..b1b8cc806c7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12304,7 +12304,8 @@ Initialize automatic variables with either a pattern or 
with zeroes to increase
 the security and predictability of a program by preventing uninitialized memory
 disclosure and use.
 GCC still considers an automatic variable that doesn't have an explicit
-initializer as uninitialized, @option{-Wuninitialized} will still report
+initializer as uninitialized, @option{-Wuninitialized} and
+@option{-Wanalyzer-use-of-uninitialized-value} will still report
 warning messages on such automatic variables.
 With this option, GCC will also initialize any padding of automatic variables
 that have structure or union types to zeroes.
-- 
2.26.3

Reply via email to