Re: PR c/16351 Extend Wnonnull for returns_nonnull

[Jeff Law <law at redhat dot com>]

On 07/24/2015 04:41 PM, Manuel LÃpez-IbÃÃez wrote:
> On 25 July 2015 at 00:17, Patrick Palka <patrick@parcs.ath.cx> wrote:
> > On Fri, Jul 24, 2015 at 5:55 PM, Manuel LÃpez-IbÃÃez
> > <lopezibanez@gmail.com> wrote:
> > Is there a PR for this particular test case?  I am interested in
> > improving the uninit analysis for gcc 6 so this potentially seems up
> > my alley.
>
> We do not warn because of the infamous PR18501 (probably the
> -Wuninitialized bug with the highest number of duplicates), where CPP
> removes the default SSA definition of n and simply returns 1
> unconditionally. But fixing PR18501 may not be necessary to detect
> this case (Clang does it before doing any optimization).
You don't have to move the warning to the FE to fix this bug. Go back to 
my proposal from several years ago which has a warning analysis phase at 
the start and the end of the optimization pipeline. It can catch this 
because it gets a chance to analyze the code prior to the generate PHI 
elimination.

> There are other cases that would be better warned from the FE:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
I haven't looked at any of these recently.  But fundamentally you don't 
have to move the warning into the front-end, you just have to move it to 
the start of the optimization pipeline.

jeff