[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)

Fznamznon wrote: I can't because I don't have a big endian to verify with. We can try to push speculatively if it doesn't break existing tests. https://github.com/llvm/llvm-project/pull/95802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org ht

[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)

Fznamznon wrote: I wonder if that would be ok to disable interpreter tests for now? https://github.com/llvm/llvm-project/pull/95802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)

Fznamznon wrote: Thank you! https://github.com/llvm/llvm-project/pull/95802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)

Fznamznon wrote: According to the bots that worked! https://github.com/llvm/llvm-project/pull/95802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { - // Bool has a different representation in memory than in registers. - if (hasBooleanRepresen

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1989,6 +1989,14 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, return EmitAtomicLoad(AtomicLValue, Loc).getScalarVal(); } + if (const auto *BIT = Ty->getAs()) { +if (BIT->getNumBits() > 128) { + // Long _BitInt has array of

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

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

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1989,6 +1989,14 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, return EmitAtomicLoad(AtomicLValue, Loc).getScalarVal(); } + if (const auto *BIT = Ty->getAs()) { +if (BIT->getNumBits() > 128) { + // Long _BitInt has array of

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1774,6 +1774,18 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (const auto *BIT = destType->getAs()) { +if (BIT->getNumBits() > 128) { + // Long _BitInt has array of bytes as in-memory type. + ConstantAggregat

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -194,7 +194,7 @@ double varargs_vec_3s(int fixed, ...) { // APCS-GNU: [[VAR:%.*]] = alloca <3 x i16>, align 8 // APCS-GNU: [[AP:%.*]] = load ptr, // APCS-GNU: [[AP_NEXT:%.*]] = getelementptr inbounds i8, ptr [[AP]], i32 8 -// APCS-GNU: [[VEC:%.*]] = load <3 x i16>, ptr [[AP]

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -5348,6 +5348,13 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) { return llvm::UndefValue::get(ArgTy); } + if (const auto *BIT = Ty->getAs()) { +if (BIT->getNumBits() > 128) { Fznamznon wrote: Called `VisitVAArgExpr` here. https://g

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1989,6 +1989,14 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, return EmitAtomicLoad(AtomicLValue, Loc).getScalarVal(); } + if (const auto *BIT = Ty->getAs()) { +if (BIT->getNumBits() > 128) { Fznamznon wrote: T

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

Fznamznon wrote: Well, I hope I got the idea right, I updated PR so now it is introducing `convertTypeForLoadStore` API, returning `iBITS` (Let `BYTES := sizeof(_BitInt(N))`, and let `BITS := BYTES * 8`). I've also tried to inspect as many places where `ConvertTypeForMem`, `emitToMemory`, emit

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { - // Bool has a different representation in memory than in registers. - if (hasBooleanRepresen

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -761,6 +761,10 @@ bool ConstStructBuilder::Build(const InitListExpr *ILE, bool AllowOverwrite) { if (Field->hasAttr()) AllowOverwrite = true; } else { + llvm::Type *LoadType = CGM.getTypes().convertTypeForLoadStore( Fznamznon wrote:

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1774,6 +1784,22 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (destType->isBitIntType()) { +if (!CGM.getTypes().LLVMTypeLayoutMatchesAST(destType, C->getType())) { + // Long _BitInt has array of bytes as in-memory

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

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

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -2567,16 +2567,16 @@ int main() { // CHECK3-NEXT:[[I:%.*]] = alloca i32, align 4 // CHECK3-NEXT:[[DOTCAPTURE_EXPR__CASTED:%.*]] = alloca i64, align 8 // CHECK3-NEXT:[[DOTBOUND_ZERO_ADDR:%.*]] = alloca i32, align 4 -// CHECK3-NEXT:[[DOTCAPTURE_EXPR__CASTED12:%

[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

https://github.com/Fznamznon commented: I wonder if we should always emit an error when a function with non-void return type doesn't have a return statement? In any case it is a serious yet dumb bug that will lead to problems and perhaps some time spent debugging it. gcc rejects the case for C+

[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

@@ -0,0 +1,7 @@ +// RUN: %clang_cc1 -Wno-return-type -std=c++23 -fsyntax-only -verify %s +// expected-no-diagnostics +constexpr int f() { } +static_assert(__is_same(decltype([] constexpr -> int { }( )), int)); Fznamznon wrote: Should we emit at least a warning in

[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

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

[clang] [Clang][C++23] update constexpr diagnostics for missing return statements per P2448 (PR #94123)

@@ -2487,6 +2477,26 @@ static bool CheckConstexprFunctionBody(Sema &SemaRef, const FunctionDecl *Dcl, return true; } +static bool CheckConstexprMissingReturn(Sema &SemaRef, +const FunctionDecl *Dcl) { + bool IsVoidOrDependentType = D

[clang] Disable constexpr function body checking in more situations (PR #94347)

@@ -2469,11 +2469,20 @@ static bool CheckConstexprFunctionBody(Sema &SemaRef, const FunctionDecl *Dcl, // base class sub-objects shall be a constexpr constructor. // // Note that this rule is distinct from the "requirements for a constexpr - // function", so is not

[clang] Disable constexpr function body checking in more situations (PR #94347)

https://github.com/Fznamznon deleted https://github.com/llvm/llvm-project/pull/94347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Disable constexpr function body checking in more situations (PR #94347)

@@ -2469,11 +2469,20 @@ static bool CheckConstexprFunctionBody(Sema &SemaRef, const FunctionDecl *Dcl, // base class sub-objects shall be a constexpr constructor. // // Note that this rule is distinct from the "requirements for a constexpr - // function", so is not

[clang] Disable constexpr function body checking in more situations (PR #94347)

@@ -2469,11 +2469,20 @@ static bool CheckConstexprFunctionBody(Sema &SemaRef, const FunctionDecl *Dcl, // base class sub-objects shall be a constexpr constructor. // // Note that this rule is distinct from the "requirements for a constexpr - // function", so is not

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

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

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -5348,18 +5348,8 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) { return llvm::UndefValue::get(ArgTy); } - // FIXME Volatility. - llvm::Value *Val = Builder.CreateLoad(ArgPtr); - - // If EmitVAArg promoted the type, we must truncate it. - if (ArgTy !=

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -761,6 +761,10 @@ bool ConstStructBuilder::Build(const InitListExpr *ILE, bool AllowOverwrite) { if (Field->hasAttr()) AllowOverwrite = true; } else { + llvm::Type *LoadType = CGM.getTypes().convertTypeForLoadStore( Fznamznon wrote:

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -128,6 +128,15 @@ class CodeGenTypes { /// memory representation is usually i8 or i32, depending on the target. llvm::Type *ConvertTypeForMem(QualType T, bool ForBitField = false); + /// Check that size and abi alignment of given LLVM type matches size and + /// align

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -436,9 +436,9 @@ class ScalarExprEmitter if (Value *Result = ConstantEmitter(CGF).tryEmitConstantExpr(E)) { if (E->isGLValue()) -return CGF.Builder.CreateLoad(Address( -Result, CGF.ConvertTypeForMem(E->getType()), -CGF.getContext().

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { Fznamznon wrote: Done. https://github.com/llvm/llvm-project/pull/91364 __

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { - // Bool has a different representation in memory than in registers. - if (hasBooleanRepresen

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -2044,6 +2048,12 @@ llvm::Value *CodeGenFunction::EmitFromMemory(llvm::Value *Value, QualType Ty) { return emitBoolVecConversion(V, ValNumElems, "extractvec"); } + if (hasBooleanRepresentation(Ty) || Ty->isBitIntType()) { +llvm::Type *ResTy = ConvertType(Ty); +

[clang] [NFC][clang] Avoid unnecessary assignment (PR #100728)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/100728 `IsStartOfLine` is set to false at the end of the loop. >From e41e817050df138a0ac791c8aac0a3331c66d8df Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Fri, 26 Jul 2024 03:39:51 -0700 Subject: [P

[clang] [NFC][clang] Avoid unnecessary assignment (PR #100728)

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

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

@@ -133,6 +133,7 @@ struct TransferrableTargetInfo { unsigned short SuitableAlign; unsigned short NewAlign; unsigned MaxVectorAlign; Fznamznon wrote: Because `MaxVectorAlign` is set to a smaller value for some x86 targets - https://github.com/llvm/llvm-

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

@@ -133,6 +133,7 @@ struct TransferrableTargetInfo { unsigned short SuitableAlign; unsigned short NewAlign; unsigned MaxVectorAlign; Fznamznon wrote: I pasted log in a weird way, sorry, all failures in this particular test I see are for Darwin. ``` // M

[clang] [clang] Be careful when choosing "fast path" for initialization with #embed (PR #99023)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/99023 When #embed appears in an initializer list, we may choose a "fast path" - if the target declaration is a char array, we simply initialize it with string literal that contains embedded data. However we need to b

[clang] [clang] Be careful when choosing "fast path" for initialization with #embed (PR #99023)

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

[clang] [clang] Inject tokens containing #embed back into token stream (PR #97274)

Fznamznon wrote: > Just checked that one and it still fails on latest clang trunk using godbolt. Hmm, ok. https://github.com/llvm/llvm-project/pull/99023 . Thanks for pointing this out. https://github.com/llvm/llvm-project/pull/97274 ___ cfe-commits

[clang] [clang] Inject tokens containing #embed back into token stream (PR #97274)

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

[clang] [clang] Fix underlying type of EmbedExpr (PR #99050)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/99050 This patch makes remaining cases of #embed to emit int type since there is an agreement to do that for C. C++ is being discussed, but in general we don't want to produce different types for C and C++. >From c

[clang] [clang] Fix underlying type of EmbedExpr (PR #99050)

@@ -13,9 +13,9 @@ int ca[] = { }; // CHECK: %arrayinit.element = getelementptr inbounds i32, ptr %notca, i64 1 -// CHECK: store i8 106, ptr %arrayinit.element, align 4 +// CHECK: store i32 106, ptr %arrayinit.element, align 4 Fznamznon wrote: This is actually

[clang] [clang] Inject tokens containing #embed back into token stream (PR #97274)

Fznamznon wrote: FYI https://github.com/llvm/llvm-project/pull/99050 https://github.com/llvm/llvm-project/pull/97274 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/98629 >From ba498f559c742e62c13a09cb0b909d57d986e19e Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Fri, 12 Jul 2024 06:13:51 -0700 Subject: [PATCH 1/2] [clang] Limit alignment for emitted vectors The

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

@@ -133,6 +133,7 @@ struct TransferrableTargetInfo { unsigned short SuitableAlign; unsigned short NewAlign; unsigned MaxVectorAlign; Fznamznon wrote: Ok, I updated the patch to use `MaxVectorAlign` instead. Thanks https://github.com/llvm/llvm-project/pu

[clang] [clang] Be careful when choosing "fast path" for initialization with #embed (PR #99023)

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

[clang] [clang] Fix underlying type of EmbedExpr (PR #99050)

Fznamznon wrote: I can add test with sizeof for sure, the problem is that it is already working https://godbolt.org/z/K69v8KPYa and we have similar ones in codebase already. The test I'm struggling with is to check that elements in initializer list that are expanded from embed also have int typ

[clang] [clang] Fix static analyzer concerns in #embed code (PR #99331)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/99331 1. Dead code int LookupEmbedFile. The loop always exited on the first iteration. This was also causing a bug of not checking all directories provided by --embed-dir 2. Use of uninitialized variable CurTok Lex

[clang] [clang] Fix static analyzer concerns in #embed code (PR #99331)

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

[clang] [clang] Fix static analyzer concerns in #embed code (PR #99331)

@@ -1,4 +1,5 @@ -// RUN: %clang_cc1 -std=c23 %s -E -verify +// RUN: %clang_cc1 -std=c23 %s -E -verify --embed-dir=%S --embed-dir=%S/Inputs +#embed Fznamznon wrote: Makes sense. https://github.com/llvm/llvm-project/pull/99331 __

[clang] [clang] Fix static analyzer concerns in #embed code (PR #99331)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/99331 >From 178c66c9c4c68485931cf2d60063dd97f7858309 Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Wed, 17 Jul 2024 07:39:02 -0700 Subject: [PATCH 1/2] [clang] Fix static analyzer concerns in #embed c

[clang] [clang] Fix static analyzer concerns in #embed code (PR #99331)

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

[clang] [clang] Fix underlying type of EmbedExpr (PR #99050)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/99050 >From c089e2519184f029ab569d40facba14351928346 Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Tue, 16 Jul 2024 05:37:33 -0700 Subject: [PATCH 1/2] [clang] Fix underlying type of EmbedExpr This p

[clang] [clang] Fix underlying type of EmbedExpr (PR #99050)

Fznamznon wrote: > If you have an embed file with a single byte in it whose value is 0xFF, you > could use a test like: struct S { signed char ch; }; constexpr struct S s = { #embed "foo" }; which should give the same behavior as: https://godbolt.org/z/Tno5YPexM Thanks! That worked. I didn't

[clang] [clang] Fix static analyzer concerns in #embed code (PR #99331)

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

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

Fznamznon wrote: Closing since https://github.com/llvm/llvm-project/pull/99257 fixed the problem without side effects. Thank you very much @efriedma-quic https://github.com/llvm/llvm-project/pull/98629 ___ cfe-commits mailing list cfe-commits@lists.l

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

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

[clang] [clang] Fix assertion failure in `injectEmbedTokens` (PR #99624)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/99624 It seems for C++ lexer has some caching ability which doesn't expect injecting "new" tokens in the middle of the cache. Technically #embed tokens are not completely new since they have already been read from t

[clang] [clang] Fix underlying type of EmbedExpr (PR #99050)

Fznamznon wrote: > The one with alignof/typeof asserts for C++ (not for C) and I'd like to make > a fix and add this test in a separate PR Posted https://github.com/llvm/llvm-project/pull/99624 to fix the assertion https://github.com/llvm/llvm-project/pull/99050 ___

[clang] [clang] Fix underlying type of EmbedExpr (PR #99050)

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

[clang] [clang] Fix assertion failure in `injectEmbedTokens` (PR #99624)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/99624 >From 4922e1d4de5ccc9e645b151eb923440573e85fae Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Fri, 19 Jul 2024 02:56:38 -0700 Subject: [PATCH] [clang] Fix assertion failure in `injectEmbedTokens`

[clang] [clang] Fix assertion failure in `injectEmbedTokens` (PR #99624)

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

[clang] [clang][C23] Support N3029 Improved Normal Enumerations (PR #103917)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/103917 >From eee57bcc211a8a045c0102ebb2f4410d52d657f6 Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Wed, 14 Aug 2024 05:56:18 -0700 Subject: [PATCH 1/3] [clang][C23] Support N3029 Improved Normal Enum

[clang] [clang][C23] Support N3029 Improved Normal Enumerations (PR #103917)

@@ -125,6 +125,8 @@ C2y Feature Support C23 Feature Support ^^^ +- Clang now supports `N3029 `_ Improved Normal Enumerations. Fznamznon wrote: Good catch, thanks! https://github.co

[clang] [clang][C23] Support N3029 Improved Normal Enumerations (PR #103917)

@@ -19474,11 +19474,12 @@ EnumConstantDecl *Sema::CheckEnumConstant(EnumDecl *Enum, // representable as an int. // Complain if the value is not representable in an int. - if (!isRepresentableIntegerValue(Context, EnumVal, Context.IntTy)) -

[clang] [clang][C23] Support N3029 Improved Normal Enumerations (PR #103917)

Fznamznon wrote: > Please fix the diagnostics in pre-C23 mode to mention that we're following > C23 rules. Sure, done. https://github.com/llvm/llvm-project/pull/103917 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi

[clang] [NFC][clang] Add a release note for `#embed` (PR #97997)

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

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -128,6 +128,16 @@ class CodeGenTypes { /// memory representation is usually i8 or i32, depending on the target. llvm::Type *ConvertTypeForMem(QualType T, bool ForBitField = false); + /// Check that size and ABI alignment of given LLVM type matches size and + /// align

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -610,8 +610,26 @@ bool ConstStructBuilder::AppendBytes(CharUnits FieldOffsetInChars, } bool ConstStructBuilder::AppendBitField( -const FieldDecl *Field, uint64_t FieldOffset, llvm::ConstantInt *CI, +const FieldDecl *Field, uint64_t FieldOffset, llvm::Constant *C,

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1774,6 +1784,22 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (destType->isBitIntType()) { +if (!CGM.getTypes().LLVMTypeLayoutMatchesAST(destType, C->getType())) { + // Long _BitInt has array of bytes as in-memory

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -118,6 +124,39 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) { return R; } +bool CodeGenTypes::typeRequiresSplitIntoByteArray(QualType ASTTy, + llvm::Type *LLVMTy) { + if (!LLVMTy) +LLVM

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -128,6 +128,16 @@ class CodeGenTypes { /// memory representation is usually i8 or i32, depending on the target. llvm::Type *ConvertTypeForMem(QualType T, bool ForBitField = false); + /// Check that size and ABI alignment of given LLVM type matches size and + /// align

[clang] [clang] Inject tokens containing #embed back into token stream (PR #97274)

Fznamznon wrote: > I'd like to point out that most of the testcases I wrote for the GCC > implementation still fail with the latest clang on godbolt. This patch should help with at least some of them. https://github.com/llvm/llvm-project/pull/97274 _

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1,12 +1,25 @@ -// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK64 -// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHEC

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1886,6 +1896,29 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (destType->isBitIntType()) { +if (CGM.getTypes().typeRequiresSplitIntoByteArray(destType, C->getType())) { + // Long _BitInt has array of bytes as in-

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -609,9 +609,25 @@ bool ConstStructBuilder::AppendBytes(CharUnits FieldOffsetInChars, return Builder.add(InitCst, StartOffset + FieldOffsetInChars, AllowOverwrite); } -bool ConstStructBuilder::AppendBitField( -const FieldDecl *Field, uint64_t FieldOffset, llvm::Const

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -118,6 +124,37 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) { return R; } +bool CodeGenTypes::LLVMTypeLayoutMatchesAST(QualType ASTTy, +llvm::Type *LLVMTy) { + CharUnits ASTSize = Context.getTyp

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -2093,17 +2107,10 @@ void CodeGenFunction::EmitStoreOfScalar(llvm::Value *Value, Address Addr, llvm::Type *SrcTy = Value->getType(); if (const auto *ClangVecTy = Ty->getAs()) { auto *VecTy = dyn_cast(SrcTy); -if (VecTy && ClangVecTy->isExtVectorBoolType()) { -

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -1774,6 +1774,18 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (const auto *BIT = destType->getAs()) { +if (BIT->getNumBits() > 128) { + // Long _BitInt has array of bytes as in-memory type. + ConstantAggregat

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

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

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

@@ -107,17 +107,52 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) { return llvm::IntegerType::get(FixedVT->getContext(), BytePadded); } - // If this is a bool type, or a bit-precise integer type in a bitfield - // representation, map this

[clang] [clang] Use different memory layout type for _BitInt(N) in LLVM IR (PR #91364)

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

[clang] [clang] Use different memory layout type for _BitInt(N) in LLVM IR (PR #91364)

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

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/98629 The max aligment that ISel and therefore LLVM Verifier accepts is 2^14. The patch also forces indirect passing and returning of vectors bigger than this limit for generic and x86_64 targets. >From ba498f559c7

[clang] [clang] Inject tokens containing #embed back into token stream (PR #97274)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/97274 >From 4d5008fcf3ac37fa213c8f2cf42c3cce6369c83d Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Thu, 20 Jun 2024 06:04:07 -0700 Subject: [PATCH 1/3] [clang] Inject tokens containing #embed back int

[clang] [clang] Inject tokens containing #embed back into token stream (PR #97274)

@@ -3644,9 +3644,11 @@ bool Sema::CheckLoopHintExpr(Expr *E, SourceLocation Loc, bool AllowZero) { ExprResult Sema::ActOnNumericConstant(const Token &Tok, Scope *UDLScope) { // Fast path for a single digit (which is quite common). A single digit // cannot have a trigraph,

[clang] [clang] Use different memory layout type for _BitInt(N) in LLVM IR (PR #91364)

Fznamznon wrote: > Mariya, would you mind looking into setting this properly on the truncates > we're doing here? It'd be fine to do that as a follow-up; no need to hold up > this PR for it. You'll need some kind of target hook to tell us whether to > set it or not. Probably that ought to go i

[clang] [clang] Use different memory layout type for _BitInt(N) in LLVM IR (PR #91364)

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

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

@@ -133,6 +133,7 @@ struct TransferrableTargetInfo { unsigned short SuitableAlign; unsigned short NewAlign; unsigned MaxVectorAlign; Fznamznon wrote: `MaxVectorAlign` is set for x86 targets. I can use it as a limit as well, but note that this patch also

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

Fznamznon wrote: BTW, I think the limitation I'm hitting is introduced by https://reviews.llvm.org/D121898 . https://github.com/llvm/llvm-project/pull/98629 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

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

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

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

[clang] [clang] Inject tokens containing #embed back into token stream (PR #97274)

Fznamznon wrote: I'm looking through https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html This patch fixes cases like: ``` const unsigned char w[] = { #embed __FILE__ prefix([0] = 42, [15] =) limit(32) }; ``` And also cases like ``` void foo (int, int, int, int); void bar (void) { f

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

@@ -133,6 +133,7 @@ struct TransferrableTargetInfo { unsigned short SuitableAlign; unsigned short NewAlign; unsigned MaxVectorAlign; Fznamznon wrote: I did MaxVectorAlign = 2^14 in base TargetInfo, ``` if (Ty->getAs() && getContext().getType

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

@@ -133,6 +133,7 @@ struct TransferrableTargetInfo { unsigned short SuitableAlign; unsigned short NewAlign; unsigned MaxVectorAlign; Fznamznon wrote: I'm not sure it will? With only modifying base TargetInfo clang will continue emit LLVM IR where giant

[clang] [clang] Limit alignment for emitted vectors (PR #98629)

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

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/91364 Currently for i128:128 targets correct implementation is possible either for __int128 or for _BitInt(129+) with lowering to iN, but not both. Since we have now correct implementation of __int128 in place afte

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

Fznamznon wrote: Thank you everyone for the feedback. I'm working on applying. https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

<    1   2   3   4   5   6   7   8   9   >