[jenkinsci/jenkins] 9581d4: [maven-release-plugin] prepare release jenkins-2.464

2024-06-25 Thread 'Jenkins Release Bot' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/jenkins
  Commit: 9581d4dc55e6f78c282434e9d735a0b39f07475c
  
https://github.com/jenkinsci/jenkins/commit/9581d4dc55e6f78c282434e9d735a0b39f07475c
  Author: Jenkins Release Bot 
<66998184+jenkins-release-...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M bom/pom.xml
M cli/pom.xml
M core/pom.xml
M coverage/pom.xml
M pom.xml
M test/pom.xml
M war/pom.xml
M websocket/jetty10/pom.xml
M websocket/spi/pom.xml

  Log Message:
  ---
  [maven-release-plugin] prepare release jenkins-2.464


  Commit: 174c3b39a83bccdaa24519959f0ff22b7010c450
  
https://github.com/jenkinsci/jenkins/commit/174c3b39a83bccdaa24519959f0ff22b7010c450
  Author: Jenkins Release Bot 
<66998184+jenkins-release-...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M bom/pom.xml
M cli/pom.xml
M core/pom.xml
M coverage/pom.xml
M pom.xml
M test/pom.xml
M war/pom.xml
M websocket/jetty10/pom.xml
M websocket/spi/pom.xml

  Log Message:
  ---
  [maven-release-plugin] prepare for next development iteration


  Commit: 7006d7442028610833b4daf037475cb8b842631f
  
https://github.com/jenkinsci/jenkins/commit/7006d7442028610833b4daf037475cb8b842631f
  Author: Jenkins Release Bot 
<66998184+jenkins-release-...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M ath.sh

  Log Message:
  ---
  Merge remote-tracking branch 'origin/master'


Compare: 
https://github.com/jenkinsci/jenkins/compare/d8925acb0ed6...7006d7442028

To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/jenkins/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/jenkins/push/refs/heads/master/d8925a-7006d7%40github.com.


[clang] 70cfece - Revert "[clang-format] Add option to remove leading blank lines (#91221)"

2024-06-25 Thread via cfe-commits
 Style.BraceWrapping.AfterClass = true;
   Style.BraceWrapping.AfterFunction = true;
