similar to: [LLVMdev] Problem with 'const' in lib/Transforms/Utils/PromoteMemoryToRegister.cpp

On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1.  Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp > llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp 3.7 was released over two years ago; there have been

Dear llvm-dev, Hi! We're collecting mis-compilation bugs in gvn and mem2reg since 3.7.1. Specifically, We're interested in bugs in the following files: llvm/lib/Transforms/Scalar/GVN.cpp llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp We checked all reports in the LLVM bugzilla (https://bugs.llvm.org/), so I'd like to ask if you know any such a bug that is not reported in

On Tue, Apr 10, 2018 at 3:09 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: >> >> Dear llvm-dev, >> >> >> Hi! We're collecting mis-compilation

On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1. Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp

Hi, I am doing a project involving checking a called specific function’s argument. Suppose that the function is int f(const char* str). When I am analyzing such a snippet: f("hello") , then compiled by Clang, I will have the “hello” as a *Constant Array* in the IR code. My goal is to call APIs of LLVM to get the “hello” from IR code. Now suppose the I got the llvm::Function* fn from

Hi there, I added a function to a module, but failed to write the bitcode to file because it hit the: assert(I != ValueMap.end() && "Value not in slotcalculator!") So I added some diagnosis information there, unsigned ValueEnumerator::getValueID(const Value *V) const { if (isa<MDNode>(V) || isa<MDString>(V)) { ValueMapType::const_iterator I =

This isn't really a bug, but it's generally bad style to declare variables with the same name in almost the same scope... The Visual C compiler can't compile things like this, so here is a patch. m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL:

On line 653 there is an assignment of a map with a user defined comparision function to one with std::less -- doesn't compile on Visual C and looks like a real error... Here is a patch. m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL:

Hello, after I started using packed types things have gone quite well, but now I hit a small problem again. The LevelRaise.cpp does some optimizing on getting the first element of a struct/array -- and now also packed types, so the assumption that if something is not a struct it must be an array is false. The solution is simple: if it's not an array it's a sequential type. Here is

+ // Otherwise this is a copy constructor for const_iterator. Do you mean "for iterator"? Otherwise, looks good to me. If you can commit this, please do. Otherwise, someone else should as I'm not going to be around tomorrow. On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich <victor.zverovich at googlemail.com> wrote: > Hi Jeffrey, > You are right that the generated

Hi nut users, (this is a re-send from the correct account) With pleasure, I have been using the code provided. Managed to get all working properly, except for the nutclient lib in C. Both functions stringset_to_strarr and stringvector_to_strarr have a similar bug in play. Although trivial in code, the coded function does not operate as intended. The pointer increment is missing (see added

Reminding about the patches... Is there a problem with them or simply nobody have looked at them since? Victor 2009/11/4 Victor Zverovich <victor.zverovich at googlemail.com> > Good catch! I meant "for iterator" of course. Attached is a corrected patch > together with an old patch for clang just to keep them together. > Could someone commit these, please? > >

Good catch! I meant "for iterator" of course. Attached is a corrected patch together with an old patch for clang just to keep them together. Could someone commit these, please? Thanks, Victor 2009/11/4 Jeffrey Yasskin <jyasskin at google.com> > + // Otherwise this is a copy constructor for const_iterator. > > Do you mean "for iterator"? > > Otherwise,

Reading the comments in Analysis/DominanceFrontier.h, I see a note that the structure is deprecated and we're not to use it for anything new. Has it been replaced with something equally useful, or shall I redo the calculation for myself, or ...? Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL:

my compiler gave me a warning in MCObjectDisassembler.cpp. it found a self-comparation in loop condition. I think it's a typo. the suspicious code was introduced by this patch: >From f176482752fbea3139394e280adfb10270dd3aac Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha <ahmed.bougacha at gmail.com> Date: Wed, 21 Aug 2013 07:28:55 +0000 Subject: MC CFG: Support disassembly at

Hi Jeffrey, You are right that the generated copy constructor is used for const_iterator. I have added a comment clarifying this. Also I have added the tests you suggested and corrected the comparison operators. Please find attached the updated patches. Best regards, Victor 2009/11/3 Jeffrey Yasskin <jyasskin at google.com> > +template <bool, typename True, typename False> >

+template <bool, typename True, typename False> +struct If { typedef True Result; }; + +template <typename True, typename False> +struct If<false, True, False> { typedef False Result; }; These should probably go into include/llvm/Support/type_traits.h. In C++0x, this is named "conditional" (section 20.6.7), so I think you should use the same name, despite the standard

Hi Tony, It doesn't look right to me either. The "begin" and "end" methods which allocation_order_begin should return a const_iterator instead of an iterator. Those methods are "const". And, yes, the MachineFunction reference isn't even used so at the very least it could be const (if not removed). However, I'm not an expert in this area of the code.

Hello, I have a transform that, given a function F, will produce a new function G such that the basic blocks of G are (copies of) a subset of the basic blocks of F, and such that control flow is connected as you would expect. Given DominatorTree and DominanceFrontier of F, I would also like to efficiently compute DominatorTrees and DominanceFrontiers of G. I understand how to do this

Any chance of adding some missing test coverage here? That code was dead (& evidently untested) before... On Thu, Jul 31, 2014 at 11:37 AM, Eric Christopher <echristo at gmail.com> wrote: > I believe you are correct. Fixed thusly: > > dzur:~/sources/llvm> git svn dcommit > Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... > M