[llvm-branch-commits] [llvm] release/20.x: [gtest] Fix building on OpenBSD/sparc64 (#145225) (PR #146155)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/146155 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] [Clang][Backport] Demote mixed enumeration arithmetic error to a warning (#131811) (PR #139396)

@@ -7567,9 +7567,13 @@ def warn_arith_conv_mixed_enum_types_cxx20 : Warning< "%sub{select_arith_conv_kind}0 " "different enumeration types%diff{ ($ and $)|}1,2 is deprecated">, InGroup; -def err_conv_mixed_enum_types_cxx26 : Error< + +def err_conv_mixed_enum_types: Error

[llvm-branch-commits] [clang] [clang][OpenMP] Improve handling of non-C/C++ directives (PR #139961)

https://github.com/AaronBallman approved this pull request. LGTM, thank you for the general fix! https://github.com/llvm/llvm-project/pull/139961 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mai

[llvm-branch-commits] [clang] [Clang][Backport] Demote mixed enumeration arithmetic error to a warning (#131811) (PR #139396)

@@ -7567,9 +7567,13 @@ def warn_arith_conv_mixed_enum_types_cxx20 : Warning< "%sub{select_arith_conv_kind}0 " "different enumeration types%diff{ ($ and $)|}1,2 is deprecated">, InGroup; -def err_conv_mixed_enum_types_cxx26 : Error< + +def err_conv_mixed_enum_types: Error

[llvm-branch-commits] [clang] [Clang][Backport] Demote mixed enumeration arithmetic error to a warning (#131811) (PR #139396)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/139396 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] [clang] Remove FEM_Indeterminable (#137661) (PR #138337)

AaronBallman wrote: > I agree, it's literally just a warning correction, and people building this > release of llvm with a newer clang can configure it to disable this warning - > I just wasn't sure what the general policy around this kind of thing was > which is why I made a PR and asked for

[llvm-branch-commits] [clang] [clang] Remove FEM_Indeterminable (#137661) (PR #138337)

AaronBallman wrote: I don't see a significant need to backport the changes, which is a good thing because I don't think we *can* backport this: it's an ABI breaking change (changes the size of the enumeration due to gaining a fixed underlying type). https://github.com/llvm/llvm-project/pull/13

[llvm-branch-commits] [clang] release/20.x: [clang][AST] Handle implicit first argument in CallExpr::getBeginLoc() (PR #135927)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/135927 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] Silence -Wcast-function-type warnings on idiomatic Windows code (#135… (PR #135798)

https://github.com/AaronBallman created https://github.com/llvm/llvm-project/pull/135798 …660) On Windows, GetProcAddress() is the API used to dynamically load function pointers (similar to dlsym on Linux). This API returns a function pointer (a typedef named FARPROC), which means that castin

[llvm-branch-commits] [clang] Silence -Wcast-function-type warnings on idiomatic Windows code (#135… (PR #135798)

https://github.com/AaronBallman milestoned https://github.com/llvm/llvm-project/pull/135798 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/20.x: [clang] Introduce "binary" StringLiteral for #embed data (#127629) (PR #133460)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/133460 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] release/20.x: [clang] Introduce "binary" StringLiteral for #embed data (#127629) (PR #133460)

@@ -1752,7 +1752,14 @@ enum class StringLiteralKind { UTF8, UTF16, UTF32, - Unevaluated + Unevaluated, + // Binary kind of string literal is used for the data coming via #embed + // directive. File's binary contents is transformed to a special kind of + // string lit

[llvm-branch-commits] [clang] release/20.x: [clang] Introduce "binary" StringLiteral for #embed data (#127629) (PR #133460)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/133460 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/20.x: [clang] Do not infer lifetimebound for functions with void return type (#131997) (PR #133997)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/133997 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] [Clang][Backport] Demote mixed enumeration arithmetic error to a warning (PR #131853)

@@ -7567,9 +7567,13 @@ def warn_arith_conv_mixed_enum_types_cxx20 : Warning< "%sub{select_arith_conv_kind}0 " "different enumeration types%diff{ ($ and $)|}1,2 is deprecated">, InGroup; -def err_conv_mixed_enum_types_cxx26 : Error< + +def err_conv_mixed_enum_types: Error

[llvm-branch-commits] [clang] [Clang][Backport] Demote mixed enumeration arithmetic error to a warning (PR #131853)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/131853 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] release/20.x: [Clang] Do not emit nodiscard warnings for the base expr of static member access (#131450) (PR #131474)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/131474 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] [clang] Fix preprocessor output from #embed (#126742) (PR #127222)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/127222 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] release/20.x: [CSKY] Default to unsigned char (PR #126436)

https://github.com/AaronBallman approved this pull request. LGTM though this definitely needs a release note so that anyone relying on the old behavior has some amount of notice (and a suggestion as to how to get the old behavior back). https://github.com/llvm/llvm-project/pull/126436

[llvm-branch-commits] [clang] release/20.x: Revert "[C++20][Modules][Serialization] Delay marking pending incompl… (#127136) (PR #127252)

AaronBallman wrote: > Not super familiar with the release cherry-picking workflow. How should I > move this forward? You've done it correctly (though you should set your email to public per https://github.com/llvm/llvm-project/pull/127252#issuecomment-2660155014). It's just waiting on review

[llvm-branch-commits] [clang] [clang] Implement instantiation context note for checking template parameters (PR #126088)

@@ -1018,9 +1019,9 @@ namespace cwg62 { // cwg62: 2.9 struct A { struct { int n; } b; }; - template struct X {}; - template T get() { return get(); } - template int take(T) { return 0; } + template struct X {}; // cxx98-note 6{{template parameter is declared here}}

[llvm-branch-commits] [clang] [clang] Implement instantiation context note for checking template parameters (PR #126088)

@@ -1018,9 +1019,9 @@ namespace cwg62 { // cwg62: 2.9 struct A { struct { int n; } b; }; - template struct X {}; - template T get() { return get(); } - template int take(T) { return 0; } + template struct X {}; // cxx98-note 6{{template parameter is declared here}}

[llvm-branch-commits] [clang] release/20.x: Revert "[C++20][Modules][Serialization] Delay marking pending incompl… (#127136) (PR #127252)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/127252 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] [clang] Implement instantiation context note for checking template parameters (PR #126088)

@@ -1018,9 +1019,9 @@ namespace cwg62 { // cwg62: 2.9 struct A { struct { int n; } b; }; - template struct X {}; - template T get() { return get(); } - template int take(T) { return 0; } + template struct X {}; // cxx98-note 6{{template parameter is declared here}}

[llvm-branch-commits] [clang] release/20.x: [TBAA] Don't emit pointer-tbaa for void pointers. (#122116) (PR #125206)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/125206 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] release/20.x: [TBAA] Don't emit pointer-tbaa for void pointers. (#122116) (PR #125206)

AaronBallman wrote: > Without the pointer-tbaa changes (which is new on by default in Clang 20), we > would always generate `any pointer`. Without this fix, we will generate > different tags for different `void` pointer depths. > > With this fix, we will generate `any pointer` again for `void`

[llvm-branch-commits] [clang] release/20.x: [TBAA] Don't emit pointer-tbaa for void pointers. (#122116) (PR #125206)

AaronBallman wrote: > @AaronBallman Isn't the pointer TBAA support new in Clang 20? It changed code in https://github.com/llvm/llvm-project/blame/27fe2c95ee067ee013b947040538224187b3adb7/clang/lib/CodeGen/CodeGenTBAA.cpp#L117 which is ~15 years old. https://github.com/llvm/llvm-project/pull/1

[llvm-branch-commits] [clang] release/20.x: [TBAA] Don't emit pointer-tbaa for void pointers. (#122116) (PR #125206)

https://github.com/AaronBallman commented: I'm on the fence. On the one hand, it's a small amount of code to change and it fixes miscompiles, so it's a good candidate. On the other hand, there's not been much bake time and it's changing behavior in Clang that's worked that way for about 15 yea

[llvm-branch-commits] [clang] release/20.x: [clang] StmtPrinter: Handle DeclRefExpr to a Decomposition (#125001) (PR #126659)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/126659 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] Allow 'inline' on some declarations in MS compatibility mode (#125250) (PR #125275)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/125275 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Allow 'inline' on some declarations in MS compatibility mode (#125250) (PR #125275)

https://github.com/AaronBallman milestoned https://github.com/llvm/llvm-project/pull/125275 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Allow 'inline' on some declarations in MS compatibility mode (#125250) (PR #125275)

https://github.com/AaronBallman created https://github.com/llvm/llvm-project/pull/125275 Microsoft allows the 'inline' specifier on a typedef of a function type in C modes. This is used by a system header (ufxclient.h), so instead of giving a hard error, we diagnose with a warning. C++ mode an

[llvm-branch-commits] [clang] release/20.x: Fix false negative when value initializing a field annotated with [[clang::require_field_initialization]] (#124329) (PR #125249)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/125249 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [compiler-rt] [compiler-rt] Convert Maintainers.txt into Maintainers.md (PR #119169)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/119169 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] [TySan] A Type Sanitizer (Clang) (PR #76260)

@@ -1027,6 +1027,10 @@ Sanitizers `_. See that link for examples. +- Introduced an experimental Type Sanitizer, activated by using the + -fsanitize=type flag. This sanitizer detects violations of C/C++ type-based

[llvm-branch-commits] [clang] [TySan] A Type Sanitizer (Clang) (PR #76260)

@@ -102,6 +102,7 @@ FEATURE(numerical_stability_sanitizer, LangOpts.Sanitize.has(SanitizerKind::Nume FEATURE(memory_sanitizer, LangOpts.Sanitize.hasOneOf(SanitizerKind::Memory | SanitizerKind::KernelMemory)) +FEATURE(type_sanitizer, L

[llvm-branch-commits] [clang] [Clang] Improve type traits recognition in `__has_builtin` (#111516) (PR #111660)

AaronBallman wrote: > It is an ugly situation that a point release fixes one problem but breaks > another. 100% agreed, it's an unfortunate situation to be in. > Preferably get intended behavior in both cases but we don't live in a perfect > world and do live with compromises. Agreed, thoug

[llvm-branch-commits] [clang] [Clang] Improve type traits recognition in `__has_builtin` (#111516) (PR #111660)

AaronBallman wrote: Yes. but other builtins were also impacted and went from returning true (18.x) to false (19.x) to true (20.x): https://godbolt.org/z/8vPvzb81x Just to double-check assumptions -- we don't know of any builtins which Clang now reports true for which Clang does not actually su

[llvm-branch-commits] [clang] [Clang] Improve type traits recognition in `__has_builtin` (#111516) (PR #111660)

AaronBallman wrote: > @tru This change breaks use of llvm 19.1.2 and 19.1.3 #113125 Can it be > reverted on the release branch? Oof, that's unfortunate because this is cherry picking a fix where Clang 19 started returning `false` for `__has_builtin(__reference_binds_to_temporary)` when it was

[llvm-branch-commits] [clang] [clang][CIR] Merge the mlir::cir namespace into cir (PR #115386)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/115386 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] [clang] Fix C23 constexpr crashes (#112708) (PR #112855)

https://github.com/AaronBallman updated https://github.com/llvm/llvm-project/pull/112855 >From fb40fba6f9caf44a1e839525efdaebdf936c2934 Mon Sep 17 00:00:00 2001 From: Mariya Podchishchaeva Date: Fri, 18 Oct 2024 10:18:34 +0200 Subject: [PATCH] [clang] Fix C23 constexpr crashes (#112708) Before

[llvm-branch-commits] [clang] [clang] Fix C23 constexpr crashes (#112708) (PR #112855)

AaronBallman wrote: > This has conflicts now. Can someone fix it and I can merge it for 19.1.4 I took a shot at resolving the conflicts (I think Mariya is out on vacation currently). https://github.com/llvm/llvm-project/pull/112855 ___ llvm-branch-co

[llvm-branch-commits] [clang] [Clang] Disable use of the counted_by attribute for whole struct pointers (#112636) (PR #112786)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/112786 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] [clang] Fix C23 constexpr crashes (#112708) (PR #112855)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/112855 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] [clang] Reject if constexpr in C (#112685) (PR #112697)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/112697 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-comm

[llvm-branch-commits] [clang] [Clang] Improve type traits recognition in `__has_builtin` (#111516) (PR #111660)

AaronBallman wrote: > @AaronBallman ok to backport? Yeah, seems reasonable to me. https://github.com/llvm/llvm-project/pull/111660 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/

[llvm-branch-commits] [clang] release/19.x: [Clang][Sema] Use the correct lookup context when building overloaded 'operator->' in the current instantiation (#104458) (PR #107886)

AaronBallman wrote: > This change has already been reverted on main because it breaks clang > bootstrap and causes assertion failures. This was already known at the time > it was accepted as "low risk" here. Please exercise at least a minimum amount > of due diligence before approving backport

[llvm-branch-commits] [clang] release/19.x: [Clang][Sema] Use the correct lookup context when building overloaded 'operator->' in the current instantiation (#104458) (PR #107886)

https://github.com/AaronBallman approved this pull request. LGTM -- I think this is important for 19.x given the behavior it's correcting. https://github.com/llvm/llvm-project/pull/107886 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.l

[llvm-branch-commits] [clang] [Clang] Workaround dependent source location issues (#106925) (PR #107212)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/107212 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] release/19.x: Fix codegen of consteval functions returning an empty class, and related issues (#93115) (PR #102070)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/102070 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [llvm] release/19.x: [IndVars] Check if WideInc available before trying to use it (PR #106892)

https://github.com/AaronBallman approved this pull request. I think you may have intended to tag someone other than Shafik and I for this one, but the changes LGTM nonetheless. https://github.com/llvm/llvm-project/pull/106892 ___ llvm-branch-commits m

[llvm-branch-commits] [clang] release/19.x: Fix codegen of consteval functions returning an empty class, and related issues (#93115) (PR #102070)

AaronBallman wrote: I'd really appreciate a review from @rjmccall -- the changes are extensive and risky enough that I worry about landing them this late in the cycle, but this does fix a miscompile and that's a pretty important thing for us to land. I didn't spot any concerns with the changes

[llvm-branch-commits] [clang] release/19.x: Revert "[clang] fix broken canonicalization of DeducedTemplateSpeciatizationType (#95202)" (PR #106516)

https://github.com/AaronBallman approved this pull request. LGTM! Do we have a release note we need to remove as well? https://github.com/llvm/llvm-project/pull/106516 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://list

[llvm-branch-commits] [clang] release/19.x: [clang][AArch64] Point the nofp ABI check diagnostics at the callee (#103392) (PR #104027)

https://github.com/AaronBallman approved this pull request. LGTM, but please add a release note when this lands. https://github.com/llvm/llvm-project/pull/104027 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm

[llvm-branch-commits] [clang] Cherry pick: [Clang][Sema] Make UnresolvedLookupExprs in class scope explicit spec… (PR #102514)

https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/102514 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] release/19.x: [AIX] Revert `#pragma mc_func` check (#102919) (PR #102968)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/102968 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [llvm] release/19.x: [AArch64] Add streaming-mode stack hazard optimization remarks (#101695) (PR #102168)

AaronBallman wrote: > The patch here is pretty big in size, but it seems to only affects the > remarks, on the other hand it doesn't seem to really fix anything and in that > case I feel like RC3 might be the wrong time to merge this. Is there a huge > upside to take this this late in the proc

[llvm-branch-commits] [clang] release/19.x: [clang] Fix crash when #embed used in a compound literal (#102304) (PR #102428)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/102428 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] [Driver] Temporarily probe aarch64-linux-gnu GCC installation (PR #102039)

https://github.com/AaronBallman approved this pull request. LGTM, thank you for the quick workaround! https://github.com/llvm/llvm-project/pull/102039 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bi

[llvm-branch-commits] [clang] release/19.x: [Clang] SFINAE on mismatching pack length during constraint satisfaction checking (#101879) (PR #101967)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/101967 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi

[llvm-branch-commits] [clang] release/19.x: [Driver] Restrict Ofast deprecation help message to Clang (#101682) (PR #101963)

https://github.com/AaronBallman approved this pull request. LGTM for a backport https://github.com/llvm/llvm-project/pull/101963 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llv

[llvm-branch-commits] [clang] release/19.x: Ofast deprecation clarifications (#101005) (PR #101663)

AaronBallman wrote: The current release note reads as: ``` - The ``-Ofast`` command-line option has been deprecated. This option both enables the ``-O3`` optimization-level, as well as enabling non-standard ``-ffast-math`` behaviors. As such, it is somewhat misleading as an "optimization le

[llvm-branch-commits] [clang] [llvm] release/19.x: [clang] Fix definition of layout-compatible to ignore empty classes (PR #101491)

AaronBallman wrote: Thanks for reminding me of that @Endilll -- LGTM still. https://github.com/llvm/llvm-project/pull/101491 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-br

[llvm-branch-commits] [clang] release/19.x: Ofast deprecation clarifications (#101005) (PR #101663)

https://github.com/AaronBallman approved this pull request. LGTM! There's no chance these changes are what is breaking the ABI precommit CI tests. ;-) https://github.com/llvm/llvm-project/pull/101663 ___ llvm-branch-commits mailing list llvm-branch-co

[llvm-branch-commits] [clang] [llvm] release/19.x: [clang] Fix definition of layout-compatible to ignore empty classes (PR #101491)

https://github.com/AaronBallman approved this pull request. LGTM! The ABI precommit CI test failures look to be unrelated to these changes, but at the same time, this could potentially impact ABI (any time we change the behavior of a type trait, it can potentially impact ABI). So it may be goo

[llvm-branch-commits] [clang] [clang][FMV][AArch64] Improve streaming mode compatibility (PR #101007)

https://github.com/AaronBallman approved this pull request. The changes LGTM -- the precommit CI failures seem to be unrelated, but it would be good to get a second opinion. After the pick lands, please be sure to add a release note so users know about the fix. https://github.com/llvm/llvm-pr

[llvm-branch-commits] [clang] [clang][FMV][AArch64] Improve streaming mode compatibility (PR #101007)

AaronBallman wrote: Ah thank you for the explanation -- what was tripping me up was the changes in `clang/test/Sema/aarch64-sme-func-attrs.c` where we used to issue diagnostics. Okay, this makes more sense as to why we'd want to backport it then, so I retract my objection. https://github.com/

[llvm-branch-commits] [clang] release/19.x: [ExprConstant] Handle shift overflow the same way as other kinds of overflow (#99579) (PR #100452)

AaronBallman wrote: Just what was hopefully already merged: - Clang now diagnoses undefined behavior in constant expressions more consistently. This includes invalid shifts, and signed overflow in arithmetic. https://github.com/llvm/llvm-project/pull/100452

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

https://github.com/AaronBallman commented: Thank you for working on this! I think we need these changes to be against `main` and not `19.x`, aside from the release notes (otherwise we're losing the documentation in 20.x). For the release notes, I think we can talk to @tstellar and @tru about g

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

@@ -495,10 +495,12 @@ New Compiler Flags Deprecated Compiler Flags - -- The ``-Ofast`` command-line option has been deprecated. This option both - enables the ``-O3`` optimization-level, as well as enabling non-standard - ``-ffast-math`` behaviors. As

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

@@ -429,8 +429,11 @@ Code Generation Options :option:`-Ofast` Enables all the optimizations from :option:`-O3` along with other aggressive optimizations that may violate strict compliance with -language standards. This is deprecated in favor of :option:`-O3` -i

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/101005 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [clang][Sema] Add support for OpenBSD's syslog format attribute (#97366) (PR #100703)

https://github.com/AaronBallman commented: I don't see a need to backport this for 19.x, it seems reasonable to let it bake for a while in 20.x (though I would be surprised if there was significant negative fallout from the changes). https://github.com/llvm/llvm-project/pull/100703 ___

[llvm-branch-commits] [clang] release/19.x: [clang][headers] Including stddef.h always redefines NULL (#99727) (PR #100191)

https://github.com/AaronBallman approved this pull request. LGTM, I think the CI failures are unrelated to this patch. https://github.com/llvm/llvm-project/pull/100191 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://list

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

AaronBallman wrote: > > Do you need me to land the changes on your behalf? > > No need, I can do that. However, this PR is in a stack and depends on two > small PRs: #94244 and #94243 that need to be reviewed before this PR can be > merged Ah thank you for pointing this out, I hadn't realized

[llvm-branch-commits] [clang] [clang][test] remove unused `run` overload in `BoundNodesCallback` (PR #94244)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/94244 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

AaronBallman wrote: > Thanks. > > > ... how this impacts build times for Clang itself? I'm assuming that if > > ASTMatchers.h isn't modified, CMake won't re-run > > generate_ast_matcher_doc_tests.py and so the compile time performance hit > > is only on full rebuilds or when changing the head

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

https://github.com/AaronBallman commented: The changes generally LGTM, though I would appreciate a second set of eyes on the CMake and Python changes because I have a bit less confidence in my review abilities there. Thank you for adding the documentation to the header file, I think that will

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

@@ -330,35 +377,46 @@ AST_POLYMORPHIC_MATCHER_P(isExpandedFromMacro, /// Matches declarations. /// -/// Examples matches \c X, \c C, and the friend declaration inside \c C; +/// Given /// \code /// void X(); /// class C { -/// friend X; +/// friend void X(); //

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

@@ -176,11 +176,13 @@ inline internal::TrueMatcher anything() { return internal::TrueMatcher(); } /// \code /// int X; /// namespace NS { -/// int Y; +/// int Y; /// } // namespace NS /// \endcode -/// decl(hasDeclContext(translationUnitDecl())) -/// matches "

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

https://github.com/AaronBallman commented: I wonder if we should add some documentation to ASTMatchers.h about the new special syntax for comments so that users who hit test failures with the new automatic tests have some more help getting to a solution. https://github.com/llvm/llvm-project/pu

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

@@ -330,35 +377,46 @@ AST_POLYMORPHIC_MATCHER_P(isExpandedFromMacro, /// Matches declarations. /// -/// Examples matches \c X, \c C, and the friend declaration inside \c C; +/// Given /// \code /// void X(); /// class C { -/// friend X; +/// friend void X(); //

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

https://github.com/AaronBallman commented: It looks like precommit CI found relevant failures: ``` _bk;t=1717501095887FAILED: tools/clang/unittests/ASTMatchers/ASTMatchersDocTests.cpp _bk;t=1717501095887cmd.exe /C "cd /D C:\ws\src\build\tools\clang\unittests\ASTMatchers && C:\ws\src\clang

[llvm-branch-commits] [NFCI][metadata][clang] Use create{Unlikely, Likely}BranchWeights (PR #89467)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/89467 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit

[llvm-branch-commits] [NFCI][metadata][clang] Use create{Unlikely, Likely}BranchWeights (PR #89467)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/89467 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

https://github.com/AaronBallman approved this pull request. I verified the layout seems reasonable in Visual Studio 2022; LGTM! https://github.com/llvm/llvm-project/pull/89743 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org http

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

AaronBallman wrote: > @AaronBallman Would you mind reviewing D89741 ? I was convinced a stakeholder > there but they decided to drop out instead of approving it. Oh the fun of PR numbers now lining up with Phabricator numbers. I thought you meant https://reviews.llvm.org/D89741 and was very co

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

AaronBallman wrote: > @AaronBallman Thanks for having a look. > > > With this patch, I get errors when loading a visual studio solution > > generated with these change, and all of clang's libraries are placed at the > > top level. The error is a dialog box saying "The solution already contains

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

https://github.com/AaronBallman commented: With this patch, I get errors when loading a visual studio solution generated with these change, and all of clang's libraries are placed at the top level. The error is a dialog box saying "The solution already contains an item named 'clang'." Another

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

@@ -3464,6 +3464,34 @@ Query for this feature with ``__has_builtin(__builtin_trap)``. ``__builtin_arm_trap`` is lowered to the ``llvm.aarch64.break`` builtin, and then to ``brk #payload``. +``__builtin_allow_runtime_check`` AaronBallman wrote: > It needs t

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

@@ -3464,6 +3464,54 @@ Query for this feature with ``__has_builtin(__builtin_trap)``. ``__builtin_arm_trap`` is lowered to the ``llvm.aarch64.break`` builtin, and then to ``brk #payload``. +``__builtin_allow_runtime_check`` +- + +``__builtin_

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

@@ -3464,6 +3464,34 @@ Query for this feature with ``__has_builtin(__builtin_trap)``. ``__builtin_arm_trap`` is lowered to the ``llvm.aarch64.break`` builtin, and then to ``brk #payload``. +``__builtin_allow_runtime_check`` AaronBallman wrote: The docs are

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

@@ -3233,6 +3233,17 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, unsigned BuiltinID, if (BuiltinCountZeroBitsGeneric(*this, TheCall)) return ExprError(); break; + + case Builtin::BI__builtin_allow_runtime_check: { +Expr *Arg = TheCall->getArg(0); +

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

AaronBallman wrote: > > LGTM, though it would be nice if @petrhosek or @Ericson2314 could validate > > the cmake changes (they look sensible to me, but I never know if there's a > > better way to do things in CMake). > > We already did that above. Petr left a comment and it was fixed :p Ah, I

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/86080 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

@@ -0,0 +1,44 @@ +//===- CIRDialect.td - CIR dialect -*- tablegen -*-===// +// +// 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: Apa

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

https://github.com/AaronBallman approved this pull request. LGTM, though it would be nice if @petrhosek or @Ericson2314 could validate the cmake changes (they look sensible to me, but I never know if there's a better way to do things in CMake). https://github.com/llvm/llvm-project/pull/86080 _

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

@@ -0,0 +1,44 @@ +//===- CIRDialect.td - CIR dialect -*- tablegen -*-===// +// +// 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: Apa

  1   2   >