Build Errors

Clang Frontend
1

I get the follwing build errors with -Werror:

[sta-opt] : [llvm] /ptmp/dag/llvm/staging/llvm/tools/clang/lib/AST/Expr.cpp: In static member function 'static int clang::StringLiteral::mapCharByteWidth(const clang::TargetInfo&, clang::StringLiteral::StringKind)':
[sta-opt] : [llvm] /ptmp/dag/llvm/staging/llvm/tools/clang/lib/AST/Expr.cpp:518:80: error: 'CharByteWidth' may be used uninitialized in this function [-Werror=uninitialized]
[sta-opt] : [llvm] cc1plus: all warnings being treated as errors

Can someone fix this? I don't have commit access.

Thanks!

                             -Dave

2

Eli took care of this in r151754.

Chad

3

I really would like to avoid silencing the GCC “may be used uninitialized” warnings by introducing unnecessary initialization.

These warnings are almost always false positives due to the way the warning was implemented. What it means is that GCC has been unable to prove initialization took place, and has not hit one of a (very short) list of known impossible cases. This warning was bad enough that we (Google) lobbied upstream and I believe it is now under a separate flag from -Wuninitialized.

Every time we add initializations like this we achieve three things:

  1. placate a fundamentally flawed warning
  2. slow down code in some cases (the ability to eliminate the initialization corresponds to when this warning doesn’t fire)
  3. prevent us from ever getting Valgrind errors if we in fact introduce a bug leaving the variable uninitialized.

It is #3 that makes me really bothered by the spirit of these changes. I would like to recommend anyone using an older GCCs should simply disable -Wuninitialized. We will catch all of the bugs with Clang’s -Wuninitialized and Valgrind.

4

I really would like to avoid silencing the GCC "may be used uninitialized"
warnings by introducing unnecessary initialization.

These warnings are almost always false positives due to the way the warning
was implemented. What it means is that GCC has been unable to *prove*
initialization took place, and has not hit one of a (very short) list of
known impossible cases. This warning was bad enough that we (Google) lobbied
upstream and I believe it is now under a separate flag from -Wuninitialized.

Every time we add initializations like this we achieve three things:

1) placate a fundamentally flawed warning
2) slow down code in some cases (the ability to eliminate the initialization
corresponds to when this warning *doesn't* fire)
3) prevent us from ever getting Valgrind errors if we in fact introduce a
bug leaving the variable uninitialized.

It is #3 that makes me really bothered by the spirit of these changes. I
would like to recommend anyone using an older GCCs should simply disable
-Wuninitialized.

Should we add some handling for this in the LLVM build if that's the
case/achievable/sufficiently useful?

- David

5

While I’m not personally motivated to add this (I think most developers should self-host most of the time, turning off -Werror in the bootstrap phase isn’t a burden then), I’m not opposed to it and would be happy to review patches to that effect.