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