Re: [PATCH] avoid -Wnonnull for printf format in dead code (PR 87041)

[Christophe Lyon <christophe dot lyon at linaro dot org>]

On Tue, 30 Oct 2018 at 20:07, Jeff Law <law@redhat.com> wrote:
>
> On 10/29/18 3:59 PM, Martin Sebor wrote:
> > PR 87041 - -Wformat "reading through null pointer" on unreachable
> > code is a complaint about -Wformat false positives due to null
> > arguments to %s directives in unreachable printf calls.  The warning
> > is issued by the front end, too early to know whether or not the call
> > is ever made.
> >
> > The -Wformat-overflow has had the ability to detect null pointers
> > in %s and similar directives to sprintf calls since GCC 7 without
> > these false positives, but the warning doesn't consider stream or
> > file I/O functions like printf/fprintf.  To resolve the bug report
> > I have enhanced -Wformat-overflow to consider all printf-like
> > functions, including user-defined ones declared attribute format
> > (printf).
> >
> > Besides null pointers the enhancement also makes it possible to
> > detect other problems (like out-of-range arguments and output in
> > excess of INT_MAX bytes).  It also lays the groundwork for
> > checking user-defined printf-like functions for buffer overflow
> > (once a suitable attribute is added to indicate which arguments
> > are the destination buffer pointer and the buffer size).
> >
> > With that, I have removed the null checking from -Wformat (again,
> > only for printf-like functions).
> >
> > Martin
> >
> > gcc-87041.diff
> >
> > PR middle-end/87041 - -Wformat reading through null pointer on unreachable code
> >
> > gcc/ChangeLog:
> >
> >       PR middle-end/87041
> >       * gimple-ssa-sprintf.c (format_directive): Use %G to include
> >       inlining context.
> >       (sprintf_dom_walker::compute_format_length):
> >       Avoid setting POSUNDER4K here.
> >       (get_destination_size): Handle null argument values.
> >       (get_user_idx_format): New function.
> >       (sprintf_dom_walker::handle_gimple_call): Handle all printf-like
> >       functions, including user-defined with attribute format printf.
> >       Use %G to include inlining context.
> >       Set POSUNDER4K here.
> >
> > gcc/c-family/ChangeLog:
> >
> >       PR middle-end/87041
> >       * c-format.c (check_format_types): Avoid diagnosing null pointer
> >       arguments to printf-family of functions.
> >
> > gcc/testsuite/ChangeLog:
> >
> >       PR middle-end/87041
> >       * gcc.c-torture/execute/fprintf-2.c: New test.
> >       * gcc.c-torture/execute/printf-2.c: Same.
> >       * gcc.c-torture/execute/user-printf.c: Same.
> >       * gcc.dg/tree-ssa/builtin-fprintf-warn-1.c: Same.
> >       * gcc.dg/tree-ssa/builtin-printf-2.c: Same.
> >       * gcc.dg/tree-ssa/builtin-printf-warn-1.c: Same.
> >       * gcc.dg/tree-ssa/user-printf-warn-1.c: Same.
> OK.
>

Hi,

I've noticed failure on targets using newlib (aarch64-elf and arm-eabi):
FAIL: gcc.c-torture/execute/printf-2.c
FAIL: gcc.c-torture/execute/user-printf.c

my gcc.log contains:
gcc.c-torture/execute/user-printf.c   -O0  execution test (reason: TCL
LOOKUP CHANNEL exp5)
which is not very helpful


> Note some folks might complain about dropping the warning from the
> front-end.  Their (largely reasonable) argument is that warning out of
> the front-end is stable across releases and doesn't depend on
> optimizations.  Of course the downside of warning out of the front-end
> is false positives like we see in this PR.
>
> jeff