<div dir="ltr">Please send to cfe-commits or phabricator and CC someone familiar with this code (svn blame is your friend).</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 10:08 AM, Azat Khuzhin <span dir="ltr"><<a href="mailto:a3at.mail@gmail.com" target="_blank">a3at.mail@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Feb 18, 2015 at 03:15:18AM +0300, Azat Khuzhin wrote:<br>
> Hi all,<br>
><br>
> During playing with clang library, I got the next assertion:<br>
> /src/oss/clang/lib/Sema/SemaDecl.cpp:10637: clang::Decl* clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool): Assertion `MaybeODRUseExprs.empty() && "Leftover expressions for odr-use checking"' failed.<br>
><br>
> Here is backtrace:<br>
> Program received signal SIGABRT, Aborted.<br>
> 0x00007fffdddef107 in __GI_raise (sig=sig@entry=6) at raise.c:56<br>
> 56      raise.c: No such file or directory.<br>
> (gdb) bt<br>
> #0  0x00007fffdddef107 in __GI_raise (sig=sig@entry=6) at raise.c:56<br>
> #1  0x00007fffdddf04e8 in __GI_abort () at abort.c:89<br>
> #2  0x00007fffddde8226 in __assert_fail_base (fmt=0x7fffddf1e968 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff679c9c0 "MaybeODRUseExprs.empty() && \"Leftover expressions for odr-use checking\"",<br>
>     file=file@entry=0x7ffff679b888 "/src/oss/clang/lib/Sema/SemaDecl.cpp", line=line@entry=10637,<br>
>     function=function@entry=0x7ffff67ac480 <clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool)::__PRETTY_FUNCTION__> "clang::Decl* clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool)") at assert.c:92<br>
> #3  0x00007fffddde82d2 in __GI___assert_fail (assertion=0x7ffff679c9c0 "MaybeODRUseExprs.empty() && \"Leftover expressions for odr-use checking\"", file=0x7ffff679b888 "/src/oss/clang/lib/Sema/SemaDecl.cpp", line=10637,<br>
>     function=0x7ffff67ac480 <clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool)::__PRETTY_FUNCTION__> "clang::Decl* clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool)") at assert.c:101<br>
> #4  0x00007ffff62062f5 in clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) () from /src/oss/llvm/.cmake/lib/libclangSema.so<br>
> #5  0x00007ffff6204fd9 in clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*) () from /src/oss/llvm/.cmake/lib/libclangSema.so<br>
> #6  0x00007ffff4dbcc52 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #7  0x00007ffff4dd65d3 in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #8  0x00007ffff4d54446 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #9  0x00007ffff4dd58e4 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #10 0x00007ffff4dd599c in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #11 0x00007ffff4dd5102 in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #12 0x00007ffff4d6beee in clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation, std::allocator<clang::<br>
> SourceLocation> >&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #13 0x00007ffff4d6bd57 in clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #14 0x00007ffff4d536d2 in clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #15 0x00007ffff4dd4d8e in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #16 0x00007ffff4dd468a in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #17 0x00007ffff4d3ce3f in clang::ParseAST(clang::Sema&, bool, bool) () from /src/oss/llvm/.cmake/lib/libclangParse.so<br>
> #18 0x00007ffff7a8a002 in clang::ASTFrontendAction::ExecuteAction() () from /src/oss/llvm/.cmake/lib/libclangFrontend.so<br>
> #19 0x00007ffff7a89ab9 in clang::FrontendAction::Execute() () from /src/oss/llvm/.cmake/lib/libclangFrontend.so<br>
> #20 0x00007ffff7a48ca5 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () from /src/oss/llvm/.cmake/lib/libclangFrontend.so<br>
> #21 0x00007ffff2d92d12 in clang::tooling::FrontendActionFactory::runInvocation(clang::CompilerInvocation*, clang::FileManager*, clang::DiagnosticConsumer*) () from /src/oss/llvm/.cmake/lib/libclangTooling.so<br>
> #22 0x00007ffff2d92bf7 in clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, clang::CompilerInvocation*) () from /src/oss/llvm/.cmake/lib/libclangTooling.so<br>
> #23 0x00007ffff2d92aaf in clang::tooling::ToolInvocation::run() () from /src/oss/llvm/.cmake/lib/libclangTooling.so<br>
> ...<br>
><br>
> After debugging, I found the reason of a crash:<br>
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/basic_string.h:2937:<br>
><br>
> And here is a sniplet from basic_string:<br>
> 2932   inline string<br>
> 2933   to_string(float __val)<br>
> 2934   {<br>
> 2935     const int __n =<br>
> 2936       __gnu_cxx::__numeric_traits<float>::__max_exponent10 + 20;<br>
> 2937     return __gnu_cxx::__to_xstring<string>(&std::vsnprintf, __n,<br>
> 2938                                            "%f", __val);<br>
> 2939   }<br>
><br>
> assert goes away if:<br>
> - you replace __n with some const (i.e. 20)<br>
> - add a cast to size_t for __n -- "(size_t)__n"<br>
><br>
> However clang compiler doesn't bail with this assert:<br>
> $ cat /tmp/string.cpp<br>
> #include <string><br>
> int main()<br>
> {<br>
>         std::string a("a");<br>
>         a = std::to_string((float)1);<br>
>         return a.length();<br>
> };<br>
> $ clang++ -std=c++11 /tmp/string.cpp # also tested using some of the next options: "-c" "-g3" "-O0" "-O3"<br>
> $ clang++ --version<br>
> clang version 3.7.0 (<a href="http://llvm.org/git/clang.git" target="_blank">http://llvm.org/git/clang.git</a> bd12ce7a3cfb1f36c0b5e21dc7fe6a5720c8f94e) (<a href="http://llvm.org/git/llvm.git" target="_blank">http://llvm.org/git/llvm.git</a> 11ef7bf0d77043e1c8d2592a819a0b247449f464)<br>
> Target: x86_64-unknown-linux-gnu<br>
> Thread model: posix<br>
><br>
> clang revision: trunk@226250<br>
> llvm  revision: trunk@226269<br>
><br>
> Could anybody explain why this may differs?<br>
> And/or possible directions for debugging/patching?<br>
<br>
</div></div>After digging this issue for a while I finally have a patch that fixes this<br>
issue, it passes clang regression tests (ninja check-clang) except<br>
Frontend/source-col-map.c (but it fails before this patch too), and llvm tests<br>
(ninja test/check).<br>
<br>
Sure this patch must have helper function like ActOnCallExprError() or<br>
something like this, and I will add this if the basic idea is good enough.<br>
Therefore *I will be very appreciate if somebody from maintainers could have a<br>
look*.<br>
Also I'm currently working on reproducing this with 50L sample and a regression<br>
test.<br>
<br>
Thanks!<br>
Azat.<br>
<br>
Leftover-expressions-for-odr-use-checking.patch:<br>
================================================<br>
diff --git a/lib/Parse/ParseExpr.cpp b/lib/Parse/ParseExpr.cpp<br>
index 4183ae4..437ba3c 100644<br>
--- a/lib/Parse/ParseExpr.cpp<br>
+++ b/lib/Parse/ParseExpr.cpp<br>
@@ -1459,6 +1459,7 @@ Parser::ParsePostfixExpressionSuffix(ExprResult LHS) {<br>
              })) {<br>
             (void)Actions.CorrectDelayedTyposInExpr(LHS);<br>
             LHS = ExprError();<br>
+            Actions.DiscardCleanupsInEvaluationContext();<br>
<div class="HOEnZb"><div class="h5">           }<br>
         }<br>
       }<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>