[clang] [HIP][Clang][Driver] Move BC preference logic into ROCm detection (PR #149294)

jchlanda wrote: No new tests are added in this patch, but the expected behaviour should not change and existing tests cover it: * [amdgpu-openmp-toolchain.c](https://github.com/jchlanda/llvm-project/blob/jakub/rocm_detection/clang/test/Driver/amdgpu-toolchain.c#L1) * [hip-device-libs.hip](http

[clang] [RISCV] Add -march=unset to cancel and ignore a previous -march. (PR #148321)

https://github.com/asb approved this pull request. I like this solution too. https://github.com/llvm/llvm-project/pull/148321 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Clang][OpenMP] Non-contiguous strided update (PR #144635)

alexey-bataev wrote: Also, update OpenMPSupport.rst and release notes https://github.com/llvm/llvm-project/pull/144635 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Clang][OpenMP] Non-contiguous strided update (PR #144635)

@@ -4724,6 +4724,65 @@ void x() { EXPECT_TRUE(matchesWithOpenMP(Source8, Matcher)); } +TEST_P(ASTMatchersTest, OMPTargetUpdateDirective_IsStandaloneDirective) { alexey-bataev wrote: Clang tests are required https://github.com/llvm/llvm-project/pull/144635

[clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)

https://github.com/alexey-bataev commented: Some previous comments are not addressed yet https://github.com/llvm/llvm-project/pull/139293 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)

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

[clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)

@@ -1143,6 +1143,83 @@ class OMPFullClause final : public OMPNoChildClause { static OMPFullClause *CreateEmpty(const ASTContext &C); }; +/// This class represents the 'looprange' clause in the +/// '#pragma omp fuse' directive +/// +/// \code {c} +/// #pragma omp fuse loopr

[clang] [llvm] [Clang] Add `__builtin_stack_address` (PR #148281)

@@ -121,6 +121,11 @@ enum NodeType { /// function calling this intrinsic. SPONENTRY, + /// STACKADDR - Represents the llvm.stackaddr intrinsic. Takes no argument + /// and returns the starting address of the stack region that may be used + /// by called functions. + ST

[clang] [llvm] [AMDGPU] Add support for `v_exp_bf16` on gfx1250 (PR #149229)

shiltian wrote: ### Merge activity * **Jul 17, 12:41 PM UTC**: A user started a stack merge that includes this pull request via [Graphite](https://app.graphite.dev/github/pr/llvm/llvm-project/149229). https://github.com/llvm/llvm-project/pull/149229 __

[clang] [Clang] Do not treat Foo -> const Foo conversion sequences as perfect (PR #148613)

cor3ntin wrote: Sorry for the inconvenience. It was clearly not the right solution in hindsight. It may take me a while to figure out how to approach a fix to https://github.com/llvm/llvm-project/issues/147374 https://github.com/llvm/llvm-project/pull/148613 ___

[clang] [clang-repl] Lay the basic infrastructure for pretty printing of types (PR #148701)

@@ -300,16 +640,17 @@ llvm::Expected Interpreter::ExtractValueFromExpr(Expr *E) { using namespace clang; // Temporary rvalue struct that need special care. -REPL_EXTERNAL_VISIBILITY void * +REPL_EXTERNAL_VISIBILITY extern "C" void * AaronBallman wrote: That

[clang] [clang][bytecode] Fix const-in-mutable fields (PR #149286)

https://github.com/tbaederr created https://github.com/llvm/llvm-project/pull/149286 For mutable and const fields, we have two bits in InlineDescriptor, which both get inherited down the hierarchy. When a field is both const and mutable, we CAN read from it if it is a mutable-in-const field, b

[clang] [llvm] [Clang] Add `__builtin_stack_address` (PR #148281)

@@ -853,6 +853,7 @@ def int_addressofreturnaddress : DefaultAttrsIntrinsic<[llvm_anyptr_ty], [], [In def int_frameaddress : DefaultAttrsIntrinsic<[llvm_anyptr_ty], [llvm_i32_ty], [IntrNoMem, ImmArg>]>; def int_sponentry : DefaultAttrsIntrinsic

[clang] [clang][bytecode] Fix const-in-mutable fields (PR #149286)

https://github.com/tbaederr updated https://github.com/llvm/llvm-project/pull/149286 >From 3ff796f7b6f09143de36746ea3e024a2903e26f2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Timm=20B=C3=A4der?= Date: Thu, 17 Jul 2025 12:31:01 +0200 Subject: [PATCH] [clang][bytecode] Fix const-in-mutable fields

[clang] [llvm] [openmp] [clang][OpenMP] New OpenMP 6.0 threadset clause (PR #135807)

@@ -1324,6 +1324,86 @@ class OMPDefaultClause : public OMPClause { } }; +/// This represents 'threadset' clause in the '#pragma omp task ...' directive. +/// +/// \code +/// #pragma omp task threadset(omp_pool) +/// \endcode +/// In this example directive '#pragma omp task'

[clang] [Clang] Do not treat Foo -> const Foo conversion sequences as perfect (PR #148613)

bgra8 wrote: Thanks for reverting @cor3ntin ! The fallout @alexfh refers too is caused by code that reduces to something similar to what @MatzeB reported. https://github.com/llvm/llvm-project/pull/148613 ___ cfe-commits mailing list cfe-commits@lists

[clang] [NFC][Clang][FMV] Refactor sema checking of target_version/clones attributes. (PR #149067)

https://github.com/BeMg approved this pull request. RISC-V part LGTM. https://github.com/llvm/llvm-project/pull/149067 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy][NFC] Enable 'performance-move-const-arg' in '.clang-tidy' config (PR #148549)

vbvictor wrote: > Are they really need to "std::move" in the patch? I think `MixData` is > meaningless since it is still need to copy all field. Do you mean with `CheckTriviallyCopyableMove` set to `true`? Technically, there would probably be no performance benefit. However, from author's poin

[clang] [clang][bytecode] Report mutable reads when copying unions (PR #149320)

https://github.com/tbaederr created https://github.com/llvm/llvm-project/pull/149320 None >From 896c606f240e302f12a891aa9ddabba70f2e6364 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Timm=20B=C3=A4der?= Date: Thu, 17 Jul 2025 16:28:15 +0200 Subject: [PATCH] [clang][bytecode] Report mutable reads wh

[clang] [clang][bytecode] Report mutable reads when copying unions (PR #149320)

llvmbot wrote: @llvm/pr-subscribers-clang Author: Timm Baeder (tbaederr) Changes --- Full diff: https://github.com/llvm/llvm-project/pull/149320.diff 3 Files Affected: - (modified) clang/lib/AST/ByteCode/InterpBuiltin.cpp (+2) - (modified) clang/lib/AST/ByteCode/InterpFrame.cpp (+5)

[clang] [llvm] [DTLTO][Clang] Add support for Integrated Distributed ThinLTO (PR #147265)

bd1976bris wrote: @tru - would you be happy for me to backport this to the LLVM 21 release branch to complete the DTLTO feature? https://github.com/llvm/llvm-project/pull/147265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llv

[clang-tools-extra] [clang-tools-extra] Bump ReleaseNotes to 22.0.0git (PR #149306)

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

[clang-tools-extra] [clang-tidy] Add MLIR check for old op builder usage. (PR #149148)

https://github.com/jpienaar updated https://github.com/llvm/llvm-project/pull/149148 >From b404f5390ac5684c7452e69f6fe209e5215f8929 Mon Sep 17 00:00:00 2001 From: Jacques Pienaar Date: Wed, 16 Jul 2025 17:37:53 + Subject: [PATCH 1/6] [clang-tidy] Add MLIR check for old op builder usage. Mo

[clang] [lld] [llvm] Integrated Distributed ThinLTO (DTLTO): Design Overview (PR #126654)

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

[clang-tools-extra] [clang-tidy] Add MLIR check for old op builder usage. (PR #149148)

@@ -0,0 +1,103 @@ +//===--- MLIROpBuilderCheck.cpp - clang-tidy --===// +// +// 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: Ap

[clang] [analyzer] Support parenthesized list initialization (CXXParenListInitExpr) (PR #148988)

https://github.com/a-tarasyuk updated https://github.com/llvm/llvm-project/pull/148988 >From 5db59d5b7f9b834762f86aa69040314e8faeb649 Mon Sep 17 00:00:00 2001 From: Oleksandr Tarasiuk Date: Wed, 16 Jul 2025 02:09:37 +0300 Subject: [PATCH 1/6] [Analyzer] support parenthesized list initialization

[clang] [llvm] [DTLTO][Clang] Add support for Integrated Distributed ThinLTO (PR #147265)

tru wrote: > @tru - would you be happy for me to backport this to the LLVM 21 release > branch to complete the DTLTO feature? Yes! https://github.com/llvm/llvm-project/pull/147265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[clang] [clang][bytecode] Fix const-in-mutable fields (PR #149286)

Timm =?utf-8?q?Bäder?= Message-ID: In-Reply-To: https://github.com/tbaederr updated https://github.com/llvm/llvm-project/pull/149286 >From 34201c4031f90a09f4e4d8295f7fb4a261bbb864 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Timm=20B=C3=A4der?= Date: Thu, 17 Jul 2025 12:31:01 +0200 Subject: [PAT

[clang] Improve clarity of the implicit declaration diagnostic (PR #149314)

@@ -376,6 +376,33 @@ class Context { return getInfo(ID).Header.getName(); } + /// Returns true if a library function is declared within a C or C++ standard + /// header (like stdio.h) or POSIX header (like malloc.h), false if the + /// function is not declared within

[clang] Improve clarity of the implicit declaration diagnostic (PR #149314)

@@ -716,6 +716,10 @@ Improvements to Clang's diagnostics Added a new warning in this group for the case where the attribute is missing/implicit on an override of a virtual method. + - Reworded the ``-Wimplicit-function-declaration`` diagnostic to make it more + clear th

[clang] Improve clarity of the implicit declaration diagnostic (PR #149314)

@@ -816,11 +816,12 @@ def warn_unreachable_association : Warning< /// Built-in functions. def ext_implicit_lib_function_decl : ExtWarn< - "implicitly declaring library function '%0' with type %1">, - InGroup; + "implicitly declaring library function '%0' with%select{| stan

[clang] [flang] [llvm] [openmp] [Flang][OpenMP] Move builtin .mod generation into runtimes (PR #137828)

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

[clang] [clang] Fix potential constant expression checking with constexpr-unknown. (PR #149227)

https://github.com/frederick-vs-ja milestoned https://github.com/llvm/llvm-project/pull/149227 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lld] [llvm] Fix Windows EH IP2State tables (remove +1 bias) (PR #144745)

frobtech wrote: > Actually, thinking about it, maybe we should just do the nop insertion for > UEFI targets. The UEFI environment is very similar to Windows. CC @Prabhuk . I think that's an appropriately conservative place to start, anyway. The uefi-* targets are still nascent and heretofore

[clang] [CIR] Upstream builtin_conj for ComplexType (PR #149170)

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

[clang] 84d65e9 - [CIR] Upstream builtin_conj for ComplexType (#149170)

Author: Amr Hesham Date: 2025-07-17T18:00:32+02:00 New Revision: 84d65e9d19ab577027238d38d053e293ba656e32 URL: https://github.com/llvm/llvm-project/commit/84d65e9d19ab577027238d38d053e293ba656e32 DIFF: https://github.com/llvm/llvm-project/commit/84d65e9d19ab577027238d38d053e293ba656e32.diff LO

[clang] Fix scope of typedefs present inside a template class (PR #146729)

ykhatav wrote: > `DW_TAG_template_alias` suffer from the same issue? It does not look like template_alias has the same issue, although I am not very familiar with template_alias types. I tried a small example where the scope is set correctly: template struct S { template using A = in

[clang] [CodeGen] Remove an unnecessary cast (NFC) (PR #149339)

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

[clang] [Sema] Remove unnecessary casts (NFC) (PR #149340)

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

[clang] [AST] Remove an unnecessary cast (NFC) (PR #149338)

@@ -610,7 +610,7 @@ void StmtPrinter::VisitObjCAtTryStmt(ObjCAtTryStmt *Node) { } } - if (auto *FS = static_cast(Node->getFinallyStmt())) { + if (auto *FS = Node->getFinallyStmt()) { shiltian wrote: If there is no cast, then we'd want to use the type

[clang] [AST] Remove an unnecessary cast (NFC) (PR #149338)

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

[clang] [flang] [llvm] [openmp] [Flang][OpenMP] Move builtin .mod generation into runtimes (PR #137828)

https://github.com/Meinersbur updated https://github.com/llvm/llvm-project/pull/137828 >From 839198d61f9937b5504d5e036c67266b4b84da8e Mon Sep 17 00:00:00 2001 From: Michael Kruse Date: Thu, 17 Jul 2025 14:09:57 +0200 Subject: [PATCH 1/2] [Flang][Flang-RT][OpenMP] Move builtin .mod generation i

[clang] [Clang][Driver] Revise Cygwin ToolChain to call linker directly (PR #147960)

@@ -107,3 +110,294 @@ void Cygwin::AddClangSystemIncludeArgs(const ArgList &DriverArgs, addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include"); addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include/w32api"); } + +static bool getStaticPIE(con

[clang] [Clang][Driver] Revise Cygwin ToolChain to call linker directly (PR #147960)

@@ -107,3 +110,294 @@ void Cygwin::AddClangSystemIncludeArgs(const ArgList &DriverArgs, addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include"); addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include/w32api"); } + +static bool getStaticPIE(con

[clang] [flang] [llvm] [openmp] [Flang][OpenMP] Move builtin .mod generation into runtimes (PR #137828)

@@ -3979,6 +3979,16 @@ def fsyntax_only : Flag<["-"], "fsyntax-only">, Visibility<[ClangOption, CLOption, DXCOption, CC1Option, FC1Option, FlangOption]>, Group, HelpText<"Run the preprocessor, parser and semantic analysis stages">; + + +def fno_builtin_modules : Flag<["-

[clang] [flang] [llvm] [openmp] [Flang][OpenMP] Move builtin .mod generation into runtimes (PR #137828)

Meinersbur wrote: > What's the main limitation here? If this is just a file dependency it should > be identical to how all the OpenMP tests depend on `omp.h` being in the > resource directory. `omp.h` is created by `configure_file` at configure time. No dependency other than `runtimes-configu

[clang] [Clang] Reintroduce obsolete symbols in libclang.map (PR #149190)

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

[clang] [Clang] Reintroduce obsolete symbols in libclang.map (PR #149190)

AaronBallman wrote: /cherry-pick 7e0fde0c2f6b0b9d727ce9196956b36e91961ac4 https://github.com/llvm/llvm-project/pull/149190 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang] [OpenMP] New OpenMP 6.0 self_maps clause - CodeGen (PR #134131)

@@ -236,6 +236,8 @@ enum class OpenMPOffloadMappingFlags : uint64_t { // dynamic. // This is an OpenMP extension for the sake of OpenACC support. OMP_MAP_OMPX_HOLD = 0x2000, + /// Self directs mapping without creating a separate device copy. + OMP_MAP_SELF = 0x4000, ---

[clang] 96a7e95 - [Sema] Remove unnecessary casts (NFC) (#149253)

Author: Kazu Hirata Date: 2025-07-17T07:22:36-07:00 New Revision: 96a7e954e1501239d1fc4bd6eba60428bd6609f7 URL: https://github.com/llvm/llvm-project/commit/96a7e954e1501239d1fc4bd6eba60428bd6609f7 DIFF: https://github.com/llvm/llvm-project/commit/96a7e954e1501239d1fc4bd6eba60428bd6609f7.diff L

[clang] 73e8ada - [Sema] Use llvm::all_of (NFC) (#149256)

Author: Kazu Hirata Date: 2025-07-17T07:22:59-07:00 New Revision: 73e8ada540acbd60f916ef4b0a5a2b454c8ece44 URL: https://github.com/llvm/llvm-project/commit/73e8ada540acbd60f916ef4b0a5a2b454c8ece44 DIFF: https://github.com/llvm/llvm-project/commit/73e8ada540acbd60f916ef4b0a5a2b454c8ece44.diff L

[clang] [Sema] Remove unnecessary casts (NFC) (PR #149253)

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

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

jamieschmeiser wrote: > This seems like a very complicated solution. > > If the AIX system headers want to define NULL, should we just let them? Just > `#include_next ` to ensure clang's stddef.h doesn't define NULL in > an inconsistent way. Just doing an `#include_next ` is a dangerous solut

[clang] [Sema] Use llvm::all_of (NFC) (PR #149256)

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

[clang-tools-extra] 9de32d5 - [clang-tools-extra] Bump ReleaseNotes to 22.0.0git (#149306)

Author: Jacques Pienaar Date: 2025-07-17T07:25:12-07:00 New Revision: 9de32d56e4fdf08d88aca74149f5f815eb6505ec URL: https://github.com/llvm/llvm-project/commit/9de32d56e4fdf08d88aca74149f5f815eb6505ec DIFF: https://github.com/llvm/llvm-project/commit/9de32d56e4fdf08d88aca74149f5f815eb6505ec.dif

[clang-tools-extra] [clang-tools-extra] Bump ReleaseNotes to 22.0.0git (PR #149306)

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

[clang] [Clang][Driver] Revise Cygwin ToolChain to call linker directly (PR #147960)

@@ -107,3 +110,294 @@ void Cygwin::AddClangSystemIncludeArgs(const ArgList &DriverArgs, addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include"); addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include/w32api"); } + +static bool getStaticPIE(con

[clang] [clang][Modules] Reporting Errors for Duplicating Link Declarations in `modulemap`s (PR #148959)

https://github.com/qiongsiwu updated https://github.com/llvm/llvm-project/pull/148959 >From 0e8a0db8ace8fd1f450cf2364b4c975d418eddc1 Mon Sep 17 00:00:00 2001 From: Qiongsi Wu Date: Mon, 14 Jul 2025 18:22:27 -0700 Subject: [PATCH 1/5] Initial implementation of modulemap link decl duplication ch

[clang] [Clang][Driver] Revise Cygwin ToolChain to call linker directly (PR #147960)

jeremyd2019 wrote: > > $ clang++ -fuse-ld=lld hello.cc > > Do you have patched to LLD locally? This should fail with `unable to find > library -lkernel32`. this new driver should be passing all the necessary `-L` paths to the linker, including `/usr/lib/w32api` https://github.com/llvm/llvm-p

[clang] [analyzer] Support parenthesized list initialization (CXXParenListInitExpr) (PR #148988)

https://github.com/a-tarasyuk updated https://github.com/llvm/llvm-project/pull/148988 >From 5db59d5b7f9b834762f86aa69040314e8faeb649 Mon Sep 17 00:00:00 2001 From: Oleksandr Tarasiuk Date: Wed, 16 Jul 2025 02:09:37 +0300 Subject: [PATCH 1/7] [Analyzer] support parenthesized list initialization

[clang] [analyzer] Support parenthesized list initialization (CXXParenListInitExpr) (PR #148988)

https://github.com/a-tarasyuk updated https://github.com/llvm/llvm-project/pull/148988 >From 5db59d5b7f9b834762f86aa69040314e8faeb649 Mon Sep 17 00:00:00 2001 From: Oleksandr Tarasiuk Date: Wed, 16 Jul 2025 02:09:37 +0300 Subject: [PATCH 1/7] [Analyzer] support parenthesized list initialization

[clang] b84f72a - [CIR] Upstream Unary Inc/Dec for ComplexType (#149162)

Author: Amr Hesham Date: 2025-07-17T19:16:04+02:00 New Revision: b84f72a7f51e2ea829feb12ecbb8be0cfc835e2c URL: https://github.com/llvm/llvm-project/commit/b84f72a7f51e2ea829feb12ecbb8be0cfc835e2c DIFF: https://github.com/llvm/llvm-project/commit/b84f72a7f51e2ea829feb12ecbb8be0cfc835e2c.diff LO

[clang] [llvm] [AMDGPU] Add support for `v_cos_bf16_e64` on gfx1250 (PR #149355)

shiltian wrote: but we do have `v_cos_bf16` in `llvm/test/MC/AMDGPU/gfx1250_asm_vop1.s`? https://github.com/llvm/llvm-project/pull/149355 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[clang] [CIR] Upstream Unary Inc/Dec for ComplexType (PR #149162)

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

[clang] [llvm] [libclang][Cygwin] Provide unversioned DLL file alongside versioned one (PR #147132)

kikairoya wrote: Thanks again. > I got pretty strong negative feedback on including these symlinks at all. I didn’t expect such a strong reaction... I'm really sorry for dragging you into it. > I've tried this with msys2 (where symlinks are really copies and > `LLVM_USE_SYMLINKS=OFF` and got

[clang] [HIP][Clang][Driver] Move BC preference logic into ROCm detection (PR #149294)

https://github.com/jchlanda created https://github.com/llvm/llvm-project/pull/149294 This patch provides a single point for handling the logic behind choosing common bitcode libraries. The intention is that the users of ROCm installation detector will not have to rewrite options handling code

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang-tools-extra] [clang-tidy] Improve `bugprone-infinite-loop` check by adding handing for structured bindings (PR #144213)

https://github.com/flovent updated https://github.com/llvm/llvm-project/pull/144213 >From 6fce04d8484a3600f292a8bbdd8621db25be7f1d Mon Sep 17 00:00:00 2001 From: flovent Date: Sat, 14 Jun 2025 15:52:26 +0800 Subject: [PATCH 1/4] [clang-tidy] Improve `bugprone-infinite-loop` check by adding han

[clang-tools-extra] [clang-tidy] Improve `bugprone-infinite-loop` check by adding handing for structured bindings (PR #144213)

@@ -83,6 +83,23 @@ static bool isVarThatIsPossiblyChanged(const Decl *Func, const Stmt *LoopStmt, isChanged(LoopStmt, Var, Context); // FIXME: Track references. } + +if (const auto *BD = dyn_cast(DRE->getDecl())) { + if (const auto *DD = +

[clang] [llvm] [AMDGPU] Add support for `v_sin_bf16_e64` on gfx1250 (PR #149355)

llvmbot wrote: @llvm/pr-subscribers-clang Author: Shilei Tian (shiltian) Changes Co-authored-by: Mekhanoshin, Stanislav --- Patch is 66.99 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/149355.diff 23 Files Af

[clang] [Clang] Ensure correct parameters are in the scope for constraint equivalence checking (PR #149264)

https://github.com/zyn0217 updated https://github.com/llvm/llvm-project/pull/149264 >From 728de4d995079208605879a0ec30e8f76fe5220c Mon Sep 17 00:00:00 2001 From: Younan Zhang Date: Thu, 17 Jul 2025 14:17:02 +0800 Subject: [PATCH 1/2] [Clang] Ensure correct parameters are in the scope for const

[clang] [llvm] [AMDGPU] Add support for `v_sin_bf16_e64` on gfx1250 (PR #149355)

shiltian wrote: * **#149355** https://app.graphite.dev/github/pr/llvm/llvm-project/149355?utm_source=stack-comment-icon"; target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" width="10px" height="10px"/> 👈 https://app.graphite.dev/github/pr/llvm/llvm-project/149

[clang] [LinkerWrapper] Fix -fsave-optimization-record default file (PR #149003)

@@ -5895,6 +5895,11 @@ def o : JoinedOrSeparate<["-"], "o">, Visibility<[ClangOption, CC1Option, CC1AsOption, FC1Option, FlangOption]>, HelpText<"Write output to ">, MetaVarName<"">, MarshallingInfoString>; +def foutput_file_base : Joined<["-"], "foutput-file-base=">, ---

[clang] [Docs] Mention security of libclang (PR #149357)

https://github.com/AaronBallman created https://github.com/llvm/llvm-project/pull/149357 Libclang is a wrapper around the Clang frontend, and frontends are not security-sensitive components of the LLVM project. However, libclang is often embedded in people's downstream tools, so it's best to m

[clang] [Docs] Mention security of libclang (PR #149357)

llvmbot wrote: @llvm/pr-subscribers-clang Author: Aaron Ballman (AaronBallman) Changes Libclang is a wrapper around the Clang frontend, and frontends are not security-sensitive components of the LLVM project. However, libclang is often embedded in people's downstream tools, so it's best

[clang] [llvm] [AMDGPU] Add support for `v_sin_bf16_e64` on gfx1250 (PR #149355)

https://github.com/shiltian created https://github.com/llvm/llvm-project/pull/149355 Co-authored-by: Mekhanoshin, Stanislav >From a6b7ccf491c4d88b18bfdba0dbf839030df189ec Mon Sep 17 00:00:00 2001 From: Shilei Tian Date: Thu, 17 Jul 2025 12:45:33 -0400 Subject: [PATCH] [AMDGPU] Add support for

[clang] [llvm] [AMDGPU] Add support for `v_sin_bf16_e64` on gfx1250 (PR #149355)

https://github.com/shiltian updated https://github.com/llvm/llvm-project/pull/149355 >From 29b54575b3e64372750466dfafab971697f402f1 Mon Sep 17 00:00:00 2001 From: Shilei Tian Date: Thu, 17 Jul 2025 12:45:33 -0400 Subject: [PATCH] [AMDGPU] Add support for `v_sin_bf16_e64` on gfx1250 Co-authored

[clang] [llvm] [AMDGPU] Add support for `v_sin_bf16_e64` on gfx1250 (PR #149355)

llvmbot wrote: @llvm/pr-subscribers-clang-codegen Author: Shilei Tian (shiltian) Changes Co-authored-by: Mekhanoshin, Stanislav --- Patch is 66.99 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/149355.diff 23

[clang] d35931c - [Clang][CodeGen][X86] don't coerce int128 into `{i64,i64}` for SysV-like ABIs (#135230)

Author: T0b1-iOS Date: 2025-07-17T09:57:32-07:00 New Revision: d35931c49e5b37243ace2b79bec87463772b6c94 URL: https://github.com/llvm/llvm-project/commit/d35931c49e5b37243ace2b79bec87463772b6c94 DIFF: https://github.com/llvm/llvm-project/commit/d35931c49e5b37243ace2b79bec87463772b6c94.diff LOG:

[clang] [Clang][CodeGen][X86] don't coerce int128 into `{i64,i64}` for SysV-like ABIs (PR #135230)

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

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -0,0 +1,70 @@ +// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -Wno-unused-value -fclangir -emit-cir %s -o %t.cir +// RUN: FileCheck --input-file=%t.cir %s -check-prefix=CIR +// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -Wno-unused-value -fclangir -emit-llvm %s -o

[clang] [Clang][CodeGen][X86] don't coerce int128 into `{i64,i64}` for SysV-like ABIs (PR #135230)

github-actions[bot] wrote: @T0b1-iOS Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with a build

[clang] Ensure proper NULL macro definition for system include files. (PR #149176)

@@ -0,0 +1,15 @@ +// There are at least 2 valid C null-pointer constants as defined +// by the C language standard. +// Test that the macro NULL is defined consistently for all platforms by +// those headers that the C standard mandates a macro definition for NULL. + +// RUN: %cla

[clang] [llvm] [AMDGPU] Add support for `v_cos_bf16_e64` on gfx1250 (PR #149355)

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

[clang] [llvm] [AMDGPU] Add support for `v_cos_bf16_e64` on gfx1250 (PR #149355)

https://github.com/changpeng approved this pull request. LGTM. Changed subject to "v_cos_bf16_e64" based on the contents. https://github.com/llvm/llvm-project/pull/149355 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cg

[libclc] [libclc] Enable -fdiscard-value-names build flag to reduce bitcode size (PR #149016)

llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `premerge-monolithic-linux` running on `premerge-linux-1` while building `libclc` at step 7 "test-build-unified-tree-check-all". Full details are available at: https://lab.llvm.org/buildbot/#/builders/153/builds/38396 Here i

[clang] [llvm] [Clang][OpenMP] Non-contiguous strided update (PR #144635)

@@ -8713,6 +8713,33 @@ AST_MATCHER_P(OMPExecutableDirective, hasAnyClause, Builder) != Clauses.end(); } +/// Matches any ``#pragma omp target update`` executable directive. +/// +/// Given +/// +/// \code +/// #pragma omp target update fro

[clang] [llvm] [Clang][OpenMP] Non-contiguous strided update (PR #144635)

@@ -7378,7 +7378,31 @@ class MappableExprsHandler { // dimension. uint64_t DimSize = 1; -bool IsNonContiguous = CombinedInfo.NonContigInfo.IsNonContiguous; +// Detects non-contiguous updates due to strided accesses. +// Sets the 'IsNonContiguous' flag so th

[clang] [llvm] [Clang][OpenMP] Non-contiguous strided update (PR #144635)

@@ -7378,7 +7378,31 @@ class MappableExprsHandler { // dimension. uint64_t DimSize = 1; -bool IsNonContiguous = CombinedInfo.NonContigInfo.IsNonContiguous; +// Detects non-contiguous updates due to strided accesses. +// Sets the 'IsNonContiguous' flag so th

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -311,6 +312,115 @@ void CIRGenFunction::emitInitializerForField(FieldDecl *field, LValue lhs, assert(!cir::MissingFeatures::requiresCleanups()); } +/// Emit a loop to call a particular constructor for each of several members +/// of an array. +/// +/// \param ctor the co

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); xlauko wrote: ```suggestion void lowerArrayCtor(cir::ArrayCtor op); ``` ht

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

[clang] [CIR] Add support for array constructors (PR #149142)

@@ -22,15 +24,97 @@ struct LoweringPreparePass : public LoweringPrepareBase { void runOnOperation() override; void runOnOp(Operation *op); + void lowerArrayCtor(ArrayCtor op); }; } // namespace -void LoweringPreparePass::runOnOp(Operation *op) {} +void LoweringPrep

  1   2   3   4   >