-  Style.KeepEmptyLines.AtStartOfBlock = false;
+  Style.KeepEmptyLinesAtTheStartOfBlocks = false;
 
   verifyFormat("class Foo\n"
"{\n"
@@ -21960,11 +21956,6 @@ TEST_F(FormatTest, HandlesUTF8BOM) {
   verifyFormat("\xef\xbb\xbf");
   verifyFormat("\xef\xbb\xbf#include ");
   verifyFormat("\xef\xbb\xbf\n#include ");
-
-  auto Style = getLLVMStyle();
-  Style.KeepEmptyLines.AtStartOfFile = false;
-  verifyFormat("\xef\xbb\xbf#include ",
-   "\xef\xbb\xbf\n#include ", Style);
 }
 
 // FIXME: Encode Cyrillic and CJK characters below to appease MS compilers.
@@ -27239,7 +27230,7 @@ TEST_F(FormatTest, InsertNewlineAtEOF) {
 
 TEST_F(FormatTest, KeepEmptyLinesAtEOF) {
   FormatStyle Style = getLLVMStyle();
-  Style.KeepEmptyLines.AtEndOfFile = true;
+  Style.KeepEmptyLinesAtEOF = true;
 
   const StringRef Code{"int i;\n\n"};
   verifyNoChange(Code, Style);



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

2024-06-25 Thread via cfe-commits
T:br label [[EXIT]]
@@ -4366,11 +4370,13 @@ int foobar() {
 // CHECK-TLS2-LABEL: define {{[^@]+}}@__tls_init
 // CHECK-TLS2-SAME: () #[[ATTR6]] {
 // CHECK-TLS2-NEXT:  entry:
-// CHECK-TLS2-NEXT:[[TMP0:%.*]] = load i8, ptr @__tls_guard, align 1
+// CHECK-TLS2-NEXT:[[TLS_ADR_5:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS2-NEXT:[[TMP0:%.*]] = load i8, ptr [[TLS_ADR_5]], align 1
 // CHECK-TLS2-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0
 // CHECK-TLS2-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT:%.*]], 
label [[EXIT:%.*]], !prof [[PROF3]]
 // CHECK-TLS2:   init:
-// CHECK-TLS2-NEXT:store i8 1, ptr @__tls_guard, align 1
+// CHECK-TLS2-NEXT:[[TLS_ADR_6:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS2-NEXT:store i8 1, ptr [[TLS_ADR_6]], align 1
 // CHECK-TLS2-NEXT:call void @__cxx_global_var_init()
 // CHECK-TLS2-NEXT:call void @__cxx_global_var_init.2()
 // CHECK-TLS2-NEXT:br label [[EXIT]]
@@ -4918,11 +4924,13 @@ int foobar() {
 // CHECK-TLS3-LABEL: define {{[^@]+}}@__tls_init
 // CHECK-TLS3-SAME: () #[[ATTR0]] !dbg [[DBG326:![0-9]+]] {
 // CHECK-TLS3-NEXT:  entry:
-// CHECK-TLS3-NEXT:[[TMP0:%.*]] = load i8, ptr @__tls_guard, align 1, !dbg 
[[DBG327:![0-9]+]]
+// CHECK-TLS3-NEXT:[[TLS_ADR_7:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS3-NEXT:[[TMP0:%.*]] = load i8, ptr [[TLS_ADR_7]], align 1, 
!dbg [[DBG327:![0-9]+]]
 // CHECK-TLS3-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0, 
!dbg [[DBG327]]
 // CHECK-TLS3-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT:%.*]], 
label [[EXIT:%.*]], !dbg [[DBG327]], !prof [[PROF206]]
 // CHECK-TLS3:   init:
-// CHECK-TLS3-NEXT:store i8 1, ptr @__tls_guard, align 1, !dbg [[DBG327]]
+// CHECK-TLS3-NEXT:[[TLS_ADR_8:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS3-NEXT:store i8 1, ptr [[TLS_ADR_8]], align 1, !dbg [[DBG327]]
 // CHECK-TLS3-NEXT:call void @__cxx_global_var_init(), !dbg [[DBG327]]
 // CHECK-TLS3-NEXT:call void @__cxx_global_var_init.2(), !dbg [[DBG327]]
 // CHECK-TLS3-NEXT:br label [[EXIT]], !dbg [[DBG327]]
@@ -5482,11 +5490,13 @@ int foobar() {
 // CHECK-TLS4-LABEL: define {{[^@]+}}@__tls_init
 // CHECK-TLS4-SAME: () #[[ATTR6]] !dbg [[DBG326:![0-9]+]] {
 // CHECK-TLS4-NEXT:  entry:
-// CHECK-TLS4-NEXT:[[TMP0:%.*]] = load i8, ptr @__tls_guard, align 1, !dbg 
[[DBG327:![0-9]+]]
+// CHECK-TLS4-NEXT:[[TLS_ADR_9:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS4-NEXT:[[TMP0:%.*]] = load i8, ptr [[TLS_ADR_9]], align 1, 
!dbg [[DBG327:![0-9]+]]
 // CHECK-TLS4-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0, 
!dbg [[DBG327]]
 // CHECK-TLS4-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT:%.*]], 
label [[EXIT:%.*]], !dbg [[DBG327]], !prof [[PROF119]]
 // CHECK-TLS4:   init:
-// CHECK-TLS4-NEXT:store i8 1, ptr @__tls_guard, align 1, !dbg [[DBG327]]
+// CHECK-TLS4-NEXT:[[TLS_ADR_10:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS4-NEXT:store i8 1, ptr [[TLS_ADR_10]], align 1, !dbg [[DBG327]]
 // CHECK-TLS4-NEXT:call void @__cxx_global_var_init(), !dbg [[DBG327]]
 // CHECK-TLS4-NEXT:call void @__cxx_global_var_init.2(), !dbg [[DBG327]]
 // CHECK-TLS4-NEXT:br label [[EXIT]], !dbg [[DBG327]]

``




https://github.com/llvm/llvm-project/pull/96633
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][FMV] Do not omit explicit default target_version attribute. (PR #96628)

2024-06-25 Thread Alexandros Lamprineas via cfe-commits


@@ -11543,8 +11551,7 @@ static bool CheckTargetCausesMultiVersioning(Sema , 
FunctionDecl *OldFD,
   }
 
   // If this is 'default', permit the forward declaration.
-  if ((NewTA && NewTA->isDefaultVersion() && !OldTA) ||
-  (NewTVA && NewTVA->isDefaultVersion() && !OldTVA)) {

labrinea wrote:

This is wrong. The new declaration cannot be a redeclaration of the old, and at 
the same time to be causing Multiversioning. Getting past the early return 
(line 11538 with the new code) means the new declaration is causing 
Multiversioning, so at this point (line 11554 with the new code) redeclaration 
is not possible for the target_version attribute.

https://github.com/llvm/llvm-project/pull/96628
___________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

2024-06-25 Thread via cfe-commits

github-actions[bot] wrote:



Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from 
other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

https://github.com/llvm/llvm-project/pull/96633
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

2024-06-25 Thread via cfe-commits
align 1 @__tls_guard)
+// CHECK-TLS1-NEXT:store i8 1, ptr [[TLS_ADR_4]], align 1
 // CHECK-TLS1-NEXT:call void @__cxx_global_var_init()
 // CHECK-TLS1-NEXT:call void @__cxx_global_var_init.2()
 // CHECK-TLS1-NEXT:br label [[EXIT]]
@@ -4366,11 +4370,13 @@ int foobar() {
 // CHECK-TLS2-LABEL: define {{[^@]+}}@__tls_init
 // CHECK-TLS2-SAME: () #[[ATTR6]] {
 // CHECK-TLS2-NEXT:  entry:
-// CHECK-TLS2-NEXT:[[TMP0:%.*]] = load i8, ptr @__tls_guard, align 1
+// CHECK-TLS2-NEXT:[[TLS_ADR_5:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS2-NEXT:[[TMP0:%.*]] = load i8, ptr [[TLS_ADR_5]], align 1
 // CHECK-TLS2-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0
 // CHECK-TLS2-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT:%.*]], 
label [[EXIT:%.*]], !prof [[PROF3]]
 // CHECK-TLS2:   init:
-// CHECK-TLS2-NEXT:store i8 1, ptr @__tls_guard, align 1
+// CHECK-TLS2-NEXT:[[TLS_ADR_6:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS2-NEXT:store i8 1, ptr [[TLS_ADR_6]], align 1
 // CHECK-TLS2-NEXT:call void @__cxx_global_var_init()
 // CHECK-TLS2-NEXT:call void @__cxx_global_var_init.2()
 // CHECK-TLS2-NEXT:br label [[EXIT]]
@@ -4918,11 +4924,13 @@ int foobar() {
 // CHECK-TLS3-LABEL: define {{[^@]+}}@__tls_init
 // CHECK-TLS3-SAME: () #[[ATTR0]] !dbg [[DBG326:![0-9]+]] {
 // CHECK-TLS3-NEXT:  entry:
-// CHECK-TLS3-NEXT:[[TMP0:%.*]] = load i8, ptr @__tls_guard, align 1, !dbg 
[[DBG327:![0-9]+]]
+// CHECK-TLS3-NEXT:[[TLS_ADR_7:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS3-NEXT:[[TMP0:%.*]] = load i8, ptr [[TLS_ADR_7]], align 1, 
!dbg [[DBG327:![0-9]+]]
 // CHECK-TLS3-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0, 
!dbg [[DBG327]]
 // CHECK-TLS3-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT:%.*]], 
label [[EXIT:%.*]], !dbg [[DBG327]], !prof [[PROF206]]
 // CHECK-TLS3:   init:
-// CHECK-TLS3-NEXT:store i8 1, ptr @__tls_guard, align 1, !dbg [[DBG327]]
+// CHECK-TLS3-NEXT:[[TLS_ADR_8:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS3-NEXT:store i8 1, ptr [[TLS_ADR_8]], align 1, !dbg [[DBG327]]
 // CHECK-TLS3-NEXT:call void @__cxx_global_var_init(), !dbg [[DBG327]]
 // CHECK-TLS3-NEXT:call void @__cxx_global_var_init.2(), !dbg [[DBG327]]
 // CHECK-TLS3-NEXT:br label [[EXIT]], !dbg [[DBG327]]
@@ -5482,11 +5490,13 @@ int foobar() {
 // CHECK-TLS4-LABEL: define {{[^@]+}}@__tls_init
 // CHECK-TLS4-SAME: () #[[ATTR6]] !dbg [[DBG326:![0-9]+]] {
 // CHECK-TLS4-NEXT:  entry:
-// CHECK-TLS4-NEXT:[[TMP0:%.*]] = load i8, ptr @__tls_guard, align 1, !dbg 
[[DBG327:![0-9]+]]
+// CHECK-TLS4-NEXT:[[TLS_ADR_9:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS4-NEXT:[[TMP0:%.*]] = load i8, ptr [[TLS_ADR_9]], align 1, 
!dbg [[DBG327:![0-9]+]]
 // CHECK-TLS4-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0, 
!dbg [[DBG327]]
 // CHECK-TLS4-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT:%.*]], 
label [[EXIT:%.*]], !dbg [[DBG327]], !prof [[PROF119]]
 // CHECK-TLS4:   init:
-// CHECK-TLS4-NEXT:store i8 1, ptr @__tls_guard, align 1, !dbg [[DBG327]]
+// CHECK-TLS4-NEXT:[[TLS_ADR_10:%.*]] = call align 1 ptr 
@llvm.threadlocal.address.p0(ptr align 1 @__tls_guard)
+// CHECK-TLS4-NEXT:store i8 1, ptr [[TLS_ADR_10]], align 1, !dbg [[DBG327]]
 // CHECK-TLS4-NEXT:call void @__cxx_global_var_init(), !dbg [[DBG327]]
 // CHECK-TLS4-NEXT:call void @__cxx_global_var_init.2(), !dbg [[DBG327]]
 // CHECK-TLS4-NEXT:br label [[EXIT]], !dbg [[DBG327]]

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][FMV] Do not omit explicit default target_version attribute. (PR #96628)

2024-06-25 Thread Alexandros Lamprineas via cfe-commits

labrinea wrote:

@ilinpv, @DanielKristofKiss, the patch 
https://github.com/llvm/llvm-project/pull/65671/files doesn't seem right. I 
have basically reverted it with my change, ensuring the original crash you were 
trying to fix doesn't occur. FYI `MVKind == MultiVersionKind::None` is 
equivallent to `NewTVA == nullptr` in that context.

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


[clang] Add documentation for `__builtin_object_size`. (PR #96573)

2024-06-25 Thread Allan Jude via cfe-commits

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


[clang] Add documentation for `__builtin_object_size`. (PR #96573)

2024-06-25 Thread Allan Jude via cfe-commits


@@ -5368,16 +5368,85 @@ The ``#pragma comment(lib, ...)`` directive is 
supported on all ELF targets.
 The second parameter is the library name (without the traditional Unix prefix 
of
 ``lib``).  This allows you to provide an implicit link of dependent libraries.
 
-Evaluating Object Size Dynamically
-==
+Evaluating Object Size
+==
+
+Clang supports the builtins ``__builtin_object_size`` and
+``__builtin_dynamic_object_size``. The semantics are compatible with GCC's
+builtins of the same names, but the details are slightly different.
+
+.. code-block:: c
+
+  size_t __builtin_[dynamic_]object_size(const void *ptr, int type)
+
+Returns the number of accessible bytes ``n`` past ``ptr``. The value returned
+depends on ``type``, which is required to be an integer constant between 0 and
+3:
+
+* If ``type & 2 == 0``, the least ``n`` is returned such that accesses to
+  ``(const char*)ptr + n`` and beyond are known to be out of bounds. This is
+  ``(size_t)-1`` if no better bound is known.
+* If ``type & 2 == 2``, the greatest ``n`` is returned such that accesses to
+  ``(const char*)ptr + i`` are known to be in bounds, for 0 <= ``i`` < ``n``.
+  This is ``(size_t)0`` if no better bound is known.
 
-Clang supports the builtin ``__builtin_dynamic_object_size``, the semantics are
-the same as GCC's ``__builtin_object_size`` (which Clang also supports), but
-``__builtin_dynamic_object_size`` can evaluate the object's size at runtime.
-``__builtin_dynamic_object_size`` is meant to be used as a drop-in replacement
-for ``__builtin_object_size`` in libraries that support it.
+.. code-block:: c
+
+  char small[10], large[100];
+  bool cond;
+  // Returns 100: writes of more than 100 bytes are known to be out of bounds.
+  int n100 = __builtin_object_size(cond ? small : large, 0);
+  // Returns 10: writes of 10 or fewer bytes are known to be in bounds.
+  int n10 = __builtin_object_size(cond ? small : large, 2);
+
+* If ``type & 1 == 0``, pointers are considered to be in bounds if they point
+  into the same storage as ``ptr`` -- that is, the same stack object, global
+  variable, or heap allocation.
+* If ``type & 1 == 1``, pointers are considered to be in bounds if they point
+  to the same subobject that ``ptr`` points to. If ``ptr`` points to an array
+  element, other elements of the same array, but not of enclosing arrays, are
+  considered in bounds.
+
+.. code-block:: c
+
+  struct X { char a, b, c; } x;
+  static_assert(__builtin_object_size(, 0) == 3);
+  static_assert(__builtin_object_size(, 0) == 2);
+  static_assert(__builtin_object_size(, 1) == 1);
+
+.. code-block:: c
 
-For instance, here is a program that ``__builtin_dynamic_object_size`` will 
make
+  char a[10][10][10];
+  static_assert(__builtin_object_size(, 1) == 1000);
+  static_assert(__builtin_object_size([1], 1) == 900);
+  static_assert(__builtin_object_size([1][1], 1) == 90);
+  static_assert(__builtin_object_size([1][1][1], 1) == 9);
+
+The values returned by this builtin are a best effort conservative 
approximation
+of the correct answers. When ``type & 2 == 0``, the true value is less than or
+equal to the value returned by the builtin, and when ``type & 2 == 1``, the 
true
+value is greater than or equal to the value returned by the builtin.
+
+For ``__builtin_object_size``, the value is determined entirely at compile 
time.
+With optimization enabled, better results will be produced, especially when the
+call to ``__builtin_object_size`` is in a different function from the formation
+of the pointer. Unlike in GCC, enabling optimization in Clang does not allow
+more information about subobjects to be determined, so the ``type & 1 == 1``
+case will often give imprecise results when used across a function call 
boundary
+even when optimization is enabled.
+
+`The ``pass_object_size`` and ``pass_dynamic_object_size`` attributes 
<https://clang.llvm.org/docs/AttributeReference.html#pass-object-size-pass-dynamic-object-size>`_

allanjude wrote:

the leading ` here makes `pass_object_size` not get the right treatment

https://github.com/llvm/llvm-project/pull/96573
___________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][FMV] Do not omit explicit default target_version attribute. (PR #96628)

2024-06-25 Thread Alexandros Lamprineas via cfe-commits

labrinea wrote:

Alternative one liner:
```
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index dd4a665ebc78..0c96a6de091a 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -3763,7 +3763,7 @@ void CodeGenModule::EmitGlobal(GlobalDecl GD) {
 // Forward declarations are emitted lazily on first use.
 if (!FD->doesThisDeclarationHaveABody()) {
   if (!FD->doesDeclarationForceExternallyVisibleDefinition() &&
-  (!FD->isMultiVersion() ||
+  (FD->getMultiVersionKind() == MultiVersionKind::None ||
!FD->getASTContext().getTargetInfo().getTriple().isAArch64()))
 return;
```
but I believe not emitting the explicit default and then patching it later is a 
hack.

https://github.com/llvm/llvm-project/pull/96628
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][FMV] Do not omit explicit default target_version attribute. (PR #96628)

2024-06-25 Thread via cfe-commits
ret i32 0
-//
-//
 // CHECK-LABEL: define dso_local noundef i32 @_ZN4Name3fooEv._Msve(
-// CHECK-SAME: ) #[[ATTR1:[0-9]+]] {
+// CHECK-SAME: ) #[[ATTR0:[0-9]+]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:ret i32 1
 //
 //
 // CHECK-LABEL: define dso_local noundef i32 @_Z3barv(
-// CHECK-SAME: ) #[[ATTR0]] {
+// CHECK-SAME: ) #[[ATTR1:[0-9]+]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:[[CALL:%.*]] = call noundef i32 @_ZN4Name3fooEv()
 // CHECK-NEXT:ret i32 [[CALL]]
@@ -56,13 +57,13 @@ int baz() { return OtherName::foo(); }
 //
 //
 // CHECK-LABEL: define dso_local noundef i32 @_ZN9OtherName3fooEv._Msve(
-// CHECK-SAME: ) #[[ATTR1]] {
+// CHECK-SAME: ) #[[ATTR0]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:ret i32 2
 //
 //
 // CHECK-LABEL: define dso_local noundef i32 @_Z3bazv(
-// CHECK-SAME: ) #[[ATTR0]] {
+// CHECK-SAME: ) #[[ATTR1]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:[[CALL:%.*]] = call noundef i32 @_ZN9OtherName3fooEv()
 // CHECK-NEXT:ret i32 [[CALL]]
@@ -81,10 +82,43 @@ int baz() { return OtherName::foo(); }
 // CHECK:   [[RESOLVER_ELSE]]:
 // CHECK-NEXT:ret ptr @_ZN9OtherName3fooEv.default
 //
+//
+// CHECK-LABEL: define dso_local noundef i32 @_ZN3Foo3barEv.default(
+// CHECK-SAME: ) #[[ATTR1]] {
+// CHECK-NEXT:  [[ENTRY:.*:]]
+// CHECK-NEXT:ret i32 0
+//
+//
+// CHECK-LABEL: define dso_local noundef i32 @_ZN3Foo3barEv._Mmops(
+// CHECK-SAME: ) #[[ATTR2:[0-9]+]] {
+// CHECK-NEXT:  [[ENTRY:.*:]]
+// CHECK-NEXT:ret i32 1
+//
+//
+// CHECK-LABEL: define dso_local noundef i32 @_ZN4Name3fooEv.default(
+// CHECK-SAME: ) #[[ATTR1]] {
+// CHECK-NEXT:  [[ENTRY:.*:]]
+// CHECK-NEXT:ret i32 0
+//
+//
+// CHECK-LABEL: define weak_odr ptr @_ZN3Foo3barEv.resolver() comdat {
+// CHECK-NEXT:  [[RESOLVER_ENTRY:.*:]]
+// CHECK-NEXT:call void @__init_cpu_features_resolver()
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
+// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 576460752303423488
+// CHECK-NEXT:[[TMP2:%.*]] = icmp eq i64 [[TMP1]], 576460752303423488
+// CHECK-NEXT:[[TMP3:%.*]] = and i1 true, [[TMP2]]
+// CHECK-NEXT:br i1 [[TMP3]], label %[[RESOLVER_RETURN:.*]], label 
%[[RESOLVER_ELSE:.*]]
+// CHECK:   [[RESOLVER_RETURN]]:
+// CHECK-NEXT:ret ptr @_ZN3Foo3barEv._Mmops
+// CHECK:   [[RESOLVER_ELSE]]:
+// CHECK-NEXT:ret ptr @_ZN3Foo3barEv.default
+//
 //.
-// CHECK: attributes #[[ATTR0]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" }
-// CHECK: attributes #[[ATTR1]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+fp-armv8,+fullfp16,+neon,+sve" }
-// CHECK: attributes #[[ATTR2:[0-9]+]] = { "no-trapping-math"="true" 
"stack-protector-buffer-size"="8" }
+// CHECK: attributes #[[ATTR0]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+fp-armv8,+fullfp16,+neon,+sve" }
+// CHECK: attributes #[[ATTR1]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" }
+// CHECK: attributes #[[ATTR2]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+mops" }
+// CHECK: attributes #[[ATTR3:[0-9]+]] = { "no-trapping-math"="true" 
"stack-protector-buffer-size"="8" }
 //.
 // CHECK: [[META0:![0-9]+]] = !{i32 1, !"wchar_size", i32 4}
 // CHECK: [[META1:![0-9]+]] = !{!"{{.*}}clang version {{.*}}"}
diff --git a/clang/test/Sema/attr-target-version.c 
b/clang/test/Sema/attr-target-version.c
index cd5be459456eb..8de3eeeaff8f5 100644
--- a/clang/test/Sema/attr-target-version.c
+++ b/clang/test/Sema/attr-target-version.c
@@ -102,8 +102,9 @@ int __attribute__((target_version("sha2"))) combine(void) { 
return 1; }
 // expected-error@+1 {{multiversioned function declaration has a different 
calling convention}}
 int __attribute__((aarch64_vector_pcs, target_version("sha3"))) combine(void) 
{ return 2; }
 
-int __attribute__((target_version("fp+aes+pmull+rcpc"))) unspec_args() { 
return -1; }
+int unspec_args();
 // expected-error@-1 {{multiversioned function must have a prototype}}
-// expected-error@+1 {{multiversioned function must have a prototype}}
+// expected-note@+1 {{function multiversioning caused by this declaration}}
+int __attribute__((target_version("fp"))) unspec_args() { return -1; }
 int __attribute__((target_version("default"))) unspec_args() { return 0; }
 int cargs() { return unspec_args(); }

``




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


[clang] [clang][FMV] Do not omit explicit default target_version attribute. (PR #96628)

2024-06-25 Thread Alexandros Lamprineas via cfe-commits
espace Foo {
+int bar();
+__attribute((target_version("default"))) int bar() { return 0; }
+__attribute((target_version("mops"))) int bar() { return 1; }
+}
+
 //.
 // CHECK: @__aarch64_cpu_features = external dso_local global { i64 }
 // CHECK: @_ZN4Name3fooEv = weak_odr ifunc i32 (), ptr @_ZN4Name3fooEv.resolver
 // CHECK: @_ZN9OtherName3fooEv = weak_odr ifunc i32 (), ptr 
@_ZN9OtherName3fooEv.resolver
+// CHECK: @_ZN3Foo3barEv = weak_odr ifunc i32 (), ptr @_ZN3Foo3barEv.resolver
 //.
-// CHECK-LABEL: define dso_local noundef i32 @_ZN4Name3fooEv.default(
-// CHECK-SAME: ) #[[ATTR0:[0-9]+]] {
-// CHECK-NEXT:  [[ENTRY:.*:]]
-// CHECK-NEXT:ret i32 0
-//
-//
 // CHECK-LABEL: define dso_local noundef i32 @_ZN4Name3fooEv._Msve(
-// CHECK-SAME: ) #[[ATTR1:[0-9]+]] {
+// CHECK-SAME: ) #[[ATTR0:[0-9]+]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:ret i32 1
 //
 //
 // CHECK-LABEL: define dso_local noundef i32 @_Z3barv(
-// CHECK-SAME: ) #[[ATTR0]] {
+// CHECK-SAME: ) #[[ATTR1:[0-9]+]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:[[CALL:%.*]] = call noundef i32 @_ZN4Name3fooEv()
 // CHECK-NEXT:ret i32 [[CALL]]
@@ -56,13 +57,13 @@ int baz() { return OtherName::foo(); }
 //
 //
 // CHECK-LABEL: define dso_local noundef i32 @_ZN9OtherName3fooEv._Msve(
-// CHECK-SAME: ) #[[ATTR1]] {
+// CHECK-SAME: ) #[[ATTR0]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:ret i32 2
 //
 //
 // CHECK-LABEL: define dso_local noundef i32 @_Z3bazv(
-// CHECK-SAME: ) #[[ATTR0]] {
+// CHECK-SAME: ) #[[ATTR1]] {
 // CHECK-NEXT:  [[ENTRY:.*:]]
 // CHECK-NEXT:[[CALL:%.*]] = call noundef i32 @_ZN9OtherName3fooEv()
 // CHECK-NEXT:ret i32 [[CALL]]
@@ -81,10 +82,43 @@ int baz() { return OtherName::foo(); }
 // CHECK:   [[RESOLVER_ELSE]]:
 // CHECK-NEXT:ret ptr @_ZN9OtherName3fooEv.default
 //
+//
+// CHECK-LABEL: define dso_local noundef i32 @_ZN3Foo3barEv.default(
+// CHECK-SAME: ) #[[ATTR1]] {
+// CHECK-NEXT:  [[ENTRY:.*:]]
+// CHECK-NEXT:ret i32 0
+//
+//
+// CHECK-LABEL: define dso_local noundef i32 @_ZN3Foo3barEv._Mmops(
+// CHECK-SAME: ) #[[ATTR2:[0-9]+]] {
+// CHECK-NEXT:  [[ENTRY:.*:]]
+// CHECK-NEXT:ret i32 1
+//
+//
+// CHECK-LABEL: define dso_local noundef i32 @_ZN4Name3fooEv.default(
+// CHECK-SAME: ) #[[ATTR1]] {
+// CHECK-NEXT:  [[ENTRY:.*:]]
+// CHECK-NEXT:ret i32 0
+//
+//
+// CHECK-LABEL: define weak_odr ptr @_ZN3Foo3barEv.resolver() comdat {
+// CHECK-NEXT:  [[RESOLVER_ENTRY:.*:]]
+// CHECK-NEXT:call void @__init_cpu_features_resolver()
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
+// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 576460752303423488
+// CHECK-NEXT:[[TMP2:%.*]] = icmp eq i64 [[TMP1]], 576460752303423488
+// CHECK-NEXT:[[TMP3:%.*]] = and i1 true, [[TMP2]]
+// CHECK-NEXT:br i1 [[TMP3]], label %[[RESOLVER_RETURN:.*]], label 
%[[RESOLVER_ELSE:.*]]
+// CHECK:   [[RESOLVER_RETURN]]:
+// CHECK-NEXT:ret ptr @_ZN3Foo3barEv._Mmops
+// CHECK:   [[RESOLVER_ELSE]]:
+// CHECK-NEXT:ret ptr @_ZN3Foo3barEv.default
+//
 //.
-// CHECK: attributes #[[ATTR0]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" }
-// CHECK: attributes #[[ATTR1]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+fp-armv8,+fullfp16,+neon,+sve" }
-// CHECK: attributes #[[ATTR2:[0-9]+]] = { "no-trapping-math"="true" 
"stack-protector-buffer-size"="8" }
+// CHECK: attributes #[[ATTR0]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+fp-armv8,+fullfp16,+neon,+sve" }
+// CHECK: attributes #[[ATTR1]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" }
+// CHECK: attributes #[[ATTR2]] = { mustprogress noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+mops" }
+// CHECK: attributes #[[ATTR3:[0-9]+]] = { "no-trapping-math"="true" 
"stack-protector-buffer-size"="8" }
 //.
 // CHECK: [[META0:![0-9]+]] = !{i32 1, !"wchar_size", i32 4}
 // CHECK: [[META1:![0-9]+]] = !{!"{{.*}}clang version {{.*}}"}
diff --git a/clang/test/Sema/attr-target-version.c 
b/clang/test/Sema/attr-target-version.c
index cd5be459456eb..8de3eeeaff8f5 100644
--- a/clang/test/Sema/attr-target-version.c
+++ b/clang/test/Sema/attr-target-version.c
@@ -102,8 +102,9 @@ int __attribute__((target_version("sha2"))) combine(void) { 
return 1; }
 // expected-error@+1 {{multiversioned function declaration has a different 
calling convention}}
 int __attribute__((aarch64_vector_pcs, target_version("sha3"))) combine(void) 
{ return 2; }
 
-int __attribute__((target_version("fp+aes+pmull+rcpc"))) unspec_args() { 
return -1; }
+int unspec_args();
 // expected-error@-1 {{multiversioned function must have a prototype}}
-// expected-error@+1 {{multiversioned function must have a prototype}}
+// expected-note@+1 {{function multiversioning caused by this declaration}}
+int __attribute__((target_version("fp"))) unspec_args() { return -1; }
 int __attribute__((target_version("default"))) unspec_args() { return 0; }
 int cargs() { return unspec_args(); }

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #96240)

2024-06-25 Thread via cfe-commits
1);
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:21: runtime error: shift exponent -1 
is negative
+  return x;
+}
+
+_BitInt(37) shift_base() __attribute__((no_sanitize("memory"))) {
+  _BitInt(37) x = (-1) << 1;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:24: runtime error: left shift of 
negative value -1
+  return x;
+}
+
+uint32_t negative_shift1(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  _BitInt(9) c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift2(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  _BitInt(17) c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift3(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  _BitInt(34) c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift4(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  int64_t c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift5(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+#ifdef __SIZEOF_INT128__
+  _BitInt(68) c = -2;
+#else
+  // We cannot check BitInt values > 64 without int128_t support
+  _BitInt(48) c = -2;
+#endif
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t unsigned_integer_overflow() __attribute__((no_sanitize("memory"))) {
+  unsigned _BitInt(37) x = ~0U;
+  ++x;
+  return x;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:10: runtime error: implicit 
conversion from type
+}
+
+// In this test no run-time overflow expected, so no diagnostics here, but 
should be a conversion error from the negative number on return.
+uint32_t signed_integer_overflow() __attribute__((no_sanitize("memory"))) {
+  _BitInt(37) x = (_BitInt(37)) ~((0x8FFFULL) >> 1);
+  --x;
+  return x;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:10: runtime error: implicit 
conversion from type
+}
+
+int main(int argc, char **argv) {
+  // clang-format off
+  uint64_t result =
+  1ULL +
+  implicit_unsigned_integer_truncation() +
+  pointer_overflow() +
+  vla_bound(argc) +
+  unsigned_shift_base() +
+  (uint32_t)array_bounds() +
+  float_cast_overflow() +
+  implicit_integer_sign_change((unsigned _BitInt(37))(argc - 2)) +
+  (uint64_t)implicit_signed_integer_truncation() +
+  shift_exponent() +
+  (uint32_t)shift_base() +
+  negative_shift1(5) +
+  negative_shift2(5) +
+  negative_shift3(5) +
+  negative_shift4(5) +
+  negative_shift5(5) +
+  unsigned_integer_overflow() +
+  signed_integer_overflow();
+  // clang-format on
+  printf("%u\n", (uint32_t)(result & 0x));
+}

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Emit bad shift warnings (PR #70307)

2024-06-25 Thread Budimir Aranđelović via cfe-commits
ues}}
@@ -107,7 +108,8 @@ enum { overflow = 123456 * 234567 };
 #endif
 
 // FIXME: This is not consistent with the above case.
-enum NoFold : int { overflow2 = 123456 * 234567 };
+enum NoFold : int { overflow2 = 123456 * 234567 }; /* expected-error 
{{expression is not an integral constant expression}}
+  expected-note {{value 
28958703552 is outside the range of representable values of type 'int}} */
 #if __cplusplus >= 201103L
 // expected-error@-2 {{enumerator value is not a constant expression}}
 // expected-note@-3 {{value 28958703552 is outside the range of representable 
values}}
diff --git a/clang/test/SemaCXX/shift.cpp b/clang/test/SemaCXX/shift.cpp
index 89a98791d3eba7..b6f795725c0d7e 100644
--- a/clang/test/SemaCXX/shift.cpp
+++ b/clang/test/SemaCXX/shift.cpp
@@ -22,7 +22,7 @@ void test() {
   c = 1 << -1; // expected-warning {{shift count is negative}}
   c = 1 >> -1; // expected-warning {{shift count is negative}}
   c = 1 << (unsigned)-1; // expected-warning {{shift count >= width of type}}
-     // expected-warning@-1 {{implicit conversion}}
+ // cxx17-warning {{implicit conversion from 'int' to 
'char' changes value from -2147483648 to 0}}
   c = 1 >> (unsigned)-1; // expected-warning {{shift count >= width of type}}
   c = 1 << c;
   c <<= 0;

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Introduce 'clang-nvlink-wrappaer' to work around 'nvlink' (PR #96561)

2024-06-25 Thread Joseph Huber via cfe-commits

jhuber6 wrote:

@MaskRay So, I think my symbol resolution is (unsurprisingly) subtly broken. Is 
there a canonical way to handle this? I first thought that we could simply 
perform the symbol resolutions as normal for every file, but keep track of 
which symbols were "lazy". However, I couldn't figure out how to then tell if a 
lazy symbol should be extracted or not because there's no information on which 
files use which symbols. Maybe I just scan all the files and see if they 
reference a symbol that's marked defined and lazy?

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


[clang] [Clang] Clarify diagnostic notes for implicitly generated deduction guides (PR #96084)

2024-06-25 Thread Younan Zhang via cfe-commits


@@ -108,8 +108,11 @@ struct Foo {
   Foo(T const (&)[N]);
 };
 
+// FIXME: Prefer non-canonical template arguments in the deduction guide?
 template 
 using Bar = Foo; // expected-note {{candidate template ignored: 
couldn't infer template argument 'X'}} \
+   // expected-note {{implicit deduction guide 
declared as 'template  Bar(Foo) -> Foo'}} \
+   // expected-note {{implicit deduction guide 
declared as 'template  Bar(const type-parameter-0-0 
(&)[sizeof(type-parameter-0-0)]) -> Foo'}} \
// expected-note {{candidate template ignored: 
constraints not satisfied [with X = int]}} \

zyn0217 wrote:

@hokein I think the `constraints not satisfied` is still a bit confusing after 
#92389? There is no constraint explicitly written in the code, although the 
note actually refers to the implicit constraint `__is_deducible`.

https://github.com/llvm/llvm-project/pull/96084
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Introduce 'clang-nvlink-wrappaer' to work around 'nvlink' (PR #96561)

2024-06-25 Thread Joseph Huber via cfe-commits
;["--"], "version">,
+  HelpText<"Display the version number and exit">;
+
+def cuda_path_EQ : Joined<["--"], "cuda-path=">,
+  MetaVarName<"">, HelpText<"Set the system CUDA path">;
+
+def o : JoinedOrSeparate<["-"], "o">, MetaVarName<"">,
+  HelpText<"Path to file to write output">;
+def output : Separate<["--"], "output-file">, Alias, Flags<[HelpHidden]>,
+  HelpText<"Alias for -o">;
+
+def library_path : JoinedOrSeparate<["-"], "L">, MetaVarName<"">,
+  HelpText<"Add  to the library search path">;
+def library_path_S : Separate<["--", "-"], "library-path">, 
Flags<[HelpHidden]>,
+  Alias;
+def library_path_EQ : Joined<["--", "-"], "library-path=">, 
Flags<[HelpHidden]>,
+  Alias;
+
+def library : JoinedOrSeparate<["-"], "l">, MetaVarName<"">,
+  HelpText<"Search for library ">;
+def library_S : Separate<["--", "-"], "library">, Flags<[HelpHidden]>,
+  Alias;
+def library_EQ : Joined<["--", "-"], "library=">, Flags<[HelpHidden]>,
+  Alias;
+
+def arch : Separate<["--", "-"], "arch">,
+  HelpText<"Specify the 'sm_' name of the target architecture.">;
+def : Joined<["--", "-"], "plugin-opt=mcpu=">,
+  Flags<[HelpHidden, WrapperOnlyOption]>, Alias;
+
+def feature : Separate<["--", "-"], "feature">, Flags<[WrapperOnlyOption]>,
+  HelpText<"Specify the '+ptx' freature to use for LTO.">;
+
+def g : Flag<["-"], "g">, HelpText<"Specify that this was a debug compile.">;
+def debug : Flag<["--"], "debug">, Alias;
+
+def O : Joined<["--", "-"], "plugin-opt=O">,
+  Flags<[WrapperOnlyOption]>, MetaVarName<"">,
+  HelpText<"Optimization level for LTO">;
+
+def plugin_opt : Joined<["--", "-"], "plugin-opt">,
+  Flags<[WrapperOnlyOption, HelpHidden]>;
+
+def save_temps : Flag<["--", "-"], "save-temps">,
+  Flags<[WrapperOnlyOption]>, HelpText<"Save intermediate results">;
+
+def whole_archive : Flag<["--", "-"], "whole-archive">,
+  Flags<[WrapperOnlyOption, HelpHidden]>;
+def no_whole_archive : Flag<["--", "-"], "no-whole-archive">,
+  Flags<[WrapperOnlyOption, HelpHidden]>;
+
+def mllvm : Separate<["-"], "mllvm">, Flags<[WrapperOnlyOption]>,
+  MetaVarName<"">, HelpText<"Arguments passed to the LLVM invocation">;
+def mllvm_EQ : Joined<["-"], "mllvm=">, Flags<[HelpHidden]>,
+  Alias;
+
+def dry_run : Flag<["--", "-"], "dry-run">, Flags<[WrapperOnlyOption]>,
+  HelpText<"Print generated commands without running.">;

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Clarify diagnostic notes for implicitly generated deduction guides (PR #96084)

2024-06-25 Thread Younan Zhang via cfe-commits
  // expected-note 
{{implicit deduction guide declared as 'template  D(B *) -> D'}}
 };
 int f(int(int, int), int(int, int));
 // FIXME: We can't deduce this because we can't deduce through a
@@ -170,7 +171,8 @@ using DT = D;
 template struct E { // expected-note {{candidate}} \
  expected-note {{implicit deduction guide 
declared as 'template  E(E) -> E'}}
   template using B = Z...>;
-  template E(B); // expected-note {{candidate}}
+  template E(B); // expected-note {{candidate}} \
+ // expected-note {{implicit deduction 
guide declared as 'template  E(B) -> 
E'
 };
 // FIXME: We can't deduce this because we can't deduce through a
 // SubstNonTypeTemplateParmPackExpr.

>From 34b665e55ceded46da20c492a99179b9a41a15b6 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 25 Jun 2024 20:17:52 +0800
Subject: [PATCH 5/5] Remove an unnecessary FIXME

---
 clang/test/SemaCXX/cxx20-ctad-type-alias.cpp | 1 -
 1 file changed, 1 deletion(-)

diff --git a/clang/test/SemaCXX/cxx20-ctad-type-alias.cpp 
b/clang/t

[clang] [llvm] [LLVM] Fix incorrect alignment on AMDGPU variadics (PR #96370)

2024-06-25 Thread Joseph Huber via cfe-commits

jhuber6 wrote:

> > Hm, that's what I'm doing in the `printf` implementation and it doesn't 
> > work without that patch. When I look at the varargs struct it didn't have 
> > any padding, which explained why `alignTo(ptr + size, align)` was wrong. 
> > So, I was trying to do the following, `printf("%d%ld", 1, 1l)`. With this 
> > patch I get the following,
> 
> For what IR? Is the small struct getting expanded into individual scalar 
> pieces?

The implementation intentionally states that the alignment is always `4` in 
this case, which results in there being no padding between the four byte and 
eight byte values when put into a `void *` buffer for varargs. You should be 
able to see it in the changes to the tests. Unfortunately, @JonChesterfield is 
on vacation so I can't ask about this as it seems to be a deliberate choice, 
but I don't know how it's correct.

https://github.com/llvm/llvm-project/pull/96370
___________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [LLVM] Fix incorrect alignment on AMDGPU variadics (PR #96370)

2024-06-25 Thread Matt Arsenault via cfe-commits

arsenm wrote:

> > > > Incrementing by align is just a bug, of course the size is the real 
> > > > value. Whether we want to continue wasting space is another 
> > > > not-correctness discussion
> > > 
> > > 
> > > Struct padding is pretty universal, AMDGPU seems the odd one out here. I 
> > > wouldn't mind it so much if it didn't require me to know which vendor I 
> > > was dealing with in the RPC implementation, but I suppose I could store 
> > > that information somewhere if we want to use a compressed option and we 
> > > know it works.
> > 
> > 
> > It's not about struct padding, but the base alignment. Any pointer 
> > increment should be alignTo(ptr + size, align), not += align. The += align 
> > won't even work for large structs
> 
> Hm, that's what I'm doing in the `printf` implementation and it doesn't work 
> without that patch. When I look at the varargs struct it didn't have any 
> padding, which explained why `alignTo(ptr + size, align)` was wrong. So, I 
> was trying to do the following, `printf("%d%ld", 1, 1l)`. With this patch I 
> get the following,

For what IR? Is the small struct getting expanded into individual scalar 
pieces? 

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


[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #96240)

2024-06-25 Thread via cfe-commits
@LINE-1]]:21: runtime error: shift exponent -1 
is negative
+  return x;
+}
+
+_BitInt(37) shift_base() __attribute__((no_sanitize("memory"))) {
+  _BitInt(37) x = (-1) << 1;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:24: runtime error: left shift of 
negative value -1
+  return x;
+}
+
+uint32_t negative_shift1(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  _BitInt(9) c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift2(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  _BitInt(17) c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift3(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  _BitInt(34) c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift4(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+  int64_t c = -2;
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t negative_shift5(unsigned _BitInt(37) x)
+__attribute__((no_sanitize("memory"))) {
+#ifdef __SIZEOF_INT128__
+  _BitInt(68) c = -2;
+#else
+  // We cannot check BitInt values > 64 without int128_t support
+  _BitInt(48) c = -2;
+#endif
+  return x >> c;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:12: runtime error: shift exponent -2 
is negative
+}
+
+uint32_t unsigned_integer_overflow() __attribute__((no_sanitize("memory"))) {
+  unsigned _BitInt(37) x = ~0U;
+  ++x;
+  return x;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:10: runtime error: implicit 
conversion from type
+}
+
+// In this test no run-time overflow expected, so no diagnostics here, but 
should be a conversion error from the negative number on return.
+uint32_t signed_integer_overflow() __attribute__((no_sanitize("memory"))) {
+  _BitInt(37) x = (_BitInt(37)) ~((0x8FFFULL) >> 1);
+  --x;
+  return x;
+  // CHECK: {{.*}}bit-int.c:[[#@LINE-1]]:10: runtime error: implicit 
conversion from type
+}
+
+int main(int argc, char **argv) {
+  // clang-format off
+  uint64_t result =
+  1ULL +
+  implicit_unsigned_integer_truncation() +
+  pointer_overflow() +
+  vla_bound(argc) +
+  unsigned_shift_base() +
+  (uint32_t)array_bounds() +
+  float_cast_overflow() +
+  implicit_integer_sign_change((unsigned _BitInt(37))(argc - 2)) +
+  (uint64_t)implicit_signed_integer_truncation() +
+  shift_exponent() +
+  (uint32_t)shift_base() +
+  negative_shift1(5) +
+  negative_shift2(5) +
+  negative_shift3(5) +
+  negative_shift4(5) +
+  negative_shift5(5) +
+  unsigned_integer_overflow() +
+  signed_integer_overflow();
+  // clang-format on
+  printf("%u\n", (uint32_t)(result & 0x));
+}

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [LLVM] Fix incorrect alignment on AMDGPU variadics (PR #96370)

2024-06-25 Thread Joseph Huber via cfe-commits

jhuber6 wrote:

> > > Incrementing by align is just a bug, of course the size is the real 
> > > value. Whether we want to continue wasting space is another 
> > > not-correctness discussion
> > 
> > 
> > Struct padding is pretty universal, AMDGPU seems the odd one out here. I 
> > wouldn't mind it so much if it didn't require me to know which vendor I was 
> > dealing with in the RPC implementation, but I suppose I could store that 
> > information somewhere if we want to use a compressed option and we know it 
> > works.
> 
> It's not about struct padding, but the base alignment. Any pointer increment 
> should be alignTo(ptr + size, align), not += align. The += align won't even 
> work for large structs

Hm, that's what I'm doing in the `printf` implementation and it doesn't work 
without that patch. When I look at the varargs struct it didn't have any 
padding, which explained why `alignTo(ptr + size, align)` was wrong. So, I was 
trying to do the following, `printf("%d%ld", 1, 1l)`. With this patch I get the 
following,
```
0xbebebebe0001
0x0001
```
Without this patch, I get this. As you can see there's no struct padding so the 
8 byte value is right next to the 4 byte one.
```
0x00010001
0xbebebebe
```

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


[clang] [Clang] Clarify diagnostic notes for implicitly generated deduction guides (PR #96084)

2024-06-25 Thread Younan Zhang via cfe-commits


@@ -12114,6 +12115,35 @@ static void NoteFunctionCandidate(Sema , 
OverloadCandidate *Cand,
 return;
   }
 
+  // If this is an implicit deduction guide against an implicitly defined
+  // constructor, add a note for it. Neither these deduction guides nor their
+  // corresponding constructors are explicitly spelled in the source code,
+  // and simply producing a deduction failure note around the heading of the
+  // enclosing RecordDecl would be confusing.
+  //
+  // We prefer adding such notes at the end of the last deduction failure
+  // reason because duplicate code snippets appearing in the diagnostic
+  // would likely become noisy.
+  auto _ = llvm::make_scope_exit([&] {
+auto *DG = dyn_cast(Fn);
+if (!DG || !DG->isImplicit() || DG->getCorrespondingConstructor())

zyn0217 wrote:

Done. I think this can be done by checking the origin template.

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


[jenkinsci/gitlab-logo-plugin] 311d1e: Enable Jenkins Security Scan

2024-06-25 Thread 'Go Sueyoshi' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/gitlab-logo-plugin
  Commit: 311d1e41a1390c9454642d32d02842c23d7b64ed
  
https://github.com/jenkinsci/gitlab-logo-plugin/commit/311d1e41a1390c9454642d32d02842c23d7b64ed
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan


  Commit: 2572dfd1b7f1af609f81363acc2e4daf770de9e3
  
https://github.com/jenkinsci/gitlab-logo-plugin/commit/2572dfd1b7f1af609f81363acc2e4daf770de9e3
  Author: Go Sueyoshi 
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Merge pull request #71 from strangelookingnerd/patch-1

Enable Jenkins Security Scan


Compare: 
https://github.com/jenkinsci/gitlab-logo-plugin/compare/3d9d7ee28dfa...2572dfd1b7f1

To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/gitlab-logo-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/gitlab-logo-plugin/push/refs/heads/master/3d9d7e-2572df%40github.com.


[clang] [Clang] Clarify diagnostic notes for implicitly generated deduction guides (PR #96084)

2024-06-25 Thread Younan Zhang via cfe-commits
  // expected-note 
{{implicit deduction guide declared as 'template  D(B *) -> D'}}
 };
 int f(int(int, int), int(int, int));
 // FIXME: We can't deduce this because we can't deduce through a
@@ -170,7 +171,8 @@ using DT = D;
 template struct E { // expected-note {{candidate}} \
  expected-note {{implicit deduction guide 
declared as 'template  E(E) -> E'}}
   template using B = Z...>;
-  template E(B); // expected-note {{candidate}}
+  template E(B); // expected-note {{candidate}} \
+ // expected-note {{implicit deduction 
guide declared as 'template  E(B) -> 
E'
 };
 // FIXME: We can't deduce this because we can't deduce through a
 // SubstNonTypeTemplateParmPackExpr.

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [IncludeCleaner] display overview (PR #93932)

2024-06-25 Thread via cfe-commits

TheHillBright wrote:

Ping @kadircet @sam-mccall for one month of inactivity for this simple PR.

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


[clang-tools-extra] [IncludeCleaner] display overview (PR #93932)

2024-06-25 Thread via cfe-commits

https://github.com/TheHillBright updated 
https://github.com/llvm/llvm-project/pull/93932

>From e803c635a64ed3c2ad0381e82ca308f63dcf4604 Mon Sep 17 00:00:00 2001
From: TheHillBright <150074496+thehillbri...@users.noreply.github.com>
Date: Fri, 31 May 2024 15:00:37 +0800
Subject: [PATCH] IncludeCleaner: display overview

---
 clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp 
b/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp
index 3bc449b0152bb..788ad87b1d4e8 100644
--- a/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp
+++ b/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp
@@ -279,7 +279,7 @@ int main(int argc, const char **argv) {
 
   llvm::sys::PrintStackTraceOnErrorSignal(argv[0]);
   auto OptionsParser =
-  clang::tooling::CommonOptionsParser::create(argc, argv, IncludeCleaner);
+  clang::tooling::CommonOptionsParser::create(argc, argv, IncludeCleaner, 
cl::OneOrMore, Overview);
   if (!OptionsParser) {
 llvm::errs() << toString(OptionsParser.takeError());
 return 1;

_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [LLVM] Fix incorrect alignment on AMDGPU variadics (PR #96370)

2024-06-25 Thread Matt Arsenault via cfe-commits

arsenm wrote:

> > Incrementing by align is just a bug, of course the size is the real value. 
> > Whether we want to continue wasting space is another not-correctness 
> > discussion
> 
> Struct padding is pretty universal, AMDGPU seems the odd one out here. I 
> wouldn't mind it so much if it didn't require me to know which vendor I was 
> dealing with in the RPC implementation, but I suppose I could store that 
> information somewhere if we want to use a compressed option and we know it 
> works.

It's not about struct padding, but the base alignment. Any pointer increment 
should be alignTo(ptr + size, align), not += align. The += align won't even 
work for large structs 

https://github.com/llvm/llvm-project/pull/96370
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Catch missing format attributes (PR #70024)

2024-06-25 Thread Budimir Aranđelović via cfe-commits
g
+vprintf(str.c_str(), args); // expected-no-warning
+}
+
+__attribute__((format(printf, 1, 2))) // expected-error {{format argument not 
a string type}}
+void f2(const std::string , ... /* args */); // #f2
+
+void f3(std::string_view str, ... /* args */) // #f3
+{
+va_list args;
+vscanf(std::string(str).c_str(), args); // expected-no-warning
+vprintf(std::string(str).c_str(), args); // expected-no-warning
+}
+
+__attribute__((format(printf, 1, 2))) // expected-error {{format argument not 
a string type}}
+void f4(std::string_view str, ... /* args */); // #f4
+
+void f5(const std::wstring , ... /* args */) // #f5
+{
+va_list args;
+vscanf((const char *)str.c_str(), args); // expected-no-warning
+vprintf((const char *)str.c_str(), args); // expected-no-warning
+}
+
+__attribute__((format(printf, 1, 2))) // expected-error {{format argument not 
a string type}}
+void f6(const std::wstring , ... /* args */); // #f6
+
+void f7(std::wstring_view str, ... /* args */) // #f7
+{
+va_list args;
+vscanf((const char *) std::wstring(str).c_str(), args); // 
expected-no-warning
+vprintf((const char *) std::wstring(str).c_str(), args); // 
expected-no-warning
+}
+
+__attribute__((format(printf, 1, 2))) // expected-error {{format argument not 
a string type}}
+void f8(std::wstring_view str, ... /* args */); // #f8
+
+struct S1
+{
+void fn1(const char *out, ... /* args */) // #S1_fn1
+{
+va_list args;
+vscanf(out, args); // expected-warning@#S1_fn1 {{diagnostic behavior 
may be improved by adding the 'scanf' format attribute to the declaration of 
'fn1'}}
+   // CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:10-[[@LINE-4]]:10}:"__attribute__((format(scanf, 
2, 3)))"
+}
+
+__attribute__((format(scanf, 2, 0)))
+void fn2(const char *out, va_list args); // #S1_fn2
+
+void fn3(const char *out, ... /* args */);
+
+void fn4(this S1& expliciteThis, const char *out, va_list args) // #S1_fn4
+{
+expliciteThis.fn2(out, args); // beforeCxx2b-error@#S1_fn4 {{explicit 
object parameters are incompatible with C++ standards before C++2b}}
+  // expected-warning@#S1_fn4 {{diagnostic 
behavior may be improved by adding the 'scanf' format attribute to the 
declaration of 'fn4'}}
+  // CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:10-[[@LINE-4]]:10}:"__attribute__((format(scanf, 
2, 0)))"
+}
+};
+
+void S1::fn3(const char *out, ... /* args */) // #S1_fn3
+{
+va_list args;
+fn2(out, args); // expected-warning@#S1_fn3 {{diagnostic behavior may be 
improved by adding the 'scanf' format attribute to the declaration of 'fn3'}}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:10-[[@LINE-4]]:10}:"__attribute__((format(scanf, 
2, 3)))"
+}
+
+union U1
+{
+__attribute__((format(printf, 2, 0)))
+void fn1(const char *out, va_list args); // #U1_fn1
+
+void fn2(const char *out, ... /* args */) // #U1_fn2
+{
+va_list args;
+fn1(out, args); // expected-warning@#U1_fn2 {{diagnostic behavior may 
be improved by adding the 'printf' format attribute to the declaration of 
'fn2'}}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:10-[[@LINE-4]]:10}:"__attribute__((format(printf, 
2, 3)))"
+}
+
+void fn3(this U1&, const char *out) // #U1_fn3
+{
+va_list args;
+printf(out, args); // beforeCxx2b-error@#U1_fn3 {{explicit object 
parameters are incompatible with C++ standards before C++2b}}
+   // expected-warning@#U1_fn3 {{diagnostic behavior 
may be improved by adding the 'printf' format attribute to the declaration of 
'fn3'}}
+   // CHECK: 
fix-it:"{{.*}}":{[[@LINE-5]]:10-[[@LINE-5]]:10}:"__attribute__((format(printf, 
2, 0)))"
+}
+};
+
+class C1
+{
+__attribute__((format(printf, 3, 0)))
+void fn1(const int n, const char *out, va_list args); // #C1_fn1
+
+void fn2(const char *out, const int n, ... /* args */) // #C1_fn2
+{
+va_list args;
+fn1(n, out, args); // expected-warning@#C1_fn2 {{diagnostic behavior 
may be improved by adding the 'printf' format attribute to the declaration of 
'fn2'}}
+   // CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:10-[[@LINE-4]]:10}:"__attribute__((format(printf, 
2, 4)))"
+}
+
+void fn3(this const C1&, const char *out, va_list args) // #C1_fn3
+{
+scanf(out, args); // beforeCxx2b-error@#C1_fn3 {{explicit object 
parameters are incompatible with C++ standards before C++2b}}
+  // expected-warning@#C1_fn3 {{diagnostic behavior 
may be improved by adding the 'scanf' format attribute to the declaration of 
'fn3'}}
+  // CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:10-[[@LINE-4]]:10}:"__attribute__((format(scanf, 
2, 0)))"
+}
+
+C1(const int n, const char *out) //#C1_C1a
+{
+va_list args;
+fn1(n, out, args); // expected-warning@#C1_C1a {{diagnostic behavior 
may be improved by adding the 'printf' format attribute to the declaration of 
'C1'}}
+   // CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:5-[[@LINE-4]]:5}:"__attribute__((format(printf, 3, 
0)))"
+}
+
+C1(const char *out, ... /* args */) // #C1_C1b
+{
+va_list args;
+printf(out, args); // expected-warning@#C1_C1b {{diagnostic behavior 
may be improved by adding the 'printf' format attribute to the declaration of 
'C1'}}
+   // CHECK: 
fix-it:"{{.*}}":{[[@LINE-4]]:5-[[@LINE-4]]:5}:"__attribute__((format(printf, 2, 
3)))"
+}
+
+~C1()
+{
+const char *out;
+va_list args;
+vprintf(out, args); // expected-no-warning
+}
+};
+
+// TODO: implement for templates
+template 
+void func(char ()[N], ... /* args */)
+{
+va_list args;
+vprintf(str, args); // expected-no-warning
+}

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[jenkinsci/configurationslicing-plugin] 2a7d24: Enable Jenkins Security Scan (#263)

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/configurationslicing-plugin
  Commit: 2a7d24ebbed25c94adc6125bf6e7b120c3dd4682
  
https://github.com/jenkinsci/configurationslicing-plugin/commit/2a7d24ebbed25c94adc6125bf6e7b120c3dd4682
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan (#263)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/configurationslicing-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/configurationslicing-plugin/push/refs/heads/master/ac1bd9-2a7d24%40github.com.


[jenkinsci/agent-setup-plugin] bbbc85: Enable Jenkins Security Scan (#40)

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/agent-setup-plugin
  Commit: bbbc858495706e6891ab8915382621bcc0c6c994
  
https://github.com/jenkinsci/agent-setup-plugin/commit/bbbc858495706e6891ab8915382621bcc0c6c994
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan (#40)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/agent-setup-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/agent-setup-plugin/push/refs/heads/master/0b5d18-bbbc85%40github.com.


[jenkinsci/cron_column-plugin] 1f9c6a: Enable Jenkins Security Scan (#34)

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/cron_column-plugin
  Commit: 1f9c6a298cd22c029ca89782ac0512e7f971bd3b
  
https://github.com/jenkinsci/cron_column-plugin/commit/1f9c6a298cd22c029ca89782ac0512e7f971bd3b
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan (#34)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/cron_column-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/cron_column-plugin/push/refs/heads/master/66a5f7-1f9c6a%40github.com.


[clang] [TBAA] Emit int TBAA metadata on FP math libcalls (PR #96025)

2024-06-25 Thread via cfe-commits


@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction , const 
FunctionDecl *FD,
   const CallExpr *E, llvm::Constant *calleeValue) {
   CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
   CGCallee callee = CGCallee::forDirect(calleeValue, GlobalDecl(FD));
-  return CGF.EmitCall(E->getCallee()->getType(), callee, E, ReturnValueSlot());
+  RValue Call =
+  CGF.EmitCall(E->getCallee()->getType(), callee, E, ReturnValueSlot());
+
+  // Check the supported intrinsic.
+  if (unsigned BuiltinID = FD->getBuiltinID()) {
+auto IntrinsicID = [&]() -> unsigned {
+  switch (BuiltinID) {
+  case Builtin::BIexpf:
+  case Builtin::BI__builtin_expf:
+  case Builtin::BI__builtin_expf128:
+return true;
+  }
+  // TODO: support more FP math libcalls
+  return false;
+}();
+
+if (IntrinsicID) {
+  llvm::MDBuilder MDHelper(CGF.getLLVMContext());
+  MDNode *RootMD = CGF.CGM.getTBAARoot();
+  // Emit "int" TBAA metadata on FP math libcalls.
+  MDNode *AliasType = MDHelper.createTBAANode("int", RootMD);

vfdff wrote:

Yes, apply your comment, thanks

https://github.com/llvm/llvm-project/pull/96025
___________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[jenkinsci/port-allocator-plugin] 88779c: Enable Jenkins Security Scan (#41)

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/port-allocator-plugin
  Commit: 88779ce1171026580413018ac688c0d5283a6aef
  
https://github.com/jenkinsci/port-allocator-plugin/commit/88779ce1171026580413018ac688c0d5283a6aef
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan (#41)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/port-allocator-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/port-allocator-plugin/push/refs/heads/master/890370-88779c%40github.com.


[jenkinsci/port-allocator-plugin] 890370: Bump org.jenkins-ci.plugins:plugin from 4.81 to 4....

2024-06-25 Thread 'dependabot[bot]' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/port-allocator-plugin
  Commit: 89037086dbd7b802d2ec2618d062b78aa4205264
  
https://github.com/jenkinsci/port-allocator-plugin/commit/89037086dbd7b802d2ec2618d062b78aa4205264
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M pom.xml

  Log Message:
  ---
  Bump org.jenkins-ci.plugins:plugin from 4.81 to 4.82 (#40)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/port-allocator-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/port-allocator-plugin/push/refs/heads/master/f7658b-890370%40github.com.


[jenkinsci/built-on-column-plugin] ac4309: Enable Jenkins Security Scan (#42)

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/built-on-column-plugin
  Commit: ac43097ee5635f7821209b12e619644c0c169495
  
https://github.com/jenkinsci/built-on-column-plugin/commit/ac43097ee5635f7821209b12e619644c0c169495
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan (#42)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/built-on-column-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/built-on-column-plugin/push/refs/heads/master/3eb303-ac4309%40github.com.


[clang] [TBAA] Emit int TBAA metadata on FP math libcalls (PR #96025)

2024-06-25 Thread via cfe-commits
k-prefixes=CHECK,NoNewStructPathTBAA
+// RUN:  %clang -S -O3 -Xclang -new-struct-path-tbaa -emit-llvm -o - -x c++ %s 
| FileCheck %s -check-prefixes=CHECK,NewStructPathTBAA
 
 #include 
 
@@ -23,10 +24,20 @@ float foo (float num[], float r2inv, int n) {
return tmp;
 }
 //.
-// CHECK: [[TBAA6]] = !{[[META7:![0-9]+]], [[META7]], i64 0}
-// CHECK: [[META7]] = !{!"float", [[META8:![0-9]+]], i64 0}
-// CHECK: [[META8]] = !{!"omnipotent char", [[META9:![0-9]+]], i64 0}
-// CHECK: [[META9]] = !{!"Simple C++ TBAA"}
-// CHECK: [[TBAA10]] = !{[[META11:![0-9]+]], [[META11]], i64 0}
-// CHECK: [[META11]] = !{!"int", [[META9]], i64 0}
+// NoNewStructPathTBAA: [[TBAA6]] = !{[[META7:![0-9]+]], [[META7]], i64 0}
+// NoNewStructPathTBAA: [[META7]] = !{!"float", [[META8:![0-9]+]], i64 0}
+// NoNewStructPathTBAA: [[META8]] = !{!"omnipotent char", [[META9:![0-9]+]], 
i64 0}
+// NoNewStructPathTBAA: [[META9]] = !{!"Simple C++ TBAA"}
+// NoNewStructPathTBAA: [[TBAA10]] = !{[[META11:![0-9]+]], [[META11]], i64 0}
+// NoNewStructPathTBAA: [[META11]] = !{!"int", [[META8]], i64 0}
 //.
+// NewStructPathTBAA: [[TBAA6]] = !{[[META7:![0-9]+]], [[META7]], i64 0, i64 4}
+// NewStructPathTBAA: [[META7]] = !{[[META8:![0-9]+]], i64 4, !"float"}
+// NewStructPathTBAA: [[META8]] = !{[[META9:![0-9]+]], i64 1, !"omnipotent 
char"}
+// NewStructPathTBAA: [[META9]] = !{!"Simple C++ TBAA"}
+// NewStructPathTBAA: [[TBAA10]] = !{[[META11:![0-9]+]], [[META11]], i64 0, 
i64 4}
+// NewStructPathTBAA: [[META11]] = !{[[META8]], i64 4, !"int"}
+//.
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add 
tests below this line:
+// NewStructPathTBAA: {{.*}}
+// NoNewStructPathTBAA: {{.*}}

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][Driver] Add HIPAMD Driver support for AMDGCN flavoured SPIR-V (PR #95061)

2024-06-25 Thread Alex Voicu via cfe-commits

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


[clang] 9acb533 - [clang][Driver] Add HIPAMD Driver support for AMDGCN flavoured SPIR-V (#95061)

2024-06-25 Thread via cfe-commits
3ee5a257..700860378ed0c 100644
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ b/clang/test/Misc/target-invalid-cpu-note.c
@@ -29,7 +29,7 @@
 
 // RUN: not %clang_cc1 -triple nvptx--- -target-cpu not-a-cpu -fsyntax-only %s 
2>&1 | FileCheck %s --check-prefix NVPTX
 // NVPTX: error: unknown target CPU 'not-a-cpu'
-// NVPTX-NEXT: note: valid target CPU values are: sm_20, sm_21, sm_30, sm_32, 
sm_35, sm_37, sm_50, sm_52, sm_53, sm_60, sm_61, sm_62, sm_70, sm_72, sm_75, 
sm_80, sm_86, sm_87, sm_89, sm_90, sm_90a, gfx600, gfx601, gfx602, gfx700, 
gfx701, gfx702, gfx703, gfx704, gfx705, gfx801, gfx802, gfx803, gfx805, gfx810, 
gfx9-generic, gfx900, gfx902, gfx904, gfx906, gfx908, gfx909, gfx90a, gfx90c, 
gfx940, gfx941, gfx942, gfx10-1-generic, gfx1010, gfx1011, gfx1012, gfx1013, 
gfx10-3-generic, gfx1030, gfx1031, gfx1032, gfx1033, gfx1034, gfx1035, gfx1036, 
gfx11-generic, gfx1100, gfx1101, gfx1102, gfx1103, gfx1150, gfx1151, gfx1152, 
gfx12-generic, gfx1200, gfx1201{{$}}
+// NVPTX-NEXT: note: valid target CPU values are: sm_20, sm_21, sm_30, sm_32, 
sm_35, sm_37, sm_50, sm_52, sm_53, sm_60, sm_61, sm_62, sm_70, sm_72, sm_75, 
sm_80, sm_86, sm_87, sm_89, sm_90, sm_90a, gfx600, gfx601, gfx602, gfx700, 
gfx701, gfx702, gfx703, gfx704, gfx705, gfx801, gfx802, gfx803, gfx805, gfx810, 
gfx9-generic, gfx900, gfx902, gfx904, gfx906, gfx908, gfx909, gfx90a, gfx90c, 
gfx940, gfx941, gfx942, gfx10-1-generic, gfx1010, gfx1011, gfx1012, gfx1013, 
gfx10-3-generic, gfx1030, gfx1031, gfx1032, gfx1033, gfx1034, gfx1035, gfx1036, 
gfx11-generic, gfx1100, gfx1101, gfx1102, gfx1103, gfx1150, gfx1151, gfx1152, 
gfx12-generic, gfx1200, gfx1201, amdgcnspirv{{$}}
 
 // RUN: not %clang_cc1 -triple r600--- -target-cpu not-a-cpu -fsyntax-only %s 
2>&1 | FileCheck %s --check-prefix R600
 // R600: error: unknown target CPU 'not-a-cpu'

diff  --git a/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp 
b/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
index ba16c0851e1fd..7a228fb6c08b9 100644
--- a/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ b/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -5309,6 +5309,8 @@ static const char *getSectionNameForBitcode(const Triple 
) {
 llvm_unreachable("GOFF is not yet implemented");
 break;
   case Triple::SPIRV:
+if (T.getVendor() == Triple::AMD)
+  return ".llvmbc";
 llvm_unreachable("SPIRV is not yet implemented");
 break;
   case Triple::XCOFF:
@@ -5334,6 +5336,8 @@ static const char *getSectionNameForCommandline(const 
Triple ) {
 llvm_unreachable("GOFF is not yet implemented");
 break;
   case Triple::SPIRV:
+if (T.getVendor() == Triple::AMD)
+  return ".llvmcmd";
 llvm_unreachable("SPIRV is not yet implemented");
 break;
   case Triple::XCOFF:



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [AMDGPU] Enable atomic optimizer for 64 bit divergent values (PR #96473)

2024-06-25 Thread Matt Arsenault via cfe-commits


@@ -228,10 +228,11 @@ void 
AMDGPUAtomicOptimizerImpl::visitAtomicRMWInst(AtomicRMWInst ) {
 
   // If the value operand is divergent, each lane is contributing a different
   // value to the atomic calculation. We can only optimize divergent values if
-  // we have DPP available on our subtarget, and the atomic operation is 32
-  // bits.
+  // we have DPP available on our subtarget, and the atomic operation is either
+  // 32 or 64 bits.
   if (ValDivergent &&
-  (!ST->hasDPP() || DL->getTypeSizeInBits(I.getType()) != 32)) {
+  (!ST->hasDPP() || (DL->getTypeSizeInBits(I.getType()) != 32 &&
+  DL->getTypeSizeInBits(I.getType()) != 64))) {

arsenm wrote:

You should move the type logic into a separate predicate function. But also, 
you should base this on the actual type and not just the bitwidth. Checking the 
bitwidth will break in the future when atomics support more vector operations

https://github.com/llvm/llvm-project/pull/96473
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [AMDGPU] Enable atomic optimizer for 64 bit divergent values (PR #96473)

2024-06-25 Thread Matt Arsenault via cfe-commits


@@ -311,10 +312,11 @@ void 
AMDGPUAtomicOptimizerImpl::visitIntrinsicInst(IntrinsicInst ) {
 
   // If the value operand is divergent, each lane is contributing a different
   // value to the atomic calculation. We can only optimize divergent values if
-  // we have DPP available on our subtarget, and the atomic operation is 32
-  // bits.
+  // we have DPP available on our subtarget, and the atomic operation is 32 or
+  // 64 bits.
   if (ValDivergent &&
-  (!ST->hasDPP() || DL->getTypeSizeInBits(I.getType()) != 32)) {
+  (!ST->hasDPP() || (DL->getTypeSizeInBits(I.getType()) != 32 &&

arsenm wrote:

Ditto 

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


[jenkinsci/additional-metrics-plugin] edc3de: Enable Jenkins Security Scan

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/additional-metrics-plugin
  Commit: edc3de1e0dc124103a8e31c3ee0fcf42bcbce4aa
  
https://github.com/jenkinsci/additional-metrics-plugin/commit/edc3de1e0dc124103a8e31c3ee0fcf42bcbce4aa
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/additional-metrics-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/additional-metrics-plugin/push/refs/heads/master/177c3e-edc3de%40github.com.


[clang] [NFC][clang] Replace unreachable code in literal processing with assert (PR #96579)

2024-06-25 Thread Aaron Ballman via cfe-commits

https://github.com/AaronBallman approved this pull request.

LGTM!

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


[jenkins-infra/jenkins.io] e157fb: Automated changelog for 2.464

2024-06-25 Thread 'jenkins-infra-changelog-generator[bot]' via Jenkins Commits
  Branch: refs/heads/automated-weekly-changelog/2.464
  Home:   https://github.com/jenkins-infra/jenkins.io
  Commit: e157fb43d1a9990fcdccb04d2bc54907dd8f48a3
  
https://github.com/jenkins-infra/jenkins.io/commit/e157fb43d1a9990fcdccb04d2bc54907dd8f48a3
  Author: jenkins-infra-changelog-generator 
<86592549+jenkins-infra-changelog-generator[bot]@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M content/_data/changelogs/weekly.yml

  Log Message:
  ---
  Automated changelog for 2.464



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkins-infra/jenkins.io/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkins-infra/jenkins.io/push/refs/heads/automated-weekly-changelog/2.464/18fc50-e157fb%40github.com.


[clang] [llvm] [AMDGPU] Extend permlane16, permlanex16 and permlane64 intrinsic lowering for generic types (PR #92725)

2024-06-25 Thread Matt Arsenault via cfe-commits

https://github.com/arsenm approved this pull request.


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


[jenkinsci/jenkins] d8925a: Update jenkins/ath Docker tag to v5883 (#9418)

2024-06-25 Thread 'renovate[bot]' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/jenkins
  Commit: d8925acb0ed616c635e98c9cf0aacfc5fe712f2e
  
https://github.com/jenkinsci/jenkins/commit/d8925acb0ed616c635e98c9cf0aacfc5fe712f2e
  Author: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M ath.sh

  Log Message:
  ---
  Update jenkins/ath Docker tag to v5883 (#9418)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/jenkins/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/jenkins/push/refs/heads/master/bf45ad-d8925a%40github.com.


[clang] [Clang][AMDGPU] Add builtins for instrinsic `llvm.amdgcn.raw.ptr.buffer.store` (PR #94576)

2024-06-25 Thread Matt Arsenault via cfe-commits

https://github.com/arsenm approved this pull request.


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


[clang-tools-extra] [clang-tidy]: Use correct term for user-provided constructor (PR #96617)

2024-06-25 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-clang-tools-extra

@llvm/pr-subscribers-clang-tidy

Author: Anders Schau Knatten (knatten)


Changes

First of all, fix a confusion in the documentation for pro-type-member-init 
which used the wrong term for a user-provided constructor. (In the 
corresponding comment in ProTypeMemberInitCheck.h, which was added in the same 
commit that added this documentation, we already use the correct term).

Second, also fix a comment in the corresponding test that had the same mistake.

https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5:

 A function is user-provided if it is user-declared and not explicitly
 defaulted or deleted on its first declaration.

("user-defined constructor" is not a thing in the standard)

---
Full diff: https://github.com/llvm/llvm-project/pull/96617.diff


2 Files Affected:

- (modified) 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
 (+1-1) 
- (modified) 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
 (+1-1) 


``diff
diff --git 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
index ae55bf7bd7c86..97af01a895e1c 100644
--- 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
+++ 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
@@ -3,7 +3,7 @@
 cppcoreguidelines-pro-type-member-init
 ==
 
-The check flags user-defined constructor definitions that do not
+The check flags user-provided constructor definitions that do not
 initialize all fields that would be left in an undefined state by
 default construction, e.g. builtins, pointers and record types without
 user-provided default constructors containing at least one such
diff --git 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
index eaa73b906ce09..d999b84cae03e 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
@@ -243,7 +243,7 @@ struct PositiveUninitializedBaseOrdering : public 
NegativeAggregateType,
 };
 
 // We shouldn't need to initialize anything because PositiveUninitializedBase
-// has a user-defined constructor.
+// has a user-provided constructor.
 struct NegativeUninitializedBase : public PositiveUninitializedBase {
   NegativeUninitializedBase() {}
 };

``




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


[clang-tools-extra] [clang-tidy]: Use correct term for user-provided constructor (PR #96617)

2024-06-25 Thread via cfe-commits

github-actions[bot] wrote:



Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from 
other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

https://github.com/llvm/llvm-project/pull/96617
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [clang-tidy]: Use correct term for user-provided constructor (PR #96617)

2024-06-25 Thread Anders Schau Knatten via cfe-commits

https://github.com/knatten created 
https://github.com/llvm/llvm-project/pull/96617

First of all, fix a confusion in the documentation for pro-type-member-init 
which used the wrong term for a user-provided constructor. (In the 
corresponding comment in ProTypeMemberInitCheck.h, which was added in the same 
commit that added this documentation, we already use the correct term).

Second, also fix a comment in the corresponding test that had the same mistake.

https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5:

> A function is user-provided if it is user-declared and not explicitly
> defaulted or deleted on its first declaration.

("user-defined constructor" is not a thing in the standard)

>From 7bc0205abaeeeab058d6568b202a0d7f98496863 Mon Sep 17 00:00:00 2001
From: Anders Schau Knatten 
Date: Tue, 25 Jun 2024 12:13:35 +0200
Subject: [PATCH] [clang-tidy]: Use correct term for user-provided constructor

First of all, fix a confusion in the documentation for
pro-type-member-init which used the wrong term for a user-provided
constructor. (In the corresponding comment in ProTypeMemberInitCheck.h,
which was added in the same commit that added this documentation, we
already use the correct term).

Second, also fix a comment in the corresponding test that had the same
mistake.

https://timsong-cpp.github.io/cppwp/std23/dcl.fct.def.default#5:

> A function is user-provided if it is user-declared and not explicitly
> defaulted or deleted on its first declaration.

("user-defined constructor" is not a thing in the standard)
---
 .../checks/cppcoreguidelines/pro-type-member-init.rst   | 2 +-
 .../checkers/cppcoreguidelines/pro-type-member-init.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
index ae55bf7bd7c86..97af01a895e1c 100644
--- 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
+++ 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.rst
@@ -3,7 +3,7 @@
 cppcoreguidelines-pro-type-member-init
 ==
 
-The check flags user-defined constructor definitions that do not
+The check flags user-provided constructor definitions that do not
 initialize all fields that would be left in an undefined state by
 default construction, e.g. builtins, pointers and record types without
 user-provided default constructors containing at least one such
diff --git 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
index eaa73b906ce09..d999b84cae03e 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/pro-type-member-init.cpp
@@ -243,7 +243,7 @@ struct PositiveUninitializedBaseOrdering : public 
NegativeAggregateType,
 };
 
 // We shouldn't need to initialize anything because PositiveUninitializedBase
-// has a user-defined constructor.
+// has a user-provided constructor.
 struct NegativeUninitializedBase : public PositiveUninitializedBase {
   NegativeUninitializedBase() {}
 };

_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refine invalidation caused by `fread` (PR #93408)

2024-06-25 Thread via cfe-commits

vabridgers wrote:

Hi @steakhal , this change seems to have exposed by div/0 error in a very 
particular corner we came across after integrating this change. Could you try 
this case to see if can repro?

The div/0 is occurring at line 1093: 
   bool IncompleteLastElement = (NumBytesRead % ElemSizeInChars) != 0;

clang -cc1 -analyze -analyzer-checker=unix.Stream -analyzer-opt-analyze-headers 
test.c 

This is the test source. 

# 1 "" 3
typedef FILE;
void *b;
a() {
  FILE f = fopen("", "");
  fread(b, 1, 1, f);
}

The crash ... 
`$ clang -cc1 -analyze -analyzer-checker=unix.Stream 
-analyzer-opt-analyze-headers test.c`
`PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and 
include the crash backtrace, preprocessed source, and associated run script.`
`Stack dump:`
`0.  Program arguments: clang -cc1 -analyze -analyzer-checker=unix.Stream 
-analyzer-opt-analyze-headers test.c`
`1.   parser at end of file`
`2.  While analyzing stack:`
`#0 Calling a`
`3.  :5:3: Error evaluating statement`
`4.  :5:3: Error evaluating statement`
` #0 0x0686046a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
llvm/lib/Support/Unix/Signals.inc:723:22`
` #1 0x068608a4 PrintStackTraceSignalHandler(void*) 
llvm/lib/Support/Unix/Signals.inc:798:1`
` #2 0x0685e1bd llvm::sys::RunSignalHandlers() 
llvm/lib/Support/Signals.cpp:105:20`
` #3 0x0685fe54 SignalHandler(int) 
llvm/lib/Support/Unix/Signals.inc:413:1`
` #4 0x7f931d2c1630 __restore_rt sigaction.c:0:0`
` #5 0x09fc96ff 
tryToInvalidateFReadBufferByElements(llvm::IntrusiveRefCntPtr, clang::ento::CheckerContext&, clang::ento::CallEvent const&, 
clang::ento::NonLoc, clang::ento::NonLoc) 
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:1093:48`




https://github.com/llvm/llvm-project/pull/93408
___________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[jenkins-infra/jenkins-infra] d380ee: chore: Update docker-ce version in common.yaml

2024-06-25 Thread 'jenkins-infra-bot' via Jenkins Commits
  Branch: 
refs/heads/updatecli_production_8b94de40a035acd8e19f05dbc0f89d0440a74e9d3483d39bf259102d9d6eeaa4
  Home:   https://github.com/jenkins-infra/jenkins-infra
  Commit: d380eeab6920916a03246b072d08b9eff2d24723
  
https://github.com/jenkins-infra/jenkins-infra/commit/d380eeab6920916a03246b072d08b9eff2d24723
  Author: Jenkins Infra Bot (updatecli) 
<60776566+jenkins-infra-...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M hieradata/common.yaml

  Log Message:
  ---
  chore: Update docker-ce version in common.yaml

Made with ❤️️ by updatecli



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkins-infra/jenkins-infra/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkins-infra/jenkins-infra/push/refs/heads/updatecli_production_8b94de40a035acd8e19f05dbc0f89d0440a74e9d3483d39bf259102d9d6eeaa4/00-d380ee%40github.com.


[tor-commits] [Git][tpo/applications/firefox-android] Pushed new tag fenix-v125.3.0

2024-06-25 Thread Pier Angelo Vendrame (@pierov) via tor-commits


Pier Angelo Vendrame pushed new tag fenix-v125.3.0 at The Tor Project / 
Applications / firefox-android

-- 
View it on GitLab: 
https://gitlab.torproject.org/tpo/applications/firefox-android/-/tree/fenix-v125.3.0
You're receiving this email because of your account on gitlab.torproject.org.


___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[clang] [compiler-rt] [llvm] [CMake] Use Clang to infer the target triple (PR #89425)

2024-06-25 Thread YunQiang Su via cfe-commits


@@ -368,14 +368,22 @@ macro(construct_compiler_rt_default_triple)
   "Default triple for which compiler-rt runtimes will be built.")
   endif()
 
-  if ("${CMAKE_C_COMPILER_ID}" MATCHES "Clang")
+  if(CMAKE_C_COMPILER_ID MATCHES "Clang")
 set(option_prefix "")
 if (CMAKE_C_SIMULATE_ID MATCHES "MSVC")
   set(option_prefix "/clang:")
 endif()
-execute_process(COMMAND ${CMAKE_C_COMPILER} 
${option_prefix}--target=${COMPILER_RT_DEFAULT_TARGET_TRIPLE} 
${option_prefix}-print-target-triple
-OUTPUT_VARIABLE COMPILER_RT_DEFAULT_TARGET_TRIPLE
-OUTPUT_STRIP_TRAILING_WHITESPACE)
+set(print_target_triple ${CMAKE_C_COMPILER} 
${option_prefix}--target=${COMPILER_RT_DEFAULT_TARGET_TRIPLE} 
${option_prefix}-print-target-triple)
+execute_process(COMMAND ${print_target_triple}
+  RESULT_VARIABLE result
+  OUTPUT_VARIABLE output
+  OUTPUT_STRIP_TRAILING_WHITESPACE)
+if(result EQUAL 0)
+  set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${output})
+else()
+  string(REPLACE ";" " " print_target_triple "${print_target_triple}")
+  message(WARNING "Failed to execute `${print_target_triple}` to normalize 
target triple.")

wzssyqa wrote:

I think that it should be a fetal error instead of just a warning?

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


[clang] [compiler-rt] [llvm] [CMake] Use Clang to infer the target triple (PR #89425)

2024-06-25 Thread YunQiang Su via cfe-commits


@@ -183,6 +183,24 @@ message(STATUS "LLVM default target triple: 
${LLVM_DEFAULT_TARGET_TRIPLE}")
 
 set(LLVM_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")
 
+if(CMAKE_C_COMPILER_ID MATCHES "Clang")
+  set(option_prefix "")
+  if (CMAKE_C_SIMULATE_ID MATCHES "MSVC")
+set(option_prefix "/clang:")
+  endif()
+  set(print_target_triple ${CMAKE_C_COMPILER} 
${option_prefix}--target=${LLVM_DEFAULT_TARGET_TRIPLE} 
${option_prefix}-print-target-triple)
+  execute_process(COMMAND ${print_target_triple}
+RESULT_VARIABLE result
+OUTPUT_VARIABLE output
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+  if(result EQUAL 0)
+set(LLVM_DEFAULT_TARGET_TRIPLE ${output})
+  else()
+string(REPLACE ";" " " print_target_triple "${print_target_triple}")

wzssyqa wrote:

Ditto.  I guess that we need to test on more target. As some target doesn't use 
the new filesystem struct.

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


[clang] [clang] Emit bad shift warnings (PR #70307)

2024-06-25 Thread Budimir Aranđelović via cfe-commits
n is not an integer constant 
expression; folding it to a constant is a GNU extension}}
+ // cpp-error@-1 {{expression is not an integral constant 
expression}}
+ // expected-note@-2 {{left shift of negative value -1}}
+};
diff --git a/clang/test/Sema/vla-2.c b/clang/test/Sema/vla-2.c
index 316931f270607..577407e15b479 100644
--- a/clang/test/Sema/vla-2.c
+++ b/clang/test/Sema/vla-2.c
@@ -4,11 +4,13 @@
 // a different codepath when we have already emitted an error.)
 
 int PotentiallyEvaluatedSizeofWarn(int n) {
-  return (int)sizeof *(0 << 32,(int(*)[n])0); // expected-warning {{left 
operand of comma operator has no effect}} expected-warning {{shift count >= 
width of type}}
+  return (int)sizeof *(0 << 32,(int(*)[n])0); /* expected-warning {{shift 
count >= width of type}}
+ expected-warning {{left 
operand of comma operator has no effect}} */
 }
 
 void PotentiallyEvaluatedTypeofWarn(int n) {
-  __typeof(*(0 << 32,(int(*)[n])0)) x; // expected-warning {{left operand of 
comma operator has no effect}} expected-warning {{shift count >= width of type}}
+  __typeof(*(0 << 32,(int(*)[n])0)) x; /* expected-warning {{shift count >= 
width of type}}
+  expected-warning {{left operand of 
comma operator has no effect}} */
   (void)x;
 }
 
diff --git a/clang/test/SemaCXX/enum.cpp b/clang/test/SemaCXX/enum.cpp
index c482b3c571ab4..7d4a05083b9cd 100644
--- a/clang/test/SemaCXX/enum.cpp
+++ b/clang/test/SemaCXX/enum.cpp
@@ -100,10 +100,12 @@ void PR8089() {
 // expressions with UB to be non-constant.
 enum { overflow = 123456 * 234567 };
 #if __cplusplus >= 201103L
-// expected-warning@-2 {{not an integral constant expression}}
-// expected-note@-3 {{value 28958703552 is outside the range of representable 
values}}
-#else 
-// expected-warning@-5 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
+// expected-warning@-2 {{expression is not an integral constant expression; 
folding it to a constant is a GNU extension}}
+// expected-note@-3 {{value 28958703552 is outside the range of representable 
values of type 'int'}}
+#else
+// expected-error@-5 {{expression is not an integral constant expression}}
+// expected-note@-6 {{value 28958703552 is outside the range of representable 
values of type 'int'}}
+// expected-warning@-7 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
 #endif
 
 // FIXME: This is not consistent with the above case.
@@ -112,8 +114,10 @@ enum NoFold : int { overflow2 = 123456 * 234567 };
 // expected-error@-2 {{enumerator value is not a constant expression}}
 // expected-note@-3 {{value 28958703552 is outside the range of representable 
values}}
 #else
-// expected-warning@-5 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
-// expected-warning@-6 {{extension}}
+// expected-warning@-5 {{enumeration types with a fixed underlying type are a 
C++11 extension}}
+// expected-warning@-6 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
+// expected-error@-7 {{expression is not an integral constant expression}}
+// expected-note@-8 {{value 28958703552 is outside the range of representable 
values of type 'int'}}
 #endif
 
 // PR28903
