llvm dev - Jan 2013 - [LLVMdev] Build Failure

David Blaikie <dblaikie at gmail.com> writes:
>>> There's little effort to keep the GCC build warning clean,
>>
>> Why?  It seems like a pertty important compiler to support.
>
> It has some silly warnings (at least in some versions) that we don't
> want to workaround/suppress. Arguably we could have the build system
> check version information & suppress certain known-bad warnings on
> specific GCC versions.
That would be ideal, but honestly in my experience there are very few
gcc warnings that should be ignored.  Which ones do you think should be
ignored?
> Honestly we need to cleanup the buildbot infrastructure in general.
> That's a work in progress. David Dean's bringing up the new
> phase-based build infrastructure & my hope is that we'll use the
> transition to a separate buildmaster running that infrastructure as a
> chance to hold a higher bar for builders/slaves and take some time to
> really assess where/how we'll allocate our build resources, including
> things like building with -Werror, C++11, etc.
What kind of higher bar?  I'm interested in contributing resources for a
build slave (particularly for -Werror) but I can't guarantee 100%
uptime.  What will be the requirements for a build slave?
>> This is with 4.7.1, BTW.
>
> & your -Werror build of Clang+LLVM is otherwise clean apart from that?
I'm not sure since I didn't build with -k.  I patched the warning and
now it's building.  I'll commit the fix if everything works.

                           -David

On Wed, Jan 2, 2013 at 1:50 PM, <dag at cray.com> wrote:
> David Blaikie <dblaikie at gmail.com> writes:
>
> >>> There's little effort to keep the GCC build warning clean,
> >>
> >> Why?  It seems like a pertty important compiler to support.
> >
> > It has some silly warnings (at least in some versions) that we
don't
> > want to workaround/suppress. Arguably we could have the build system
> > check version information & suppress certain known-bad warnings on
> > specific GCC versions.
>
> That would be ideal, but honestly in my experience there are very few
> gcc warnings that should be ignored.  Which ones do you think should be
> ignored?
>
The implementations of -Wuninitialized, -Wreturn-type, and a few other GCC
warnings are extremely aggressive. They have high false positive rates with
few benefits. We regularly keep -Wreturn-type working despite this (see all
of the llvm_unreachable after switch statements), but the fix to silence
GCC's -Wuninitialized false positives actively degrades the quality of the
code -- it forces dead stores to variables. These dead stores are a waste
and prevent tools like Valgrind from finding very real bugs in the logic
which cause a variable to be left uninitialized.


I'm a big fan of -Werror, but only when the warnings actually make sense.
There are many older compilers (both Clang and GCC) which have false
positives in their warnings which should *not* be fixed because the code is
in fact correct. Even with the latest GCC, we would need to suppress some
warnings due to a fundamentally different approach to when and where the
warning is appropriate.

> > Honestly we need to cleanup the buildbot infrastructure in general.
> > That's a work in progress. David Dean's bringing up the new
> > phase-based build infrastructure & my hope is that we'll use
the
> > transition to a separate buildmaster running that infrastructure as a
> > chance to hold a higher bar for builders/slaves and take some time to
> > really assess where/how we'll allocate our build resources,
including
> > things like building with -Werror, C++11, etc.
>
> What kind of higher bar?  I'm interested in contributing resources for
a
> build slave (particularly for -Werror) but I can't guarantee 100%
> uptime.  What will be the requirements for a build slave?
>
> >> This is with 4.7.1, BTW.
> >
> > & your -Werror build of Clang+LLVM is otherwise clean apart from
that?
>
> I'm not sure since I didn't build with -k.  I patched the warning
and
> now it's building.  I'll commit the fix if everything works.
>
>                            -David
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130102/3d2ce8d1/attachment.html>

Chandler Carruth <chandlerc at google.com> writes:
> The implementations of -Wuninitialized, -Wreturn-type, and a few other
> GCC warnings are extremely aggressive. They have high false positive
> rates with few benefits. We regularly keep -Wreturn-type working
> despite this (see all of the llvm_unreachable after switch
> statements), 
So why not add -Wno-uninitialized and friends to the command line?

It seems a better option than simply ignoring warnings and then missing
a real bug in the haystack of warning messages.
> but the fix to silence GCC's -Wuninitialized false positives actively
> degrades the quality of the code -- it forces dead stores to
> variables. These dead stores are a waste and prevent tools like
> Valgrind from finding very real bugs in the logic which cause a
> variable to be left uninitialized.
I'm curious about this statement.  Can you give an example?  I've
committed fixes to lots of -Wuninitialized warnings in my tree.  It's
all just initializing local variables, which shouldn't result in extra
stores.

                        -David