Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jeff Law <law at redhat dot com>]

On 12/19/2016 11:56 AM, Jakub Jelinek wrote:
> On Mon, Dec 19, 2016 at 11:46:24AM -0700, Jeff Law wrote:
> > But I don't see that as inherently blocking this patch.  It's pointing out a
> > bad API interface.  It's no different than when I added teh NULL pointer
> > dereference warnings a while ago -- we had the exact same kinds of problems.
> >
> > The question is how many of them are there.  We *know* this kind of thing is
> > going to happen.  Again, at this point I don't see 78859 as inherently
> > meaning Martin's patch should be reverted.
>
> profiledbootstrap is meant to be supported without --disable-werror, has
> been working that way for at least last 10 years.
But we also have to twiddle things to deal with profiledbootstrap 
selecting different jump threads to realize and as a result we get 
different Wuninitialized warnings.   This happens all the time


 And so is normal
> bootstrap on powerpc* or hppa*.
Agreed, but we need to investigate those at a level deep enough to 
understand the real problem.


So broken bootstrap is a
> strong reason for having to do something.
Certainly we have to do something.  But that doesn't mean flat out 
reversion and rejection of the patch.  It means careful analysis of the 
costs & benefits.  Jumping to reversion & rejection because it triggers 
some warnings in cases we don't like is too hasty.



> By moving the warning earlier, we'll still warn for the most cases, but
> won't warn in the more convoluted cases.  We can perhaps work on it further
> in GCC 8.  If we keep it as is, I think most users will just -Wno-nonnull
> as soon as they run into some warning that will be hard to figure out what
> is going on.  At that point they will not get warnings even for the obvious
> cases that we used to warn.  Look at how the Linux kernel folks disable most
> of warnings even for smaller reasons.
But again, the user case is no different than other warnings that are 
sensitive to optimizations.

My sense is that we should revert and table until gcc-8 where we can 
evaluate the space more thoroughly.

Jeff