diff --git a/clang/test/SemaCXX/shift.cpp b/clang/test/SemaCXX/shift.cpp
index 89a98791d3eba..6367e6d2f250b 100644
--- a/clang/test/SemaCXX/shift.cpp
+++ b/clang/test/SemaCXX/shift.cpp
@@ -22,7 +22,7 @@ void test() {
   c = 1 << -1; // expected-warning {{shift count is negative}}
   c = 1 >> -1; // expected-warning {{shift count is negative}}
   c = 1 << (unsigned)-1; // expected-warning {{shift count >= width of type}}
-     // expected-warning@-1 {{implicit conversion}}
+ // expected-warning@-1 {{implicit conversion from 
'int' to 'char' changes value from -2147483648 to 0}}
   c = 1 >> (unsigned)-1; // expected-warning {{shift count >= width of type}}
   c = 1 << c;
   c <<= 0;

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Emit bad shift warnings (PR #70307)

2024-06-25 Thread Budimir Aranđelović via cfe-commits
 GNU extension}}
+ // cpp-error@-1 {{expression is not an integral constant 
expression}}
+ // expected-note@-2 {{left shift of negative value -1}}
+};
diff --git a/clang/test/Sema/vla-2.c b/clang/test/Sema/vla-2.c
index 316931f270607..577407e15b479 100644
--- a/clang/test/Sema/vla-2.c
+++ b/clang/test/Sema/vla-2.c
@@ -4,11 +4,13 @@
 // a different codepath when we have already emitted an error.)
 
 int PotentiallyEvaluatedSizeofWarn(int n) {
-  return (int)sizeof *(0 << 32,(int(*)[n])0); // expected-warning {{left 
operand of comma operator has no effect}} expected-warning {{shift count >= 
width of type}}
+  return (int)sizeof *(0 << 32,(int(*)[n])0); /* expected-warning {{shift 
count >= width of type}}
+ expected-warning {{left 
operand of comma operator has no effect}} */
 }
 
 void PotentiallyEvaluatedTypeofWarn(int n) {
-  __typeof(*(0 << 32,(int(*)[n])0)) x; // expected-warning {{left operand of 
comma operator has no effect}} expected-warning {{shift count >= width of type}}
+  __typeof(*(0 << 32,(int(*)[n])0)) x; /* expected-warning {{shift count >= 
width of type}}
+  expected-warning {{left operand of 
comma operator has no effect}} */
   (void)x;
 }
 
