[cfe-dev] Warnings when building with gcc-4.5

Sebastien Binet binet at cern.ch
Wed May 12 10:37:07 PDT 2010


Excerpts from Douglas Gregor's message of 2010-05-10 20:27:44 +0200:
> 
> On May 6, 2010, at 8:04 AM, Mulder, Jonathan wrote:
> 
> > Hello all,
> > 
> > I have been compiling clang using the stock gcc on apple (4.2.1) for awhile with no issues or warnings, but now I am trying to compile clang using the gcc 4.5.0 release, and I am getting a bunch of warnings of this variety.
> > 
> > llvm[4]: Compiling ParseExprCXX.cpp for Debug build
> > ParseExprCXX.cpp: In member function ‘clang::Parser::OwningExprResult clang::Parser::ParseCXXAmbiguousParenExpression(clang::Parser::ParenParseOption&, clang::Parser::TypeTy*&, clang::SourceLocation, clang::SourceLocation&)’:
> > ParseExprCXX.cpp:1774:54: warning: converting ‘false’ to pointer type for argument 4 of ‘clang::Parser::OwningExprResult clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeTy*)’
> > 
> > llvm[2]: Compiling ExecutionEngineTest.cpp for Debug build
> > ExecutionEngineTest.cpp: In member function ‘virtual void<unnamed>::ExecutionEngineTest_ForwardGlobalMapping_Test::TestBody()’:
> > ExecutionEngineTest.cpp:52:3: warning: passing NULL to non-pointer argument 3 of ‘static testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, T2*) [with T1 = int, T2 = void]’
> > 
> > Where they are either booleans (generally false values) being converted to pointer types, or the latter of passing NULL to non-pointer types.  If you could enlighten me as to the proper way to silence these warning I would be happy to go through them all and submit a patch.
> 
> These look like potential bugs in LLVM and Clang, each of which will have to be considered. If you're willing to fix these cases and provide a patch, that would be wonderful.
> 
> (Clang should probably warn about these kinds of conversions, too!)

speaking of GCC-4.5 warnings, I still get the strict-aliasing ones
(yes, I saw the thread on the mailing list as well as the use of
unions to prevent broken assembly generation)

in "my" codebase (one of the LHC experiments, so maybe not your
typical state of the art source code), we usually get rid of those
like so: 

template<typename DEST, typename SRC>
DEST* hackish_cast(SRC* src)
{
 // lame way of handling const-ness
 // a proper partial specialization would do just fine
 const void* cptr = src; 
 void* ptr = const_cast<void*>(cptr);
 return reinterpret_cast<DEST*>(ptr);
}

would you consider applying a patch with such a modification ?

cheers,
sebastien.
-- 
#########################################
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#########################################



More information about the cfe-dev mailing list