search for: overflowingbinaryoperator

Displaying 6 results from an estimated 6 matches for "overflowingbinaryoperator".

2012 Sep 28
0
[LLVMdev] LLVM build fails using gcc-4.7.0 and -std=c++11 flags
I've fixed this specific error in r164813. Please let me know if there are more behind it. On Thu, Sep 27, 2012 at 2:16 PM, Sid Manning <sidneym at codeaurora.org> wrote: > > I just updated my llvm sources (revision 164794.) and I see the error, > "overriding non-deleted function" when building with gcc 4.7.0 and passing > -std=c++11. > >
2012 Sep 27
2
[LLVMdev] LLVM build fails using gcc-4.7.0 and -std=c++11 flags
I just updated my llvm sources (revision 164794.) and I see the error, "overriding non-deleted function" when building with gcc 4.7.0 and passing -std=c++11. /usr2/sidneym/llvm/tools/install/bin/c++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fPIC -fvisibility-inlines-hidden -I/local/scratch/llvm-tmp/build/lib/VMCore
2017 Aug 21
2
[RFC] Injecting new element atomic memory intrinsics into MemIntrinsic class hierarchy
...sses would multiply inherit from. I’m not sure if there is precedence for this sort of thing in the instruction class hierarchy, though; I haven’t reviewed the entire hierarchy, but all of the parts that I have looked at appear to be single inheritance. There is precedent for something like this: OverflowingBinaryOperator will return true for both isa<Instruction> and isa<ConstantExpr>. I also think this combined with (a) is probably the cleanest path forward: AtomicMemIntrinsic * AtomicMemSetInst * AtomicMemTransferInst ** AtomicMemCpyInst ** AtomicMemMoveInst PlainMemIntrinsic * PlainMemSetInst * Pla...
2017 Aug 17
3
[RFC] Injecting new element atomic memory intrinsics into MemIntrinsic class hierarchy
Hi all, We somewhat recently created/updated element-wise unordered-atomic versions of the memcpy, memmove, and memset memory intrinsics: Memcpy: https://reviews.llvm.org/rL305558 Memmove: https://reviews.llvm.org/rL307796 Memset: https://reviews.llvm.org/rL307854 These intrinsics are semantically similar to the regular versions. The main difference is that the underlying operation is performed
2014 Sep 19
2
[LLVMdev] More careful treatment of floating point exceptions
Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey
2014 Sep 25
2
[LLVMdev] More careful treatment of floating point exceptions
...onstant *C1, Constant *C2) { } Constant *ConstantExpr::getMul(Constant *C1, Constant *C2, - bool HasNUW, bool HasNSW) { + bool HasNUW, bool HasNSW, + bool HonorFPExceptions) { unsigned Flags = (HasNUW ? OverflowingBinaryOperator::NoUnsignedWrap : 0) | (HasNSW ? OverflowingBinaryOperator::NoSignedWrap : 0); - return get(Instruction::Mul, C1, C2, Flags); + return get(Instruction::Mul, C1, C2, Flags, nullptr, HonorFPExceptions); } -Constant *ConstantExpr::getFMul(Constant *C1, Constant *C2) { - ret...