diff --git a/clang/test/SemaCXX/enum.cpp b/clang/test/SemaCXX/enum.cpp
index c482b3c571ab4..7d4a05083b9cd 100644
--- a/clang/test/SemaCXX/enum.cpp
+++ b/clang/test/SemaCXX/enum.cpp
@@ -100,10 +100,12 @@ void PR8089() {
 // expressions with UB to be non-constant.
 enum { overflow = 123456 * 234567 };
 #if __cplusplus >= 201103L
-// expected-warning@-2 {{not an integral constant expression}}
-// expected-note@-3 {{value 28958703552 is outside the range of representable 
values}}
-#else 
-// expected-warning@-5 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
+// expected-warning@-2 {{expression is not an integral constant expression; 
folding it to a constant is a GNU extension}}
+// expected-note@-3 {{value 28958703552 is outside the range of representable 
values of type 'int'}}
+#else
+// expected-error@-5 {{expression is not an integral constant expression}}
+// expected-note@-6 {{value 28958703552 is outside the range of representable 
values of type 'int'}}
+// expected-warning@-7 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
 #endif
 
 // FIXME: This is not consistent with the above case.
@@ -112,8 +114,10 @@ enum NoFold : int { overflow2 = 123456 * 234567 };
 // expected-error@-2 {{enumerator value is not a constant expression}}
 // expected-note@-3 {{value 28958703552 is outside the range of representable 
