[LLVMdev] Build Failure

Chandler Carruth chandlerc at google.com
Wed Jan 2 14:05:47 PST 2013

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>

More information about the llvm-dev mailing list