search for: parsedeclaration

Displaying 6 results from an estimated 6 matches for "parsedeclaration".

Did you mean: parse_declaration
2013 Jan 31
2
[LLVMdev] std::string suffices for Init* argument?
Hi Jakob, How is `FieldName`, which is a std::string, being passed as the third argument to SetValue on line 1848 of TGParser.cpp, which is declared as being an Init*? The nearly identical (FIXME) codepath in ParseDeclaration immediately puts the string into a StringInit, which makes sense, but how on earth is the std::string being passed in? This is really freaking me out. -- Sean Silva
2016 Nov 20
3
uninitialized values in Attributes.cpp
I did a RelWithDebInfo + asserts build of LLVM just now and, when running "make check" under Valgrind, am seeing a lot of uses of uninitialized memory like the one below. Anyone know offhand what's likely to be the root cause? Unfortunately a Debug build doesn't give these errors. Thanks, John FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)
2016 Nov 20
3
uninitialized values in Attributes.cpp
Well, it looks like almost all of the problems go away when I build using trunk instead of 3.9. So, that was scary but I'm going to forget it ever happened. >8000 test cases failed under Valgrind!! John On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote: > Hi John, > > This is probably somewhat of a stretch, but since the problem does not > happen with a Debug build,
2016 Jun 02
6
-Wmisleading-indentation violations
Hi, I was building LLVM with gcc 6.1.1 recently and it was spitting out some warnings relating to misleading indention that caught my eye. This wasn't a fresh build so I may have missed some. I've CC'ed the authors of the potentially misleading lines so they can decide what do about the warnings (if anything). I'm wondering if clang-format is making some inappropriate choices
2013 Jan 31
0
[LLVMdev] std::string suffices for Init* argument?
On Jan 30, 2013, at 9:37 PM, Sean Silva <silvas at purdue.edu> wrote: > How is `FieldName`, which is a std::string, being passed as the third > argument to SetValue on line 1848 of TGParser.cpp, which is declared > as being an Init*? The nearly identical (FIXME) codepath in > ParseDeclaration immediately puts the string into a StringInit, which > makes sense, but how on earth is the std::string being passed in? This > is really freaking me out. See TGParser.h: bool SetValue(Record *TheRec, SMLoc Loc, Init *ValName, const std::vector<unsigned> &BitList...
2016 Jul 20
2
[XRay] Build instrumented Clang, some analysis results
...or<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) 4. clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) 5. clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) 6. clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) 7. clang::BackendConsumer::HandleTranslationUnit(clang::ASTConte...