[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)

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

[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)

@@ -0,0 +1,95 @@ +// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only --embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall + +#include + +enum us : unsigned short { + us_max = USHRT_MAX, + us_violation, // expected-error {{enumerator value 65536 is not rep

[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)

@@ -0,0 +1,95 @@ +// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only --embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall + +#include + +enum us : unsigned short { + us_max = USHRT_MAX, + us_violation, // expected-error {{enumerator value 65536 is not rep

[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)

@@ -5413,18 +5413,20 @@ void Parser::ParseEnumSpecifier(SourceLocation StartLoc, DeclSpec &DS, BaseRange = SourceRange(ColonLoc, DeclaratorInfo.getSourceRange().getEnd()); - if (!getLangOpts().ObjC && !getLangOpts().C23) { + if (!getLangOpts().ObjC) {

[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)

@@ -0,0 +1,95 @@ +// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only --embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall Fznamznon wrote: Done, thanks for the catch! https://github.com/llvm/llvm-project/pull/107260 _

[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/107260 >From da76f2dfd3b0c8e2a03165ad1ac06b517c4af391 Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Wed, 4 Sep 2024 07:45:27 -0700 Subject: [PATCH 1/2] [clang][C23] Claim N3030 Enhancements to Enumera

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

https://github.com/Fznamznon closed https://github.com/llvm/llvm-project/pull/103917 ___ 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)

Fznamznon wrote: ping @AaronBallman https://github.com/llvm/llvm-project/pull/103917 ___ 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)

@@ -169,13 +169,19 @@ enum class GH42372_2 { One }; +enum IncOverflow { + V2 = __INT_MAX__, + V3 // c99-warning {{incremented enumerator value that is exceeding range of 'int' is a C23 extension}} +#if __STDC_VERSION__ >= 202311L Fznamznon wrote: I misse

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

@@ -1,23 +1,23 @@ -// RUN: %clang_cc1 -triple %itanium_abi_triple %s -fsyntax-only -verify -pedantic +// RUN: %clang_cc1 -triple %itanium_abi_triple %s -fsyntax-only -verify=expected,c99 -pedantic Fznamznon wrote: Hmm, I think removing the prefix is more accura

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

@@ -0,0 +1,59 @@ +// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only --embed-dir=%S/Inputs -std=c23 %s -pedantic -Wpre-c23-compat Fznamznon wrote: Done. https://github.com/llvm/llvm-project/pull/103917

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

@@ -6194,9 +6195,12 @@ def err_misplaced_ivar : Error< def warn_ivars_in_interface : Warning< "declaration of instance variables in the interface is deprecated">, InGroup>, DefaultIgnore; -def ext_enum_value_not_int : Extension< - "ISO C restricts enumerator values to rang

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

@@ -1039,7 +1039,8 @@ def err_opencl_invalid_param : Error< "declaring function parameter of type %0 is not allowed%select{; did you forget * ?|}1">; def err_opencl_invalid_return : Error< "declaring function return value of type %0 is not allowed %select{; did you forget

[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/5] [clang][C23] Support N3029 Improved Normal Enum

[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)

@@ -0,0 +1,95 @@ +// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only --embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall + +#include + +enum us : unsigned short { + us_max = USHRT_MAX, + us_violation, // expected-error {{enumerator value 65536 is not rep

[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] [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)

@@ -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)

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)

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/2] [clang][C23] Support N3029 Improved Normal Enum

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

@@ -172,10 +172,8 @@ enum class GH42372_2 { #if __STDC_VERSION__ >= 202311L // FIXME: GCC picks __uint128_t as the underlying type for the enumeration // value and Clang picks unsigned long long. -// FIXME: Clang does not yet implement WG14 N3029, so the warning about -// restr

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

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/103917 Basically clang already implemented 90% of the feature as an extension. This commit disables warnings for C23 and aligns types of enumerators according to the recent wording. >From eee57bcc211a8a045c0102ebb2

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

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

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

@@ -7042,12 +7042,38 @@ void Sema::CheckCompletedCXXClass(Scope *S, CXXRecordDecl *Record) { } } +bool EffectivelyConstexprDestructor = true; +// Avoid triggering vtable instantiation due to a dtor that is not +// "effectively constexpr" for better compa

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

@@ -7042,12 +7042,38 @@ void Sema::CheckCompletedCXXClass(Scope *S, CXXRecordDecl *Record) { } } +bool EffectivelyConstexprDestructor = true; +// Avoid triggering vtable instantiation due to a dtor that is not +// "effectively constexpr" for better compa

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

Fznamznon wrote: > Does this also fix #92486? Yes, it does. https://github.com/llvm/llvm-project/pull/102605 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/102605 >From eb97afb9cade7b496ec55acdd4f02a915c4a4955 Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Fri, 9 Aug 2024 05:20:37 -0700 Subject: [PATCH 1/2] [clang] Avoid triggering vtable instantiation fo

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

@@ -0,0 +1,22 @@ +// RUN: %clang_cc1 -std=c++23 -fsyntax-only -verify %s +// expected-no-diagnostics + +template static void destroy() { +T t; +++t; +} + +struct Incomplete; + +template struct HasD { + ~HasD() { destroy(); } +}; + +struct HasVT { + virtual ~HasVT(); +}

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

@@ -0,0 +1,22 @@ +// RUN: %clang_cc1 -std=c++23 -fsyntax-only -verify %s +// expected-no-diagnostics + +template static void destroy() { +T t; +++t; +} + +struct Incomplete; + +template struct HasD { + ~HasD() { destroy(); } +}; + +struct HasVT { + virtual ~HasVT(); +}

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

@@ -7042,12 +7042,38 @@ void Sema::CheckCompletedCXXClass(Scope *S, CXXRecordDecl *Record) { } } +bool EffectivelyConstexprDestructor = true; +// Avoid triggering vtable instantiation due to a dtor that is not +// "effectively constexpr" for better compa

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

