search for: llparser

These warnings started appearing recently when building LLVM: llvm[2]: Compiling LLParser.cpp for Release build /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp: In member function ‘bool llvm::LLParser::ParseBr(llvm::Instruction*&, llvm::LLParser::PerFunctionState&)’: /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp:3195: warning: ‘Op1’ may be used uninit...

...p;, llvm::Intrinsic::ID) (Intrinsics.gen:20104) ==29299== by 0x146F3A0: llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, llvm::Module*) (Function.cpp:277) ==29299== by 0x1CD2B36: Create (Function.h:106) ==29299== by 0x1CD2B36: llvm::LLParser::ParseFunctionHeader(llvm::Function*&, bool) (LLParser.cpp:4766) ==29299== by 0x1CCE2C2: llvm::LLParser::ParseDeclare() (LLParser.cpp:444) ==29299== by 0x1CCC15A: llvm::LLParser::ParseTopLevelEntities() (LLParser.cpp:276) ==29299== by 0x1CCBFBF: llvm::LLParser::Run() (LLParser.cpp:74...

...t;> ==29299== by 0x146F3A0: llvm::Function::Function(llvm::FunctionType*, >> llvm::GlobalValue::LinkageTypes, llvm::Twine const&, llvm::Module*) >> (Function.cpp:277) >> ==29299== by 0x1CD2B36: Create (Function.h:106) >> ==29299== by 0x1CD2B36: >> llvm::LLParser::ParseFunctionHeader(llvm::Function*&, bool) >> (LLParser.cpp:4766) >> ==29299== by 0x1CCE2C2: llvm::LLParser::ParseDeclare() (LLParser.cpp:444) >> ==29299== by 0x1CCC15A: llvm::LLParser::ParseTopLevelEntities() >> (LLParser.cpp:276) >> ==29299== by 0x1CCB...

On cygwin-1.7, clang and llvm can be built fine through 3 stages. With --disable-assertions (RC3's default), I saw a few warnings in llvm/lib/AsmParser/LLParser.cpp with g++-4.3.4. (and two warnings, PR9515) ...Takumi $ uname.exe -a CYGWIN_NT-6.1-WOW64 HEAVEN64 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ gcc --version gcc (GCC) 4.3.4 20090804 (release) 1 * Stage 1 configured by ../../llvm/configure, generated by GNU Autoconf 2.60, with options &...

...vm[1]: Compiling raw_ostream.cpp for Release build raw_ostream.cpp: In member function ‘virtual void llvm::raw_fd_ostream::flush_impl()’: raw_ostream.cpp:245: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result llvm[2]: Compiling LLParser.cpp for Release build LLParser.cpp: In member function ‘bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)’: LLParser.cpp:448: warning: ‘IsConstant’ may be used uninitialized in this function Ciao, Duncan.

...^~ /home/dsl11/dev/llvm-upstream/src/lib/Target/AMDGPU/R600MachineScheduler.cpp:228:5: note: ...this statement, but the latter is misleadingly in dented as if it is guarded by the ‘if’ switch (MI->getOpcode()) { ^~~~~~ ``` and ``` /home/dsl11/dev/llvm-upstream/src/lib/AsmParser/LLParser.cpp: In member function ‘bool llvm::LLParser::ParseTopLevelEntities()’: /home/dsl11/dev/llvm-upstream/src/lib/AsmParser/LLParser.cpp:260:34: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (ParseUseListOrderBB()) return true; break;...

Hello Tim, Thank you for getting back to me. The language grammar as defined by the LLVM Language Reference Manual [1] does not include the details of the LLVM IR parser reference implementation. The following extract from "lib/AsmParser/LLParser.cpp" illustrates that unnamed globals are allowed [2]. > /// ParseUnnamedGlobal: > /// OptionalVisibility (ALIAS | IFUNC) ... > /// OptionalLinkage OptionalVisibility OptionalDLLStorageClass > /// ... -> global var...

2 new warnings in llvm: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:446: warning: 'IsConstant' may be used uninitialized in this function Volumes/mrs5/net/llv...

A new warning: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:448: warning: 'IsConstant' may be used uninitialized in this function

The following comment: 00881 // As a hack, we allow "align 2" on functions as a synonym for "alignstack 00882 // 2". in "lib/AsmParser/LLParser.cpp" appears inaccurate, the "alignment" is later parsed as the alignment of the function itself, both when directly placed on the function: 02975 // If the alignment was parsed as an attribute, move to the alignment field. 02976 if (FuncAttrs.hasAlignmentAttr()) { 02977 Ali...

Hi, I'm wondering why lib/AsmParser/LLParser handles fast-math flags in the following IR: ... %val = fmul nnan double 1.0, 1.0 ... but doesn't allow any flags if "fmul" is inside "phi": ... %val = phi double [ fmul (double 1.0, double 1.0), %cond.true ], [ fmul (double 1.0,...

Hello! I see the following build failure of the sources at the top of the trunk, on x86_64. make[2]: Entering directory `<llvm-root>/build/llvm/lib/AsmParser' llvm[2]: Compiling LLLexer.cpp for Release build llvm[2]: Compiling LLParser.cpp for Release build <llvm-root>/src/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': <llvm-root>/src/llvm/lib/AsmParser/LLParser.cpp:446: warning: 'IsConstant'...

...isa<FunctionType>(ElemTy); +} Please use "!ElemTy->isVoidTy()" etc. --- lib/VMCore/ConstantsContext.h (revision 93451) +template<> +struct ConstantKeyData<ConstantUnion> { + typedef Constant* ValType; + static ValType getValType(ConstantUnion *CS) { CU not CS. LLParser.cpp: In LLParser::ParseUnionType, you can use SmallVector instead of std::vector for ParamsList & ParamsListTy. @@ -2135,7 +2173,8 @@ ParseToken(lltok::rparen, "expected ')' in extractvalue constantexpr")) return true; - if (!isa<StructType>(V...

...->isVoidTy()" etc. > > --- lib/VMCore/ConstantsContext.h (revision 93451) > > +template<> > +struct ConstantKeyData<ConstantUnion> { > + typedef Constant* ValType; > + static ValType getValType(ConstantUnion *CS) { > > CU not CS. > > > LLParser.cpp: > > In LLParser::ParseUnionType, you can use SmallVector instead of std::vector > for ParamsList & ParamsListTy. > > @@ -2135,7 +2173,8 @@ > ParseToken(lltok::rparen, "expected ')' in extractvalue > constantexpr")) > return true; >...

...le. In the .ll file > (*), it's the part of the module that looks like this: > > target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" > > it is global to the entire module and always available. My point was that the DataLayout isn't available inside the LLParser and the BitcodeReader, up until the point when it has been parsed. So I would not say "always available". Both LLParser and BitcodeReader is for example using getAddressSpace(), both directly and maybe also indirectly through different interfaces (perhaps not on function pointers though)...

...hecks so that higher-level developers, like we are, see the friendly messages/warnings (see 1). It would help us a lot to see that the reason is incompatibility, not any other reasons like mistakes that we sometimes make. Is there a reason why this kind of versioning is not being done in AsmParser/LLParser? Is it hard to have such functionality in place? Background: we develop `Mull` as in-source project inside LLVM. We often use stable LLVM distribution from `brew` and Rust stable/nightly compilers that are often one version behind the latest stable version of LLVM. Currently our solution is to st...

...look like a bug, more like a limitation of constant expressions > as llvm::BinaryConstantExpr doesn't have FastMastFlags. > > -- > Sergey > > On Thu, Nov 27, 2014 at 03:39:20PM +0200, Sergey Dmitrouk wrote: >> Hi, >> >> I'm wondering why lib/AsmParser/LLParser handles fast-math flags in the >> following IR: >> >> ... >> %val = fmul nnan double 1.0, 1.0 >> ... >> >> but doesn't allow any flags if "fmul" is inside "phi": >> >> ... >> %val = phi double [ fm...

On 25 May 2016 at 16:10, Robin Eklind via llvm-dev <llvm-dev at lists.llvm.org> wrote: > declare void @foo() unnamed_addr > global i32 42 Doesn't a global have to be named? The syntax in the IR reference doesn't make it optional: @<GlobalVarName> = [Linkage] [Visibility] [DLLStorageClass] [ThreadLocal] ... Cheers. Tim.

...->isVoidTy()" etc. > > --- lib/VMCore/ConstantsContext.h (revision 93451) > > +template<> > +struct ConstantKeyData<ConstantUnion> { > + typedef Constant* ValType; > + static ValType getValType(ConstantUnion *CS) { > > CU not CS. > > > LLParser.cpp: > > In LLParser::ParseUnionType, you can use SmallVector instead of std::vector > for ParamsList & ParamsListTy. > > @@ -2135,7 +2173,8 @@ > ParseToken(lltok::rparen, "expected ')' in extractvalue > constantexpr")) > return true; >...

Hello everyone, While developing a parser for LLVM IR, I seem to have stumbled upon a potential ambiguity in the LLVM IR assembly language grammar. Most likely there is something which I may have overlooked, so wanted to reach out to a more experienced crowed for some feedback. How would the following set of tokens be interpreted [1]? declare void @foo() unnamed_addr global i32 42 As far as