values}}
 #else
-// expected-warning@-5 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
-// expected-warning@-6 {{extension}}
+// expected-warning@-5 {{enumeration types with a fixed underlying type are a 
C++11 extension}}
+// expected-warning@-6 {{overflow in expression; result is -1'106'067'520 with 
type 'int'}}
+// expected-error@-7 {{expression is not an integral constant expression}}
+// expected-note@-8 {{value 28958703552 is outside the range of representable 
values of type 'int'}}
 #endif
 
 // PR28903
diff --git a/clang/test/SemaCXX/shift.cpp b/clang/test/SemaCXX/shift.cpp
index 89a98791d3eba..6367e6d2f250b 100644
--- a/clang/test/SemaCXX/shift.cpp
+++ b/clang/test/SemaCXX/shift.cpp
@@ -22,7 +22,7 @@ void test() {
   c = 1 << -1; // expected-warning {{shift count is negative}}
   c = 1 >> -1; // expected-warning {{shift count is negative}}
   c = 1 << (unsigned)-1; // expected-warning {{shift count >= width of type}}
-         // expected-warning@-1 {{implicit conversion}}
+ // expected-warning@-1 {{implicit conversion from 
'int' to 'char' changes value from -2147483648 to 0}}
   c = 1 >> (unsigned)-1; // expected-warning {{shift count >= width of type}}
   c = 1 << c;
   c <<= 0;

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][nullability] Improve modeling of `++`/`--` operators. (PR #96601)

2024-06-25 Thread Gábor Horváth via cfe-commits

https://github.com/Xazax-hun approved this pull request.


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


[clang] [Clang] Extend lifetime bound analysis to support assignments (PR #96475)

2024-06-25 Thread Gábor Horváth via cfe-commits

Xazax-hun wrote:

+1, I like Ilya's suggestion. 

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


[clang] f09b024 - [clang] Remove a stale FIXME

2024-06-25 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2024-06-25T11:45:25+02:00
New Revision: f09b02484b865e4e6e2243ee2ff59d70b60d28e4

URL: 
https://github.com/llvm/llvm-project/commit/f09b02484b865e4e6e2243ee2ff59d70b60d28e4
DIFF: 
https://github.com/llvm/llvm-project/commit/f09b02484b865e4e6e2243ee2ff59d70b60d28e4.diff

LOG: [clang] Remove a stale FIXME

This FIXME has already been addressed in #89358

Added: 


Modified: 
clang/lib/Sema/SemaTemplate.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index a032e3ec6f635..e36ee2d5a46cf 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -3170,10 +3170,6 @@ BuildDeductionGuideForTypeAlias(Sema ,
 Expr *RequiresClause = buildAssociatedConstraints(
 SemaRef, F, AliasTemplate, DeduceResults, IsDeducible);
 
-// FIXME: implement the is_deducible constraint per C++
-// [over.match.class.deduct]p3.3:
-//... and a constraint that is satisfied if and only if the arguments
-//of A are deducible (see below) from the return type.
 auto *FPrimeTemplateParamList = TemplateParameterList::Create(
 Context, AliasTemplate->getTemplateParameters()->getTemplateLoc(),
 AliasTemplate->getTemplateParameters()->getLAngleLoc(),



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm-branch-commits] [llvm] AMDGPU: Add a subtarget feature for fine-grained remote memory support (PR #96442)

2024-06-25 Thread Matt Arsenault via llvm-branch-commits


@@ -788,6 +788,14 @@ def FeatureFlatAtomicFaddF32Inst
   "Has flat_atomic_add_f32 instruction"
 >;
 
+def FeatureAgentScopeFineGrainedRemoteMemoryAtomics
+  : SubtargetFeature<"agent-scope-fine-grained-remote-memory-atomics",
+  "HasAgentScopeFineGrainedRemoteMemoryAtomics",
+  "true",
+  "Agent (device) scoped atomic operations not directly supported by "

arsenm wrote:

I dropped the last PCIe reference since XGMI should also work 

https://github.com/llvm/llvm-project/pull/96442
___________
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] [llvm] AMDGPU: Add subtarget feature for memory atomic fadd f64 (PR #96444)

2024-06-25 Thread Matt Arsenault via llvm-branch-commits
t
 
 let SubtargetPredicate = HasAtomicFMinFMaxF64GlobalInsts in {
   defm : SIBufferAtomicPat<"SIbuffer_atomic_fmin", f64, 
"BUFFER_ATOMIC_MIN_F64">;
diff --git a/llvm/lib/Target/AMDGPU/FLATInstructions.td 
b/llvm/lib/Target/AMDGPU/FLATInstructions.td
index 98054dde398b3..89946a4719557 100644
--- a/llvm/lib/Target/AMDGPU/FLATInstructions.td
+++ b/llvm/lib/Target/AMDGPU/FLATInstructions.td
@@ -772,10 +772,10 @@ defm GLOBAL_ATOMIC_MIN_F64 : 
FLAT_Global_Atomic_Pseudo<"global_atomic_min_f64",
 defm GLOBAL_ATOMIC_MAX_F64 : 
FLAT_Global_Atomic_Pseudo<"global_atomic_max_f64", VReg_64, f64>;
 }
 
-let SubtargetPredicate = HasBufferFlatGlobalAtomicsF64 in {
+let SubtargetPredicate = HasFlatBufferGlobalAtomicFaddF64Inst  in {
   defm FLAT_ATOMIC_ADD_F64   : FLAT_Atomic_Pseudo<"flat_atomic_add_f64", 
VReg_64, f64>;
   defm GLOBAL_ATOMIC_ADD_F64 : 
FLAT_Global_Atomic_Pseudo<"global_atomic_add_f64", VReg_64, f64>;
-} // End SubtargetPredicate = HasBufferFlatGlobalAtomicsF64
+} // End SubtargetPredicate = HasFlatBufferGlobalAtomicFaddF64Inst
 
 let SubtargetPredicate = HasAtomicFlatPkAdd16Insts in {
   defm FLAT_ATOMIC_PK_ADD_F16: 
FLAT_Atomic_Pseudo<"flat_atomic_pk_add_f16",  VGPR_32, v2f16>;
@@ -1654,7 +1654,7 @@ defm : FlatAtomicIntrPat <"FLAT_ATOMIC_MIN_F64", 
"int_amdgcn_flat_atomic_fmin",
 defm : FlatAtomicIntrPat <"FLAT_ATOMIC_MAX_F64", 
"int_amdgcn_flat_atomic_fmax", f64>;
 }
 
-let OtherPredicates = [HasBufferFlatGlobalAtomicsF64] in {
+let OtherPredicates = [HasFlatBufferGlobalAtomicFaddF64Inst] in {
 defm : GlobalFLATAtomicPats <"GLOBAL_ATOMIC_ADD_F64", 
"atomic_load_fadd_global", f64>;
 defm : GlobalFLATAtomicPatsWithAddrSpace<"GLOBAL_ATOMIC_ADD_F64", 
"int_amdgcn_flat_atomic_fadd", "global_addrspace", f64>;
 defm : GlobalFLATAtomicPatsWithAddrSpace<"GLOBAL_ATOMIC_ADD_F64", 
"int_amdgcn_global_atomic_fadd", "global_addrspace", f64>;
diff --git a/llvm/lib/Target/AMDGPU/GCNSubtarget.h 
b/llvm/lib/Target/AMDGPU/GCNSubtarget.h
index 674d84422538f..51e38cfcf73dc 100644
--- a/llvm/lib/Target/AMDGPU/GCNSubtarget.h
+++ b/llvm/lib/Target/AMDGPU/GCNSubtarget.h
@@ -174,6 +174,7 @@ class GCNSubtarget final : public AMDGPUGenSubtargetInfo,
   bool HasAtomicGlobalPkAddBF16Inst = false;
   bool HasAtomicBufferPkAddBF16Inst = false;
   bool HasFlatAtomicFaddF32Inst = false;
+  bool HasFlatBufferGlobalAtomicFaddF64Inst = false;
   bool HasDefaultComponentZero = false;
   bool HasAgentScopeFineGrainedRemoteMemoryAtomics = false;
   bool HasDefaultComponentBroadcast = false;
@@ -660,9 +661,6 @@ class GCNSubtarget final : public AMDGPUGenSubtargetInfo,
 return GFX10_BEncoding;
   }
 
-  // BUFFER/FLAT/GLOBAL_ATOMIC_ADD/MIN/MAX_F64
-  bool hasBufferFlatGlobalAtomicsF64() const { return hasGFX90AInsts(); }
-
   bool hasExportInsts() const {
 return !hasGFX940Insts();
   }
@@ -873,6 +871,12 @@ class GCNSubtarget final : public AMDGPUGenSubtargetInfo,
 
   bool hasFlatAtomicFaddF32Inst() const { return HasFlatAtomicFaddF32Inst; }
 
+  /// \return true if the target has flat, global, and buffer atomic fadd for
+  /// double.
+  bool hasFlatBufferGlobalAtomicFaddF64Inst() const {
+return HasFlatBufferGlobalAtomicFaddF64Inst;
+  }
+
   /// \return true if the target's flat, global, and buffer atomic fadd for
   /// float supports denormal handling.
   bool hasMemoryAtomicFaddF32DenormalSupport() const {
diff --git a/llvm/lib/Target/AMDGPU/SIISelLowering.cpp 
b/llvm/lib/Target/AMDGPU/SIISelLowering.cpp
index eec750e5b8251..6b5ba160d6402 100644
--- a/llvm/lib/Target/AMDGPU/SIISelLowering.cpp
+++ b/llvm/lib/Target/AMDGPU/SIISelLowering.cpp
@@ -16028,7 +16028,7 @@ 
SITargetLowering::shouldExpandAtomicRMWInIR(AtomicRMWInst *RMW) const {
   return AtomicExpansionKind::CmpXChg;
 
 // global and flat atomic fadd f64: gfx90a, gfx940.
-if (Subtarget->hasGFX90AInsts() && Ty->isDoubleTy())
+if (Subtarget->hasFlatBufferGlobalAtomicFaddF64Inst() && Ty->isDoubleTy())
   return ReportUnsafeHWInst(AtomicExpansionKind::None);
 
 if (AS != AMDGPUAS::FLAT_ADDRESS && Ty->isFloatTy()) {

___
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] [llvm] AMDGPU: Add subtarget feature for global atomic fadd denormal support (PR #96443)

2024-06-25 Thread Matt Arsenault via llvm-branch-commits

https://github.com/arsenm updated 
https://github.com/llvm/llvm-project/pull/96443

>From 975c64c4becd802f9d0038fa79f46e4e94623691 Mon Sep 17 00:00:00 2001
From: Matt Arsenault 
Date: Sun, 23 Jun 2024 16:44:08 +0200
Subject: [PATCH 1/2] AMDGPU: Add subtarget feature for global atomic fadd
 denormal support

Not sure what the behavior for gfx90a is. The SPG says it always flushes.
The instruction documentation says it does not.
---
 llvm/lib/Target/AMDGPU/AMDGPU.td  | 13 +++--
 llvm/lib/Target/AMDGPU/GCNSubtarget.h |  7 +++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/llvm/lib/Target/AMDGPU/AMDGPU.td b/llvm/lib/Target/AMDGPU/AMDGPU.td
index 4d2faacaa915b..9e8c36af97cf2 100644
--- a/llvm/lib/Target/AMDGPU/AMDGPU.td
+++ b/llvm/lib/Target/AMDGPU/AMDGPU.td
@@ -788,6 +788,13 @@ def FeatureFlatAtomicFaddF32Inst
   "Has flat_atomic_add_f32 instruction"
 >;
 
+def FeatureMemoryAtomicFaddF32DenormalSupport
+  : SubtargetFeature<"memory-atomic-fadd-f32-denormal-support",
+  "HasAtomicMemoryAtomicFaddF32DenormalSupport",
+  "true",
+  "global/flat/buffer atomic fadd for float supports denormal handling"
+>;
+
 def FeatureAgentScopeFineGrainedRemoteMemoryAtomics
   : SubtargetFeature<"agent-scope-fine-grained-remote-memory-atomics",
   "HasAgentScopeFineGrainedRemoteMemoryAtomics",
@@ -1427,7 +1434,8 @@ def FeatureISAVersion9_4_Common : FeatureSet<
FeatureKernargPreload,
FeatureAtomicFMinFMaxF64GlobalInsts,
FeatureAtomicFMinFMaxF64FlatInsts,
-   FeatureAgentScopeFineGrainedRemoteMemoryAtomics
+   FeatureAgentScopeFineGrainedRemoteMemoryAtomics,
+   FeatureMemoryAtomicFaddF32DenormalSupport
]>;
 
 def FeatureISAVersion9_4_0 : FeatureSet<
@@ -1630,7 +1638,8 @@ def FeatureISAVersion12 : FeatureSet<
FeatureVGPRSingleUseHintInsts,
FeatureScalarDwordx3Loads,
FeatureDPPSrc1SGPR,
-   FeatureMaxHardClauseLength32]>;
+   FeatureMaxHardClauseLength32,
+   FeatureMemoryAtomicFaddF32DenormalSupport]>;
 
 def FeatureISAVersion12_Generic: FeatureSet<
   !listconcat(FeatureISAVersion12.Features,
diff --git a/llvm/lib/Target/AMDGPU/GCNSubtarget.h 
b/llvm/lib/Target/AMDGPU/GCNSubtarget.h
index c40efbdcf7f0b..674d84422538f 100644
--- a/llvm/lib/Target/AMDGPU/GCNSubtarget.h
+++ b/llvm/lib/Target/AMDGPU/GCNSubtarget.h
@@ -167,6 +167,7 @@ class GCNSubtarget final : public AMDGPUGenSubtargetInfo,
   bool HasAtomicFlatPkAdd16Insts = false;
   bool HasAtomicFaddRtnInsts = false;
   bool HasAtomicFaddNoRtnInsts = false;
+  bool HasAtomicMemoryAtomicFaddF32DenormalSupport = false;
   bool HasAtomicBufferGlobalPkAddF16NoRtnInsts = false;
   bool HasAtomicBufferGlobalPkAddF16Insts = false;
   bool HasAtomicCSubNoRtnInsts = false;
@@ -872,6 +873,12 @@ class GCNSubtarget final : public AMDGPUGenSubtargetInfo,
 
   bool hasFlatAtomicFaddF32Inst() const { return HasFlatAtomicFaddF32Inst; }
 
+  /// \return true if the target's flat, global, and buffer atomic fadd for
+  /// float supports denormal handling.
+  bool hasMemoryAtomicFaddF32DenormalSupport() const {
+return HasAtomicMemoryAtomicFaddF32DenormalSupport;
+  }
+
   /// \return true if atomic operations targeting fine-grained memory work
   /// correctly at device scope, in allocations in host or peer PCIe device
   /// memory.

>From 3ec4e64a5cb5a3fe7904fa608c20a774bdc11b2b Mon Sep 17 00:00:00 2001
From: Matt Arsenault 
Date: Mon, 24 Jun 2024 12:10:37 +0200
Subject: [PATCH 2/2] Add to gfx11.

RDNA 3 manual says "Floating-point addition handles NAN/INF/denorm"
thought I'm not sure I trust it.
---
 llvm/lib/Target/AMDGPU/AMDGPU.td | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/Target/AMDGPU/AMDGPU.td b/llvm/lib/Target/AMDGPU/AMDGPU.td
index 9e8c36af97cf2..3d0d18e59a8c3 100644
--- a/llvm/lib/Target/AMDGPU/AMDGPU.td
+++ b/llvm/lib/Target/AMDGPU/AMDGPU.td
@@ -1547,7 +1547,8 @@ def FeatureISAVersion11_Common : FeatureSet<
FeatureFlatAtomicFaddF32Inst,
FeatureImageInsts,
FeaturePackedTID,
-   FeatureVcmpxPermlaneHazard]>;
+   FeatureVcmpxPermlaneHazard,
+   FeatureMemoryAtomicFaddF32DenormalSupport]>;
 
 // There are few workarounds that need to be
 // added to all targets. This pessimizes codegen

___
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] [llvm] AMDGPU: Add a subtarget feature for fine-grained remote memory support (PR #96442)

2024-06-25 Thread Matt Arsenault via llvm-branch-commits

https://github.com/arsenm updated 
https://github.com/llvm/llvm-project/pull/96442

>From 1a441c05eb510f3310604594b2687ddf90e884fe Mon Sep 17 00:00:00 2001
From: Matt Arsenault 
Date: Sun, 23 Jun 2024 22:02:36 +0200
Subject: [PATCH] AMDGPU: Add a subtarget feature for fine-grained remote
 memory support

Atomic access to fine-grained remote memory does not work on all
subtargets. Add a feature for targets where this is expected to work.
---
 llvm/lib/Target/AMDGPU/AMDGPU.td  | 16 ++--
 llvm/lib/Target/AMDGPU/GCNSubtarget.h |  8 
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/llvm/lib/Target/AMDGPU/AMDGPU.td b/llvm/lib/Target/AMDGPU/AMDGPU.td
index 5bc0fe8bba608..4d2faacaa915b 100644
--- a/llvm/lib/Target/AMDGPU/AMDGPU.td
+++ b/llvm/lib/Target/AMDGPU/AMDGPU.td
@@ -788,6 +788,16 @@ def FeatureFlatAtomicFaddF32Inst
   "Has flat_atomic_add_f32 instruction"
 >;
 
+def FeatureAgentScopeFineGrainedRemoteMemoryAtomics
+  : SubtargetFeature<"agent-scope-fine-grained-remote-memory-atomics",
+  "HasAgentScopeFineGrainedRemoteMemoryAtomics",
+  "true",
+  "Agent (device) scoped atomic operations, excluding those directly "
+  "supported by PCIe (i.e. integer atomic add, exchange, and "
+  "compare-and-swap), are functional for allocations in host or peer "
+  "device memory."
+>;
+
 def FeatureDefaultComponentZero : SubtargetFeature<"default-component-zero",
   "HasDefaultComponentZero",
   "true",
@@ -1207,7 +1217,8 @@ def FeatureGFX12 : GCNSubtargetFeatureGeneration<"GFX12",
FeatureUnalignedBufferAccess, FeatureUnalignedDSAccess,
FeatureTrue16BitInsts, FeatureDefaultComponentBroadcast,
FeatureMaxHardClauseLength32,
-   FeatureAtomicFMinFMaxF32GlobalInsts, FeatureAtomicFMinFMaxF32FlatInsts
+   FeatureAtomicFMinFMaxF32GlobalInsts, FeatureAtomicFMinFMaxF32FlatInsts,
+   FeatureAgentScopeFineGrainedRemoteMemoryAtomics
   ]
 >;
 
@@ -1415,7 +1426,8 @@ def FeatureISAVersion9_4_Common : FeatureSet<
FeatureBackOffBarrier,
FeatureKernargPreload,
FeatureAtomicFMinFMaxF64GlobalInsts,
-   FeatureAtomicFMinFMaxF64FlatInsts
+   FeatureAtomicFMinFMaxF64FlatInsts,
+   FeatureAgentScopeFineGrainedRemoteMemoryAtomics
]>;
 
 def FeatureISAVersion9_4_0 : FeatureSet<
diff --git a/llvm/lib/Target/AMDGPU/GCNSubtarget.h 
b/llvm/lib/Target/AMDGPU/GCNSubtarget.h
index 966708db4f37c..c40efbdcf7f0b 100644
--- a/llvm/lib/Target/AMDGPU/GCNSubtarget.h
+++ b/llvm/lib/Target/AMDGPU/GCNSubtarget.h
@@ -174,6 +174,7 @@ class GCNSubtarget final : public AMDGPUGenSubtargetInfo,
   bool HasAtomicBufferPkAddBF16Inst = false;
   bool HasFlatAtomicFaddF32Inst = false;
   bool HasDefaultComponentZero = false;
+  bool HasAgentScopeFineGrainedRemoteMemoryAtomics = false;
   bool HasDefaultComponentBroadcast = false;
   /// The maximum number of instructions that may be placed within an S_CLAUSE,
   /// which is one greater than the maximum argument to S_CLAUSE. A value of 0
@@ -871,6 +872,13 @@ class GCNSubtarget final : public AMDGPUGenSubtargetInfo,
 
   bool hasFlatAtomicFaddF32Inst() const { return HasFlatAtomicFaddF32Inst; }
 
+  /// \return true if atomic operations targeting fine-grained memory work
+  /// correctly at device scope, in allocations in host or peer PCIe device
+  /// memory.
+  bool supportsAgentScopeFineGrainedRemoteMemoryAtomics() const {
+return HasAgentScopeFineGrainedRemoteMemoryAtomics;
+  }
+
   bool hasDefaultComponentZero() const { return HasDefaultComponentZero; }
 
   bool hasDefaultComponentBroadcast() const {

_______
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[clang] [llvm] [AMDGPU] Extend readlane, writelane and readfirstlane intrinsic lowering for generic types (PR #89217)

2024-06-25 Thread Vikram Hegde via cfe-commits

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


[clang] [Clang] Remove preprocessor guards and global feature checks for NEON (PR #95224)

2024-06-25 Thread via cfe-commits
r ,
  Sema , VectorKind VecKind) {
-  bool IsTargetCUDAAndHostARM = false;
-  if (S.getLangOpts().CUDAIsDevice) {
-const TargetInfo *AuxTI = S.getASTContext().getAuxTargetInfo();
-IsTargetCUDAAndHostARM =
-AuxTI && (AuxTI->getTriple().isAArch64() || 
AuxTI->getTriple().isARM());
-  }
-
   // Target must have NEON (or MVE, whose vectors are similar enough
   // not to need a separate attribute)
-  if (!(S.Context.getTargetInfo().hasFeature("mve") ||
-IsTargetCUDAAndHostARM) &&
+  if (!S.Context.getTargetInfo().hasFeature("mve") &&
   VecKind == VectorKind::Neon &&
   S.Context.getTargetInfo().getTriple().isArmMClass()) {
 S.Diag(Attr.getLoc(), diag::err_attribute_unsupported_m_profile)
@@ -8095,8 +8087,7 @@ static void HandleNeonVectorTypeAttr(QualType , 
const ParsedAttr ,
 Attr.setInvalid();
 return;
   }
-  if (!(S.Context.getTargetInfo().hasFeature("mve") ||
-IsTargetCUDAAndHostARM) &&
+  if (!S.Context.getTargetInfo().hasFeature("mve") &&
   VecKind == VectorKind::NeonPoly &&
   S.Context.getTargetInfo().getTriple().isArmMClass()) {
 S.Diag(Attr.getLoc(), diag::err_attribute_unsupported_m_profile)

>From 24790e699b6d96471fc7a125571cb0461a31e515 Mon Sep 17 00:00:00 2001
From: Marian Lukac 
Date: Fri, 21 Jun 2024 14:36:14 +
Subject: [PATCH 6/6] Incorrectly removed IsTargetCUDA

---
 clang/lib/Sema/SemaType.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index a723938d65c61..a2d7dc9460853 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -8077,6 +8077,13 @@ static bool verifyValidIntegerConstantExpr(Sema , 
const ParsedAttr ,
 /// match one of the standard Neon vector types.
 static void HandleNeonVectorTypeAttr(QualType , const ParsedAttr ,
  Sema , VectorKind VecKind) {
+  bool IsTargetCUDAAndHostARM = false;
+  if (S.getLangOpts().CUDAIsDevice) {
+const TargetInfo *AuxTI = S.getASTContext().getAuxTargetInfo();
+IsTargetCUDAAndHostARM =
+AuxTI && (AuxTI->getTriple().isAArch64() || 
AuxTI->getTriple().isARM());
+  }
+
   // Target must have NEON (or MVE, whose vectors are similar enough
   // not to need a separate attribute)
   if (!S.Context.getTargetInfo().hasFeature("mve") &&

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [Clang][ARM][AArch64] Alway emit protection attributes for functions. (PR #82819)

2024-06-25 Thread Daniel Kiss via cfe-commits

DanielKristofKiss wrote:

> For return-address signing, each function can make its own choice about 
> whether to sign; the function that's doing the signing is the same function 
> that does the auth, so it doesn't directly impact any other function. For 
> branch target enforcement, though, everything needs to agree that branch 
> targets are supposed to be enforced, or else the process crashes. So there's 
> no point to modifying whether it's enabled for a single function.

You are right in case of user space application but in some other use cases it 
is desired to keep the function properties because the executable is loaded 
differently (higher EL's).



https://github.com/llvm/llvm-project/pull/82819
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[Lldb-commits] [lldb] [lldb/DWARF] Remove parsing recursion when searching for definition DIEs (PR #96484)

2024-06-25 Thread Pavel Labath via lldb-commits

https://github.com/labath closed https://github.com/llvm/llvm-project/pull/96484
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 8395f9c - [lldb/DWARF] Remove parsing recursion when searching for definition DIEs (#96484)

2024-06-25 Thread via lldb-commits
SymbolFile/DWARF/SymbolFileDWARFDwo.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
index 365cba6495982..4a8c532a0d2a5 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -125,9 +125,8 @@ UniqueDWARFASTTypeMap 
::GetUniqueDWARFASTTypeMap() {
   return GetBaseSymbolFile().GetUniqueDWARFASTTypeMap();
 }
 
-lldb::TypeSP
-SymbolFileDWARFDwo::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) 
{
-  return GetBaseSymbolFile().FindDefinitionTypeForDWARFDeclContext(die);
+DWARFDIE SymbolFileDWARFDwo::FindDefinitionDIE(const DWARFDIE ) {
+  return GetBaseSymbolFile().FindDefinitionDIE(die);
 }
 
 lldb::TypeSP SymbolFileDWARFDwo::FindCompleteObjCDefinitionTypeForDIE(

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
index 6b7f672aaa57a..3bd0a2d25a5a6 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
@@ -78,8 +78,7 @@ class SymbolFileDWARFDwo : public SymbolFileDWARF {
 
   UniqueDWARFASTTypeMap () override;
 
-  lldb::TypeSP
-  FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) override;
+  DWARFDIE FindDefinitionDIE(const DWARFDIE ) override;
 
   lldb::TypeSP
   FindCompleteObjCDefinitionTypeForDIE(const DWARFDIE ,



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/DWARF] Remove parsing recursion when searching for definition DIEs (PR #96484)

2024-06-25 Thread Pavel Labath via lldb-commits

labath wrote:

> > > This patch as-is is NFC?
> > 
> > 
> > NFC_**I**_, I would say :) I don't think this should change the behavior in 
> > any way, but it's pretty hard to guarantee that.
> 
> Sure enough - I take any claim as a statement of intent/belief, not of 
> something mathematically proved, etc.

True, but in case of this code, even believing you know what it does may be a 
tough ask. :D

> Perhaps a separate commit could add another RUN line to the existing test you 
> added to demonstrate the reason for the revert? Rather than worrying about 
> which comes first (the type unit patch or the delay patch)
> 
> But in any case, I /think/ I understand why this patch doesn't need a test 
> (because this patch avoids the delay patch causing a crash (yeah, more 
> complex than that because the patch doesn't apply cleanly over this one) and 
> that crash already has a test committed) - thanks for the explanation.

Correct. The reason for revert has already been established with the first 
test. I'll create a separate patch for the type unit bug, but it will be 
slightly more complicated than adding a RUN line, because, due to the bug, the 
lldb will print the wrong type.

https://github.com/llvm/llvm-project/pull/96484
_______
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[llvm-branch-commits] [tsan] Lock/Unlock allocator and stacks on fork (PR #96600)

2024-06-25 Thread Dmitry Vyukov via llvm-branch-commits

https://github.com/dvyukov approved this pull request.

Note that tsan simply disables itself after multithreaded fork, so it produces 
false sense to operation with die_after_fork=0. And it still can deadlock on 
mutex/atomic operations and maybe more.

https://github.com/llvm/llvm-project/pull/96600
___
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] [tsan] Test `__tsan_test_only_on_fork` only on Mac (PR #96597)

2024-06-25 Thread Dmitry Vyukov via llvm-branch-commits

https://github.com/dvyukov approved this pull request.


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


[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

2024-06-25 Thread via cfe-commits
mentptr inbounds (%struct.S, ptr @arr, i64 1), i32 0, i32 
1), ptr noundef @.str.1)
+// CHECK: call void @_ZN1AC1EPKc(ptr {{[^,]*}} getelementptr inbounds (i8, ptr 
getelementptr inbounds (%struct.S, ptr @arr, i64 1), i64 4), ptr noundef 
@.str.1)
 // CHECK: store i32 2, ptr getelementptr inbounds (%struct.S, ptr @arr, i64 2)
-// CHECK: call void @_ZN1AC1EPKc(ptr {{[^,]*}} getelementptr inbounds 
(%struct.S, ptr getelementptr inbounds (%struct.S, ptr @arr, i64 2), i32 0, i32 
1), ptr noundef @.str.2)
+// CHECK: call void @_ZN1AC1EPKc(ptr {{[^,]*}} getelementptr inbounds (i8, ptr 
getelementptr inbounds (%struct.S, ptr @arr, i64 2), i64 4), ptr noundef 
@.str.2)
diff --git a/clang/test/CodeGenCXX/auto-var-init.cpp 
b/clang/test/CodeGenCXX/auto-var-init.cpp
index e1568bee136e5..b0fc4946040b7 100644
--- a/clang/test/CodeGenCXX/auto-var-init.cpp
+++ b/clang/test/CodeGenCXX/auto-var-init.cpp
@@ -1,9 +1,9 @@
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks %s 
-emit-llvm -o - | FileCheck %s -check-prefixes=CHECK,CHECK-O0
-// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks 
-ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s 
-check-prefixes=CHECK-O0,PATTERN,PATTERN-O0
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks 
-ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s 
-check-prefixes=CHECK-O0,PATTERN,PATTERN-O0,PATTERN-64-O0
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks 
-ftrivial-auto-var-init=pattern %s -O1 -emit-llvm -o - | FileCheck %s 
-check-prefixes=PATTERN,PATTERN-O1
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks 
-ftrivial-auto-var-init=zero %s -emit-llvm -o - | FileCheck %s 
-check-prefixes=CHECK-O0,ZERO,ZERO-O0
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks 
-ftrivial-auto-var-init=zero %s -O1 -emit-llvm -o - | FileCheck %s 
-check-prefixes=ZERO,ZERO-O1
-// RUN: %clang_cc1 -std=c++14 -triple i386-unknown-unknown -fblocks 
-ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s 
-check-prefixes=CHECK-O0,PATTERN,PATTERN-O0
+// RUN: %clang_cc1 -std=c++14 -triple i386-unknown-unknown -fblocks 
-ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s 
-check-prefixes=CHECK-O0,PATTERN,PATTERN-O0,PATTERN-32-O0
 
 #pragma clang diagnostic ignored "-Winaccessible-base"
 
@@ -174,14 +174,17 @@ struct semivolatileinit { int i = 0x; volatile 
int vi = 0x; };
 // PATTERN-O0: @__const.test_base_braces.braces = private unnamed_addr 
constant %struct.base { ptr inttoptr ([[IPTRT]] [[IPTR]] to ptr) }, align
 // PATTERN-O1-NOT: @__const.test_base_braces.braces
 struct base { virtual ~base(); };
-// PATTERN-O0: @__const.test_derived_uninit.uninit = private unnamed_addr 
constant %struct.derived { %struct.base { ptr inttoptr ([[IPTRT]] [[IPTR]] to 
ptr) } }, align
+// PATTERN-32-O0: @__const.test_derived_uninit.uninit = private unnamed_addr 
constant %struct.derived { [4 x i8] c"\FF\FF\FF\FF" }, align 4
+// PATTERN-64-O0: @__const.test_derived_uninit.uninit = private unnamed_addr 
constant %struct.derived { [8 x i8] c"\AA\AA\AA\AA\AA\AA\AA\AA" }, align 8
 // PATTERN-O1-NOT: @__const.test_derived_uninit.uninit
-// PATTERN-O0: @__const.test_derived_braces.braces = private unnamed_addr 
constant %struct.derived { %struct.base { ptr inttoptr ([[IPTRT]] [[IPTR]] to 
ptr) } }, align
+// PATTERN-32-O0: @__const.test_derived_braces.braces = private unnamed_addr 
constant %struct.derived { [4 x i8] c"\FF\FF\FF\FF" }, align 4
+// PATTERN-64-O0: @__const.test_derived_braces.braces = private unnamed_addr 
constant %struct.derived { [8 x i8] c"\AA\AA\AA\AA\AA\AA\AA\AA" }, align 8
 // PATTERN-O1-NOT: @__const.test_derived_braces.braces
 struct derived : public base {};
-// PATTERN-O0: @__const.test_virtualderived_uninit.uninit = private 
unnamed_addr constant %struct.virtualderived { %struct.base { ptr inttoptr 
([[IPTRT]] [[IPTR]] to ptr) }, %struct.derived { %struct.base { ptr inttoptr 
([[IPTRT]] [[IPTR]] to ptr) } } }, align
+// PATERN-O0: @__const.test_virtualderived_uninit.uninit = private 
unnamed_addr constant %struct.virtualderived { %struct.base { ptr inttoptr (i64 
-6148914691236517206 to ptr) }, [8 x i8] c"\AA\AA\AA\AA\AA\AA\AA\AA" }, align 8
 // PATTERN-O1-NOT: @__const.test_virtualderived_uninit.uninit
-// PATTERN-O0: @__const.test_virtualderived_braces.braces = private unnam...
[truncated]

``




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


[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

2024-06-25 Thread Michael Buch via cfe-commits

https://github.com/Michael137 ready_for_review 
https://github.com/llvm/llvm-project/pull/96422
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

2024-06-25 Thread Michael Buch via cfe-commits

Michael137 wrote:

> (Please move out of "draft" when you think this is ready.)

Updated the PR with some more context. There's still a few instances of 
`FieldDecl::isZeroSize`/`CXXRecordDecl::isEmpty` around `CodeGen` (see 
`CGClass`, `CGExprConstant`), but it wasn't obvious to me whether those needed 
replacing as well. Particularly `ConstStructBuilder::Build` has 
`[[no_unique_address]]` specific logic.

https://github.com/llvm/llvm-project/pull/96422
_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[jenkinsci/gradle-plugin] 3a68e1: Bump com.github.spotbugs from 6.0.15 to 6.0.18

2024-06-25 Thread 'dependabot[bot]' via Jenkins Commits
  Branch: refs/heads/dependabot/gradle/com.github.spotbugs-6.0.18
  Home:   https://github.com/jenkinsci/gradle-plugin
  Commit: 3a68e1010d6041ff199bfa2eaba3968640af54ed
  
https://github.com/jenkinsci/gradle-plugin/commit/3a68e1010d6041ff199bfa2eaba3968640af54ed
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M build.gradle.kts

  Log Message:
  ---
  Bump com.github.spotbugs from 6.0.15 to 6.0.18

Bumps com.github.spotbugs from 6.0.15 to 6.0.18.

---
updated-dependencies:
- dependency-name: com.github.spotbugs
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] 



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/gradle-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/gradle-plugin/push/refs/heads/dependabot/gradle/com.github.spotbugs-6.0.18/c5accd-3a68e1%40github.com.


[jenkinsci/gradle-plugin] 6d5108: Update Jenkins min version and adapt build (#461)

2024-06-25 Thread 'Alexis Tual' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/gradle-plugin
  Commit: 6d5108d271219b4f00f746889035213e2ebcb63c
  
https://github.com/jenkinsci/gradle-plugin/commit/6d5108d271219b4f00f746889035213e2ebcb63c
  Author: Alexis Tual 
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M acceptance-tests/build.gradle.kts
M 
acceptance-tests/src/test/java/hudson/plugins/gradle/MavenInjectionTest.java
M build.gradle.kts
M settings.gradle.kts
M src/test/groovy/hudson/plugins/gradle/BaseGradleIntegrationTest.groovy
M src/test/groovy/hudson/plugins/gradle/BuildScanIntegrationTest.groovy
M src/test/groovy/hudson/plugins/gradle/GradlePluginIntegrationTest.groovy
M 
src/test/groovy/hudson/plugins/gradle/injection/BuildScanInjectionGradleIntegrationTest.groovy
M src/test/groovy/hudson/plugins/gradle/injection/InjectionConfigTest.groovy

  Log Message:
  ---
  Update Jenkins min version and adapt build (#461)

* Update Jenkins versions and adapt JDK requirement

Latest Jenkins requires Java 17 or above.
Recently added plugin dependencies (jackson) require Jenkins 2.401.3
Jenkins 2.401.3 requires Java 11 or above.
Animal Sniffer is not needed with Java 11, replaced by compileJava 
`options.release = 11`.

* Remove `autoInjectionSkippedWhenOldMavenPlugin` test as it requires 
maven-plugin 3.14 which won't install on the current Jenkins version

* Try to kill Gradle daemons on Windows

* Try again to kill Gradle daemons on Windows

* Ignore CodeNarc warn



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/gradle-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/gradle-plugin/push/refs/heads/master/a52630-6d5108%40github.com.


[llvm-branch-commits] [sanitizer] Rename DEFINE_REAL_PTHREAD_FUNCTIONS (PR #96527)

2024-06-25 Thread Dmitry Vyukov via llvm-branch-commits

https://github.com/dvyukov approved this pull request.


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


[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

2024-06-25 Thread Michael Buch via cfe-commits

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


[jenkins-infra/jenkins-infra] 9ef0fd: Revert "feat(cijio_agents_1): Disabling kubernetes...

2024-06-25 Thread 'Jaideep' via Jenkins Commits
  Branch: refs/heads/production
  Home:   https://github.com/jenkins-infra/jenkins-infra
  Commit: 9ef0fdbab988516d45737dc72e1b7d3c488acc64
  
https://github.com/jenkins-infra/jenkins-infra/commit/9ef0fdbab988516d45737dc72e1b7d3c488acc64
  Author: Jaideep <79799016+jayfranco...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M hieradata/clients/controller.sponsorship.ci.jenkins.io.yaml

  Log Message:
  ---
  Revert "feat(cijio_agents_1): Disabling kubernetes for cluster cijio-agents1" 
(#3496)

This reverts commit 577f672ec544b43e87e59814569425517ae16db1.



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkins-infra/jenkins-infra/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkins-infra/jenkins-infra/push/refs/heads/production/577f67-9ef0fd%40github.com.


[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

2024-06-25 Thread Michael Buch via cfe-commits

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


[clang] [clang] Allow class with anonymous union member to be const-default-constructible even if a union member has a default member initializer (#95854) (PR #96301)

2024-06-25 Thread Rajveer Singh Bharadwaj via cfe-commits

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


[jenkinsci/gradle-plugin] a52630: Fix README regarding Build Scan publication (#462)

2024-06-25 Thread 'Alexis Tual' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/gradle-plugin
  Commit: a52630a49956931eb19242c2caf2ab8579d41dc5
  
https://github.com/jenkinsci/gradle-plugin/commit/a52630a49956931eb19242c2caf2ab8579d41dc5
  Author: Alexis Tual 
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M README.adoc

  Log Message:
  ---
  Fix README regarding Build Scan publication (#462)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/gradle-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/gradle-plugin/push/refs/heads/master/b6a94a-a52630%40github.com.


[clang] [compiler-rt] [llvm] [CMake] Use Clang to infer the target triple (PR #89425)

2024-06-25 Thread Petr Hosek via cfe-commits

petrhosek wrote:

> Does it really needed?

It is, #89234 only covers compiler-rt but not other runtime libraries such as 
libc or libc++ so you might end up with the following:

```
lib/19/clang/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a
lib/x86_64-linux-gnu/libc++.a
```

The driver will then fail to fine `libc++.a` leading to a link failure.

This change expand the normalization to cover all runtime libraries.

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


[clang] [compiler-rt] [llvm] [CMake] Use Clang to infer the target triple (PR #89425)

2024-06-25 Thread Petr Hosek via cfe-commits


@@ -28,6 +28,19 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
   if (NOT LLVM_RUNTIMES_BUILD)
 load_llvm_config()
   endif()
+  if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)

petrhosek wrote:

I have updated the block in `compiler-rt/cmake/Modules/CompilerRTUtils.cmake` 
and removed this version which is no longer needed.

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


[clang] [compiler-rt] [llvm] [CMake] Use Clang to infer the target triple (PR #89425)

2024-06-25 Thread Petr Hosek via cfe-commits


@@ -181,6 +181,20 @@ message(STATUS "LLVM default target triple: 
${LLVM_DEFAULT_TARGET_TRIPLE}")
 
 set(LLVM_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")
 
+if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
+  set(print_target_triple ${CMAKE_CXX_COMPILER} 
--target=${LLVM_RUNTIME_TRIPLE} -print-target-triple)
+  execute_process(COMMAND ${print_target_triple}
+RESULT_VARIABLE result
+OUTPUT_VARIABLE output
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+  if(result EQUAL 0)
+set(LLVM_RUNTIME_TRIPLE ${output})

petrhosek wrote:

Thanks for catching this, it was replaced by `LLVM_DEFAULT_TARGET_TRIPLE`.

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


[clang] [compiler-rt] [llvm] [CMake] Use Clang to infer the target triple (PR #89425)

2024-06-25 Thread Petr Hosek via cfe-commits
_SIMULATE_ID MATCHES "MSVC")
   set(option_prefix "/clang:")
 endif()
-execute_process(COMMAND ${CMAKE_C_COMPILER} 
${option_prefix}--target=${COMPILER_RT_DEFAULT_TARGET_TRIPLE} 
${option_prefix}-print-target-triple
-OUTPUT_VARIABLE COMPILER_RT_DEFAULT_TARGET_TRIPLE
-OUTPUT_STRIP_TRAILING_WHITESPACE)
+set(print_target_triple ${CMAKE_C_COMPILER} 
${option_prefix}--target=${COMPILER_RT_DEFAULT_TARGET_TRIPLE} 
${option_prefix}-print-target-triple)
+execute_process(COMMAND ${print_target_triple}
+  RESULT_VARIABLE result
+  OUTPUT_VARIABLE output
+  OUTPUT_STRIP_TRAILING_WHITESPACE)
+if(result EQUAL 0)
+  set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${output})
+else()
+  string(REPLACE ";" " " print_target_triple "${print_target_triple}")
+  message(WARNING "Failed to execute `${print_target_triple}` to normalize 
target triple.")
+endif()
   endif()
 
   string(REPLACE "-" ";" LLVM_TARGET_TRIPLE_LIST 
${COMPILER_RT_DEFAULT_TARGET_TRIPLE})
diff --git a/compiler-rt/lib/builtins/CMakeLists.txt 
b/compiler-rt/lib/builtins/CMakeLists.txt
index 53c2a3bfd2eb1..ba81c78f16608 100644
--- a/compiler-rt/lib/builtins/CMakeLists.txt
+++ b/compiler-rt/lib/builtins/CMakeLists.txt
@@ -28,19 +28,6 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
   if (NOT LLVM_RUNTIMES_BUILD)
 load_llvm_config()
   endif()
-  if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
-set(print_target_triple ${CMAKE_CXX_COMPILER} 
--target=${LLVM_RUNTIME_TRIPLE} -print-target-triple)
-execute_process(COMMAND ${print_target_triple}
-  RESULT_VARIABLE result
-  OUTPUT_VARIABLE output
-  OUTPUT_STRIP_TRAILING_WHITESPACE)
-if(result EQUAL 0)
-  set(LLVM_RUNTIME_TRIPLE ${output})
-else()
-  string(REPLACE ";" " " print_target_triple "${print_target_triple}")
-  message(WARNING "Failed to execute `${print_target_triple}` to normalize 
target triple.")
-endif()
-  endif()
   construct_compiler_rt_default_triple()
 
   include(SetPlatformToolchainTools)
diff --git a/runtimes/CMakeLists.txt b/runtimes/CMakeLists.txt
index c3646a18b6689..ca176dc88a6c9 100644
--- a/runtimes/CMakeLists.txt
+++ b/runtimes/CMakeLists.txt
@@ -183,14 +183,18 @@ message(STATUS "LLVM default target triple: 
${LLVM_DEFAULT_TARGET_TRIPLE}")
 
 set(LLVM_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")
 
-if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
-  set(print_target_triple ${CMAKE_CXX_COMPILER} 
--target=${LLVM_RUNTIME_TRIPLE} -print-target-triple)
+if(CMAKE_C_COMPILER_ID MATCHES "Clang")
+  set(option_prefix "")
+  if (CMAKE_C_SIMULATE_ID MATCHES "MSVC")
+set(option_prefix "/clang:")
+  endif()
+  set(print_target_triple ${CMAKE_C_COMPILER} 
${option_prefix}--target=${LLVM_DEFAULT_TARGET_TRIPLE} 
${option_prefix}-print-target-triple)
   execute_process(COMMAND ${print_target_triple}
 RESULT_VARIABLE result
 OUTPUT_VARIABLE output
     OUTPUT_STRIP_TRAILING_WHITESPACE)
   if(result EQUAL 0)
-set(LLVM_RUNTIME_TRIPLE ${output})
+set(LLVM_DEFAULT_TARGET_TRIPLE ${output})
   else()
 string(REPLACE ";" " " print_target_triple "${print_target_triple}")
 message(WARNING "Failed to execute `${print_target_triple}` to normalize 
target triple.")

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[jenkins-infra/jenkins-infra] 577f67: feat(cijio): Disabling kubernetes for cluster ciji...

2024-06-25 Thread 'Jaideep' via Jenkins Commits
  Branch: refs/heads/production
  Home:   https://github.com/jenkins-infra/jenkins-infra
  Commit: 577f672ec544b43e87e59814569425517ae16db1
  
https://github.com/jenkins-infra/jenkins-infra/commit/577f672ec544b43e87e59814569425517ae16db1
  Author: Jaideep <79799016+jayfranco...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M hieradata/clients/controller.sponsorship.ci.jenkins.io.yaml

  Log Message:
  ---
  feat(cijio): Disabling kubernetes for cluster cijio-agents1 (#3495)

Signed-off-by: jayfranco999 



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkins-infra/jenkins-infra/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkins-infra/jenkins-infra/push/refs/heads/production/8774c3-577f67%40github.com.


[jenkinsci/gradle-plugin] b6a94a: Enable Jenkins Security Scan (#460)

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/gradle-plugin
  Commit: b6a94adb18553051625988694f12ec4b866472f7
  
https://github.com/jenkinsci/gradle-plugin/commit/b6a94adb18553051625988694f12ec4b866472f7
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan (#460)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/gradle-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/gradle-plugin/push/refs/heads/master/57d769-b6a94a%40github.com.


[jenkinsci/ssh-agents-plugin]

2024-06-25 Thread 'dependabot[bot]' via Jenkins Commits
  Branch: 
refs/heads/dependabot/maven/io.jenkins.tools.bom-bom-2.426.x-3143.v347db_7c6db_6e
  Home:   https://github.com/jenkinsci/ssh-agents-plugin

To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/ssh-agents-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/ssh-agents-plugin/push/refs/heads/dependabot/maven/io.jenkins.tools.bom-bom-2.426.x-3143.v347db_7c6db_6e/70fe3e-00%40github.com.


[jenkinsci/ssh-agents-plugin] 01a561: chore(deps): bump io.jenkins.tools.bom:bom-2.426.x...

2024-06-25 Thread 'dependabot[bot]' via Jenkins Commits
  Branch: refs/heads/main
  Home:   https://github.com/jenkinsci/ssh-agents-plugin
  Commit: 01a561b6f66e3eb60a98d4752b322af4d805536c
  
https://github.com/jenkinsci/ssh-agents-plugin/commit/01a561b6f66e3eb60a98d4752b322af4d805536c
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M pom.xml

  Log Message:
  ---
  chore(deps): bump io.jenkins.tools.bom:bom-2.426.x (#493)

Bumps [io.jenkins.tools.bom:bom-2.426.x](https://github.com/jenkinsci/bom) from 
3135.v6d6c1f6b_3572 to 3143.v347db_7c6db_6e.
- [Release notes](https://github.com/jenkinsci/bom/releases)
- [Commits](https://github.com/jenkinsci/bom/commits)

---
updated-dependencies:
- dependency-name: io.jenkins.tools.bom:bom-2.426.x
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] 
Co-authored-by: dependabot[bot] 
<49699333+dependabot[bot]@users.noreply.github.com>



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/ssh-agents-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/ssh-agents-plugin/push/refs/heads/main/0fa8c0-01a561%40github.com.


[jenkinsci/trilead-api-plugin] ed144c: chore(deps): bump io.jenkins.tools.bom:bom-2.426.x...

2024-06-25 Thread 'dependabot[bot]' via Jenkins Commits
  Branch: refs/heads/main
  Home:   https://github.com/jenkinsci/trilead-api-plugin
  Commit: ed144c243dedc0405daa9e4fa58949a42154aa2c
  
https://github.com/jenkinsci/trilead-api-plugin/commit/ed144c243dedc0405daa9e4fa58949a42154aa2c
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M pom.xml

  Log Message:
  ---
  chore(deps): bump io.jenkins.tools.bom:bom-2.426.x (#156)

Bumps [io.jenkins.tools.bom:bom-2.426.x](https://github.com/jenkinsci/bom) from 
3135.v6d6c1f6b_3572 to 3143.v347db_7c6db_6e.
- [Release notes](https://github.com/jenkinsci/bom/releases)
- [Commits](https://github.com/jenkinsci/bom/commits)

---
updated-dependencies:
- dependency-name: io.jenkins.tools.bom:bom-2.426.x
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] 
Co-authored-by: dependabot[bot] 
<49699333+dependabot[bot]@users.noreply.github.com>



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/trilead-api-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/trilead-api-plugin/push/refs/heads/main/ac53f8-ed144c%40github.com.


[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

2024-06-25 Thread Pavel Labath via lldb-commits

labath wrote:

I've been trying to stay out of this, as I don't think I can be objective here, 
but since I've been summoned, here's what I think. :)

For me, the worst possible outcome of this is an incomplete transition -- 
having a third (maybe fourth, since I sort of also count dwim-print) 
expression-like syntax, which is "almost" complete, but for whatever reason 
(technical or political) can't replace the previous one. With that in mind, I'd 
try to stage this in a way that minimizes this risk. Building the whole thing 
in layers from the bottom up is not the best way to achieve that, I think.

If I were doing this, I'd prioritise replacing the current "frame var" 
implementation as soon as possible. Ideally, the steps would be something like:
1. implement the minimal necessary functionality to match current "frame var" 
feature set. (I think that's `&`, `[]`, `*` and `->`)
2. flip the switch
3. remove the old implementation
4. add other features, one group of related operators at a time

Besides managing that risk (if this fades out for whatever reason, there's less 
dead code around), I think this would also make it easier to review, as we 
could have patches like "add operator/ to the DIL", which would focus solely on 
that, and also come with associated tests. I think it would also make it easier 
to discuss things like whether we want to add modifying operations (operator++) 
or obviously language-specific features (dynamic_cast), both of which I think 
are very good questions.

https://github.com/llvm/llvm-project/pull/95738
___________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[jenkinsci/naginator-plugin] 0ca8fd: Suppress false positives

2024-06-25 Thread 'Steve Hill' via Jenkins Commits
  Branch: refs/heads/bugfix/warnings
  Home:   https://github.com/jenkinsci/naginator-plugin
  Commit: 0ca8fd925a650d8b20f07d9842904c91e03978df
  
https://github.com/jenkinsci/naginator-plugin/commit/0ca8fd925a650d8b20f07d9842904c91e03978df
  Author: Steve Hill 
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M src/main/java/com/chikli/hudson/plugin/naginator/NaginatorPublisher.java

  Log Message:
  ---
  Suppress false positives


  Commit: 973b48c5c2f3ac9918c7fac76d382689986ef069
  
https://github.com/jenkinsci/naginator-plugin/commit/973b48c5c2f3ac9918c7fac76d382689986ef069
  Author: Steve Hill 
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M src/main/java/com/chikli/hudson/plugin/naginator/NaginatorRetryAction.java

  Log Message:
  ---
  RequirePOST for retrying build


Compare: 
https://github.com/jenkinsci/naginator-plugin/compare/0ca8fd925a65%5E...973b48c5c2f3

To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/naginator-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/naginator-plugin/push/refs/heads/bugfix/warnings/00-973b48%40github.com.


[clang] [clang] Allow class with anonymous union member to be const-default-constructible even if a union member has a default member initializer (#95854) (PR #96301)

2024-06-25 Thread Rajveer Singh Bharadwaj via cfe-commits


@@ -1392,7 +1392,8 @@ class CXXRecordDecl : public RecordDecl {
   bool allowConstDefaultInit() const {
 return !data().HasUninitializedFields ||
!(data().HasDefaultedDefaultConstructor ||
- needsImplicitDefaultConstructor());
+ needsImplicitDefaultConstructor()) ||
+   hasInClassInitializer();

Rajveer100 wrote:

@zygoloid 
Is there an existing method for checking nested structures for cases like you 
mentioned above?

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


[clang] 8153773 - [clang][Interp] Fix returning primitive non-blockpointers

2024-06-25 Thread Timm Bäder via cfe-commits

Author: Timm Bäder
Date: 2024-06-25T09:09:49+02:00
New Revision: 8153773b23032177546944ec2524dce131b8a46e

URL: 
https://github.com/llvm/llvm-project/commit/8153773b23032177546944ec2524dce131b8a46e
DIFF: 
https://github.com/llvm/llvm-project/commit/8153773b23032177546944ec2524dce131b8a46e.diff

LOG: [clang][Interp] Fix returning primitive non-blockpointers

We can't deref() them, so return false here.

Added: 


Modified: 
clang/lib/AST/Interp/Pointer.cpp
clang/test/AST/Interp/literals.cpp

Removed: 




diff  --git a/clang/lib/AST/Interp/Pointer.cpp 
b/clang/lib/AST/Interp/Pointer.cpp
index d77cd8943c496..4070d0c54225d 100644
--- a/clang/lib/AST/Interp/Pointer.cpp
+++ b/clang/lib/AST/Interp/Pointer.cpp
@@ -347,7 +347,7 @@ std::optional Pointer::toRValue(const Context 
) const {
   Ty = AT->getValueType();
 
 // Invalid pointers.
-if (Ptr.isDummy() || !Ptr.isLive() ||
+if (Ptr.isDummy() || !Ptr.isLive() || !Ptr.isBlockPointer() ||
 (!Ptr.isUnknownSizeArray() && Ptr.isOnePastEnd()))
   return false;
 

diff  --git a/clang/test/AST/Interp/literals.cpp 
b/clang/test/AST/Interp/literals.cpp
index 5a29013a053a2..ef98b4947e64f 100644
--- a/clang/test/AST/Interp/literals.cpp
+++ b/clang/test/AST/Interp/literals.cpp
@@ -45,6 +45,8 @@ constexpr int Failed2 = Failed1 + 1; // both-error {{must be 
initialized by a co
 static_assert(Failed2 == 0, ""); // both-error {{not an integral constant 
expression}} \
  // both-note {{initializer of 'Failed2' is 
not a constant expression}}
 
+const int x = *(volatile int*)0x1234;
+
 namespace ScalarTypes {
   constexpr int ScalarInitInt = int();
   static_assert(ScalarInitInt == 0, "");



_______
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[jenkinsci/office-365-connector-plugin] c6e2c5: Enable Jenkins Security Scan (#352)

2024-06-25 Thread 'strangelookingnerd' via Jenkins Commits
  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/office-365-connector-plugin
  Commit: c6e2c58e8a404ee64b3baf99ce80c084cf813004
  
https://github.com/jenkinsci/office-365-connector-plugin/commit/c6e2c58e8a404ee64b3baf99ce80c084cf813004
  Author: strangelookingnerd 
<49242855+strangelookingn...@users.noreply.github.com>
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
A .github/workflows/jenkins-security-scan.yml

  Log Message:
  ---
  Enable Jenkins Security Scan (#352)



To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/office-365-connector-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/office-365-connector-plugin/push/refs/heads/master/4f7bee-c6e2c5%40github.com.


[clang] fa20184 - [C++20] [Modules] [Serialization] Don't reuse type ID and identifier ID from imported modules

2024-06-25 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-06-25T15:04:32+08:00
New Revision: fa20184a8f336e4154f2ffeeeb8a538dc9462d9a

URL: 
https://github.com/llvm/llvm-project/commit/fa20184a8f336e4154f2ffeeeb8a538dc9462d9a
DIFF: 
https://github.com/llvm/llvm-project/commit/fa20184a8f336e4154f2ffeeeb8a538dc9462d9a.diff

LOG: [C++20] [Modules] [Serialization] Don't reuse type ID and identifier ID 
from imported modules

To support no-transitive-change model for named modules, we can't reuse
type ID and identifier ID from imported modules arbitrarily. Since the
theory for no-transitive-change model is,
for a user of a named module, the user can only access the
indirectly imported decls via the directly imported module. So that it is
possible to control what matters to the users when writing the module.

And it will be unsafe to do so if the users can reuse the type IDs and
identifier IDs from the indirectly imported modules not via the directly
imported modules.

So in this patch, we don't reuse the type ID and identifier ID in the
AST writer to avoid the problematic case.

Added: 
clang/test/Modules/no-external-identifier-id.cppm
clang/test/Modules/no-external-type-id.cppm

Modified: 
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/lib/Serialization/ASTWriter.cpp 
b/clang/lib/Serialization/ASTWriter.cpp
index 5b39055cf9f27..9c55960b14cba 100644
--- a/clang/lib/Serialization/ASTWriter.cpp
+++ b/clang/lib/Serialization/ASTWriter.cpp
@@ -5355,6 +5355,20 @@ ASTFileSignature ASTWriter::WriteASTCore(Sema , 
StringRef isysroot,
 
   writeUnhashedControlBlock(PP, Context);
 
+  // Don't reuse type ID and Identifier ID from readers for C++ standard named
+  // modules since we want to support no-transitive-change model for named
+  // modules. The theory for no-transitive-change model is,
+  // for a user of a named module, the user can only access the indirectly
+  // imported decls via the directly imported module. So that it is possible to
+  // control what matters to the users when writing the module. It would be
+  // problematic if the users can reuse the type IDs and identifier IDs from
+  // indirectly imported modules arbitrarily. So we choose to clear these ID
+  // here.
+  if (isWritingStdCXXNamedModules()) {
+TypeIdxs.clear();
+IdentifierIDs.clear();
+  }
+
   // Look for any identifiers that were named while processing the
   // headers, but are otherwise not needed. We add these to the hash
   // table to enable checking of the predefines buffer in the case
@@ -6686,6 +6700,11 @@ void ASTWriter::ReaderInitialized(ASTReader *Reader) {
 }
 
 void ASTWriter::IdentifierRead(IdentifierID ID, IdentifierInfo *II) {
+  // Don't reuse Type ID from external modules for named modules. See the
+  // comments in WriteASTCore for details.
+  if (isWritingStdCXXNamedModules())
+return;
+
   IdentifierID  = IdentifierIDs[II];
   unsigned OriginalModuleFileIndex = StoredID >> 32;
 
@@ -6708,6 +6727,11 @@ void ASTWriter::MacroRead(serialization::MacroID ID, 
MacroInfo *MI) {
 }
 
 void ASTWriter::TypeRead(TypeIdx Idx, QualType T) {
+  // Don't reuse Type ID from external modules for named modules. See the
+  // comments in WriteASTCore for details.
+  if (isWritingStdCXXNamedModules())
+return;
+
   // Always take the type index that comes in later module files.
   // This copes with an interesting
   // case for chained AST writing where we schedule writing the type and then,

diff  --git a/clang/test/Modules/no-external-identifier-id.cppm 
b/clang/test/Modules/no-external-identifier-id.cppm
new file mode 100644
index 0..25825ef67ad91
--- /dev/null
+++ b/clang/test/Modules/no-external-identifier-id.cppm
@@ -0,0 +1,37 @@
+// Testing that we won't record the identifier ID from external modules.
+//
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/a.cppm -emit-module-interface -o %t/a.pcm
+// RUN: %clang_cc1 -std=c++20 %t/b.cppm -emit-module-interface -o %t/b.pcm \
+// RUN: -fmodule-file=a=%t/a.pcm
+// RUN: llvm-bcanalyzer --dump --disable-histogram %t/b.pcm | FileCheck 
%t/b.cppm
+//
+// RUN: %clang_cc1 -std=c++20 %t/a.v1.cppm -emit-module-interface -o 
%t/a.v1.pcm
+// RUN: %clang_cc1 -std=c++20 %t/b.cppm -emit-module-interface -o %t/b.v1.pcm \
+// RUN: -fmodule-file=a=%t/a.v1.pcm
+// RUN: 
diff  %t/b.pcm %t/b.v1.pcm &> /dev/null
+
+//--- a.cppm
+export module a;
+export inline int a() {
+int foo = 43;
+return foo;
+}
+
+//--- b.cppm
+export module b;
+import a;
+export inline int b() {
+int foo = 43;
+return foo;
+}
+
+// CHECK:  /dev/null
+
+//--- a.cppm
+export module a;
+export int a();
+
+//--- b.cppm
+export module b;
+import a;
+export int b();
+
+// CHECK: https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Add option to remove leading blank lines (PR #91221)

2024-06-25 Thread Vitaly Buka via cfe-commits

vitalybuka wrote:

@sstwcw Please don't ignore the presubmit, it detected issue before merging:

Some checks were not successful
2 skipped, 65 successful, 48 failing, and 3 pending checks

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


[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

2024-06-25 Thread Pavel Labath via lldb-commits

labath wrote:

Thanks for the explanation, Jason. I believe I understand the problem now. 
Here, we're concerned with whether the physical breakpoint opcode got executed, 
and not about the higher level machinery (conditional breakpoints, ignore 
count, ...), which builds on top of that and can cause a breakpoint hit to 
"disappear". Since StopInfo tracks the "logical" stop reason of the process 
(after all of these filters are applied), using it to track the "physical" one 
would be tricky at best.

> Looking at the total requirements, the rule can be condensed to: If this 
> thread stopped at a BreakpointSite which it did not execute, we should 
> execute the breakpoint on Resume. In any other case, a thread sitting at a 
> BreakpointSite should silently step past it and resume execution.

So, IIUC, there would just be one field (the "unexecuted breakpoint site") 
instead of two. I'll take that, I think having just one field to think about 
would make it easier to understand the overall logic.

https://github.com/llvm/llvm-project/pull/96260
___________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


  1   2   3   4   5   6   7   8   9   10   >