Fznamznon wrote: I'm really in doubts that this is actually correct and useful... https://github.com/llvm/llvm-project/pull/102605 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/102605 In C++23 anything can be constexpr, including a dtor of a class whose members and bases don't have constexpr dtors. Avoid early triggering of vtable instantiation int this case. Fixes https://github.com/llvm

[clang] [clang] Fix crash when #embed used in a compound literal (PR #102304)

Fznamznon wrote: /cherry-pick 3606d69d0b57dc1d23a4362e376e7ad27f650c27 https://github.com/llvm/llvm-project/pull/102304 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix crash when #embed used in a compound literal (PR #102304)

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

[clang] [clang] Fix crash when #embed used in a compound literal (PR #102304)

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

[clang] [clang] Fix crash when #embed used in a compound literal (PR #102304)

@@ -1,9 +1,15 @@ // RUN: %clang_cc1 %s -triple x86_64 --embed-dir=%S/Inputs -emit-llvm -o - | FileCheck %s +// CHECK: @.compoundliteral = internal global [2 x i8] c"jk" // CHECK: @__const._Z3fooi.ca = private unnamed_addr constant [3 x i32] [i32 0, i32 106, i32 107], align 4

[clang] [clang] Fix crash when #embed used in a compound literal (PR #102304)

https://github.com/Fznamznon updated https://github.com/llvm/llvm-project/pull/102304 >From ebeb9264e8a4e6d57a4573376248191f64ad99e7 Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Wed, 7 Aug 2024 04:04:09 -0700 Subject: [PATCH 1/2] [clang] Fix crash when #embed used in a compound

[clang] [clang] Fix crash when #embed used in a compound literal (PR #102304)

https://github.com/Fznamznon created https://github.com/llvm/llvm-project/pull/102304 Fixes https://github.com/llvm/llvm-project/issues/102248 >From ebeb9264e8a4e6d57a4573376248191f64ad99e7 Mon Sep 17 00:00:00 2001 From: "Podchishchaeva, Mariya" Date: Wed, 7 Aug 2024 04:04:09 -0700 Subject: [P

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

@@ -2123,17 +2123,18 @@ class Preprocessor { char getSpellingOfSingleCharacterNumericConstant(const Token &Tok, Fznamznon wrote: Thank you @AaronBallman https://github.com/llvm/llvm-project/pull/97274 ___ cfe-co

[clang] [Clang] prevent assertion failure by avoiding required literal type checking in C context (PR #101426)

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

[clang] [Clang] prevent assertion failure by avoiding required literal type checking in C context (PR #101426)

@@ -9267,14 +9267,14 @@ bool Sema::RequireLiteralType(SourceLocation Loc, QualType T, if (!RT) return true; - const CXXRecordDecl *RD = cast(RT->getDecl()); - // A partially-defined class type can't be a literal type, because a literal // class type must have a t

[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] [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] [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] 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 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 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 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] 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] 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] 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] 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 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 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)

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)

@@ -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 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)

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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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)

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)

@@ -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)

@@ -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] 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)

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] 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)

@@ -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] 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] 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] 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] 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] 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] 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] 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] 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)

@@ -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)

@@ -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)

@@ -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)

@@ -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)

@@ -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)

@@ -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] 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)

@@ -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)

@@ -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)

@@ -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)

@@ -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)

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

  1   2   3   4   5   6   >