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...