similar to: 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,

Hi, when building the llvm cfe (3.4 derivative), for the mingw platform, I get this error: 'error: there are no arguments to `lrand48' that depend on a template parameter, so a declaration of `lrand48' must be available'. ------------------------ make[3]: Entering directory `/C/projects/build/MinGW/llvm-gcc-1-1/i686-pc-mingw32/libstdc++-v3/testsuite'

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 uninitialized in

On Fri, 14 Jan 2005, Henrik Bach wrote: > when building the llvm cfe (3.4 derivative), for the mingw platform, I get > this error: 'error: there are no arguments to `lrand48' that depend on a > template parameter, so a declaration of `lrand48' must be available'. Hi Henrik, We haven't modified the GCC configure script or build system, so I don't know what

This sounds suspiciously like the problem I ran into with VC++, whose std implementation also includes _Distance. Could mingw have copied VC++ too closely? The fix with VC++ was to add a "using std::_Distance" line (or just "using namespace std". Chris Lattner wrote: > On Fri, 14 Jan 2005, Henrik Bach wrote: > >> when building the llvm cfe (3.4 derivative), for

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

Hi Tanya, I see the following warnings when building. I'm not sure how to fix any of them. The last one looks like it might be serious (seems like a job for Chris). llvm[1]: Compiling Path.cpp for Release build In file included from Path.cpp:270: Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’: Unix/Path.inc:661: warning: ignoring return

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, double 1.0), %cond.false ] ...

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

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

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

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

Greetings, I have a compiler error that I have not been able to get through. I usually depend upon pre-built binaries but there was none available for the pre-release. I also try scanning the web site and mail list but was unable to find an answer. I was getting this or similar error with 2.3. I am just trying to build with the core library. I tried this in a xp and vista VM with the

Hi, All I m not sure if this question has been asked or not. I'd like cache the MCJIT compiled object into memory buffer so it can be reused later. I followed the Andy Kaylor's example wrote an inherited class from ObjectCache and use raw_fd_ostream to save the cache and load the cache from a file. I checked raw_ostream and its subclass, maybe I am wrong but I don't see one is fit to

I'm copying some LLD code into my codebase like this: // workaround for LLD not exposing ability to convert .def to .lib #include <set> namespace lld { namespace coff { class SymbolBody; class StringChunk; struct Symbol; struct Export { StringRef Name; // N in /export:N or /export:E=N StringRef ExtName; // E in /export:E=N SymbolBody *Sym = nullptr; uint16_t Ordinal

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.

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

OK here's a new version of the patch - and the unions.ll test actually passes :) On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK here's the patch for real this time :) >> >> On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: >> Here's a work

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

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: den 13 juli 2017 16:01 > To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>; David Chisnall > <David.Chisnall at cl.cam.ac.uk>; Dylan McKay <me at dylanmckay.io> > Cc: llvm-dev at lists.llvm.org; Carl Peto <carl.peto at me.com> > Subject: Re: [llvm-dev] RFC: