search for: exprconstant

Just got clang from head and getting: ExprConstant.cpp: In function Obool TryEvaluateBuiltinNaN(clang::ASTContext&, clang::QualType, const clang::Expr*, bool, llvm::APFloat&)¹: ExprConstant.cpp:1578: error: no matching function for call to Ollvm::StringRef::getAsInteger(int, llvm::APInt&)¹ /home/neale/LLVM/llvm/include/llvm/ADT/StringRe...

...call void @abort() #3 unreachable } //end test.ll As we can see from test.ll, foo function is optimized out by clang. And then call abort function directly. However, the real is that this test never executes abort function. So, I debug source code of clang. In the 3167 line of ExprConstant.cpp(tools/clang/lib/AST/ExprConstant.cpp), these codes are 3166: // Don't call function pointers which have been cast to some other type. 3167: if (!Info.Ctx.hasSameType(CalleeType->getPointeeType(), FD->getType())) 3168: return Error(E); It returns Error(E) . Then, th...

Hi Haishan, > int foo(int j) { > return ++j > 0; > } > int main() { > if (foo(((~0U)>>1))) > abort(); > exit(0) > } This test contains undefined behaviour, and you can never rely on the compiler doing anything predictable with that. Specifically, the result of casting (~0U) >> 1 to an int is almost certainly INT_MAX and when foo

Hi Tim, Firstly, thanks for your reply. I agree on your idea about integer overflow in this test. But, in fact, the content of this test is the same to gcc\testsuite\gcc.c-torture\execute\920612-1.c. gcc can handle it correctly. Moreover, when I compile this test using clang with optlevel O0 instead of O2. Its execution result is the same to gcc. That to say, for this test, clang with optlevel

...alueTracking.cpp - lib/CodeGen/SelectionDAG/SelectionDAG.cpp - lib/IR/ConstantFold.cpp - lib/Target/ARM/ARMFastISel.cpp - lib/Target/ARM/ARMISelLowering.cpp - lib/Target/ARM/ARMInstrVFP.td (through predicates) - lib/Target/ARM/ARMRegisterInfo.td (through predicates) and in Clang: - lib/AST/ExprConstant.cpp Did I get it right and there is no such flag so far? Does what I'm suggesting sounds reasonable? Thanks, Sergey

...aluator::Success(const llvm::APSInt&, const clang::Expr*, clang::APValue&) 7096 0 0 DEBUG: bool {anonymous}::IntExprEvaluator::Success(const llvm::APSInt&, const clang::Expr*, clang::APValue&) 7096 1 0 clang-7: /home/zhaixiang/project/Loong-Language/loong-llvm/tools/clang/lib/AST/ExprConstant.cpp:7098: bool {anonymous}::IntExprEvaluator::Success(const llvm::APSInt&, const clang::Expr*, clang::APValue&): Assertion `SI.isSigned() == E->getType()->isSignedIntegerOrEnumerationType() && "Invalid evaluation result."' failed. Stack dump: 0. Program ar...

...on: void __atomic_load_8(…) { If (__c11_atomic_is_lock_free(8)) return __c11_atomic_load_8(..) /* otherwise lock-based implementation */ } Let’s say a target supports lock-free atomics for 8-byte objects. Then the front-end will lower __c11_atomic_is_lock_free(8) to “true” in clang/lib/AST/ExprConstant.cpp VisitBuiltinCallExpr() and further __c11_atomic_load_8() will expand into an inlined sequence of instructions. Therefore, we get what we want which is an optimized implementation of __atomic_load_8(). But, let’s say the target is an ARM variant that does not support atomics for 8-byte objects...

...stantFold.cpp > A - lib/Target/ARM/ARMFastISel.cpp > A - lib/Target/ARM/ARMISelLowering.cpp > A - lib/Target/ARM/ARMInstrVFP.td (through predicates) > A - lib/Target/ARM/ARMRegisterInfo.td (through predicates) > > and in Clang: > > A - lib/AST/ExprConstant.cpp > > Did I get it right and there is no such flag so far?A Does what I'm > suggesting sounds reasonable? > > Thanks, > Sergey > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc...

...> >> A - lib/Target/ARM/ARMISelLowering.cpp > >> A - lib/Target/ARM/ARMInstrVFP.td (through predicates) > >> A - lib/Target/ARM/ARMRegisterInfo.td (through predicates) > >> > >> and in Clang: > >> > >> A - lib/AST/ExprConstant.cpp > >> > >> Did I get it right and there is no such flag so far?A Does what I'm > >> suggesting sounds reasonable? > >> > >> Thanks, > >> Sergey -------------- next part -------------- Subject: [PATCH 1/7] Do not emit in...