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::ExecutionEngineTest_ForwardGlobalMapping_Test::TestBody()’:
ExecutionEngineTest.cpp:52:3: warning: passing NULL to non-pointer argument 3 of ‘static testing::AssertionResult testing::internal::EqHelper::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.
Thanks for any insight on how to solve this,
Jon
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!)
- Doug
Excerpts from Douglas Gregor's message of 2010-05-10 20:27:44 +0200:
> 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.
Are you sure the warnings are not being produced for a valid reason, and might lead to incorrect code?
Chris
If you mean gcc warnings of the form "dereferencing type-punned pointer
will break strict-aliasing rules", then you should either fix those
dereferencing instances, or compile with -fno-strict-aliasing.
I currently do the latter with llvm/clang, since it gives quite a number
of those warnings, even with gcc 4.2.1...
Excerpts from Christopher Jefferson's message of 2010-05-12 19:40:19 +0200:
> Excerp
> 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 ?
Are you sure the warnings are not being produced for a valid reason,
and might lead to incorrect code?
for LLVM/CLang, I don't know (yet?) although I suspect -from the
previous email thread about that issue- gcc was just over nitpicking.
(for the LHC code I was talking about, yes, we checked the warning
was a red herring)
cheers,
sebastien.
I know this was a long time back (I kinda forgot about this, sorry), but I was wondering if this was the proper way to silence these warnings. Basically, I did it for APValue as a first go, and if it works I will keep on pruning out the errors. All I did was put a (void *) cast in between the other errors to silence the gcc warnings.
Let me know what you think…
Jon
APValueStrictAliasing.patch (5.97 KB)
Just to clarify, I meant to say warnings not errors.
Sorry for the confusion and the email clutter,
Jon
I know this was a long time back (I kinda forgot about this, sorry), but I was wondering if this was the proper way to silence these warnings. Basically, I did it for APValue as a first go, and if it works I will keep on pruning out the errors. All I did was put a (void *) cast in between the other errors to silence the gcc warnings.
Let me know what you think…
We went ahead and added -fno-strict-aliasing, since we’ve run into too many false positives with these particular warnings and we don’t want to uglify the code with so many (void*) casts.