[clang] [CodeGen] Emit a more accurate alignment for non-temporal loads/stores (PR #75675)

https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/75675 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [compiler-rt] [clang-tools-extra] [clang] [flang] [libc] [libcxx] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true); else ArrayLV = EmitLValue(Array); + auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if

[libc] [libcxx] [llvm] [flang] [clang-tools-extra] [compiler-rt] [clang] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true); else ArrayLV = EmitLValue(Array); + auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if

[clang-tools-extra] [flang] [compiler-rt] [clang] [llvm] [libc] [libcxx] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/73730 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [flang] [compiler-rt] [clang] [llvm] [libc] [libcxx] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true); else ArrayLV = EmitLValue(Array); + auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if

[clang-tools-extra] [flang] [compiler-rt] [clang] [llvm] [libc] [libcxx] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true); else ArrayLV = EmitLValue(Array); + auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if

[clang-tools-extra] [compiler-rt] [flang] [libcxx] [libc] [llvm] [clang] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true); else ArrayLV = EmitLValue(Array); + auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if

[libc] [libcxx] [compiler-rt] [llvm] [clang-tools-extra] [clang] [flang] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true); else ArrayLV = EmitLValue(Array); + auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if

[compiler-rt] [libcxx] [llvm] [clang-tools-extra] [libc] [flang] [clang] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/73730 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [libcxx] [flang] [clang] [clang-tools-extra] [compiler-rt] [libc] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4073,6 +4221,51 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitLValue(Array); auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if (SanOpts.has(SanitizerKind::ArrayBounds)) { + // If the array being accessed

[compiler-rt] [libc] [clang-tools-extra] [clang] [libcxx] [llvm] [flang] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/73730 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [compiler-rt] [clang] [flang] [libcxx] [libc] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4073,6 +4221,51 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitLValue(Array); auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if (SanOpts.has(SanitizerKind::ArrayBounds)) { + // If the array being accessed

[libc] [compiler-rt] [clang] [clang-tools-extra] [llvm] [flang] [libcxx] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true); else ArrayLV = EmitLValue(Array); + auto *Idx = EmitIdxAfterBase(/*Promote*/true); +if

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/75397 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

@@ -0,0 +1,300 @@ +=== +HLSL Function Calls +=== + +.. contents:: + :local: + +Introduction + + +This document descries the design and implementation of HLSL's function call +semantics in Clang. This includes details related to

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

rjmccall wrote: > @rjmccall, I'm curious if you have any thoughts on the proposed > implementation approach here? > > The TL;DR for the gnarly bit is to have AST nodes representing parameters > that need temporary values, and for "output" parameters where there may be > cast sequences

[clang] [FPEnv] Add strictfp in some C++ constructors lacking a FunctionDecl. (PR #74883)

@@ -6,14 +7,80 @@ float z(); #pragma float_control(except, on) class ON { float w = 2 + y() * z(); - // CHECK-LABEL: define {{.*}} @_ZN2ONC2Ev{{.*}} - // CHECK: llvm.experimental.constrained.fmul{{.*}}tonearest{{.*}}strict }; ON on; #pragma float_control(except, off)

[clang] [FPEnv] Add strictfp in some C++ constructors lacking a FunctionDecl. (PR #74883)

@@ -5520,6 +5520,12 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo , CGM.AdjustMemoryAttribute(CalleePtr->getName(), Callee.getAbstractInfo(), Attrs); } + // We may not have a FunctionDecl*, but we still need to support

[clang] [HLSL] Vector standard conversions (PR #71098)

@@ -1422,6 +1424,9 @@ Value *ScalarExprEmitter::EmitScalarConversion(Value *Src, QualType SrcType, return Builder.CreateVectorSplat(NumElements, Src, "splat"); } + if (SrcType->isExtVectorType() && DstType->isExtVectorType()) +return

[llvm] [clang] [CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (PR #67454)

@@ -232,19 +232,19 @@ static Value *MakeBinaryAtomicValue( static Value *EmitNontemporalStore(CodeGenFunction , const CallExpr *E) { Value *Val = CGF.EmitScalarExpr(E->getArg(0)); - Value *Address = CGF.EmitScalarExpr(E->getArg(1)); + Address Addr =

[clang] [llvm] [CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (PR #67454)

@@ -232,110 +279,133 @@ class CGBuilderTy : public CGBuilderBaseTy { /// where i64 is actually the target word size. Address CreateConstGEP(Address Addr, uint64_t Index, const llvm::Twine = "") { +llvm::Type *ElTy = Addr.getElementType();

[clang] [FPEnv] Add strictfp in some C++ constructors lacking a FunctionDecl. (PR #74883)

@@ -6,14 +7,80 @@ float z(); #pragma float_control(except, on) class ON { float w = 2 + y() * z(); - // CHECK-LABEL: define {{.*}} @_ZN2ONC2Ev{{.*}} - // CHECK: llvm.experimental.constrained.fmul{{.*}}tonearest{{.*}}strict }; ON on; #pragma float_control(except, off)

[clang] [FPEnv] Add strictfp in some C++ constructors lacking a FunctionDecl. (PR #74883)

@@ -5587,10 +5593,12 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo , !isa_and_nonnull(TargetDecl)) EmitKCFIOperandBundle(ConcreteCallee, BundleList); +#if 0 // XXX Why is this here? Duplicate! if (const FunctionDecl *FD =

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

rjmccall wrote: Right, I'd just like to make sure that we're not deepening a divergence here. It would be good to get agreement from the GCC devs that they think `ms_struct` probably ought to do something on e.g. ARM MinGW targets and that they consider this a bug (in a feature that they may

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

rjmccall wrote: > @rjmccall The problem will arise only if GCC implements support for MSVC C++ > ABI and decides that there is a better way to implement `gcc_struct`. Since, > AFAIC, MSVC-compatibility for GCC is not even planned, it's unlikely anybody > there will have strong opinions on

[clang] [Clang] Emit TBAA info for enums in C (PR #73326)

rjmccall wrote: This seems conservatively correct, yeah. My reading is that we could also use the underlying type as a parent type for the TBAA metadata: enums are compatible with their underlying type, but two enums with the same underlying type are not compatible with each other. But this

[clang] Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg. (PR #74349)

https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/74349 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

rjmccall wrote: It sounds like we're talking about extending the behavior of these attributes, and I'd like to make sure that whatever we do here is acceptable to GCC. That is, if we're going to start accepting these attributes on new targets which GCC doesn't currently support, we should

[clang] fix: C++ empty record with align lead to va_list out of sync (PR #72197)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/72197 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fix: C++ empty record with align lead to va_list out of sync (PR #72197)

@@ -307,7 +307,12 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool IsVariadic, // 0. if (IsEmpty && Size == 0) return ABIArgInfo::getIgnore(); -return ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext())); +// An empty struct can have

[clang] fix: C++ empty record with align lead to va_list out of sync (PR #72197)

@@ -307,7 +307,12 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool IsVariadic, // 0. if (IsEmpty && Size == 0) return ABIArgInfo::getIgnore(); -return ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext())); +// An empty struct can have

[clang] [AVR] make the AVR ABI Swift compatible (PR #72298)

rjmccall wrote: This is less about the implementation weeds of LLVM and more about the actual details of your calling convention — the decisions about how arguments and results are passed that are ultimately downstream of the choices made here. Mostly, I'm encouraging you as a platform

[clang] [AVR] make the AVR ABI Swift compatible (PR #72298)

rjmccall wrote: > @efriedma-quic Cool. So it sounds like it's worth parking this for now, until > Kuba's work #71986 is merged? > > @rjmccall I'm not 100% sure I understand? The existing code in AVR.cpp > handles the standard AVR ABI, which has a few simple rules based on GCC > behaviour.

[clang] [AVR] make the AVR ABI Swift compatible (PR #72298)

rjmccall wrote: Right, that would be the way to test it. I don't know much about AVR, but you should also look at some of the parameters to the lowering (e.g. how many max values it's okay to break an aggregate into) and make sure you're happy with them.

[clang] [clang] Ensure fixed point conversions work in C++ (PR #68344)

https://github.com/rjmccall approved this pull request. LGTM, thanks! https://github.com/llvm/llvm-project/pull/68344 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

https://github.com/rjmccall reopened https://github.com/llvm/llvm-project/pull/72197 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: > The code you noted is supposed to handle two cases, neither of which are > relevant to your testcase: > > * Darwin-specific calling convention rules. > * GNU extensions for zero-size structs (which aren't allowed according to > either C or C++ standards, but GNU invented a

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

https://github.com/rjmccall closed https://github.com/llvm/llvm-project/pull/72197 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: > This is the code I debug located. Seem the comment is out of date? That seems like the right place to fix the issue, specifically the place below where it always passes a single `i8`. The right rule is to just fall through to the normal conventions for passing the argument

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

https://github.com/rjmccall requested changes to this pull request. Marking as changes requested so that this doesn't get committed. https://github.com/llvm/llvm-project/pull/72197 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: Oh, the [Apple AArch64 calling convention](https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Pass-arguments-to-functions-correctly) diverges from AAPCS and ignores empty classes as parameters. We appear to consider this an empty class

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: First off, the change here actually applies to all over-aligned empty structs, not just to those with aligned bit-fields. Maybe we can say that aligned zero-width bit-fields are ill-formed, but I don't think we can say that all aligned empty classes are ill-formed, among

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

rjmccall wrote: I agree with the Sema/AST-level LGTM (but also don't feel comfortable approving the driver changes) https://github.com/llvm/llvm-project/pull/71148 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

@@ -5031,7 +5031,12 @@ void RecordDecl::completeDefinition() { /// This which can be turned on with an attribute, pragma, or the /// -mms-bitfields command-line option. bool RecordDecl::isMsStruct(const ASTContext ) const { - return hasAttr() || C.getLangOpts().MSBitfields ==

[clang] [clang] Remove fixed point arithmetic error (PR #71884)

rjmccall wrote: I definitely don't think we should be handling this in the lexer by trying to retroactively make this a keyword. I was just thinking that we might have some sort of parser-level recovery for e.g. `unrecognized_identifier_t x = 5;` that might guess that

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

@@ -5031,7 +5031,12 @@ void RecordDecl::completeDefinition() { /// This which can be turned on with an attribute, pragma, or the /// -mms-bitfields command-line option. bool RecordDecl::isMsStruct(const ASTContext ) const { - return hasAttr() || C.getLangOpts().MSBitfields ==

[clang] Ignore template parameter visibility (PR #72092)

rjmccall wrote: The basic design idea behind Clang's visibility model is to treat hidden visibility as essentially a second grade of external linkage, external to the translation unit but internal to the linkage unit (i.e. image). So what you pointed out about using an anonymous namespace is

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

@@ -5031,7 +5031,12 @@ void RecordDecl::completeDefinition() { /// This which can be turned on with an attribute, pragma, or the /// -mms-bitfields command-line option. bool RecordDecl::isMsStruct(const ASTContext ) const { - return hasAttr() || C.getLangOpts().MSBitfields ==

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

@@ -7255,20 +7255,27 @@ void Sema::CheckCompletedCXXClass(Scope *S, CXXRecordDecl *Record) { CheckCompletedMemberFunction(MD); } - // ms_struct is a request to use the same ABI rules as MSVC. Check - // whether this class uses any C++ features that are implemented

[clang] Ignore template parameter visibility (PR #72092)

rjmccall wrote: > I cannot figure out a test case for `TemplateArgument::Expression`. I wonder > whether it applies to `X<> x5;` (address of static member), which Clang > doesn't support. It's primarily used as a dependent template argument. I'm not sure off-hand that it's *never*

[clang] [ARC][Documentation] Explicitly state that messaging weak objects keeps a strong reference during call lifetime (PR #72169)

https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/72169 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Ignore template parameter visibility (PR #72092)

rjmccall wrote: Can we just ignore template parameters selectively when we have a visibility attribute, the way I suggested in https://reviews.llvm.org/D154774? To quote: > A visibility attribute on an explicit specialization or instantiation should > definitely override everything else. A

[clang] [clang] Remove fixed point arithmetic error (PR #71884)

rjmccall wrote: I'm happy with the basic idea here of making fixed-point an opt-in feature. It'd be nice to preserve the special diagnostic that tells the user that they need to use `-ffixed-point`, though. Do we have any existing parsing paths that recognize unrecognized identifiers that

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

https://github.com/rjmccall commented: Otherwise LGTM https://github.com/llvm/llvm-project/pull/70646 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

@@ -710,9 +710,11 @@ class Sema final { return result; } + // Saves the current floating-point pragma stack and clear it in this Sema. class FpPragmaStackSaveRAII { public: -FpPragmaStackSaveRAII(Sema ) : S(S), SavedStack(S.FpPragmaStack) {} +

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/70646 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

rjmccall wrote: > pragma pack uses pragma stack and it is allowed in any place: > https://godbolt.org/z/f8fP1vn63 . If such pragma presents in the late-parsed > template, and push-pop operations in it are not balanced, the late parse of > such function can break the pragma stack and next

[clang] [ObjC] Fix offsets following `[[no_unique_address]]` for `@encode()` (PR #71321)

https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/71321 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

rjmccall wrote: > > The upshot is that we don't (and shouldn't) ever late-parse at file > > context, which by design means we can't see stack-manipulating pragmas > > because they're all restricted to file context. In late parsing, we only > > ever observe and change the innermost state of

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

rjmccall wrote: > > And contrariwise, if there's some sneaky way to put push/pop pragmas in > > non-file contexts, that also seems like a serious problem, because the way > > we process them is not designed to understand local scopes, which means > > we're just doing random stuff instead of

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

rjmccall wrote: It's certainly possible to see push/pop pragmas in late-parsed code, but Sema should immediately emit an error and ignore them because, like I said, they're only allowed at file context, and AFAIK late-parsed code is never at file context. If there's some sneaky way to

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

rjmccall wrote: I see, that makes sense. It shouldn't really need to be saved even during late template parsing, right? Late template parsing is never at the top level, and push/pop are only allowed at the top level. https://github.com/llvm/llvm-project/pull/70646

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

rjmccall wrote: That makes sense. Out of curiosity, since presumably the instantiation path is using the RAII class, and the RAII class seems to save and restore the entire stack, what actually ends up going wrong? It doesn't look like your test case has local changes to the stack within

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

https://github.com/rjmccall commented: To be clear, we're still ensuring the current pragma state during instantiation is what it was when the template is parsed, we're just not incorrectly dropping all of the saved pragma state when we're doing it?

[clang] SwiftCallingConv: Fix the splitVectorEntry function (PR #69953)

https://github.com/rjmccall approved this pull request. Oops. LGTM. https://github.com/llvm/llvm-project/pull/69953 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Ensure fixed point conversions work in C++ (PR #68344)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/68344 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Ensure fixed point conversions work in C++ (PR #68344)

@@ -156,7 +156,8 @@ ImplicitConversionRank clang::GetConversionRank(ImplicitConversionKind Kind) { // it was omitted by the patch that added // ICK_Zero_Queue_Conversion ICR_C_Conversion, -ICR_C_Conversion_Extension +

[clang] [clang] Ensure fixed point conversions work in C++ (PR #68344)

@@ -2192,6 +2194,9 @@ static bool IsStandardConversion(Sema , Expr* From, QualType ToType, From->isIntegerConstantExpr(S.getASTContext())) { SCS.Second = ICK_Compatible_Conversion; FromType = ToType; + } else if (ToType->isFixedPointType() ||

[clang] [clang] Ensure fixed point conversions work in C++ (PR #68344)

@@ -1,6 +1,8 @@ // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py -// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,SIGNED -// RUN: %clang_cc1 -ffixed-point -triple

[clang] [clang][codegen] Add a verifier IR pass before any further passes. (PR #68015)

https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/68015 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][codegen] Add a verifier IR pass before any further passes. (PR #68015)

rjmccall wrote: Thank you. If your PR is just changing things so that we run the existing verifier on the direct result of IR generation instead of only verifying it after a few passes run, I agree that it's the right thing to do. https://github.com/llvm/llvm-project/pull/68015

[clang] [clang][codegen] Add a verifier IR pass before any further passes. (PR #68015)

@@ -923,6 +923,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline( PB.crossRegisterProxies(LAM, FAM, CGAM, MAM); ModulePassManager MPM; + // Add a verifier pass, before any other passes, to catch CodeGen issues. + MPM.addPass(VerifierPass());

[clang] [clang][codegen] Add a verifier IR pass before any further passes. (PR #68015)

@@ -1020,21 +1022,23 @@ void EmitAssemblyHelper::RunOptimizationPipeline( } if (CodeGenOpts.FatLTO) { - MPM = PB.buildFatLTODefaultPipeline(Level, PrepareForThinLTO, - PrepareForThinLTO || -

[clang] [clang] Support fixed point type mangling (PR #67750)

https://github.com/rjmccall commented: This patch is *primarily* adding support for fixed-point types to C++, which seems like it ought to be in the PR title. With that said, I don't have any objection to either the goal or the implementation. https://github.com/llvm/llvm-project/pull/67750

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

@@ -0,0 +1,167 @@ +/*=== ptrauth.h - Pointer authentication ---=== + * + * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. + * See https://llvm.org/LICENSE.txt for license information. + * SPDX-License-Identifier:

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

@@ -4869,6 +4869,73 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID, case Builtin::BI__iso_volatile_store64: return RValue::get(EmitISOVolatileStore(*this, E)); + case Builtin::BI__builtin_ptrauth_auth: + case

[clang] [MS] Follow up fix to pass aligned args to variadic x86_32 functions (PR #65692)

https://github.com/rjmccall requested changes to this pull request. Functionally LGTM; just a minor request. https://github.com/llvm/llvm-project/pull/65692 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [MS] Follow up fix to pass aligned args to variadic x86_32 functions (PR #65692)

@@ -812,11 +815,13 @@ ABIArgInfo X86_32ABIInfo::classifyArgumentType(QualType Ty, CCState , } llvm::IntegerType *PaddingType = NeedsPadding ? Int32 : nullptr; -// Pass over-aligned aggregates on Windows indirectly. This behavior was -// added in MSVC 2015.

[clang] [MS] Follow up fix to pass aligned args to variadic x86_32 functions (PR #65692)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65692 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

On Mon, Nov 22, 2021 at 2:28 PM John McCall wrote: > On Mon, Nov 22, 2021 at 1:08 PM David Goldblatt via Phabricator < > revi...@reviews.llvm.org> wrote: > >> and related projects avoid relying on alignment guarantees (e.g. >> libstdc++ at one point considered assuming that 8-byte allocs were

Re: [PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

On Mon, Nov 22, 2021 at 1:08 PM David Goldblatt via Phabricator < revi...@reviews.llvm.org> wrote: > davidtgoldblatt added a comment. > > (For background: I'm a jemalloc maintainer and wrote N2293). > > In D100879#3145361 , @rjmccall > wrote: > > >

[clang] 5ab6ee7 - Fix a variety of bugs with nil-receiver checks when targeting

Author: John McCall Date: 2021-10-08T05:44:06-04:00 New Revision: 5ab6ee75994d645725264e757d67bbb1c96fb2b6 URL: https://github.com/llvm/llvm-project/commit/5ab6ee75994d645725264e757d67bbb1c96fb2b6 DIFF: https://github.com/llvm/llvm-project/commit/5ab6ee75994d645725264e757d67bbb1c96fb2b6.diff

[clang] cec49a5 - Revert "[SYCL] Implement __builtin_unique_stable_name."

Author: John McCall Date: 2020-10-12T01:10:09-04:00 New Revision: cec49a583693752b3984e49f9c193de07c2a7698 URL: https://github.com/llvm/llvm-project/commit/cec49a583693752b3984e49f9c193de07c2a7698 DIFF: https://github.com/llvm/llvm-project/commit/cec49a583693752b3984e49f9c193de07c2a7698.diff

[clang] 984744a - Fix a variety of minor issues with ObjC method mangling:

Author: John McCall Date: 2020-09-29T19:51:53-04:00 New Revision: 984744a1314ce165378e7945bc45995302a8cb80 URL: https://github.com/llvm/llvm-project/commit/984744a1314ce165378e7945bc45995302a8cb80 DIFF: https://github.com/llvm/llvm-project/commit/984744a1314ce165378e7945bc45995302a8cb80.diff

[clang] 98ef7e2 - This reduces code duplication between CGObjCMac.cpp and Mangle.cpp

Author: Ellis Hoag Date: 2020-09-29T02:26:51-04:00 New Revision: 98ef7e29b0fe03da77fa6ef5c86bea9e31c178d0 URL: https://github.com/llvm/llvm-project/commit/98ef7e29b0fe03da77fa6ef5c86bea9e31c178d0 DIFF: https://github.com/llvm/llvm-project/commit/98ef7e29b0fe03da77fa6ef5c86bea9e31c178d0.diff

[clang] 7fac1ac - Set the LLVM FP optimization flags conservatively.

Author: John McCall Date: 2020-06-11T18:16:41-04:00 New Revision: 7fac1acc617113b7a3276ee0f0664bedca978292 URL: https://github.com/llvm/llvm-project/commit/7fac1acc617113b7a3276ee0f0664bedca978292 DIFF: https://github.com/llvm/llvm-project/commit/7fac1acc617113b7a3276ee0f0664bedca978292.diff

[clang] 8a8d703 - Fix how cc1 command line options are mapped into FP options.

Author: John McCall Date: 2020-06-01T22:00:30-04:00 New Revision: 8a8d703be0986dd6785cba0b610c9c4708b83e89 URL: https://github.com/llvm/llvm-project/commit/8a8d703be0986dd6785cba0b610c9c4708b83e89 DIFF: https://github.com/llvm/llvm-project/commit/8a8d703be0986dd6785cba0b610c9c4708b83e89.diff

[clang] 32870a8 - Expose IRGen API to add the default IR attributes to a function definition.

Author: John McCall Date: 2020-05-16T14:44:54-04:00 New Revision: 32870a84d9a40ea682e22a24b5f0d1a218c3b062 URL: https://github.com/llvm/llvm-project/commit/32870a84d9a40ea682e22a24b5f0d1a218c3b062 DIFF: https://github.com/llvm/llvm-project/commit/32870a84d9a40ea682e22a24b5f0d1a218c3b062.diff

[clang] e4422ae - Rewrite the non-trivial structs section of the ARC spec.

Author: John McCall Date: 2020-03-06T02:51:45-05:00 New Revision: e4422ae0f6e4159a8560514ce221306c30a7f2c1 URL: https://github.com/llvm/llvm-project/commit/e4422ae0f6e4159a8560514ce221306c30a7f2c1 DIFF: https://github.com/llvm/llvm-project/commit/e4422ae0f6e4159a8560514ce221306c30a7f2c1.diff

[clang] 7848a3c - Update the ARC docs for non-trivial ownership in structs.

Author: John McCall Date: 2020-02-26T16:42:08-05:00 New Revision: 7848a3c8ab54570f5875e63606ff75b5736750b4 URL: https://github.com/llvm/llvm-project/commit/7848a3c8ab54570f5875e63606ff75b5736750b4 DIFF: https://github.com/llvm/llvm-project/commit/7848a3c8ab54570f5875e63606ff75b5736750b4.diff

[clang] 77b2ffc - Fix a reentrance bug with deserializing ObjC type parameters.

Author: John McCall Date: 2020-02-12T18:44:19-05:00 New Revision: 77b2ffc498e92cce7546d191f6712a3046300501 URL: https://github.com/llvm/llvm-project/commit/77b2ffc498e92cce7546d191f6712a3046300501 DIFF: https://github.com/llvm/llvm-project/commit/77b2ffc498e92cce7546d191f6712a3046300501.diff

Re: [PATCH] D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing

On Tue, Jan 7, 2020 at 3:18 PM Aaron Ballman wrote: > It seems like GCC doesn't do good things when trying to link two > functions with empty asm labels but Clang does seem to do something > reasonable. I can't quite tell whether this is a case for a diagnostic > or not. Note the generated

Re: [PATCH] D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing

On Tue, Jan 7, 2020 at 3:02 PM Aaron Ballman wrote: > On Tue, Jan 7, 2020 at 2:57 PM John McCall via cfe-commits > wrote: > > On Tue, Jan 7, 2020 at 1:44 PM Aaron Ballman via Phabricator > > wrote: > > > Sorry to dredge up an old review, but I recently ran into a bug

Re: [PATCH] D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing

On Tue, Jan 7, 2020 at 1:44 PM Aaron Ballman via Phabricator wrote: > aaron.ballman added inline comments. > > > > Comment at: cfe/trunk/lib/AST/Mangle.cpp:127 > +// do not add a "\01" prefix. > +if (!ALA->getIsLiteralLabel() || ALA->getLabel().startswith("llvm.")) { > +

[clang] 803403a - Fix a bug in the property-based serialization of

Author: John McCall Date: 2019-12-16T16:08:09-05:00 New Revision: 803403afc83f659be1c620eb1896dcf704b18b0a URL: https://github.com/llvm/llvm-project/commit/803403afc83f659be1c620eb1896dcf704b18b0a DIFF: https://github.com/llvm/llvm-project/commit/803403afc83f659be1c620eb1896dcf704b18b0a.diff

Re: [clang] 00bc76e - Move Basic{Reader,Writer} emission into ASTPropsEmitter; NFC.

On 16 Dec 2019, at 15:11, John McCall wrote: On 16 Dec 2019, at 15:07, Vedant Kumar wrote: Hi John, The lldb bot went red after your clang AST changes landed: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/4801/changes#detail0

Re: [clang] 00bc76e - Move Basic{Reader,Writer} emission into ASTPropsEmitter; NFC.

issues with missing emails lately? On Dec 16, 2019, at 10:34 AM, John McCall via cfe-commits wrote: Author: John McCall Date: 2019-12-16T13:33:59-05:00 New Revision: 00bc76edddb5a6cd417610e96289a5dc15245867 URL: https://github.com/llvm/llvm-project/commit/00bc76edddb5a6cd417610e96289a5dc15245867 D

[clang] c82e4ef - Always -I clang/include when tblgen'ing in Clang.

Author: John McCall Date: 2019-12-16T13:33:59-05:00 New Revision: c82e4ef6960b9f09fc77abc10f374417007f5f00 URL: https://github.com/llvm/llvm-project/commit/c82e4ef6960b9f09fc77abc10f374417007f5f00 DIFF: https://github.com/llvm/llvm-project/commit/c82e4ef6960b9f09fc77abc10f374417007f5f00.diff

<    1   2   3   4   5   6   7   8   >