similar to: [LLVMdev] [RC3] Status on Cygwin-1.7

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

It is good. Two clang tests will fail due to PR8520 and have been fixed in llvm ToT r127724. With 3-stage build, stage-3 binaries are working fine. Bill, thank you to work for release_29! ps. binaries of stage2 and stage3 would not match. [PR9569] ...Takumi $ uname.exe -a MINGW32_NT-6.1 HEAVEN64 1.0.12(0.46/3/2) 2010-02-05 01:08 i686 unknown $ gcc --version gcc.exe (TDM-1 mingw32) 4.4.0 *

On Thursday 11 February 2010 13:31:58 David Greene wrote: > > Putting a bit (or multiple bits) in MachineMemOperand for this > > would also make sense. > > Is there any chance a MachineMemOperand will be shared by multiple > instructions? So I tried to do this: %r8 = load <2 x double>* %r6, align 16, !"nontemporal" and the assembler doesn't like it.

Hi, I got a problem when I am trying to add a dummy basic block. Let say there are two blocks, A and B. A----->B I am trying to generate new BB called C which is located between A and B, but not break the edge of AB. The graph is like the following A---->B \ / \ / C There is new BB 'C' with edges AC and CB. It is kind of like what breakcriticaledge pass does.

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

Hello guys, On cygwin-1.7, I can build and test clang successfully by 3-stage. Known issues: - binaries among stage2 and stage3 do not match. (other than timestamp and checksum) investigating. - I met some warnings. I have fixes for them. - [llvm] r127241 - [llvm] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110307/117725.html - [clang] r127283 - [clang]

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

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)

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,

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

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

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

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

Out of curiosity, how would you envision fast-math flags interacting with constant expressions? Off the top of my head, I can’t think of any flags that would be relevant if the expression can just be constant-folded away at full precision anyways. > On Nov 28, 2014, at 4:56 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote: > > Doesn't look like a bug, more like a

On Wednesday 10 February 2010 14:58:58 Dan Gohman wrote: > On Feb 10, 2010, at 12:42 PM, David Greene wrote: > > On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: > >> I think that adding a bit to LoadSDNode and StoreSDNode would make > >> sense. > > > > Ok. The consequence is that a number of functions will have to change to > > propagate

I've made all the suggested changes - however, I'm having a bit of problem running the tests. I started "make check" and several hours later it had only made it through about 1/3 of the tests. I'm not sure what the deal is. 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

Hi, I have a question regarding the LLParser and the new type system rewrite when running the JIT. I think there may be a problem with the parser not picking up on named types currently defined in a given Module (global context). However, I don't have much experience with the LLVM internals so there's a good chance that I'm not fully understanding the new changes ;) For Example:

On Feb 10, 2010, at 12:42 PM, David Greene wrote: > On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: > >> I think that adding a bit to LoadSDNode and StoreSDNode would make sense. > > Ok. The consequence is that a number of functions will have to change to > propagate this bit, analogous to what happens with isVolatile. It's > essentially what we do