[clang] cd0d526 - [clang][dataflow] In `optional` model, match call return via hasType

[Yitzhak Mandelbaum via cfe-commits]

Author: Sam Estep
Date: 2022-06-10T14:52:05Z
New Revision: cd0d52610d80116324f19983320ec6db2048450f

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

LOG: [clang][dataflow] In `optional` model, match call return via hasType

Currently the unchecked-optional-access model fails on this example:

#include 
#include 

void foo() {
  std::unique_ptr> x;
  *x = std::nullopt;
}

You can verify the failure by saving the file as `foo.cpp` and running this 
command:

clang-tidy -checks='-*,bugprone-unchecked-optional-access' foo.cpp -- 
-std=c++17

The failing `assert` is in the `transferAssignment` function of the 
`UncheckedOptionalAccessModel.cpp` file:

assert(OptionalLoc != nullptr);

The symptom can be treated by replacing that `assert` with an early `return`:

if (OptionalLoc == nullptr)
  return;

That would be better anyway since we cannot expect to always cover all possible 
LHS expressions, but it is out of scope for this patch and left as a followup.

Note that the failure did not occur on this very similar example:

#include 

template 
struct smart_ptr {
  T& operator*() &;
  T* operator->();
};

void foo() {
  smart_ptr> x;
  *x = std::nullopt;
}

The difference is caused by the `isCallReturningOptional` matcher, which was 
previously checking the `functionDecl` of the `callee`. This patch changes it 
to instead use `hasType` directly on the call expression, fixing the failure 
for the `std::unique_ptr` example above.

Reviewed By: sgatev

Differential Revision: https://reviews.llvm.org/D127434

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

Removed: 




diff  --git 
a/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp 
b/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
index 00d22fbe8bb80..993d56e44a87d 100644
--- a/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -165,8 +165,8 @@ auto isValueOrNotEqX() {
 }
 
 auto isCallReturningOptional() {
-  return callExpr(callee(functionDecl(returns(anyOf(
-  optionalOrAliasType(), 
referenceType(pointee(optionalOrAliasType(;
+  return callExpr(hasType(qualType(anyOf(
+  optionalOrAliasType(), referenceType(pointee(optionalOrAliasType()));
 }
 
 /// Creates a symbolic value for an `optional` value using `HasValueVal` as the

diff  --git 
a/clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
index 72efc724776b3..3c37bec82139c 100644
--- 
a/clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
+++ 
b/clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
@@ -179,6 +179,11 @@ struct is_void : is_same::type> {};
 
 namespace detail {
 
+template 
+auto try_add_lvalue_reference(int) -> type_identity;
+template 
+auto try_add_lvalue_reference(...) -> type_identity;
+
 template 
 auto try_add_rvalue_reference(int) -> type_identity;
 template 
@@ -186,6 +191,10 @@ auto try_add_rvalue_reference(...) -> type_identity;
 
 }  // namespace detail
 
+template 
+struct add_lvalue_reference : decltype(detail::try_add_lvalue_reference(0)) 
{
+};
+
 template 
 struct add_rvalue_reference : decltype(detail::try_add_rvalue_reference(0)) 
{
 };
@@ -2318,6 +2327,26 @@ TEST_P(UncheckedOptionalAccessTest, 
OptionalValueInitialization) {
   UnorderedElementsAre(Pair("merge", "unsafe: input.cc:19:7")));
 }
 
+TEST_P(UncheckedOptionalAccessTest, AssignThroughLvalueReferencePtr) {
+  ExpectLatticeChecksFor(
+  R"(
+#include "unchecked_optional_access_test.h"
+
+template 
+struct smart_ptr {
+  typename std::add_lvalue_reference::type operator*() &;
+};
+
+void target() {
+  smart_ptr<$ns::$optional> x;
+  *x = $ns::nullopt;
+  (*x).value();
+  /*[[check]]*/
+}
+  )",
+  UnorderedElementsAre(Pair("check", "unsafe: input.cc:12:7")));
+}
+
 // FIXME: Add support for:
 // - constructors (copy, move)
 // - assignment operators (default, copy, move)



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

[PATCH] D127434: [clang][dataflow] In `optional` model, match call return via hasType

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcd0d52610d80: [clang][dataflow] In `optional` model, match 
call return via hasType (authored by samestep, committed by ymandel).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127434/new/

https://reviews.llvm.org/D127434

Files:
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
  clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp


Index: 
clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
@@ -179,6 +179,11 @@
 
 namespace detail {
 
+template 
+auto try_add_lvalue_reference(int) -> type_identity;
+template 
+auto try_add_lvalue_reference(...) -> type_identity;
+
 template 
 auto try_add_rvalue_reference(int) -> type_identity;
 template 
@@ -186,6 +191,10 @@
 
 }  // namespace detail
 
+template 
+struct add_lvalue_reference : decltype(detail::try_add_lvalue_reference(0)) 
{
+};
+
 template 
 struct add_rvalue_reference : decltype(detail::try_add_rvalue_reference(0)) 
{
 };
@@ -2318,6 +2327,26 @@
   UnorderedElementsAre(Pair("merge", "unsafe: input.cc:19:7")));
 }
 
+TEST_P(UncheckedOptionalAccessTest, AssignThroughLvalueReferencePtr) {
+  ExpectLatticeChecksFor(
+  R"(
+#include "unchecked_optional_access_test.h"
+
+template 
+struct smart_ptr {
+  typename std::add_lvalue_reference::type operator*() &;
+};
+
+void target() {
+  smart_ptr<$ns::$optional> x;
+  *x = $ns::nullopt;
+  (*x).value();
+  /*[[check]]*/
+}
+  )",
+  UnorderedElementsAre(Pair("check", "unsafe: input.cc:12:7")));
+}
+
 // FIXME: Add support for:
 // - constructors (copy, move)
 // - assignment operators (default, copy, move)
Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -165,8 +165,8 @@
 }
 
 auto isCallReturningOptional() {
-  return callExpr(callee(functionDecl(returns(anyOf(
-  optionalOrAliasType(), 
referenceType(pointee(optionalOrAliasType(;
+  return callExpr(hasType(qualType(anyOf(
+  optionalOrAliasType(), referenceType(pointee(optionalOrAliasType()));
 }
 
 /// Creates a symbolic value for an `optional` value using `HasValueVal` as the


Index: clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
@@ -179,6 +179,11 @@
 
 namespace detail {
 
+template 
+auto try_add_lvalue_reference(int) -> type_identity;
+template 
+auto try_add_lvalue_reference(...) -> type_identity;
+
 template 
 auto try_add_rvalue_reference(int) -> type_identity;
 template 
@@ -186,6 +191,10 @@
 
 }  // namespace detail
 
+template 
+struct add_lvalue_reference : decltype(detail::try_add_lvalue_reference(0)) {
+};
+
 template 
 struct add_rvalue_reference : decltype(detail::try_add_rvalue_reference(0)) {
 };
@@ -2318,6 +2327,26 @@
   UnorderedElementsAre(Pair("merge", "unsafe: input.cc:19:7")));
 }
 
+TEST_P(UncheckedOptionalAccessTest, AssignThroughLvalueReferencePtr) {
+  ExpectLatticeChecksFor(
+  R"(
+#include "unchecked_optional_access_test.h"
+
+template 
+struct smart_ptr {
+  typename std::add_lvalue_reference::type operator*() &;
+};
+
+void target() {
+  smart_ptr<$ns::$optional> x;
+  *x = $ns::nullopt;
+  (*x).value();
+  /*[[check]]*/
+}
+  )",
+  UnorderedElementsAre(Pair("check", "unsafe: input.cc:12:7")));
+}
+
 // FIXME: Add support for:
 // - constructors (copy, move)
 // - assignment operators (default, copy, move)
Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -165,8 +165,8 @@
 }
 
 auto isCallReturningOptional() {
-  return callExpr(callee(functionDecl(returns(anyOf(
-  optionalOrAliasType(), referenceType(pointee(optionalOrAliasType(;
+  return callExpr(hasType(qualType(anyOf(
+  optionalOrAliasType(), referenceType(pointee(optionalOrAliasType()));
 }
 
 /// Creates a symbolic value for an `optional` value using `HasValueVal` as the
___

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:352
+  [this](const Expr *AtomicExpr) -> ExprResult {
+// We only do this to immitate lvalue-to-rvalue conversion.
+return PerformContextuallyConvertToBool(const_cast(AtomicExpr));

erichkeane wrote:
> ilya-biryukov wrote:
> > erichkeane wrote:
> > > Can you explain this more?  How does this work, and why don't we do that 
> > > directly instead?
> > That's entangled with `calculateConstraintSatisfaction`. I actually tried 
> > to do it directly, but before passing expressions to this function 
> > `calculateConstraintSatisfaction` calls `IgnoreParenImpCasts()`, which 
> > strips away the lvalue-to-rvalue conversion.
> > And we need this conversion so that the evaluation that runs after this 
> > callback returns actually produces an r-value.
> > 
> > Note that the other call to `calculateConstraintSatisfaction` also calls 
> > `PerformContextuallyConvertToBool` after doing template substitution into 
> > the constraint expression.
> > 
> > I don't have full context on why it's the way it is, maybe there is a more 
> > fundamental change that helps with both cases.
> Hmm... my understanding is we DO need these to be a boolean expression 
> eventually, since we have to test them as a bool, so that is why the other 
> attempts the converesion.  If you think of any generalizations of this, it 
> would be appreciated, I'll think it through as well.
Note we already have a related bug about this 
https://github.com/llvm/llvm-project/issues/54524


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127487/new/

https://reviews.llvm.org/D127487

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

[PATCH] D125349: [Sema] Fix crash for C11 atomic in gnu++ mode

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Type.h:617
 
+struct QualifiersAndAtomic {
+  Qualifiers Quals;

The set of operations here feel a bit weird. We have `withVolatile` and 
`withAtomic` but not `withConst` or `withRestrict`. We have `hasVolatile` and 
`hasRestrict` but no `hasConst` or `hasAtomic`. And we have `addConst` but no 
other add methods for the other qualifiers.

Should these sets be rounded out to cover all the qualifiers? I know we don't 
need them for the functionality you're fixing up, but this seems like a pretty 
generic interface in a header file that's used all over the place.



Comment at: clang/lib/Sema/SemaOverload.cpp:8982
 
 // Extension: Add the binary operators =, +=, -=, *=, /= for vector types.
 for (QualType Vec1Ty : CandidateTypes[0].vector_types())

rjmccall wrote:
> jansvoboda11 wrote:
> > jansvoboda11 wrote:
> > > aaron.ballman wrote:
> > > > Do we need to handle atomic vector types?
> > > I tried those, but it appears vector types don't accept `_Atomic` element 
> > > types:
> > > 
> > > ```
> > > typedef _Atomic unsigned v_a_unsigned 
> > > __attribute__((__vector_size__(16)));
> > > // error: invalid vector element type '_Atomic(unsigned int)'
> > > ```
> > > 
> > > And `_Atomic` vector gives this error:
> > > 
> > > ```
> > > typedef unsigned v_unsigned __attribute__((__vector_size__(16)));
> > > typedef _Atomic v_unsigned a_v_unsigned;
> > > 
> > > a_v_unsigned avu;
> > > 
> > > void enum5() { avu += an_enum_value; }
> > > void enum6() { avu |= an_enum_value; }
> > > ```
> > > 
> > > I'm not an expert in this area, so I can't say for sure this is the 
> > > correct behavior. But at least we don't crash.
> > > And `_Atomic` vector gives this error:
> > 
> > ```
> > error: invalid operands to binary expression
> > ```
> The way to get an answer here, I think, is to see if it works with something 
> like a single scalar `int`.
> 
> Unfortunately, it probably does need to work (maybe conditionally), because 
> at least some of our supported vector types have an implicit "splat" 
> promotion from scalars, so you have the enum -> int -> splat conversion path. 
>  But we don't have to do that in this patch.
> But we don't have to do that in this patch.

+1, if it's involved, it can definitely be done in a follow-up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125349/new/

https://reviews.llvm.org/D125349

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

[PATCH] D127313: [libc++] Implement P0618R0 (Deprecating )

[Louis Dionne via Phabricator via cfe-commits]

ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

LGTM with changes applied and passing CI.




Comment at: libcxx/docs/ReleaseNotes.rst:149-152
+- The contents of , ``wstring_convert`` and ``wbuffer_convert`` 
have been marked as deprecated.
+  To disable deprecation warnings you have to define 
``_LIBCPP_DISABLE_DEPRECATION_WARNINGS``. Note that this
+  disables all deprecation warnings.
+

This should be under `API Changes`, not `ABI Changes`



Comment at: libcxx/include/codecvt:266-267
 unsigned long _Maxcode_;
+_LIBCPP_DIAGNOSTIC_PUSH
+_LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wdeprecated-declarations")
 codecvt_mode _Mode_;

Here and elsewhere, let's use `_LIBCPP_SUPPRESS_DEPRECATED_PUSH` and 
`_LIBCPP_SUPPRESS_DEPRECATED_POP` instead.



Comment at: libcxx/src/locale.cpp:1834-1835
 
+_LIBCPP_DIAGNOSTIC_PUSH
+_LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wdeprecated-declarations")
 static

`_LIBCPP_SUPPRESS_DEPRECATED_PUSH`



Comment at: 
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/depr.verify.cpp:8
 
//===--===//
 
+// UNSUPPORTED: c++03, c++11, c++14

I think you'll need to handle `no-localization` and `no-wide-characters` here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127313/new/

https://reviews.llvm.org/D127313

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

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

[Bardia Mahjour via Phabricator via cfe-commits]

bmahjour added inline comments.



Comment at: lld/test/ELF/lto/discard-value-names.ll:4
 
 ; RUN: ld.lld -shared -save-temps %t.o -o %t2.o
 ; RUN: llvm-dis < %t2.o.0.0.preopt.bc | FileCheck %s

I see `--plugin-opt=opaque-pointers` is being explicitly specified for some but 
not all tests. I suppose the reason you explicitly specify it is to make sure 
the tests pass even for builds where opaque pointers are disabled. If that's 
the case, why aren't you doing it consistently?



Comment at: llvm/test/Analysis/StackSafetyAnalysis/ipa.ll:86
 
-; RUN: llvm-lto2 run %t.summ0.bc %t.summ1.bc -o %t.lto -stack-safety-print 
-stack-safety-run -save-temps -thinlto-threads 1 -O0 \
+; RUN: llvm-lto2 run -opaque-pointers=0 %t.summ0.bc %t.summ1.bc -o %t.lto 
-stack-safety-print -stack-safety-run -save-temps -thinlto-threads 1 -O0 \
 ; RUN:  $(cat %t.res.txt) \

why does this test (and ipa-alias.ll above) need to run with opaque pointers 
off?



Comment at: llvm/test/LTO/Resolution/X86/alias-alias.ll:3
 ; RUN: llvm-as %p/Inputs/alias-alias-1.ll -o %t2.o
 ; RUN: llvm-lto2 run -o %t3.o %t1.o %t2.o -r %t2.o,a, -r %t2.o,d,px -r 
%t1.o,a,p -r %t1.o,c,p -r %t1.o,b -save-temps
 ; RUN: llvm-dis < %t3.o.0.0.preopt.bc -o - | FileCheck %s

Why do you pass `-lto-opaque-pointers` to llvm-lto2 in clang/tests but not here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125847/new/

https://reviews.llvm.org/D125847

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

[PATCH] D127502: [clang][dataflow] Don't `assert` full LHS coverage in `optional` model

[Sam Estep via Phabricator via cfe-commits]

samestep created this revision.
samestep added a reviewer: ymandel.
Herald added subscribers: tschuett, steakhal, xazax.hun.
Herald added a project: All.
samestep requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127502

Files:
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp


Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -450,7 +450,8 @@
 
   auto *OptionalLoc =
   State.Env.getStorageLocation(*E->getArg(0), SkipPast::Reference);
-  assert(OptionalLoc != nullptr);
+  if (OptionalLoc == nullptr)
+return;
 
   State.Env.setValue(*OptionalLoc, createOptionalValue(State.Env, 
HasValueVal));
 


Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -450,7 +450,8 @@
 
   auto *OptionalLoc =
   State.Env.getStorageLocation(*E->getArg(0), SkipPast::Reference);
-  assert(OptionalLoc != nullptr);
+  if (OptionalLoc == nullptr)
+return;
 
   State.Env.setValue(*OptionalLoc, createOptionalValue(State.Env, HasValueVal));
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126479: [Clang] Allow 'Complex float __attribute__((mode(HC)))'

[Jolanta Jensen via Phabricator via cfe-commits]

jolanta.jensen updated this revision to Diff 435922.
jolanta.jensen added a comment.

Removing the implicit dependency on the FloatModeKind enumerator values.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126479/new/

https://reviews.llvm.org/D126479

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/test/CodeGen/aarch64-attr-mode-complex.c
  clang/test/CodeGen/aarch64-attr-mode-float.c
  clang/test/Sema/attr-mode-vector-types.c
  clang/test/Sema/attr-mode.c

Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -37,6 +37,11 @@
 __attribute__((mode(QI))) int invalid_func(void) { return 1; } // expected-error{{'mode' attribute only applies to variables, enums, typedefs, and non-static data members}}
 enum invalid_enum { A1 __attribute__((mode(QI))) }; // expected-error{{'mode' attribute only applies to}}
 
+typedef _Complex float c16a __attribute((mode(HC)));
+int c16a_test[sizeof(c16a) == 4 ? 1 : -1];
+typedef _Complex double c16b __attribute((mode(HC)));
+int c16b_test[sizeof(c16b) == 4 ? 1 : -1];
+
 typedef _Complex double c32 __attribute((mode(SC)));
 int c32_test[sizeof(c32) == 8 ? 1 : -1];
 typedef _Complex float c64 __attribute((mode(DC)));
Index: clang/test/Sema/attr-mode-vector-types.c
===
--- clang/test/Sema/attr-mode-vector-types.c
+++ clang/test/Sema/attr-mode-vector-types.c
@@ -22,8 +22,7 @@
 // expected-error@-1{{unsupported machine mode 'QC'}}
 // expected-error@-2{{type of machine mode does not match type of base type}}
 typedef _Complex float __attribute__((mode(HC))) __attribute__((vector_size(256))) vec_t9;
-// expected-error@-1{{unsupported machine mode 'HC'}}
-// expected-error@-2{{invalid vector element type '_Complex float'}}
+// expected-error@-1{{invalid vector element type '_Complex float'}}
 typedef int __attribute__((mode(SC))) __attribute__((vector_size(256))) vec_t10;
 // expected-error@-1{{type of machine mode does not match type of base type}}
 // expected-error@-2{{type of machine mode does not support base vector types}}
Index: clang/test/CodeGen/aarch64-attr-mode-float.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-attr-mode-float.c
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -triple arm64-none-linux-gnu -emit-llvm %s -o - | FileCheck %s
+
+typedef float f16a __attribute((mode(HF)));
+typedef double f16b __attribute((mode(HF)));
+typedef float f32a __attribute((mode(SF)));
+typedef double f32b __attribute((mode(SF)));
+typedef float f64a __attribute((mode(DF)));
+typedef double f64b __attribute((mode(DF)));
+f16b tmp;
+
+// CHECK: define{{.*}} ptr @f16_test(ptr noundef {{.*}})
+// CHECK:   store half {{.*}}, ptr @tmp, align 2
+// CHECK:   ret ptr @tmp
+f16b *f16_test(f16a *x) {
+  tmp = *x + *x;
+  return &tmp;
+}
+
+// CHECK: define{{.*}} float @f32_test(float noundef {{.*}})
+// CHECK:   ret float {{.*}}
+f32b f32_test(f32a x) {
+  return x + x;
+}
+
+// CHECK: define{{.*}} double @f64_test(double noundef {{.*}})
+// CHECK:   ret double {{.*}}
+f64b f64_test(f64a x) {
+  return x + x;
+}
Index: clang/test/CodeGen/aarch64-attr-mode-complex.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-attr-mode-complex.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple arm64-none-linux-gnu -emit-llvm %s -o - | FileCheck %s
+
+typedef _Complex float c16a __attribute((mode(HC)));
+typedef _Complex double c16b __attribute((mode(HC)));
+typedef _Complex float c32a __attribute((mode(SC)));
+typedef _Complex double c32b __attribute((mode(SC)));
+typedef _Complex float c64a __attribute((mode(DC)));
+typedef _Complex double c64b __attribute((mode(DC)));
+
+// CHECK: define{{.*}} { half, half } @c16_test([2 x half] noundef {{.*}}
+// CHECK:   ret { half, half } {{.*}}
+c16b c16_test(c16a x) {
+  return x + x;
+}
+
+// CHECK: define{{.*}} { float, float } @c32_test([2 x float] noundef {{.*}})
+// CHECK:   ret { float, float } {{.*}}
+c32b c32_test(c32a x) {
+  return x + x;
+}
+
+// CHECK: define{{.*}} { double, double } @c64_test([2 x double] noundef {{.*}})
+// CHECK:   ret { double, double } {{.*}}
+c64b c64_test(c64a x) {
+  return x + x;
+}
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -284,6 +284,8 @@
 
 FloatModeKind TargetInfo::getRealTypeByWidth(unsigned BitWidth,
  FloatModeKind ExplicitType) const {
+  if (getHalfWidth() == BitWidth)
+return FloatModeKind::Half;
   if (getFloatWidth() == BitWidth)
 return FloatModeKind::Float;
   if (getDoubleWidth() == BitWidth)
Index: clang/lib/AST/ASTCo

[PATCH] D125349: [Sema] Fix crash for C11 atomic in gnu++ mode

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 435927.
jansvoboda11 added a comment.

Code review feedback


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125349/new/

https://reviews.llvm.org/D125349

Files:
  clang/include/clang/AST/Type.h
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/atomic-builtin-compound-assignment-overload.cpp
  clang/test/SemaCXX/atomic-builtin-compound-assignment-overload.cpp

Index: clang/test/SemaCXX/atomic-builtin-compound-assignment-overload.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/atomic-builtin-compound-assignment-overload.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -std=gnu++98 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+_Atomic unsigned an_atomic_uint;
+
+enum { an_enum_value = 1 };
+
+void enum1() { an_atomic_uint += an_enum_value; }
+
+void enum2() { an_atomic_uint |= an_enum_value; }
+
+volatile _Atomic unsigned an_volatile_atomic_uint;
+
+void enum3() { an_volatile_atomic_uint += an_enum_value; }
+
+void enum4() { an_volatile_atomic_uint |= an_enum_value; }
Index: clang/test/CodeGenCXX/atomic-builtin-compound-assignment-overload.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/atomic-builtin-compound-assignment-overload.cpp
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -std=gnu++11 -emit-llvm -triple=x86_64-linux-gnu -o - %s | FileCheck %s
+
+_Atomic unsigned an_atomic_uint;
+
+enum { an_enum_value = 1 };
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum1v()
+void enum1() {
+  an_atomic_uint += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum2v()
+void enum2() {
+  an_atomic_uint |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum3RU7_Atomicj({{.*}})
+void enum3(_Atomic unsigned &an_atomic_uint_param) {
+  an_atomic_uint_param += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum4RU7_Atomicj({{.*}})
+void enum4(_Atomic unsigned &an_atomic_uint_param) {
+  an_atomic_uint_param |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
+
+volatile _Atomic unsigned an_volatile_atomic_uint;
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum5v()
+void enum5() {
+  an_volatile_atomic_uint += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum6v()
+void enum6() {
+  an_volatile_atomic_uint |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum7RVU7_Atomicj({{.*}})
+void enum7(volatile _Atomic unsigned &an_volatile_atomic_uint_param) {
+  an_volatile_atomic_uint_param += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum8RVU7_Atomicj({{.*}})
+void enum8(volatile _Atomic unsigned &an_volatile_atomic_uint_param) {
+  an_volatile_atomic_uint_param |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -8191,6 +8191,39 @@
 return VRQuals;
 }
 
+// Note: We're currently only handling qualifiers that are meaningful for the
+// LHS of compound assignment overloading.
+static void forAllQualifierCombinationsImpl(
+QualifiersAndAtomic available, QualifiersAndAtomic applied,
+llvm::function_ref callback) {
+  // _Atomic
+  if (available.HasAtomic) {
+available.HasAtomic = false;
+forAllQualifierCombinationsImpl(available, applied.withAtomic(), callback);
+forAllQualifierCombinationsImpl(available, applied, callback);
+return;
+  }
+
+  // volatile
+  if (available.Quals.hasVolatile()) {
+available.Quals.removeVolatile();
+assert(!applied.Quals.hasVolatile());
+forAllQualifierCombinationsImpl(available, applied.withVolatile(),
+callback);
+forAllQualifierCombinationsImpl(available, applied, callback);
+return;
+  }
+
+  callback(applied);
+}
+
+static void forAllQualifierCombinations(
+QualifiersAndAtomic quals,
+llvm::function_ref callback) {
+  return forAllQualifierCombinationsImpl(quals, QualifiersAndAtomic(),
+ callback);
+}
+
 namespace {
 
 /// Helper class to manage the addition of builtin operator overload
@@ -8201,7 +8234,7 @@
   // Common instance state available to all overload candidate addition methods.
   Sema &S;
   ArrayRef Args;
-  Qualifiers VisibleTypeConversionsQuals;
+  QualifiersAndAtomic VisibleTypeConversionsQuals;
   bool HasArithmeticOrEnumeralCandidateType;
   SmallVectorImpl &CandidateTypes;
   OverloadCandidateSet &CandidateSet;
@@ -8325,7 +8358,7 @@
 public:
   BuiltinOperatorOverloadBuilder(
 Sema &S, ArrayRef Args,
-Qualifiers VisibleTypeConversionsQuals,
+QualifiersAndAtomic VisibleTypeConversionsQuals,
 bool 

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

[Matthias Braun via Phabricator via cfe-commits]

MatzeB added inline comments.



Comment at: lld/test/ELF/lto/discard-value-names.ll:4
 
 ; RUN: ld.lld -shared -save-temps %t.o -o %t2.o
 ; RUN: llvm-dis < %t2.o.0.0.preopt.bc | FileCheck %s

bmahjour wrote:
> I see `--plugin-opt=opaque-pointers` is being explicitly specified for some 
> but not all tests. I suppose the reason you explicitly specify it is to make 
> sure the tests pass even for builds where opaque pointers are disabled. If 
> that's the case, why aren't you doing it consistently?
It‘s not specified in any of the lld tests except the two tests for the option 
itself (because in lld lto its enabled by default now).

It is specified for clang (but not clang cc1) in a coupletests because the 
clang driver drfaults can currently be changed with a cmake flag.




Comment at: llvm/test/Analysis/StackSafetyAnalysis/ipa.ll:86
 
-; RUN: llvm-lto2 run %t.summ0.bc %t.summ1.bc -o %t.lto -stack-safety-print 
-stack-safety-run -save-temps -thinlto-threads 1 -O0 \
+; RUN: llvm-lto2 run -opaque-pointers=0 %t.summ0.bc %t.summ1.bc -o %t.lto 
-stack-safety-print -stack-safety-run -save-temps -thinlto-threads 1 -O0 \
 ; RUN:  $(cat %t.res.txt) \

bmahjour wrote:
> why does this test (and ipa-alias.ll above) need to run with opaque pointers 
> off?
I don‘t remember this test specifically but some were tricky to update, feel 
free to submit a patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125847/new/

https://reviews.llvm.org/D125847

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

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

[Matthias Braun via Phabricator via cfe-commits]

MatzeB added a comment.

@JakeEgan I did a quick look for the code in that stacktrace but nothing jumped 
out on me. It‘s with inlining effects obscuring it. But I think that crash must 
be investigated on an AIX machine, there‘s no indication that this directly 
related to my change which works on all other systems.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125847/new/

https://reviews.llvm.org/D125847

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

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

[Matthias Braun via Phabricator via cfe-commits]

MatzeB added a comment.

In D125847#3552297 , @MaskRay wrote:

> Your commit message seems to use the original summary.

Yes sorry, I noticed it too after pushing it. I think this can‘t be fixed after 
the push though…


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125847/new/

https://reviews.llvm.org/D125847

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

[PATCH] D126291: [flang][Driver] Update link job on windows

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D126291#3573137 , @mmuetzel wrote:

> Not sure if this is the right place to add this. But maybe something like 
> this could be used to add 'windows-msvc' and 'windows-gnu' features that 
> could be used to run tests conditionally on Windows with MSVC or MinGW 
> toolchains:
>
>   diff --git a/llvm/utils/lit/lit/llvm/config.py 
> b/llvm/utils/lit/lit/llvm/config.py
>   index b65316128146..8b911997a876 100644
>   --- a/llvm/utils/lit/lit/llvm/config.py
>   +++ b/llvm/utils/lit/lit/llvm/config.py
>   @@ -134,6 +134,10 @@ class LLVMConfig(object):
>features.add('target-aarch64')
>elif re.match(r'^arm.*', target_triple):
>features.add('target-arm')
>   +if re.match(r'.*-windows-msvc', target_triple):
>   +features.add('windows-msvc')
>   +elif re.match(r'.*-windows-gnu', target_triple):
>   +features.add('windows-gnu')
>
>use_gmalloc = lit_config.params.get('use_gmalloc', None)
>if lit.util.pythonize_bool(use_gmalloc):`

FWIW, something very similar was added just a couple days ago in an lldb 
specific lit.cfg.py: https://reviews.llvm.org/D127048#change-KJ7QgKPHtN1S


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126291/new/

https://reviews.llvm.org/D126291

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

[PATCH] D127184: [clangd] Add to header map

[Florian Albrechtskirchinger via Phabricator via cfe-commits]

falbrechtskirchinger added a comment.

In D127184#3572731 , @nridge wrote:

> This change looks fine to me.
>
> I wonder though if we should be a bit more systematic about it, and try to 
> cover other newly added libstdc++ implementation headers?

Sure thing.

> (There are other new ones in gcc 11, and some in older versions that we've 
> missed, but I think handling a single gcc version would be a good scope for 
> this patch.)

I don't mind doing a systematic review including older and newer versions. Give 
me a few days to find some spare time to do it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127184/new/

https://reviews.llvm.org/D127184

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

[PATCH] D127502: [clang][dataflow] Don't `assert` full LHS coverage in `optional` model

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel accepted this revision.
ymandel added a comment.
This revision is now accepted and ready to land.

Do I understand correctly that the test you added in D127434 
 covers this change as well? (in that this 
change moves it from crashing to not crashing)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127502/new/

https://reviews.llvm.org/D127502

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

[PATCH] D125349: [Sema] Fix crash for C11 atomic in gnu++ mode

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 435932.
jansvoboda11 added a comment.

Implement another round of review feedback


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125349/new/

https://reviews.llvm.org/D125349

Files:
  clang/include/clang/AST/Type.h
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGenCXX/atomic-builtin-compound-assignment-overload.cpp
  clang/test/SemaCXX/atomic-builtin-compound-assignment-overload.cpp

Index: clang/test/SemaCXX/atomic-builtin-compound-assignment-overload.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/atomic-builtin-compound-assignment-overload.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -std=gnu++98 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+_Atomic unsigned an_atomic_uint;
+
+enum { an_enum_value = 1 };
+
+void enum1() { an_atomic_uint += an_enum_value; }
+
+void enum2() { an_atomic_uint |= an_enum_value; }
+
+volatile _Atomic unsigned an_volatile_atomic_uint;
+
+void enum3() { an_volatile_atomic_uint += an_enum_value; }
+
+void enum4() { an_volatile_atomic_uint |= an_enum_value; }
Index: clang/test/CodeGenCXX/atomic-builtin-compound-assignment-overload.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/atomic-builtin-compound-assignment-overload.cpp
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -std=gnu++11 -emit-llvm -triple=x86_64-linux-gnu -o - %s | FileCheck %s
+
+_Atomic unsigned an_atomic_uint;
+
+enum { an_enum_value = 1 };
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum1v()
+void enum1() {
+  an_atomic_uint += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum2v()
+void enum2() {
+  an_atomic_uint |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum3RU7_Atomicj({{.*}})
+void enum3(_Atomic unsigned &an_atomic_uint_param) {
+  an_atomic_uint_param += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum4RU7_Atomicj({{.*}})
+void enum4(_Atomic unsigned &an_atomic_uint_param) {
+  an_atomic_uint_param |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
+
+volatile _Atomic unsigned an_volatile_atomic_uint;
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum5v()
+void enum5() {
+  an_volatile_atomic_uint += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum6v()
+void enum6() {
+  an_volatile_atomic_uint |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum7RVU7_Atomicj({{.*}})
+void enum7(volatile _Atomic unsigned &an_volatile_atomic_uint_param) {
+  an_volatile_atomic_uint_param += an_enum_value;
+  // CHECK: atomicrmw add ptr
+}
+
+// CHECK-LABEL: define {{.*}}void @_Z5enum8RVU7_Atomicj({{.*}})
+void enum8(volatile _Atomic unsigned &an_volatile_atomic_uint_param) {
+  an_volatile_atomic_uint_param |= an_enum_value;
+  // CHECK: atomicrmw or ptr
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -8191,6 +8191,39 @@
 return VRQuals;
 }
 
+// Note: We're currently only handling qualifiers that are meaningful for the
+// LHS of compound assignment overloading.
+static void forAllQualifierCombinationsImpl(
+QualifiersAndAtomic available, QualifiersAndAtomic applied,
+llvm::function_ref callback) {
+  // _Atomic
+  if (available.hasAtomic()) {
+available.removeAtomic();
+forAllQualifierCombinationsImpl(available, applied.withAtomic(), callback);
+forAllQualifierCombinationsImpl(available, applied, callback);
+return;
+  }
+
+  // volatile
+  if (available.hasVolatile()) {
+available.removeVolatile();
+assert(!applied.hasVolatile());
+forAllQualifierCombinationsImpl(available, applied.withVolatile(),
+callback);
+forAllQualifierCombinationsImpl(available, applied, callback);
+return;
+  }
+
+  callback(applied);
+}
+
+static void forAllQualifierCombinations(
+QualifiersAndAtomic quals,
+llvm::function_ref callback) {
+  return forAllQualifierCombinationsImpl(quals, QualifiersAndAtomic(),
+ callback);
+}
+
 namespace {
 
 /// Helper class to manage the addition of builtin operator overload
@@ -8201,7 +8234,7 @@
   // Common instance state available to all overload candidate addition methods.
   Sema &S;
   ArrayRef Args;
-  Qualifiers VisibleTypeConversionsQuals;
+  QualifiersAndAtomic VisibleTypeConversionsQuals;
   bool HasArithmeticOrEnumeralCandidateType;
   SmallVectorImpl &CandidateTypes;
   OverloadCandidateSet &CandidateSet;
@@ -8325,7 +8358,7 @@
 public:
   BuiltinOperatorOverloadBuilder(
 Sema &S, ArrayRef Args,
-Qualifiers VisibleTypeConversionsQuals,
+QualifiersAndAtomic VisibleTypeConversionsQuals,
 bo

[PATCH] D127502: [clang][dataflow] Don't `assert` full LHS coverage in `optional` model

[Sam Estep via Phabricator via cfe-commits]

samestep added a comment.

@ymandel Yes, either this patch or D127434  
would bring that test from crashing to passing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127502/new/

https://reviews.llvm.org/D127502

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

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

I've checked that the change works fine on top of D126907 
. The bug is still there after D126907 
 and gets fixed by this.
Also, the merge conflict is actually minimal, no code changes intersect.




Comment at: clang/lib/Sema/SemaConcept.cpp:352
+  [this](const Expr *AtomicExpr) -> ExprResult {
+// We only do this to immitate lvalue-to-rvalue conversion.
+return PerformContextuallyConvertToBool(const_cast(AtomicExpr));

royjacobson wrote:
> erichkeane wrote:
> > ilya-biryukov wrote:
> > > erichkeane wrote:
> > > > Can you explain this more?  How does this work, and why don't we do 
> > > > that directly instead?
> > > That's entangled with `calculateConstraintSatisfaction`. I actually tried 
> > > to do it directly, but before passing expressions to this function 
> > > `calculateConstraintSatisfaction` calls `IgnoreParenImpCasts()`, which 
> > > strips away the lvalue-to-rvalue conversion.
> > > And we need this conversion so that the evaluation that runs after this 
> > > callback returns actually produces an r-value.
> > > 
> > > Note that the other call to `calculateConstraintSatisfaction` also calls 
> > > `PerformContextuallyConvertToBool` after doing template substitution into 
> > > the constraint expression.
> > > 
> > > I don't have full context on why it's the way it is, maybe there is a 
> > > more fundamental change that helps with both cases.
> > Hmm... my understanding is we DO need these to be a boolean expression 
> > eventually, since we have to test them as a bool, so that is why the other 
> > attempts the converesion.  If you think of any generalizations of this, it 
> > would be appreciated, I'll think it through as well.
> Note we already have a related bug about this 
> https://github.com/llvm/llvm-project/issues/54524
Yeah, they have to be bool and we actually check for that in 
`CheckConstraintExpression`. The standard explicitly mentions only the 
lvalue-to-rvalue conversion should be performed.
```
[temp.constr.atomic]p3 If substitution results in an invalid type or 
expression, the constraint is
not satisfied. Otherwise, the lvalue-to-rvalue conversion (7.3.1) is performed 
if necessary, and E shall be a constant expression of type bool.
```

However, in the calls to `calculateConstraintSatisfaction` we do a more generic 
boolean conversion, but the comment in the other call site suggests this 
probably accidental and we actually want a less generic conversion:
```
  // Substitution might have stripped off a contextual conversion to
  // bool if this is the operand of an '&&' or '||'. For example, we
  // might lose an lvalue-to-rvalue conversion here. If so, put it back
  // before we try to evaluate.
  if (!SubstitutedExpression.isInvalid())
SubstitutedExpression =
S.PerformContextuallyConvertToBool(SubstitutedExpression.get());
```

I am happy to take a look at fixing the mentioned bug.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2042
+!SemaRef.CheckConstraintExpression(TransConstraint.get())) {
+  assert(Trap.hasErrorOccurred() && "CheckConstraintExpression failed, but 
"
+"did not produce a SFINAE error");

erichkeane wrote:
> ilya-biryukov wrote:
> > erichkeane wrote:
> > > This branch ends up being empty if asserts are off.  Also, it results in 
> > > CheckConstraintExpression happening 2x, which ends up being more 
> > > expensive after https://reviews.llvm.org/D126907
> > > This branch ends up being empty if asserts are off.  Also, it results in 
> > > CheckConstraintExpression happening 2x, which ends up being more 
> > > expensive after https://reviews.llvm.org/D126907
> > 
> > Yeah, good point, I have update it.
> > 
> > I am not sure why would `CheckConstraintExpression` be called twice, could 
> > you elaborate? Note that we do not call `BuildNestedRequirement` anymore 
> > and use placement new directly to avoid extra template instantiations. 
> > Instead we call `CheckConstraintExpression` directly to account for any 
> > errors.
> This check does not seem to cause a 'return' to the function, but then falls 
> through to the version on 2052, right?  
> 
> `CheckConstraintExpression`/`CheckConstraintSatisfaction`(i think?) ends up 
> now having to re-instantiate every time it is called, so any ability to cache 
> results ends up being beneficial here.
The number of calls to these functions is actually the same.

`CheckConstraintExpression` used to be called during 
`CheckConstraintSatisfaction` (that does instantiations) for every atomic 
constraint after the substitution. It merely checks that each constraint have a 
bool type and does not do any substitutions, so it's pretty cheap anyway.

`CheckConstraintSatisfaction` was called inside `BuildNest

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan added a comment.

Thanks for taking a look. I agree someone on AIX should investigate.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125847/new/

https://reviews.llvm.org/D125847

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

[PATCH] D127498: [SystemZ/z/OS] Set DWARF version to 4 for z/OS.

[Ulrich Weigand via Phabricator via cfe-commits]

uweigand accepted this revision.
uweigand added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127498/new/

https://reviews.llvm.org/D127498

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

[PATCH] D124690: [clangd] add inlay hints for std::forward-ed parameter packs

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

I will do my best to take a look this weekend. Your patience is appreciated :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124690/new/

https://reviews.llvm.org/D124690

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

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D127487#3573667 , @ilya-biryukov 
wrote:

> I've checked that the change works fine on top of D126907 
> . The bug is still there after D126907 
>  and gets fixed by this.
> Also, the merge conflict is actually minimal, no code changes intersect.

Thanks for looking into this!  I DID see it was still in place after the fact, 
but wanted to make sure this wouldn't break any more of the tests.




Comment at: clang/lib/Sema/SemaConcept.cpp:352
+  [this](const Expr *AtomicExpr) -> ExprResult {
+// We only do this to immitate lvalue-to-rvalue conversion.
+return PerformContextuallyConvertToBool(const_cast(AtomicExpr));

ilya-biryukov wrote:
> royjacobson wrote:
> > erichkeane wrote:
> > > ilya-biryukov wrote:
> > > > erichkeane wrote:
> > > > > Can you explain this more?  How does this work, and why don't we do 
> > > > > that directly instead?
> > > > That's entangled with `calculateConstraintSatisfaction`. I actually 
> > > > tried to do it directly, but before passing expressions to this 
> > > > function `calculateConstraintSatisfaction` calls 
> > > > `IgnoreParenImpCasts()`, which strips away the lvalue-to-rvalue 
> > > > conversion.
> > > > And we need this conversion so that the evaluation that runs after this 
> > > > callback returns actually produces an r-value.
> > > > 
> > > > Note that the other call to `calculateConstraintSatisfaction` also 
> > > > calls `PerformContextuallyConvertToBool` after doing template 
> > > > substitution into the constraint expression.
> > > > 
> > > > I don't have full context on why it's the way it is, maybe there is a 
> > > > more fundamental change that helps with both cases.
> > > Hmm... my understanding is we DO need these to be a boolean expression 
> > > eventually, since we have to test them as a bool, so that is why the 
> > > other attempts the converesion.  If you think of any generalizations of 
> > > this, it would be appreciated, I'll think it through as well.
> > Note we already have a related bug about this 
> > https://github.com/llvm/llvm-project/issues/54524
> Yeah, they have to be bool and we actually check for that in 
> `CheckConstraintExpression`. The standard explicitly mentions only the 
> lvalue-to-rvalue conversion should be performed.
> ```
> [temp.constr.atomic]p3 If substitution results in an invalid type or 
> expression, the constraint is
> not satisfied. Otherwise, the lvalue-to-rvalue conversion (7.3.1) is 
> performed if necessary, and E shall be a constant expression of type bool.
> ```
> 
> However, in the calls to `calculateConstraintSatisfaction` we do a more 
> generic boolean conversion, but the comment in the other call site suggests 
> this probably accidental and we actually want a less generic conversion:
> ```
>   // Substitution might have stripped off a contextual conversion to
>   // bool if this is the operand of an '&&' or '||'. For example, we
>   // might lose an lvalue-to-rvalue conversion here. If so, put it 
> back
>   // before we try to evaluate.
>   if (!SubstitutedExpression.isInvalid())
> SubstitutedExpression =
> 
> S.PerformContextuallyConvertToBool(SubstitutedExpression.get());
> ```
> 
> I am happy to take a look at fixing the mentioned bug.
Hmm... yeah, I find myself wondering if there is a better lval/rval conversion 
function here, and I'm guessing the contextually convert to bool is the wrong 
one.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2042
+!SemaRef.CheckConstraintExpression(TransConstraint.get())) {
+  assert(Trap.hasErrorOccurred() && "CheckConstraintExpression failed, but 
"
+"did not produce a SFINAE error");

ilya-biryukov wrote:
> erichkeane wrote:
> > ilya-biryukov wrote:
> > > erichkeane wrote:
> > > > This branch ends up being empty if asserts are off.  Also, it results 
> > > > in CheckConstraintExpression happening 2x, which ends up being more 
> > > > expensive after https://reviews.llvm.org/D126907
> > > > This branch ends up being empty if asserts are off.  Also, it results 
> > > > in CheckConstraintExpression happening 2x, which ends up being more 
> > > > expensive after https://reviews.llvm.org/D126907
> > > 
> > > Yeah, good point, I have update it.
> > > 
> > > I am not sure why would `CheckConstraintExpression` be called twice, 
> > > could you elaborate? Note that we do not call `BuildNestedRequirement` 
> > > anymore and use placement new directly to avoid extra template 
> > > instantiations. Instead we call `CheckConstraintExpression` directly to 
> > > account for any errors.
> > This check does not seem to cause a 'return' to the function, but then 
> > falls through to the version on 2052, right?  
> > 
> > `Ch

[PATCH] D126479: [Clang] Allow 'Complex float __attribute__((mode(HC)))'

[Tom Honermann via Phabricator via cfe-commits]

tahonermann requested changes to this revision.
tahonermann added inline comments.
This revision now requires changes to proceed.



Comment at: clang/include/clang/Basic/TargetInfo.h:223-224
   unsigned HasAlignMac68kSupport : 1;
-  unsigned RealTypeUsesObjCFPRet : 3;
+  unsigned RealTypeUsesObjCFPRet : (1 << (int)FloatModeKind::Float) |
+   (1 << (int)FloatModeKind::Double);
   unsigned ComplexLongDoubleUsesFP2Ret : 1;

This doesn't look right to me. The size of the bit field would be `(1 << 1) | 
(1 << 2)` which is `0b110` which is 6, but more by coincidence than by 
construction. I think what we want is:
  unsigned RealTypeUsesObjCFPRet  : (int)FloatModeKind::Last + 1;


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126479/new/

https://reviews.llvm.org/D126479

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

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:352
+  [this](const Expr *AtomicExpr) -> ExprResult {
+// We only do this to immitate lvalue-to-rvalue conversion.
+return PerformContextuallyConvertToBool(const_cast(AtomicExpr));

erichkeane wrote:
> ilya-biryukov wrote:
> > royjacobson wrote:
> > > erichkeane wrote:
> > > > ilya-biryukov wrote:
> > > > > erichkeane wrote:
> > > > > > Can you explain this more?  How does this work, and why don't we do 
> > > > > > that directly instead?
> > > > > That's entangled with `calculateConstraintSatisfaction`. I actually 
> > > > > tried to do it directly, but before passing expressions to this 
> > > > > function `calculateConstraintSatisfaction` calls 
> > > > > `IgnoreParenImpCasts()`, which strips away the lvalue-to-rvalue 
> > > > > conversion.
> > > > > And we need this conversion so that the evaluation that runs after 
> > > > > this callback returns actually produces an r-value.
> > > > > 
> > > > > Note that the other call to `calculateConstraintSatisfaction` also 
> > > > > calls `PerformContextuallyConvertToBool` after doing template 
> > > > > substitution into the constraint expression.
> > > > > 
> > > > > I don't have full context on why it's the way it is, maybe there is a 
> > > > > more fundamental change that helps with both cases.
> > > > Hmm... my understanding is we DO need these to be a boolean expression 
> > > > eventually, since we have to test them as a bool, so that is why the 
> > > > other attempts the converesion.  If you think of any generalizations of 
> > > > this, it would be appreciated, I'll think it through as well.
> > > Note we already have a related bug about this 
> > > https://github.com/llvm/llvm-project/issues/54524
> > Yeah, they have to be bool and we actually check for that in 
> > `CheckConstraintExpression`. The standard explicitly mentions only the 
> > lvalue-to-rvalue conversion should be performed.
> > ```
> > [temp.constr.atomic]p3 If substitution results in an invalid type or 
> > expression, the constraint is
> > not satisfied. Otherwise, the lvalue-to-rvalue conversion (7.3.1) is 
> > performed if necessary, and E shall be a constant expression of type bool.
> > ```
> > 
> > However, in the calls to `calculateConstraintSatisfaction` we do a more 
> > generic boolean conversion, but the comment in the other call site suggests 
> > this probably accidental and we actually want a less generic conversion:
> > ```
> >   // Substitution might have stripped off a contextual conversion to
> >   // bool if this is the operand of an '&&' or '||'. For example, we
> >   // might lose an lvalue-to-rvalue conversion here. If so, put it 
> > back
> >   // before we try to evaluate.
> >   if (!SubstitutedExpression.isInvalid())
> > SubstitutedExpression =
> > 
> > S.PerformContextuallyConvertToBool(SubstitutedExpression.get());
> > ```
> > 
> > I am happy to take a look at fixing the mentioned bug.
> Hmm... yeah, I find myself wondering if there is a better lval/rval 
> conversion function here, and I'm guessing the contextually convert to bool 
> is the wrong one.
Yep, it's definitely the wrong function. I could not find a better one, but I 
only briefly looked through the options.

I will have to find one or implement it while fixing  
https://github.com/llvm/llvm-project/issues/54524.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2042
+!SemaRef.CheckConstraintExpression(TransConstraint.get())) {
+  assert(Trap.hasErrorOccurred() && "CheckConstraintExpression failed, but 
"
+"did not produce a SFINAE error");

erichkeane wrote:
> ilya-biryukov wrote:
> > erichkeane wrote:
> > > ilya-biryukov wrote:
> > > > erichkeane wrote:
> > > > > This branch ends up being empty if asserts are off.  Also, it results 
> > > > > in CheckConstraintExpression happening 2x, which ends up being more 
> > > > > expensive after https://reviews.llvm.org/D126907
> > > > > This branch ends up being empty if asserts are off.  Also, it results 
> > > > > in CheckConstraintExpression happening 2x, which ends up being more 
> > > > > expensive after https://reviews.llvm.org/D126907
> > > > 
> > > > Yeah, good point, I have update it.
> > > > 
> > > > I am not sure why would `CheckConstraintExpression` be called twice, 
> > > > could you elaborate? Note that we do not call `BuildNestedRequirement` 
> > > > anymore and use placement new directly to avoid extra template 
> > > > instantiations. Instead we call `CheckConstraintExpression` directly to 
> > > > account for any errors.
> > > This check does not seem to cause a 'return' to the function, but then 
> > > falls through to the version on 2052, right?  
> > > 
> > > `CheckConstraintExpression`/`CheckConstraintSatisfaction`(i think?) ends 
> > > up no

[PATCH] D126291: [flang][Driver] Update link job on windows

[Markus Mützel via Phabricator via cfe-commits]

mmuetzel added a comment.

In D126291#3573607 , @mstorsjo wrote:

> FWIW, something very similar was added just a couple days ago in an lldb 
> specific lit.cfg.py: https://reviews.llvm.org/D127048#change-KJ7QgKPHtN1S

Thank you for pointing this out.
Those feature definitions for the lldb subproject probably stem from around 
here:
https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/lit.cfg.py#L65

Instead of every subproject adding their own conditions for similar features, 
would it make sense to move these definitions to somewhere where all 
subprojects could use those same lit features? Would that be in 
`/llvm/utils/lit/lit/llvm/config.py`?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126291/new/

https://reviews.llvm.org/D126291

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

[PATCH] D126291: [flang][Driver] Update link job on windows

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D126291#3573742 , @mmuetzel wrote:

> In D126291#3573607 , @mstorsjo 
> wrote:
>
>> FWIW, something very similar was added just a couple days ago in an lldb 
>> specific lit.cfg.py: https://reviews.llvm.org/D127048#change-KJ7QgKPHtN1S
>
> Thank you for pointing this out.
> Those feature definitions for the lldb subproject probably stem from around 
> here:
> https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/lit.cfg.py#L65
>
> Instead of every subproject adding their own conditions for similar features, 
> would it make sense to move these definitions to somewhere where all 
> subprojects could use those same lit features? Would that be in 
> `/llvm/utils/lit/lit/llvm/config.py`?

Maybe, but keep in mind that those kinds of tests should be the exception, not 
the rule.

As clang (and flang too, I would presume) generally can be cross compiling, one 
shouldn't imply that you need to be running on windows, to be able to test how 
the clang driver behaves when targeting windows. You can test that on any 
system, by passing `-target x86_64-windows-msvc` to the e.g. clang command in a 
lit test, so you can get test coverage for that aspect of the functionality 
regardless of what system you're running. Most tests in `clang/test/Driver` 
work that way.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126291/new/

https://reviews.llvm.org/D126291

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

[PATCH] D119296: KCFI sanitizer

[Sami Tolvanen via Phabricator via cfe-commits]

samitolvanen added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2257
+
+  F->setPrefixData(CreateKCFITypeId(FD->getType()));
+  F->addFnAttr("kcfi-target");

ychen wrote:
> FYI: using prefix data may not work for the C++ coroutine. 
> (https://github.com/llvm/llvm-project/issues/49689) because corosplit pass 
> may clone coro functions and change its function type. But prefix data is 
> opaque, so there is no way to detect this, and then drop the prefix data in 
> the corosplit pass.
> 
> If this is a concern for now or for the near future, it might be better to 
> use alternative approaches like D115844.
> FYI: using prefix data may not work for the C++ coroutine.

Thanks for the link, that's interesting. The Linux kernel doesn't use C++ so 
this isn't a concern there, but I suppose there could theoretically also be C++ 
users for this feature. @pcc, any thoughts if we should just switch from prefix 
data to a metadata node here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119296/new/

https://reviews.llvm.org/D119296

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

[PATCH] D127496: [NFC] Suggest Release mode in clang GettingStarted.html

[Shivam Gupta via Phabricator via cfe-commits]

xgupta updated this revision to Diff 435947.
xgupta added a comment.

Address comments


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127496/new/

https://reviews.llvm.org/D127496

Files:
  clang/www/get_started.html


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -69,9 +69,13 @@
 cd llvm-project
 mkdir build (in-tree build is not supported)
 cd build
-cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" 
../llvm
+This builds both LLVM and Clang for release mode. Alternatively if
+you need a debug build, switch Release to Debug. See
+frequently
 used cmake variables
+for more options.
+
+cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G 
"Unix Makefiles" ../llvm
 make
-This builds both LLVM and Clang for debug mode.
 Note: For subsequent Clang development, you can just run
 make clang.
 CMake allows you to generate project files for several IDEs: Xcode,


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -69,9 +69,13 @@
 cd llvm-project
 mkdir build (in-tree build is not supported)
 cd build
-cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm
+This builds both LLVM and Clang for release mode. Alternatively if
+you need a debug build, switch Release to Debug. See
+frequently used cmake variables
+for more options.
+
+cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm
 make
-This builds both LLVM and Clang for debug mode.
 Note: For subsequent Clang development, you can just run
 make clang.
 CMake allows you to generate project files for several IDEs: Xcode,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127496: [NFC] Suggest Release mode in clang GettingStarted.html

[Shivam Gupta via Phabricator via cfe-commits]

xgupta added inline comments.



Comment at: clang/www/get_started.html:72
 cd build
+This builds both LLVM and Clang for debug mode and takes a lot of time 
and space. Alternatively -DCMAKE_BUILD_TYPE=Release" can be use to make a 
release build.
 cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" 
../llvm

aaron.ballman wrote:
> thieta wrote:
> > This isn't correct - invoking cmake without a `CMAKE_BUILD_TYPE` argument 
> > will just print an error. I would fix the command line below to include 
> > `-DCMAKE_BUILD_TYPE=Release` and have a comment saying switch Release to 
> > Debug if you need a debug build.
> +1 to most of this, but I'd have the comment say something along the lines of 
> "See https://llvm.org/docs/CMake.html#frequently-used-cmake-variables for 
> more options".
I hope 'most of this' also includes making changes to the default suggestion of 
 -DCMAKE_BUILD_TYPE :) 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127496/new/

https://reviews.llvm.org/D127496

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

[PATCH] D107082: [X86][RFC] Enable `_Float16` type support on X86 following the psABI

[Phoebe Wang via Phabricator via cfe-commits]

pengfei added inline comments.



Comment at: llvm/test/CodeGen/X86/fpclamptosat_vec.ll:605
+; CHECK-NEXT:.cfi_def_cfa_offset 80
+; CHECK-NEXT:movss %xmm2, {{[-0-9]+}}(%r{{[sb]}}p) # 4-byte Spill
+; CHECK-NEXT:movss %xmm1, {{[-0-9]+}}(%r{{[sb]}}p) # 4-byte Spill

pengfei wrote:
> LuoYuanke wrote:
> > Is the vector <4 x half> split to 4 scalar and pass by xmm? What's the ABI 
> > for vector half? Is there any case that test the scenario that run out of 
> > register and pass parameter through stack?
> Good question! Previously, I discussed with GCC folks we won't support vector 
> in emulation. I expected the FE with pass whole vector through stack. So a 
> vector in IR is illegal to ABI and can be splited.
> But seems GCC passes it by vector register. https://godbolt.org/z/a67rMhTW6
> I'll double confirm with GCC folks.
Discussed with GCC folks today. We should support the vector ABI. But we have 
to adding more patterns to support load/store etc. operations for vector type. 
I'd like to address this as a follow up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107082/new/

https://reviews.llvm.org/D107082

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

[PATCH] D127496: [NFC] Suggest Release mode in clang GettingStarted.html

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Looks pretty close, just some minor nits from me.




Comment at: clang/www/get_started.html:72-75
+This builds both LLVM and Clang for release mode. Alternatively if
+you need a debug build, switch Release to Debug. See
+frequently
 used cmake variables
+for more options.





Comment at: clang/www/get_started.html:72
 cd build
+This builds both LLVM and Clang for debug mode and takes a lot of time 
and space. Alternatively -DCMAKE_BUILD_TYPE=Release" can be use to make a 
release build.
 cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" 
../llvm

xgupta wrote:
> aaron.ballman wrote:
> > thieta wrote:
> > > This isn't correct - invoking cmake without a `CMAKE_BUILD_TYPE` argument 
> > > will just print an error. I would fix the command line below to include 
> > > `-DCMAKE_BUILD_TYPE=Release` and have a comment saying switch Release to 
> > > Debug if you need a debug build.
> > +1 to most of this, but I'd have the comment say something along the lines 
> > of "See https://llvm.org/docs/CMake.html#frequently-used-cmake-variables 
> > for more options".
> I hope 'most of this' also includes making changes to the default suggestion 
> of  -DCMAKE_BUILD_TYPE :) 
> I hope 'most of this' also includes making changes to the default suggestion 
> of -DCMAKE_BUILD_TYPE :)

Heh, it did! :-)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127496/new/

https://reviews.llvm.org/D127496

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

[PATCH] D127509: Prefer `getCurrentFileOrBufferName` in `FrontendAction::EndSourceFile`

[Yuki Okushi via Phabricator via cfe-commits]

JohnTitor created this revision.
Herald added a project: All.
JohnTitor requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

`getCurrentFile` here causes an assertion on some condition.
`getCurrentFileOrBufferName` is preferrable instead.

llvm#55950


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127509

Files:
  clang/lib/Frontend/FrontendAction.cpp


Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -1075,7 +1075,7 @@
   }
 
   if (CI.getFrontendOpts().ShowStats) {
-llvm::errs() << "\nSTATISTICS FOR '" << getCurrentFile() << "':\n";
+llvm::errs() << "\nSTATISTICS FOR '" << getCurrentFileOrBufferName() << 
"':\n";
 CI.getPreprocessor().PrintStats();
 CI.getPreprocessor().getIdentifierTable().PrintStats();
 CI.getPreprocessor().getHeaderSearchInfo().PrintStats();


Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -1075,7 +1075,7 @@
   }
 
   if (CI.getFrontendOpts().ShowStats) {
-llvm::errs() << "\nSTATISTICS FOR '" << getCurrentFile() << "':\n";
+llvm::errs() << "\nSTATISTICS FOR '" << getCurrentFileOrBufferName() << "':\n";
 CI.getPreprocessor().PrintStats();
 CI.getPreprocessor().getIdentifierTable().PrintStats();
 CI.getPreprocessor().getHeaderSearchInfo().PrintStats();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127496: [NFC] Suggest Release mode in clang GettingStarted.html

[Shivam Gupta via Phabricator via cfe-commits]

xgupta updated this revision to Diff 435957.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127496/new/

https://reviews.llvm.org/D127496

Files:
  clang/www/get_started.html


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -69,9 +69,13 @@
 cd llvm-project
 mkdir build (in-tree build is not supported)
 cd build
-cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" 
../llvm
+This builds both LLVM and Clang in release mode. Alternatively if
+you need a debug build, switch Release to Debug. See
+https://llvm.org/docs/CMake.html#frequently-used-cmake-variables";>frequently
 used cmake variables
+for more options.
+
+cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G 
"Unix Makefiles" ../llvm
 make
-This builds both LLVM and Clang for debug mode.
 Note: For subsequent Clang development, you can just run
 make clang.
 CMake allows you to generate project files for several IDEs: Xcode,


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -69,9 +69,13 @@
 cd llvm-project
 mkdir build (in-tree build is not supported)
 cd build
-cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm
+This builds both LLVM and Clang in release mode. Alternatively if
+you need a debug build, switch Release to Debug. See
+https://llvm.org/docs/CMake.html#frequently-used-cmake-variables";>frequently used cmake variables
+for more options.
+
+cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm
 make
-This builds both LLVM and Clang for debug mode.
 Note: For subsequent Clang development, you can just run
 make clang.
 CMake allows you to generate project files for several IDEs: Xcode,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2042
+!SemaRef.CheckConstraintExpression(TransConstraint.get())) {
+  assert(Trap.hasErrorOccurred() && "CheckConstraintExpression failed, but 
"
+"did not produce a SFINAE error");

ilya-biryukov wrote:
> erichkeane wrote:
> > ilya-biryukov wrote:
> > > erichkeane wrote:
> > > > ilya-biryukov wrote:
> > > > > erichkeane wrote:
> > > > > > This branch ends up being empty if asserts are off.  Also, it 
> > > > > > results in CheckConstraintExpression happening 2x, which ends up 
> > > > > > being more expensive after https://reviews.llvm.org/D126907
> > > > > > This branch ends up being empty if asserts are off.  Also, it 
> > > > > > results in CheckConstraintExpression happening 2x, which ends up 
> > > > > > being more expensive after https://reviews.llvm.org/D126907
> > > > > 
> > > > > Yeah, good point, I have update it.
> > > > > 
> > > > > I am not sure why would `CheckConstraintExpression` be called twice, 
> > > > > could you elaborate? Note that we do not call 
> > > > > `BuildNestedRequirement` anymore and use placement new directly to 
> > > > > avoid extra template instantiations. Instead we call 
> > > > > `CheckConstraintExpression` directly to account for any errors.
> > > > This check does not seem to cause a 'return' to the function, but then 
> > > > falls through to the version on 2052, right?  
> > > > 
> > > > `CheckConstraintExpression`/`CheckConstraintSatisfaction`(i think?) 
> > > > ends up now having to re-instantiate every time it is called, so any 
> > > > ability to cache results ends up being beneficial here.
> > > The number of calls to these functions is actually the same.
> > > 
> > > `CheckConstraintExpression` used to be called during 
> > > `CheckConstraintSatisfaction` (that does instantiations) for every atomic 
> > > constraint after the substitution. It merely checks that each constraint 
> > > have a bool type and does not do any substitutions, so it's pretty cheap 
> > > anyway.
> > > 
> > > `CheckConstraintSatisfaction` was called inside `BuildNestedRequirement`, 
> > > we now call a different overload here directly that does not do any extra 
> > > template instantiations directly.
> > > 
> > > That way we end up doing the same checks without running recursive 
> > > template instantiations.
> > Hmm... I guess what I'm saying is: I would like it if we could 
> > minimize/reduce the calls to calcuateConstraintSatisfaction (in 
> > SemaConcept.cpp) that does the call to SubstConstraintExpr (or substExpr).  
> > 
> > That ends up being more expensive thanks to my other patch.
> Ah, yes, that makes sense. Note that `CheckConstraintSatisfaction` call on 
> 2052 does not do any substitutions, it merely evaluates the expressions if 
> they are not dependent.
> 
> I will have to look more closely into your patch to get a sense of why 
> substituting to the constraint expressions is more expensive after it.
> 
> BTW, I was wondering if there is any reason to substitute empty template 
> arguments to evaluate non-dependent constraints? (This is what 
> `CalculateConstraintSatisfaction` does)
> I feels like merely evaluating those should be enough.
ah, I see!  Constraint expressions get 'more expensive' because now we actually 
have to do substitution EVERY time we evaluate, rather than just having an 
already non-dependent expression stored.  This is because the deferred 
constraint instantiation requires that we re-evaluate it just about every time 
we check a constraint.

Which version of `CalculateConstraintSatisfaction` are you referring to?  it 
DOES actually appear that the one you modify above doesn't actually DO any 
substitution.  it DOES looklike it does some checking to make sure we 
specifically are a boolean expr ([temp.constr.atompic]p1 ~ line 210), but it 
isn't clear to me what the logic there is either.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127487/new/

https://reviews.llvm.org/D127487

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

[PATCH] D127496: [NFC] Suggest Release mode in clang GettingStarted.html

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM aside from a missing comma (that can be fixed when landing). But you 
should give @thieta a chance to chime in before landing.




Comment at: clang/www/get_started.html:72
 cd build
-cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" 
../llvm
+This builds both LLVM and Clang in release mode. Alternatively if
+you need a debug build, switch Release to Debug. See

Looks like this was missed with the other changes.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127496/new/

https://reviews.llvm.org/D127496

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

[PATCH] D126291: [flang][Driver] Update link job on windows

[Markus Mützel via Phabricator via cfe-commits]

mmuetzel added a comment.

In D126291#3573751 , @mstorsjo wrote:

> Maybe, but keep in mind that those kinds of tests should be the exception, 
> not the rule.
>
> As clang (and flang too, I would presume) generally can be cross compiling, 
> one shouldn't imply that you need to be running on windows, to be able to 
> test how the clang driver behaves when targeting windows. You can test that 
> on any system, by passing `-target x86_64-windows-msvc` to the e.g. clang 
> command in a lit test, so you can get test coverage for that aspect of the 
> functionality regardless of what system you're running. Most tests in 
> `clang/test/Driver` work that way.

Ah ok. So instead of having `! REQUIRES:` lines, those tests should add 
`-target x86_64-windows-msvc` to the flang invocation?
On platforms that didn't build the necessary libraries (e.g., a GNU system not 
explicitly configured to build a cross-compiler for that target), linking will 
likely fail. I don't know what `FileCheck` is doing. Can it cope with that?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126291/new/

https://reviews.llvm.org/D126291

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

[PATCH] D126291: [flang][Driver] Update link job on windows

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D126291#3573937 , @mmuetzel wrote:

> Ah ok. So instead of having `! REQUIRES:` lines, those tests should add 
> `-target x86_64-windows-msvc` to the flang invocation?

Exactly

> On platforms that didn't build the necessary libraries (e.g., a GNU system 
> not explicitly configured to build a cross-compiler for that target), linking 
> will likely fail. I don't know what `FileCheck` is doing. Can it cope with 
> that?

These tests don't try to run the full link command - the `-###` parameter means 
that it only prints what subcommands it would have executed. So on any system, 
you can run the codepath in clang that just prints that it should execute `link 
... Fortran_main.lib`, even if `Fortran_main.lib` doesn't actually exist. This 
is the basis of how all of LLVM's shell tests work - you don't need to be able 
to execute the full compiler toolchain, but you can verify that each individual 
step does what it's supposed to do.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126291/new/

https://reviews.llvm.org/D126291

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

[PATCH] D117977: [cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore

[Stephan Bergmann via Phabricator via cfe-commits]

sberg added a comment.

There might be something fishy with this commit.  My fresh from-scratch `cmake 
--build . && cmake --build . --target install` monorepo build now lacked e.g. 
the `bin/clang++` symlink in the installation dir, and locally reverting this 
commit fixed that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117977/new/

https://reviews.llvm.org/D117977

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

[PATCH] D127496: [NFC] Suggest Release mode in clang GettingStarted.html

[Tobias Hieta via Phabricator via cfe-commits]

thieta accepted this revision.
thieta added a comment.
This revision is now accepted and ready to land.

Looks fine to me. Thanks for fixing!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127496/new/

https://reviews.llvm.org/D127496

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

[clang] f21187e - [clang][tablegen] adds human documentation to `WarningOption`

[Christopher Di Bella via cfe-commits]

Author: Christopher Di Bella
Date: 2022-06-10T17:23:00Z
New Revision: f21187eb2d943c1407ae764b87f73602177dcba8

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

LOG: [clang][tablegen] adds human documentation to `WarningOption`

Building on D126796, this commit adds the infrastructure for being able
to print out descriptions of what each warning does.

Differential Revision: https://reviews.llvm.org/D126832

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/DiagnosticCategories.h
clang/include/clang/Basic/DiagnosticIDs.h
clang/lib/Basic/DiagnosticIDs.cpp
clang/tools/diagtool/DiagnosticNames.cpp
clang/utils/TableGen/ClangDiagnosticsEmitter.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 5905fa2e917e5..cf140d31f6187 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -110,12 +110,12 @@ Bug Fixes
   `51414 `_,
   `51416 `_,
   and `51641 `_.
-- The builtin function __builtin_dump_struct would crash clang when the target 
+- The builtin function __builtin_dump_struct would crash clang when the target
   struct contains a bitfield. It now correctly handles bitfields.
   This fixes Issue `Issue 54462 
`_.
 - Statement expressions are now disabled in default arguments in general.
   This fixes Issue `Issue 53488 
`_.
-- According to `CWG 1394 `_ and 
+- According to `CWG 1394 `_ and
   `C++20 [dcl.fct.def.general]p2 
`_,
   Clang should not diagnose incomplete types in function definitions if the 
function body is "= delete;".
   This fixes Issue `Issue 52802 
`_.
@@ -149,8 +149,8 @@ Bug Fixes
   because there is no way to fully qualify the enumerator name, so this
   "extension" was unintentional and useless. This fixes
   `Issue 42372 `_.
-- Clang will now find and emit a call to an allocation function in a 
-  promise_type body for coroutines if there is any allocation function 
+- Clang will now find and emit a call to an allocation function in a
+  promise_type body for coroutines if there is any allocation function
   declaration in the scope of promise_type. Additionally, to implement CWG2585,
   a coroutine will no longer generate a call to a global allocation function
   with the signature (std::size_t, p0, ..., pn).
@@ -296,6 +296,8 @@ New Compiler Flags
   operations, such as division or float-to-integer conversion, on ``_BitInt``
   types with more than 128 bits currently crash clang. This option will be
   removed in the future once clang supports all such operations.
+- Added the ``-print-diagnostic-options`` option, which prints a list of
+  warnings the compiler supports.
 
 Deprecated Compiler Flags
 -
@@ -545,7 +547,7 @@ Static Analyzer
 
 - Added a new checker ``alpha.unix.cstring.UninitializedRead`` this will check 
for uninitialized reads
   from common memory copy/manipulation functions such as ``memcpy``, 
``mempcpy``, ``memmove``, ``memcmp``, `
-  `strcmp``, ``strncmp``, ``strcpy``, ``strlen``, ``strsep`` and many more. 
Although 
+  `strcmp``, ``strncmp``, ``strcpy``, ``strlen``, ``strsep`` and many more. 
Although
   this checker currently is in list of alpha checkers due to a false positive.
 
 .. _release-notes-ubsan:

diff  --git a/clang/include/clang/Basic/DiagnosticCategories.h 
b/clang/include/clang/Basic/DiagnosticCategories.h
index 2bbdeb31a7b7d..14be326f7515f 100644
--- a/clang/include/clang/Basic/DiagnosticCategories.h
+++ b/clang/include/clang/Basic/DiagnosticCategories.h
@@ -21,7 +21,8 @@ namespace clang {
 };
 
 enum class Group {
-#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups) GroupName,
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups, Docs)
\
+  GroupName,
 #include "clang/Basic/DiagnosticGroups.inc"
 #undef CATEGORY
 #undef DIAG_ENTRY

diff  --git a/clang/include/clang/Basic/DiagnosticIDs.h 
b/clang/include/clang/Basic/DiagnosticIDs.h
index f27bf356888c4..709d5e1dc80d4 100644
--- a/clang/include/clang/Basic/DiagnosticIDs.h
+++ b/clang/include/clang/Basic/DiagnosticIDs.h
@@ -231,6 +231,9 @@ class DiagnosticIDs : public RefCountedBase {
   /// "deprecated-declarations".
   static StringRef getWarningOptionForGroup(diag::Group);
 
+  /// Given a diagnostic group ID, return it

[PATCH] D126832: [clang][tablegen] adds human documentation to `WarningOption`

[Christopher Di Bella via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf21187eb2d94: [clang][tablegen] adds human documentation to 
`WarningOption` (authored by cjdb).

Changed prior to commit:
  https://reviews.llvm.org/D126832?vs=435255&id=435962#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126832/new/

https://reviews.llvm.org/D126832

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticCategories.h
  clang/include/clang/Basic/DiagnosticIDs.h
  clang/lib/Basic/DiagnosticIDs.cpp
  clang/tools/diagtool/DiagnosticNames.cpp
  clang/utils/TableGen/ClangDiagnosticsEmitter.cpp

Index: clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
===
--- clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
+++ clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
@@ -1534,14 +1534,22 @@
 const bool hasSubGroups =
 !SubGroups.empty() || (IsPedantic && !GroupsInPedantic.empty());
 if (hasSubGroups) {
-  OS << "/* DiagSubGroup" << I.second.IDNo << " */ " << SubGroupIndex;
+  OS << "/* DiagSubGroup" << I.second.IDNo << " */ " << SubGroupIndex
+ << ", ";
   if (IsPedantic)
 SubGroupIndex += GroupsInPedantic.size();
   SubGroupIndex += SubGroups.size() + 1;
 } else {
-  OS << "0";
+  OS << "0, ";
 }
 
+std::string Documentation = I.second.Defs.back()
+->getValue("Documentation")
+->getValue()
+->getAsUnquotedString();
+
+OS << "R\"(" << StringRef(Documentation).trim() << ")\"";
+
 OS << ")\n";
   }
   OS << "#endif // DIAG_ENTRY\n\n";
Index: clang/tools/diagtool/DiagnosticNames.cpp
===
--- clang/tools/diagtool/DiagnosticNames.cpp
+++ clang/tools/diagtool/DiagnosticNames.cpp
@@ -66,7 +66,7 @@
 
 // Second the table of options, sorted by name for fast binary lookup.
 static const GroupRecord OptionTable[] = {
-#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups)  \
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups, Docs)\
   {FlagNameOffset, Members, SubGroups},
 #include "clang/Basic/DiagnosticGroups.inc"
 #undef DIAG_ENTRY
Index: clang/lib/Basic/DiagnosticIDs.cpp
===
--- clang/lib/Basic/DiagnosticIDs.cpp
+++ clang/lib/Basic/DiagnosticIDs.cpp
@@ -607,6 +607,7 @@
 uint16_t NameOffset;
 uint16_t Members;
 uint16_t SubGroups;
+StringRef Documentation;
 
 // String is stored with a pascal-style length byte.
 StringRef getName() const {
@@ -618,12 +619,17 @@
 
 // Second the table of options, sorted by name for fast binary lookup.
 static const WarningOption OptionTable[] = {
-#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups)  \
-  {FlagNameOffset, Members, SubGroups},
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups, Docs)\
+  {FlagNameOffset, Members, SubGroups, Docs},
 #include "clang/Basic/DiagnosticGroups.inc"
 #undef DIAG_ENTRY
 };
 
+/// Given a diagnostic group ID, return its documentation.
+StringRef DiagnosticIDs::getWarningOptionDocumentation(diag::Group Group) {
+  return OptionTable[static_cast(Group)].Documentation;
+}
+
 StringRef DiagnosticIDs::getWarningOptionForGroup(diag::Group Group) {
   return OptionTable[static_cast(Group)].getName();
 }
Index: clang/include/clang/Basic/DiagnosticIDs.h
===
--- clang/include/clang/Basic/DiagnosticIDs.h
+++ clang/include/clang/Basic/DiagnosticIDs.h
@@ -231,6 +231,9 @@
   /// "deprecated-declarations".
   static StringRef getWarningOptionForGroup(diag::Group);
 
+  /// Given a diagnostic group ID, return its documentation.
+  static StringRef getWarningOptionDocumentation(diag::Group GroupID);
+
   /// Given a group ID, returns the flag that toggles the group.
   /// For example, for "deprecated-declarations", returns
   /// Group::DeprecatedDeclarations.
Index: clang/include/clang/Basic/DiagnosticCategories.h
===
--- clang/include/clang/Basic/DiagnosticCategories.h
+++ clang/include/clang/Basic/DiagnosticCategories.h
@@ -21,7 +21,8 @@
 };
 
 enum class Group {
-#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups) GroupName,
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups, Docs)\
+  GroupName,
 #include "clang/Basic/DiagnosticGroups.inc"
 #undef CATEGORY
 #undef DIAG_ENTRY
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -110,12 +110,12 @@
   `51414 

[clang] a01579a - [NFC] Suggest Release mode in clang GettingStarted.html

[Shivam Gupta via cfe-commits]

Author: Shivam Gupta
Date: 2022-06-10T11:00:05+05:30
New Revision: a01579ad0a1bde4d90f4fb656f07586c3097428a

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

LOG: [NFC] Suggest Release mode in clang GettingStarted.html

This fix https://github.com/llvm/llvm-project/issues/23841.
Lots of beginners are not of aware of this option do suggesting it here
would be helpful.

Added: 


Modified: 
clang/www/get_started.html

Removed: 




diff  --git a/clang/www/get_started.html b/clang/www/get_started.html
index ab5f7fac6a6c9..48ce7f8edbbcf 100755
--- a/clang/www/get_started.html
+++ b/clang/www/get_started.html
@@ -69,9 +69,13 @@ On Unix-like Systems
 cd llvm-project
 mkdir build (in-tree build is not supported)
 cd build
-cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" 
../llvm
+This builds both LLVM and Clang in release mode. Alternatively, if
+you need a debug build, switch Release to Debug. See
+https://llvm.org/docs/CMake.html#frequently-used-cmake-variables";>frequently
 used cmake variables
+for more options.
+
+cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G 
"Unix Makefiles" ../llvm
 make
-This builds both LLVM and Clang for debug mode.
 Note: For subsequent Clang development, you can just run
 make clang.
 CMake allows you to generate project files for several IDEs: Xcode,



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

[PATCH] D127496: [NFC] Suggest Release mode in clang GettingStarted.html

[Shivam Gupta via Phabricator via cfe-commits]

xgupta added a comment.

Thank you for review! Committed in 
https://reviews.llvm.org/rGa01579ad0a1bde4d90f4fb656f07586c3097428a.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127496/new/

https://reviews.llvm.org/D127496

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

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2042
+!SemaRef.CheckConstraintExpression(TransConstraint.get())) {
+  assert(Trap.hasErrorOccurred() && "CheckConstraintExpression failed, but 
"
+"did not produce a SFINAE error");

erichkeane wrote:
> ilya-biryukov wrote:
> > erichkeane wrote:
> > > ilya-biryukov wrote:
> > > > erichkeane wrote:
> > > > > ilya-biryukov wrote:
> > > > > > erichkeane wrote:
> > > > > > > This branch ends up being empty if asserts are off.  Also, it 
> > > > > > > results in CheckConstraintExpression happening 2x, which ends up 
> > > > > > > being more expensive after https://reviews.llvm.org/D126907
> > > > > > > This branch ends up being empty if asserts are off.  Also, it 
> > > > > > > results in CheckConstraintExpression happening 2x, which ends up 
> > > > > > > being more expensive after https://reviews.llvm.org/D126907
> > > > > > 
> > > > > > Yeah, good point, I have update it.
> > > > > > 
> > > > > > I am not sure why would `CheckConstraintExpression` be called 
> > > > > > twice, could you elaborate? Note that we do not call 
> > > > > > `BuildNestedRequirement` anymore and use placement new directly to 
> > > > > > avoid extra template instantiations. Instead we call 
> > > > > > `CheckConstraintExpression` directly to account for any errors.
> > > > > This check does not seem to cause a 'return' to the function, but 
> > > > > then falls through to the version on 2052, right?  
> > > > > 
> > > > > `CheckConstraintExpression`/`CheckConstraintSatisfaction`(i think?) 
> > > > > ends up now having to re-instantiate every time it is called, so any 
> > > > > ability to cache results ends up being beneficial here.
> > > > The number of calls to these functions is actually the same.
> > > > 
> > > > `CheckConstraintExpression` used to be called during 
> > > > `CheckConstraintSatisfaction` (that does instantiations) for every 
> > > > atomic constraint after the substitution. It merely checks that each 
> > > > constraint have a bool type and does not do any substitutions, so it's 
> > > > pretty cheap anyway.
> > > > 
> > > > `CheckConstraintSatisfaction` was called inside 
> > > > `BuildNestedRequirement`, we now call a different overload here 
> > > > directly that does not do any extra template instantiations directly.
> > > > 
> > > > That way we end up doing the same checks without running recursive 
> > > > template instantiations.
> > > Hmm... I guess what I'm saying is: I would like it if we could 
> > > minimize/reduce the calls to calcuateConstraintSatisfaction (in 
> > > SemaConcept.cpp) that does the call to SubstConstraintExpr (or 
> > > substExpr).  
> > > 
> > > That ends up being more expensive thanks to my other patch.
> > Ah, yes, that makes sense. Note that `CheckConstraintSatisfaction` call on 
> > 2052 does not do any substitutions, it merely evaluates the expressions if 
> > they are not dependent.
> > 
> > I will have to look more closely into your patch to get a sense of why 
> > substituting to the constraint expressions is more expensive after it.
> > 
> > BTW, I was wondering if there is any reason to substitute empty template 
> > arguments to evaluate non-dependent constraints? (This is what 
> > `CalculateConstraintSatisfaction` does)
> > I feels like merely evaluating those should be enough.
> ah, I see!  Constraint expressions get 'more expensive' because now we 
> actually have to do substitution EVERY time we evaluate, rather than just 
> having an already non-dependent expression stored.  This is because the 
> deferred constraint instantiation requires that we re-evaluate it just about 
> every time we check a constraint.
> 
> Which version of `CalculateConstraintSatisfaction` are you referring to?  it 
> DOES actually appear that the one you modify above doesn't actually DO any 
> substitution.  it DOES looklike it does some checking to make sure we 
> specifically are a boolean expr ([temp.constr.atompic]p1 ~ line 210), but it 
> isn't clear to me what the logic there is either.
> This is because the deferred constraint instantiation requires that we 
> re-evaluate it just about every time we check a constraint.
That makes sense. And this is to meet the requirements of the standard, right? 
Reading through it, we should keep "template parameter mappings" and original 
expressions for atomic constraint and only do the substitution once we actually 
need to check the constraint.

PS I should really read the code first to understand what it's doing, but 
hopefully I'm on the right track.

> Which version of CalculateConstraintSatisfaction are you referring to?
Sorry, got confused here. I meant the overload of `CheckConstraintSatisfaction` 
that does empty template argument substitution. I was wondering whether we need 
template instantiations there in the first place. It looks like it might be 
there for

[clang] b5019ff - [SystemZ/z/OS] Set DWARF version to 4 for z/OS.

[Kai Nacke via cfe-commits]

Author: Kai Nacke
Date: 2022-06-10T13:38:58-04:00
New Revision: b5019ffc8efd472d18eb9ed55a004af8d713583d

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

LOG: [SystemZ/z/OS] Set DWARF version to 4 for z/OS.

The DWARF version was raised to 5 for all platforms which do not opt
out. Default to DWARF version to 4 for z/OS again.

Reviewed By: abhina.sreeskantharajan, uweigand

Differential Revision: https://reviews.llvm.org/D127498

Added: 
clang/test/Driver/zos-dwarfversion.c

Modified: 
clang/lib/Driver/ToolChains/ZOS.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/ZOS.h 
b/clang/lib/Driver/ToolChains/ZOS.h
index 50bff09935613..53138306fd410 100644
--- a/clang/lib/Driver/ToolChains/ZOS.h
+++ b/clang/lib/Driver/ToolChains/ZOS.h
@@ -30,6 +30,8 @@ class LLVM_LIBRARY_VISIBILITY ZOS : public ToolChain {
 
   bool IsIntegratedAssemblerDefault() const override { return true; }
 
+  unsigned GetDefaultDwarfVersion() const override { return 4; }
+
   void addClangTargetOptions(
   const llvm::opt::ArgList &DriverArgs, llvm::opt::ArgStringList &CC1Args,
   Action::OffloadKind DeviceOffloadingKind) const override;

diff  --git a/clang/test/Driver/zos-dwarfversion.c 
b/clang/test/Driver/zos-dwarfversion.c
new file mode 100644
index 0..53a727102f081
--- /dev/null
+++ b/clang/test/Driver/zos-dwarfversion.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target s390x-none-zos -g -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: !"Dwarf Version", i32 4



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

[PATCH] D127498: [SystemZ/z/OS] Set DWARF version to 4 for z/OS.

[Kai Nacke via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb5019ffc8efd: [SystemZ/z/OS] Set DWARF version to 4 for 
z/OS. (authored by Kai).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127498/new/

https://reviews.llvm.org/D127498

Files:
  clang/lib/Driver/ToolChains/ZOS.h
  clang/test/Driver/zos-dwarfversion.c


Index: clang/test/Driver/zos-dwarfversion.c
===
--- /dev/null
+++ clang/test/Driver/zos-dwarfversion.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target s390x-none-zos -g -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: !"Dwarf Version", i32 4
Index: clang/lib/Driver/ToolChains/ZOS.h
===
--- clang/lib/Driver/ToolChains/ZOS.h
+++ clang/lib/Driver/ToolChains/ZOS.h
@@ -30,6 +30,8 @@
 
   bool IsIntegratedAssemblerDefault() const override { return true; }
 
+  unsigned GetDefaultDwarfVersion() const override { return 4; }
+
   void addClangTargetOptions(
   const llvm::opt::ArgList &DriverArgs, llvm::opt::ArgStringList &CC1Args,
   Action::OffloadKind DeviceOffloadingKind) const override;


Index: clang/test/Driver/zos-dwarfversion.c
===
--- /dev/null
+++ clang/test/Driver/zos-dwarfversion.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target s390x-none-zos -g -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: !"Dwarf Version", i32 4
Index: clang/lib/Driver/ToolChains/ZOS.h
===
--- clang/lib/Driver/ToolChains/ZOS.h
+++ clang/lib/Driver/ToolChains/ZOS.h
@@ -30,6 +30,8 @@
 
   bool IsIntegratedAssemblerDefault() const override { return true; }
 
+  unsigned GetDefaultDwarfVersion() const override { return 4; }
+
   void addClangTargetOptions(
   const llvm::opt::ArgList &DriverArgs, llvm::opt::ArgStringList &CC1Args,
   Action::OffloadKind DeviceOffloadingKind) const override;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Stephen Long via Phabricator via cfe-commits]

steplong added a comment.

In D126984#3571573 , @aeubanks wrote:

> IIRC in the past there was a strong preference to not have the pass manager 
> support this sort of thing
> if you want to support this, there should be an RFC for how the optimization 
> part of this will work as it may require invasive changes to the LLVM pass 
> manager
>
> (if this is purely a clang frontend thing then ignore me)

Hmm, this does affect codegen, so I'm not sure if it's purely a clang frontend 
thing. Maybe someone else can confirm. The motivation behind this was to add 
support for MSVC's `pragma optimize` in D125723 
. 
https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126974: [scan-build-py] Fix exception on shutdown with sarif-html output format

[Daniel via Phabricator via cfe-commits]

isthismyaccount accepted this revision.
isthismyaccount added a comment.
This revision is now accepted and ready to land.

lgtm


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126974/new/

https://reviews.llvm.org/D126974

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D126984#3571573 , @aeubanks wrote:

> IIRC in the past there was a strong preference to not have the pass manager 
> support this sort of thing
> if you want to support this, there should be an RFC for how the optimization 
> part of this will work as it may require invasive changes to the LLVM pass 
> manager
>
> (if this is purely a clang frontend thing then ignore me)

Hmm, does the pass manager have to support anything here? The only Clang 
codegen changes are for emitting IR attributes that we already emitted based on 
command line flags/other attributes, so I had the impression this would not be 
invasive for the backend at all.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added a comment.

In D126984#3574033 , @steplong wrote:

> In D126984#3571573 , @aeubanks 
> wrote:
>
>> IIRC in the past there was a strong preference to not have the pass manager 
>> support this sort of thing
>> if you want to support this, there should be an RFC for how the optimization 
>> part of this will work as it may require invasive changes to the LLVM pass 
>> manager
>>
>> (if this is purely a clang frontend thing then ignore me)
>
> Hmm, this does affect codegen, so I'm not sure if it's purely a clang 
> frontend thing. Maybe someone else can confirm. The motivation behind this 
> was to add support for MSVC's `pragma optimize` in D125723 
> . 
> https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170

adding `optsize`/`minsize`/`optnone` attributes to functions is fine and is 
already handled in optimizations, but being able to specify `-O[0-3]` would 
require a lot of new complexity in the pass manager which would likely not be 
worth it
I think D125723  is fine as is


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126291: [flang][Driver] Update link job on windows

[Markus Mützel via Phabricator via cfe-commits]

mmuetzel added inline comments.



Comment at: clang/lib/Driver/ToolChains/Darwin.cpp:645
   if (getToolChain().getDriver().IsFlangMode() &&
   Args.hasArg(options::OPT_flang_experimental_exec)) {
 addFortranRuntimeLibraryPath(getToolChain(), Args, CmdArgs);

If this condition is removed from the GNU, MSVC, and MinGW toolchain files, it 
should probably also be removed from here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126291/new/

https://reviews.llvm.org/D126291

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

I agree with @aeubanks , this feature requires major changes to pass manager 
and I see no value to land this currently.

I see that somebody may prefer “opt for size”, but this is exposed via 
“minsize” attribute so I see no strong need for optimize(“-Os”)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added a comment.

In D126984#3574046 , @aaron.ballman 
wrote:

> In D126984#3571573 , @aeubanks 
> wrote:
>
>> IIRC in the past there was a strong preference to not have the pass manager 
>> support this sort of thing
>> if you want to support this, there should be an RFC for how the optimization 
>> part of this will work as it may require invasive changes to the LLVM pass 
>> manager
>>
>> (if this is purely a clang frontend thing then ignore me)
>
> Hmm, does the pass manager have to support anything here? The only Clang 
> codegen changes are for emitting IR attributes that we already emitted based 
> on command line flags/other attributes, so I had the impression this would 
> not be invasive for the backend at all.

if we're allowing individual functions to specify that they want the `-O1` 
pipeline when everything else in the module should be compiled with `-O2`, 
that's a huge change in the pass manager. but perhaps I'm misunderstanding the 
point of this patch


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

So from what I can tell, the problem is evaluating `Constraint` on `initiate`, 
and trying to find the 'right' argument from the 
`MultiLevelTemplateArgumentList` for `RawCompletionToken`.  The problem is that 
the `RawCompletionToken`, as a template parameter, gets 'filled in to' the 
Concept relative to `initiate` instead of relative to the "root".

I suspect we have to go back to when the `ConceptSpecializationExpr` was 
created, and change the template argument to be relative to the top?  I'm not 
sure that is the right answer here, or what else that could screw up?  In my 
head, I think it should be 'fine', since the 'relative to the top' is the way 
we evaluate ALL constraints (including these in the template argument), but I 
probably need to think it through.

See:

  FunctionTemplateDecl 0x13575598  
col:17 initiate
  |-TemplateTypeParmDecl 0x13573fd8  col:24 typename depth 0 
index 0 Initiation
  |-TemplateTypeParmDecl 0x13574060  col:47 Concept 0x13555838 
'Constraint' depth 0 index 1 RawCompletionToken
  | `-ConceptSpecializationExpr 0x135741a8  'bool' Concept 0x13555838 
'Constraint'
  |   `-TemplateArgument  type 'RawCompletionToken'
  | `-TemplateTypeParmType 0x13574130 'RawCompletionToken' dependent depth 
0 index 1
  |   `-TemplateTypeParm 0x13574060 'RawCompletionToken'




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126907/new/

https://reviews.llvm.org/D126907

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Stephen Long via Phabricator via cfe-commits]

steplong added a comment.

In D126984#3574077 , @aeubanks wrote:

> In D126984#3574046 , @aaron.ballman 
> wrote:
>
>> In D126984#3571573 , @aeubanks 
>> wrote:
>>
>>> IIRC in the past there was a strong preference to not have the pass manager 
>>> support this sort of thing
>>> if you want to support this, there should be an RFC for how the 
>>> optimization part of this will work as it may require invasive changes to 
>>> the LLVM pass manager
>>>
>>> (if this is purely a clang frontend thing then ignore me)
>>
>> Hmm, does the pass manager have to support anything here? The only Clang 
>> codegen changes are for emitting IR attributes that we already emitted based 
>> on command line flags/other attributes, so I had the impression this would 
>> not be invasive for the backend at all.
>
> if we're allowing individual functions to specify that they want the `-O1` 
> pipeline when everything else in the module should be compiled with `-O2`, 
> that's a huge change in the pass manager. but perhaps I'm misunderstanding 
> the point of this patch

That makes sense. The MSVC pragma allows 4 options, "stgy":

| Parameter | On
  | Off 
   |
| - | 
---
 |  
  |
| g | Deprecated
  | Deprecated  
   |
| s | Add MinSize   
  | Remove MinSize (I think this would 
be difficult to do if -Os is passed on the cmdline) |
| t | Add -O2 (We can't support -O2 with this attribute so ignore)  
  | Add Optnone 
   |
| y | Add frame-pointers (We can't support -f arguments with the 
attribute in this patch so we are ignoring this) | No frame-pointers (Same 
thing as on)   |
|

For our use case, I think we only really see `#pragma optimize("", off)` and 
`#pragma optimize("", on)`, so I'm not opposed to abandoning this patch and 
just supporting the common use case for now. I think `#pragma optimize("", on)` 
would just mean do nothing and apply whatever is on the command line and 
`#pragma optimize("", off)` would mean add optnone to the functions below it


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D127515: [Clang] Change host/device only compilation to a driver mode

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: tra, jdoerfert, JonChesterfield, yaxunl.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

We use the flags `--offload-host-only` and `--offload-device-only` to
change the driver's code generation for offloading programs. These are
currently parsed out independently in many places. This patch simply
refactors this to work as a mode for the Driver. This stopped us from
emitting warnings if unused because it's always used now, but I don't
think this is a great loss.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127515

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/cuda-unused-arg-warning.cu

Index: clang/test/Driver/cuda-unused-arg-warning.cu
===
--- clang/test/Driver/cuda-unused-arg-warning.cu
+++ /dev/null
@@ -1,28 +0,0 @@
-// Tests that we trigger unused-arg warnings on CUDA flags appropriately.
-
-// REQUIRES: x86-registered-target
-// REQUIRES: nvptx-registered-target
-
-// --cuda-host-only and --cuda-compile-host-device should never trigger an
-// unused arg warning.
-// RUN: %clang -### -target x86_64-linux-gnu --cuda-host-only -c %s 2>&1 | \
-// RUN:FileCheck %s
-// RUN: %clang -### -target x86_64-linux-gnu --cuda-host-only -x c -c %s 2>&1 | \
-// RUN:FileCheck %s
-// RUN: %clang -### -target x86_64-linux-gnu --cuda-compile-host-device -c %s 2>&1 | \
-// RUN:FileCheck %s
-// RUN: %clang -### -target x86_64-linux-gnu --cuda-compile-host-device -x c -c %s 2>&1 | \
-// RUN:FileCheck %s
-
-// --cuda-device-only should warn during non-CUDA compilation.
-// RUN: %clang -### -target x86_64-linux-gnu --cuda-device-only -x c -c %s 2>&1 | \
-// RUN:FileCheck -check-prefix UNUSED-WARNING %s
-
-// --cuda-device-only should not produce warning compiling CUDA files
-// RUN: %clang -### -target x86_64-linux-gnu --cuda-device-only -c %s 2>&1 | \
-// RUN:FileCheck -check-prefix NO-UNUSED-WARNING %s
-
-// CHECK-NOT: warning: argument unused during compilation: '--cuda-host-only'
-// CHECK-NOT: warning: argument unused during compilation: '--cuda-compile-host-device'
-// UNUSED-WARNING: warning: argument unused during compilation: '--cuda-device-only'
-// NO-UNUSED-WARNING-NOT: warning: argument unused during compilation: '--cuda-device-only'
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -192,13 +192,14 @@
IntrusiveRefCntPtr VFS)
 : Diags(Diags), VFS(std::move(VFS)), Mode(GCCMode),
   SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone),
-  CXX20HeaderType(HeaderMode_None), ModulesModeCXX20(false),
-  LTOMode(LTOK_None), ClangExecutable(ClangExecutable),
-  SysRoot(DEFAULT_SYSROOT), DriverTitle(Title), CCCPrintBindings(false),
-  CCPrintOptions(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCPrintProcessStats(false),
-  TargetTriple(TargetTriple), Saver(Alloc), CheckInputsExist(true),
-  ProbePrecompiled(true), SuppressMissingInputWarning(false) {
+  Offload(OffloadHostDevice), CXX20HeaderType(HeaderMode_None),
+  ModulesModeCXX20(false), LTOMode(LTOK_None),
+  ClangExecutable(ClangExecutable), SysRoot(DEFAULT_SYSROOT),
+  DriverTitle(Title), CCCPrintBindings(false), CCPrintOptions(false),
+  CCPrintHeaders(false), CCLogDiagnostics(false), CCGenDiagnostics(false),
+  CCPrintProcessStats(false), TargetTriple(TargetTriple), Saver(Alloc),
+  CheckInputsExist(true), ProbePrecompiled(true),
+  SuppressMissingInputWarning(false) {
   // Provide a sane fallback if no VFS is specified.
   if (!this->VFS)
 this->VFS = llvm::vfs::getRealFileSystem();
@@ -1284,6 +1285,17 @@
 .Default(SaveTempsCwd);
   }
 
+  if (const Arg *A = Args.getLastArg(options::OPT_offload_host_only,
+ options::OPT_offload_device_only,
+ options::OPT_offload_host_device)) {
+if (A->getOption().matches(options::OPT_offload_host_only))
+  Offload = OffloadHost;
+else if (A->getOption().matches(options::OPT_offload_device_only))
+  Offload = OffloadDevice;
+else
+  Offload = OffloadHostDevice;
+  }
+
   setLTOMode(Args);
 
   // Process -fembed-bitcode= flags.
@@ -2920,15 +2932,8 @@
   ? C.getSingleOffloadToolChain()
   : C.getSingleOffloadToolChain());
 
-  Arg *PartialCompilationArg = Args.getLastArg(
-  options::OPT_offload_host_only, options::OPT_offload_device_only,
-  options::OPT_offload_host_device);
-  CompileHostOnly =
-  PartialCompilationArg && PartialCompilationArg->getOption().matches(
-  

[PATCH] D126495: [clang-tidy] Organize test docs into subdirectories by module (NFC)

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

In D126495#3571511 , @njames93 wrote:

> Search engines isn't really an issue, its more people who are using older 
> versions of llvm that try and go to the documentation which turns out is a 
> dead link. 
> Having said that, I still think the lack of a redirect shouldn't block this 
> change.

Aren't we archiving old versions of the documentation, though?

So if I know I'm using LLVM 3.8, I would consult the documentation for 3.8 not 
top-of-tree, and all the links would work correctly within the 3.8 
documentation, adjusting for the base path.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126495/new/

https://reviews.llvm.org/D126495

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added a comment.

In D126984#3574091 , @steplong wrote:

> In D126984#3574077 , @aeubanks 
> wrote:
>
>> In D126984#3574046 , 
>> @aaron.ballman wrote:
>>
>>> In D126984#3571573 , @aeubanks 
>>> wrote:
>>>
 IIRC in the past there was a strong preference to not have the pass 
 manager support this sort of thing
 if you want to support this, there should be an RFC for how the 
 optimization part of this will work as it may require invasive changes to 
 the LLVM pass manager

 (if this is purely a clang frontend thing then ignore me)
>>>
>>> Hmm, does the pass manager have to support anything here? The only Clang 
>>> codegen changes are for emitting IR attributes that we already emitted 
>>> based on command line flags/other attributes, so I had the impression this 
>>> would not be invasive for the backend at all.
>>
>> if we're allowing individual functions to specify that they want the `-O1` 
>> pipeline when everything else in the module should be compiled with `-O2`, 
>> that's a huge change in the pass manager. but perhaps I'm misunderstanding 
>> the point of this patch
>
> That makes sense. The MSVC pragma allows 4 options, "stgy":
>
> | Parameter | On  
> | Off 
>|
> | - | 
> ---
>  |
> |
> | g | Deprecated  
> | Deprecated  
>|
> | s | Add MinSize 
> | Remove MinSize (I think this 
> would be difficult to do if -Os is passed on the cmdline) |
> | t | Add -O2 (We can't support -O2 with this attribute so ignore)
> | Add Optnone 
>|
> | y | Add frame-pointers (We can't support -f arguments with the 
> attribute in this patch so we are ignoring this) | No frame-pointers (Same 
> thing as on)   |
> |
>
> For our use case, I think we only really see `#pragma optimize("", off)` and 
> `#pragma optimize("", on)`, so I'm not opposed to abandoning this patch and 
> just supporting the common use case for now. I think `#pragma optimize("", 
> on)` would just mean do nothing and apply whatever is on the command line and 
> `#pragma optimize("", off)` would mean add optnone to the functions below it

looks good to me, I agree that we should just honor whatever optimization level 
the file is compiled with with `t`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126974: [scan-build-py] Fix exception on shutdown with sarif-html output format

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

Would it be possible to reupload the diff with full context?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126974/new/

https://reviews.llvm.org/D126974

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D126984#3574077 , @aeubanks wrote:

> In D126984#3574046 , @aaron.ballman 
> wrote:
>
>> In D126984#3571573 , @aeubanks 
>> wrote:
>>
>>> IIRC in the past there was a strong preference to not have the pass manager 
>>> support this sort of thing
>>> if you want to support this, there should be an RFC for how the 
>>> optimization part of this will work as it may require invasive changes to 
>>> the LLVM pass manager
>>>
>>> (if this is purely a clang frontend thing then ignore me)
>>
>> Hmm, does the pass manager have to support anything here? The only Clang 
>> codegen changes are for emitting IR attributes that we already emitted based 
>> on command line flags/other attributes, so I had the impression this would 
>> not be invasive for the backend at all.
>
> if we're allowing individual functions to specify that they want the `-O1` 
> pipeline when everything else in the module should be compiled with `-O2`, 
> that's a huge change in the pass manager. but perhaps I'm misunderstanding 
> the point of this patch

I guess I'm not seeing what burden is being added here (you may still be 
correct though!)

The codegen changes basically boil down to:

  if (!HasOptnone) {
if (CodeGenOpts.OptimizeSize || HasOptsize) // This was updated for || 
HasOptsize
  FuncAttrs.addAttribute(llvm::Attribute::OptimizeForSize);
if (CodeGenOpts.OptimizeSize == 2)
  FuncAttrs.addAttribute(llvm::Attribute::MinSize);
  }

and

  bool HasOptimizeAttrO0 = false; // NEW
  if (const auto *OA = D->getAttr())
HasOptimizeAttrO0 = OA->getOptLevel() == OptimizeAttr::O0;
  
  // Add optnone, but do so only if the function isn't always_inline.
  if ((ShouldAddOptNone || D->hasAttr() ||
   HasOptimizeAttrO0) &&  // NEW
  !F->hasFnAttribute(llvm::Attribute::AlwaysInline)) {
B.addAttribute(llvm::Attribute::OptimizeNone);

For my own education, are you saying that these changes are specifying the 
entire -O pipeline?

The patch looks for `O0` in the attribute, but the other O values are noops. 
We do some mapping though:

  OptimizeAttr::OptLevelKind Kind = OA->getOptLevel();
  HasOptnone = HasOptnone || (Kind == OptimizeAttr::O0);
  HasOptsize = Kind == OptimizeAttr::Os || Kind == OptimizeAttr::Og ||
   Kind == OptimizeAttr::Ofast || Kind == OptimizeAttr::Oz;

but I'm failing to understand why this would be a concern for the backend given 
that we already support setting the LLVM IR flags based on other attributes. 
e.g., why is `[[clang::optnone]]` okay but `[[gnu::optimize("O0")]]` a problem?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D127518: [Diagnostics] Fix inconsistent shift-overflow warnings in C++20

[Shivam Gupta via Phabricator via cfe-commits]

xgupta created this revision.
xgupta added a reviewer: aaron.ballman.
Herald added a project: All.
xgupta requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes https://github.com/llvm/llvm-project/issues/52873.
Don't warn in C++2A mode (and newer), as signed left shifts
always wrap and never overflow. Ref. -
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127518

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CXX/expr/expr.const/p2-0x.cpp
  clang/test/SemaCXX/constant-expression-cxx2a.cpp
  clang/test/SemaCXX/shift.cpp


Index: clang/test/SemaCXX/shift.cpp
===
--- clang/test/SemaCXX/shift.cpp
+++ clang/test/SemaCXX/shift.cpp
@@ -41,7 +41,7 @@
 
   int i;
   i = 1 << (WORD_BIT - 2);
-  i = 2 << (WORD_BIT - 1); // expected-warning {{bits to represent, but 'int' 
only has}}
+  i = 2 << (WORD_BIT - 1); // cxx17-warning {{bits to represent, but 'int' 
only has}}
   i = 1 << (WORD_BIT - 1); // expected-warning {{sets the sign bit of the 
shift expression}}
   i = -1 << (WORD_BIT - 1); // cxx17-warning {{shifting a negative signed 
value is undefined}}
   i = -1 << 0; // cxx17-warning {{shifting a negative signed value is 
undefined}}
@@ -53,7 +53,7 @@
   u = 5U << (WORD_BIT - 1);
 
   long long int lli;
-  lli = INT_MIN << 2; // cxx17-warning {{shifting a negative signed value is 
undefined}} cxx2a-warning {{requires 34 bits to represent}}
+  lli = INT_MIN << 2; // cxx17-warning {{shifting a negative signed value is 
undefined}}
   lli = 1LL << (sizeof(long long) * CHAR_BIT - 2);
 }
 
Index: clang/test/SemaCXX/constant-expression-cxx2a.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx2a.cpp
+++ clang/test/SemaCXX/constant-expression-cxx2a.cpp
@@ -530,8 +530,8 @@
   using int32 = __INT32_TYPE__;
   static_assert(uint32(int32(0x1234) << 16) == 0x1234);
   static_assert(uint32(int32(0x1234) << 19) == 0x91a0);
-  static_assert(uint32(int32(0x1234) << 20) == 0x2340); // 
expected-warning {{requires 34 bits}}
-  static_assert(uint32(int32(0x1234) << 24) == 0x3400); // 
expected-warning {{requires 38 bits}}
+  static_assert(uint32(int32(0x1234) << 20) == 0x2340);
+  static_assert(uint32(int32(0x1234) << 24) == 0x3400);
   static_assert(uint32(int32(-1) << 31) == 0x8000);
 
   static_assert(-1 >> 1 == -1);
Index: clang/test/CXX/expr/expr.const/p2-0x.cpp
===
--- clang/test/CXX/expr/expr.const/p2-0x.cpp
+++ clang/test/CXX/expr/expr.const/p2-0x.cpp
@@ -162,9 +162,9 @@
   constexpr int shl_signed_ok = 1 << 30; // ok
   constexpr int shl_signed_into_sign = 1 << 31; // ok (DR1457)
   constexpr int shl_signed_into_sign_2 = 0x7fff << 1; // ok (DR1457)
-  constexpr int shl_signed_off_end = 2 << 31; // cxx11-error {{constant 
expression}} cxx11-note {{signed left shift discards bits}} expected-warning 
{{signed shift result (0x1) requires 34 bits to represent, but 'int' 
only has 32 bits}}
-  constexpr int shl_signed_off_end_2 = 0x7fff << 2; // cxx11-error 
{{constant expression}} cxx11-note {{signed left shift discards bits}} 
expected-warning {{signed shift result (0x1FFFC) requires 34 bits to 
represent, but 'int' only has 32 bits}}
-  constexpr int shl_signed_overflow = 1024 << 31; // cxx11-error {{constant 
expression}} cxx11-note {{signed left shift discards bits}} expected-warning 
{{requires 43 bits to represent}}
+  constexpr int shl_signed_off_end = 2 << 31; // cxx11-error {{constant 
expression}} cxx11-note {{signed left shift discards bits}} cxx11-warning 
{{signed shift result (0x1) requires 34 bits to represent, but 'int' 
only has 32 bits}}
+  constexpr int shl_signed_off_end_2 = 0x7fff << 2; // cxx11-error 
{{constant expression}} cxx11-note {{signed left shift discards bits}} 
cxx11-warning {{signed shift result (0x1FFFC) requires 34 bits to 
represent, but 'int' only has 32 bits}}
+  constexpr int shl_signed_overflow = 1024 << 31; // cxx11-error {{constant 
expression}} cxx11-note {{signed left shift discards bits}} cxx11-warning 
{{requires 43 bits to represent}}
   constexpr int shl_signed_ok2 = 1024 << 20; // ok
 
   constexpr int shr_m1 = 0 >> -1; // expected-error {{constant expression}} 
expected-note {{negative shift count -1}}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -11453,6 +11453,9 @@
 return;
   }
 
+  if (S.getLangOpts().CPlusPlus20)
+return;
+
   S.Diag(Loc, diag::warn_shift_result_gt_typewidth)
 << HexResult.str() << Result.getMinSignedBits() << LHSType
 << Left.getBitWidth() << LHS.get()->getSourceRange()


Index: clang/test/SemaCXX/shift.cpp
=

[PATCH] D127408: [clang][driver] Introduce new -fdriver-only flag

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith accepted this revision.
dexonsmith added a comment.

LGTM with a minor comment on the test.




Comment at: clang/test/Driver/driver-only.c:13
+
+// Check that -fdriver-only respects -v.
+//

Should there be a `-check-epmty` or similar when `-v` is not passed? (This 
tests the positive, but I don’t see a test that it’s not ALWAYS verbose.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127408/new/

https://reviews.llvm.org/D127408

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

[PATCH] D127251: [Lex] Fix `fixits` for typo-corrections of preprocessing directives within skipped blocks

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Preprocessor/suggest-typoed-directive.c:1-2
+// clang-format off
+
 // RUN: %clang_cc1 -fsyntax-only -verify=pre-c2x-cpp2b %s

akyrtzi wrote:
> akyrtzi wrote:
> > aaron.ballman wrote:
> > > You can remove this -- we don't require test files to be formatted 
> > > properly, and formatting comments can quickly become distracting.
> > The debian bot failed for this patch with `clang-format` complaining about 
> > the test file. Was this unintentional?
> For reference the bot failure is here: 
> https://buildkite.com/llvm-project/premerge-checks/builds/96481#01814013-61ed-4a53-a9d0-4d1a183ac360
Yeah -- the precommit CI bots still check it and report back failures, which is 
incredibly frustrating given how much noise that generates. I've filed 
https://github.com/llvm/llvm-project/issues/55982 to track that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127251/new/

https://reviews.llvm.org/D127251

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

[PATCH] D127519: [clang-cl] Accept /FA[c][s][u], but ignore the arguments

[Stephen Long via Phabricator via cfe-commits]

steplong created this revision.
Herald added a project: All.
steplong requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Previously, /FAsc would emit a warning. Now, it will just do what /FA does.

https://docs.microsoft.com/en-us/cpp/build/reference/fa-fa-listing-file?view=msvc-170


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127519

Files:
  clang/lib/Driver/Driver.cpp


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4872,7 +4872,8 @@
 return TC.useIntegratedAs() && !SaveTemps &&
!C.getArgs().hasArg(options::OPT_via_file_asm) &&
!C.getArgs().hasArg(options::OPT__SLASH_FA) &&
-   !C.getArgs().hasArg(options::OPT__SLASH_Fa);
+   !C.getArgs().hasArg(options::OPT__SLASH_Fa) &&
+   !C.getArgs().hasArg(options::OPT__SLASH_FA_joined);
   }
 
   /// Return true if a preprocessor action can be collapsed.
@@ -5552,7 +5553,8 @@
   // Is this the assembly listing for /FA?
   if (JA.getType() == types::TY_PP_Asm &&
   (C.getArgs().hasArg(options::OPT__SLASH_FA) ||
-   C.getArgs().hasArg(options::OPT__SLASH_Fa))) {
+   C.getArgs().hasArg(options::OPT__SLASH_Fa) ||
+   C.getArgs().hasArg(options::OPT__SLASH_FA_joined))) {
 // Use /Fa and the input filename to determine the asm file name.
 StringRef BaseName = llvm::sys::path::filename(BaseInput);
 StringRef FaValue = C.getArgs().getLastArgValue(options::OPT__SLASH_Fa);


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4872,7 +4872,8 @@
 return TC.useIntegratedAs() && !SaveTemps &&
!C.getArgs().hasArg(options::OPT_via_file_asm) &&
!C.getArgs().hasArg(options::OPT__SLASH_FA) &&
-   !C.getArgs().hasArg(options::OPT__SLASH_Fa);
+   !C.getArgs().hasArg(options::OPT__SLASH_Fa) &&
+   !C.getArgs().hasArg(options::OPT__SLASH_FA_joined);
   }
 
   /// Return true if a preprocessor action can be collapsed.
@@ -5552,7 +5553,8 @@
   // Is this the assembly listing for /FA?
   if (JA.getType() == types::TY_PP_Asm &&
   (C.getArgs().hasArg(options::OPT__SLASH_FA) ||
-   C.getArgs().hasArg(options::OPT__SLASH_Fa))) {
+   C.getArgs().hasArg(options::OPT__SLASH_Fa) ||
+   C.getArgs().hasArg(options::OPT__SLASH_FA_joined))) {
 // Use /Fa and the input filename to determine the asm file name.
 StringRef BaseName = llvm::sys::path::filename(BaseInput);
 StringRef FaValue = C.getArgs().getLastArgValue(options::OPT__SLASH_Fa);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127519: [clang-cl] Accept /FA[c][s][u], but ignore the arguments

[Stephen Long via Phabricator via cfe-commits]

steplong added reviewers: rnk, hans.
steplong added a comment.

I'm not sure which test file to modify and how to test this. I do see it 
generating the `.asm` file now when I pass `/FAsc`, not the `.codd` file though 
since we are ignoring the `c` argument.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127519/new/

https://reviews.llvm.org/D127519

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

[PATCH] D126974: [scan-build-py] Fix exception on shutdown with sarif-html output format

[Anders Waldenborg via Phabricator via cfe-commits]

wanders updated this revision to Diff 435999.
wanders added a comment.

Updated patch with full context.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126974/new/

https://reviews.llvm.org/D126974

Files:
  clang/tools/scan-build-py/lib/libscanbuild/analyze.py


Index: clang/tools/scan-build-py/lib/libscanbuild/analyze.py
===
--- clang/tools/scan-build-py/lib/libscanbuild/analyze.py
+++ clang/tools/scan-build-py/lib/libscanbuild/analyze.py
@@ -357,6 +357,7 @@
 try:
 yield name
 finally:
+args = (name,)
 if os.listdir(name):
 if output_format not in ['sarif', 'sarif-html']: # FIXME:
 # 'scan-view' currently does not support sarif format.
@@ -364,6 +365,7 @@
 elif output_format == 'sarif-html':
 msg = "Run 'scan-view %s' to examine bug reports or see " \
 "merged sarif results at %s/results-merged.sarif."
+args = (name, name)
 else:
 msg = "View merged sarif results at %s/results-merged.sarif."
 keep = True
@@ -372,7 +374,7 @@
 msg = "Report directory '%s' contains no report, but kept."
 else:
 msg = "Removing directory '%s' because it contains no report."
-logging.warning(msg, name)
+logging.warning(msg, *args)
 
 if not keep:
 os.rmdir(name)


Index: clang/tools/scan-build-py/lib/libscanbuild/analyze.py
===
--- clang/tools/scan-build-py/lib/libscanbuild/analyze.py
+++ clang/tools/scan-build-py/lib/libscanbuild/analyze.py
@@ -357,6 +357,7 @@
 try:
 yield name
 finally:
+args = (name,)
 if os.listdir(name):
 if output_format not in ['sarif', 'sarif-html']: # FIXME:
 # 'scan-view' currently does not support sarif format.
@@ -364,6 +365,7 @@
 elif output_format == 'sarif-html':
 msg = "Run 'scan-view %s' to examine bug reports or see " \
 "merged sarif results at %s/results-merged.sarif."
+args = (name, name)
 else:
 msg = "View merged sarif results at %s/results-merged.sarif."
 keep = True
@@ -372,7 +374,7 @@
 msg = "Report directory '%s' contains no report, but kept."
 else:
 msg = "Removing directory '%s' because it contains no report."
-logging.warning(msg, name)
+logging.warning(msg, *args)
 
 if not keep:
 os.rmdir(name)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

[[gnu::optimize("O0")]] is okay but [[gnu::optimize("O3 
")]] is not gonna work without 
major changes. Not sure why we should deliver half-broken new attribute.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126651: [clang-diff] Fix getStmtValue when dealing with wide, UTF16 UTF32 chars

[Johannes Altmanninger via Phabricator via cfe-commits]

johannes added a comment.

No idea why the conversion fails for the wide string.
First step is to reproduce the problem. I guess we should try in a Ubuntu VM.
Is there an easy way to see if other builders succeeded?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126651/new/

https://reviews.llvm.org/D126651

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

[PATCH] D127471: [Coroutines] Convert coroutine.presplit to enum attr

[Eugene Zhulenev via Phabricator via cfe-commits]

ezhulenev accepted this revision.
ezhulenev added a comment.
This revision is now accepted and ready to land.

Yes, that's the correct MLIR way of passing attributes to LLVM.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127471/new/

https://reviews.llvm.org/D127471

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

[PATCH] D126974: [scan-build-py] Fix exception on shutdown with sarif-html output format

[Petr Hosek via Phabricator via cfe-commits]

phosek accepted this revision.
phosek added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126974/new/

https://reviews.llvm.org/D126974

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

[clang] a9ad689 - [clang][dataflow] Don't `assert` full LHS coverage in `optional` model

[Yitzhak Mandelbaum via cfe-commits]

Author: Sam Estep
Date: 2022-06-10T19:10:20Z
New Revision: a9ad689e352dd1037f947dacc7d01c091b67e00c

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

LOG: [clang][dataflow] Don't `assert` full LHS coverage in `optional` model

Followup to D127434.

Reviewed By: ymandel, sgatev

Differential Revision: https://reviews.llvm.org/D127502

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp

Removed: 




diff  --git 
a/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp 
b/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
index 993d56e44a87d..f837fe31c6cd8 100644
--- a/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -450,7 +450,8 @@ void transferAssignment(const CXXOperatorCallExpr *E, 
BoolValue &HasValueVal,
 
   auto *OptionalLoc =
   State.Env.getStorageLocation(*E->getArg(0), SkipPast::Reference);
-  assert(OptionalLoc != nullptr);
+  if (OptionalLoc == nullptr)
+return;
 
   State.Env.setValue(*OptionalLoc, createOptionalValue(State.Env, 
HasValueVal));
 



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

[PATCH] D127502: [clang][dataflow] Don't `assert` full LHS coverage in `optional` model

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa9ad689e352d: [clang][dataflow] Don't `assert` full LHS 
coverage in `optional` model (authored by samestep, committed by ymandel).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127502/new/

https://reviews.llvm.org/D127502

Files:
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp


Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -450,7 +450,8 @@
 
   auto *OptionalLoc =
   State.Env.getStorageLocation(*E->getArg(0), SkipPast::Reference);
-  assert(OptionalLoc != nullptr);
+  if (OptionalLoc == nullptr)
+return;
 
   State.Env.setValue(*OptionalLoc, createOptionalValue(State.Env, 
HasValueVal));
 


Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -450,7 +450,8 @@
 
   auto *OptionalLoc =
   State.Env.getStorageLocation(*E->getArg(0), SkipPast::Reference);
-  assert(OptionalLoc != nullptr);
+  if (OptionalLoc == nullptr)
+return;
 
   State.Env.setValue(*OptionalLoc, createOptionalValue(State.Env, HasValueVal));
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125936: [Sema] Relax an assertion in BuildStmtExpr

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125936/new/

https://reviews.llvm.org/D125936

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

[clang] b3b08ad - [Clang] Added missing doc for minsize attribute

[Dávid Bolvanský via cfe-commits]

Author: Dávid Bolvanský
Date: 2022-06-10T21:18:45+02:00
New Revision: b3b08ad6239ccf68bb725defde07edb7a471a9b2

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

LOG: [Clang] Added missing doc for minsize attribute

Fixes https://github.com/llvm/llvm-project/issues/53226

Added: 


Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index fe6295f3069c..d1f407259cb6 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -1438,7 +1438,7 @@ def Final : InheritableAttr {
 def MinSize : InheritableAttr {
   let Spellings = [Clang<"minsize">];
   let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
-  let Documentation = [Undocumented];
+  let Documentation = [MinSizeDocs];
 }
 
 def FlagEnum : InheritableAttr {

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 872eb8a26673..59bbc80708ed 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5833,6 +5833,15 @@ attribute can also be written using C++11 syntax: 
``[[mig::server_routine]]``.
 }];
 }
 
+def MinSizeDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+This function attribute indicates that optimization passes and code generator 
passes
+make choices that keep the function code size as small as possible. 
Optimizations may
+also sacrifice runtime performance in order to minimize the size of the 
generated code.
+  }];
+}
+
 def MSAllocatorDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{



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

[PATCH] D127528: [Clang] Let the linker choose shared or static libunwind unless specified

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added reviewers: saugustine, jkz.
Herald added a subscriber: mstorsjo.
Herald added a project: All.
phosek requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

We shouldn't assume that libunwind.so is available. Rather can defer
the decision to the linker which defaults to libunwind.so, but if .so
isn't available, it'd pick libunwind.a. Users can use -static-libgcc
and -shared-libgcc to override this behavior and explicitly choose
the version they want.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127528

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/compiler-rt-unwind.c


Index: clang/test/Driver/compiler-rt-unwind.c
===
--- clang/test/Driver/compiler-rt-unwind.c
+++ clang/test/Driver/compiler-rt-unwind.c
@@ -13,7 +13,15 @@
 // RUN: --gcc-toolchain="" -resource-dir=%S/Inputs/resource_dir \
 // RUN:   | FileCheck --check-prefix=RTLIB-GCC-UNWINDLIB-COMPILER-RT %s
 // RTLIB-GCC-UNWINDLIB-COMPILER-RT: "{{.*}}lgcc"
-// RTLIB-GCC-UNWINDLIB-COMPILER-RT: "{{.*}}l:libunwind.so"
+// RTLIB-GCC-UNWINDLIB-COMPILER-RT: "{{.*}}lunwind"
+//
+// RUN: %clang -### %s 2>&1 \
+// RUN: --target=x86_64-unknown-linux -rtlib=libgcc --unwindlib=libunwind \
+// RUN: -shared-libgcc \
+// RUN: --gcc-toolchain="" -resource-dir=%S/Inputs/resource_dir \
+// RUN:   | FileCheck --check-prefix=RTLIB-GCC-SHARED-UNWINDLIB-COMPILER-RT %s
+// RTLIB-GCC-SHARED-UNWINDLIB-COMPILER-RT: "{{.*}}l:libunwind.so"
+// RTLIB-GCC-SHARED-UNWINDLIB-COMPILER-RT: "{{.*}}lgcc"
 //
 // RUN: %clang -### %s 2>&1 \
 // RUN: --target=x86_64-unknown-linux -rtlib=libgcc --unwindlib=libunwind \
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1471,17 +1471,12 @@
 static LibGccType getLibGccType(const ToolChain &TC, const Driver &D,
 const ArgList &Args) {
   if (Args.hasArg(options::OPT_static_libgcc) ||
-  Args.hasArg(options::OPT_static) || Args.hasArg(options::OPT_static_pie))
+  Args.hasArg(options::OPT_static) || Args.hasArg(options::OPT_static_pie) 
||
+  // The Android NDK only provides libunwind.a, not libunwind.so.
+  TC.getTriple().isAndroid())
 return LibGccType::StaticLibGcc;
   if (Args.hasArg(options::OPT_shared_libgcc))
 return LibGccType::SharedLibGcc;
-  // The Android NDK only provides libunwind.a, not libunwind.so.
-  if (TC.getTriple().isAndroid())
-return LibGccType::StaticLibGcc;
-  // For MinGW, don't imply a shared libgcc here, we only want to return
-  // SharedLibGcc if that was explicitly requested.
-  if (D.CCCIsCXX() && !TC.getTriple().isOSCygMing())
-return LibGccType::SharedLibGcc;
   return LibGccType::UnspecifiedLibGcc;
 }
 
@@ -1508,7 +1503,7 @@
 return;
 
   LibGccType LGT = getLibGccType(TC, D, Args);
-  bool AsNeeded = LGT == LibGccType::UnspecifiedLibGcc &&
+  bool AsNeeded = LGT == LibGccType::UnspecifiedLibGcc && !D.CCCIsCXX() &&
   !TC.getTriple().isAndroid() &&
   !TC.getTriple().isOSCygMing() && !TC.getTriple().isOSAIX();
   if (AsNeeded)
@@ -1532,15 +1527,15 @@
 CmdArgs.push_back("-lunwind");
 } else if (LGT == LibGccType::StaticLibGcc) {
   CmdArgs.push_back("-l:libunwind.a");
-} else if (TC.getTriple().isOSCygMing()) {
-  if (LGT == LibGccType::SharedLibGcc)
+} else if (LGT == LibGccType::SharedLibGcc) {
+  if (TC.getTriple().isOSCygMing())
 CmdArgs.push_back("-l:libunwind.dll.a");
   else
-// Let the linker choose between libunwind.dll.a and libunwind.a
-// depending on what's available, and depending on the -static flag
-CmdArgs.push_back("-lunwind");
+CmdArgs.push_back("-l:libunwind.so");
 } else {
-  CmdArgs.push_back("-l:libunwind.so");
+  // Let the linker choose between libunwind.so and libunwind.a
+  // depending on what's available, and depending on the -static flag
+  CmdArgs.push_back("-lunwind");
 }
 break;
   }
@@ -1552,10 +1547,12 @@
 static void AddLibgcc(const ToolChain &TC, const Driver &D,
   ArgStringList &CmdArgs, const ArgList &Args) {
   LibGccType LGT = getLibGccType(TC, D, Args);
-  if (LGT != LibGccType::SharedLibGcc)
+  if (LGT == LibGccType::StaticLibGcc ||
+  (LGT == LibGccType::UnspecifiedLibGcc && !D.CCCIsCXX()))
 CmdArgs.push_back("-lgcc");
   AddUnwindLibrary(TC, D, CmdArgs, Args);
-  if (LGT == LibGccType::SharedLibGcc)
+  if (LGT == LibGccType::SharedLibGcc ||
+  (LGT == LibGccType::UnspecifiedLibGcc && D.CCCIsCXX()))
 CmdArgs.push_back("-lgcc");
 }
 


Index: clang/test/Driver/compiler-rt-unwind.c
==

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

In D126984#3574071 , @xbolva00 wrote:

> I agree with @aeubanks , this feature requires major changes to pass manager 
> and I see no value to land this currently.
>
> I see that somebody may prefer “opt for size”, but this is exposed via 
> “minsize” attribute so I see no strong need for optimize(“-Os”)

Hmm.. We expose minsize attribute in C, (like -Oz), but "optsize" is not 
exposed (like -Os). I will try to create a patch for exposing it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D127528: [Clang] Let the linker choose shared or static libunwind unless specified

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

We ran into this in the Fuchsia toolchain where we only ship `libunwind.a` on 
Linux, but Clang is forcing the use of `libunwind.so` unless you explicitly set 
`-shared-libgcc`. With this change, the linker will choose whichever library is 
available by default.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127528/new/

https://reviews.llvm.org/D127528

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

[clang] 0bb317b - Revert "[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore"

[John Ericson via cfe-commits]

Author: John Ericson
Date: 2022-06-10T19:26:12Z
New Revision: 0bb317b7bff3d4f70bddd03a1f337c3f2a118943

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

LOG: Revert "[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore"

This reverts commit d5daa5c5b091cafb9b7ffd19b5dfa2daadef3229.

Added: 


Modified: 
bolt/tools/CMakeLists.txt
bolt/tools/driver/CMakeLists.txt
bolt/tools/heatmap/CMakeLists.txt
bolt/tools/merge-fdata/CMakeLists.txt
clang/CMakeLists.txt
clang/cmake/modules/AddClang.cmake
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
lld/CMakeLists.txt
lld/cmake/modules/AddLLD.cmake
llvm/cmake/modules/AddLLVM.cmake
llvm/cmake/modules/CMakeLists.txt
llvm/cmake/modules/LLVMConfig.cmake.in
llvm/cmake/modules/TableGen.cmake
mlir/CMakeLists.txt
mlir/cmake/modules/AddMLIR.cmake
mlir/tools/mlir-cpu-runner/CMakeLists.txt
mlir/tools/mlir-linalg-ods-gen/CMakeLists.txt
mlir/tools/mlir-lsp-server/CMakeLists.txt
mlir/tools/mlir-opt/CMakeLists.txt
mlir/tools/mlir-pdll-lsp-server/CMakeLists.txt
mlir/tools/mlir-reduce/CMakeLists.txt
mlir/tools/mlir-spirv-cpu-runner/CMakeLists.txt
mlir/tools/mlir-translate/CMakeLists.txt
mlir/tools/mlir-vulkan-runner/CMakeLists.txt
mlir/tools/tblgen-lsp-server/CMakeLists.txt
openmp/libomptarget/tools/CMakeLists.txt
openmp/libomptarget/tools/deviceinfo/CMakeLists.txt

Removed: 




diff  --git a/bolt/tools/CMakeLists.txt b/bolt/tools/CMakeLists.txt
index 91b00a5438af3..1fe85145d79a1 100644
--- a/bolt/tools/CMakeLists.txt
+++ b/bolt/tools/CMakeLists.txt
@@ -1,17 +1,3 @@
-set(BOLT_TOOLS_INSTALL_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
-"Path for binary subdirectory (defaults to '${CMAKE_INSTALL_BINDIR}')")
-mark_as_advanced(BOLT_TOOLS_INSTALL_DIR)
-
-# Move these macros to AddBolt if such a CMake module is ever created.
-
-macro(add_bolt_tool name)
-  llvm_add_tool(BOLT ${ARGV})
-endmacro()
-
-macro(add_bolt_tool_symlink name)
-  llvm_add_tool_symlink(BOLT ${ARGV})
-endmacro()
-
 add_subdirectory(driver)
 add_subdirectory(llvm-bolt-fuzzer)
 add_subdirectory(merge-fdata)

diff  --git a/bolt/tools/driver/CMakeLists.txt 
b/bolt/tools/driver/CMakeLists.txt
index e56be15dbcff6..2338ccec11d2b 100644
--- a/bolt/tools/driver/CMakeLists.txt
+++ b/bolt/tools/driver/CMakeLists.txt
@@ -11,7 +11,7 @@ else()
   set(BOLT_DRIVER_DEPS "")
 endif()
 
-add_bolt_tool(llvm-bolt
+add_llvm_tool(llvm-bolt
   llvm-bolt.cpp
 
   DEPENDS
@@ -25,8 +25,8 @@ target_link_libraries(llvm-bolt
   LLVMBOLTUtils
   )
 
-add_bolt_tool_symlink(perf2bolt llvm-bolt)
-add_bolt_tool_symlink(llvm-bolt
diff  llvm-bolt)
+add_llvm_tool_symlink(perf2bolt llvm-bolt)
+add_llvm_tool_symlink(llvm-bolt
diff  llvm-bolt)
 
 set(BOLT_DEPENDS
   llvm-bolt

diff  --git a/bolt/tools/heatmap/CMakeLists.txt 
b/bolt/tools/heatmap/CMakeLists.txt
index cb8e7ee2605c4..820b268125e85 100644
--- a/bolt/tools/heatmap/CMakeLists.txt
+++ b/bolt/tools/heatmap/CMakeLists.txt
@@ -5,7 +5,7 @@ set(LLVM_LINK_COMPONENTS
   Support
   )
 
-add_bolt_tool(llvm-bolt-heatmap
+add_llvm_tool(llvm-bolt-heatmap
   heatmap.cpp
   )
 

diff  --git a/bolt/tools/merge-fdata/CMakeLists.txt 
b/bolt/tools/merge-fdata/CMakeLists.txt
index 08b2e65b1bce8..2de2ede8f2b5c 100644
--- a/bolt/tools/merge-fdata/CMakeLists.txt
+++ b/bolt/tools/merge-fdata/CMakeLists.txt
@@ -1,6 +1,6 @@
 set(LLVM_LINK_COMPONENTS Support)
 
-add_bolt_tool(merge-fdata
+add_llvm_tool(merge-fdata
   merge-fdata.cpp
 
   DEPENDS

diff  --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index c27beec313d78..191f4f2af242a 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -366,10 +366,6 @@ endif()
 # The libdir suffix must exactly match whatever LLVM's configuration used.
 set(CLANG_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}")
 
-set(CLANG_TOOLS_INSTALL_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
-"Path for binary subdirectory (defaults to '${CMAKE_INSTALL_BINDIR}')")
-mark_as_advanced(CLANG_TOOLS_INSTALL_DIR)
-
 set(CLANG_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
 set(CLANG_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
 

diff  --git a/clang/cmake/modules/AddClang.cmake 
b/clang/cmake/modules/AddClang.cmake
index c58af0b26a8e5..299f8ce6e2fb4 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -173,9 +173,9 @@ macro(add_clang_tool name)
 endmacro()
 
 macro(add_clang_symlink name dest)
-  llvm_add_tool_symlink(CLANG ${name} ${dest} ALWAYS_GENERATE)
+  add_llvm_tool_symlink(${name} ${dest} ALWAYS_GENERATE)
   # Always generate install targets
-  llvm_install_symlink(CLANG name} ${dest} ALWAYS_GENERATE)
+  llvm_install_symlink(${name} ${dest} ALWAYS_GENERATE)
 endmacro()
 
 function(clang_target_link_libraries target type)

diff  --g

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D126984#3574288 , @xbolva00 wrote:

> [[gnu::optimize("O0")]] is okay but [[gnu::optimize("O3 
> ")]] is not gonna work without 
> major changes. Not sure why we should deliver half-broken new attribute.

I don't see it as half-broken given that it's explicitly documented by GCC as 
"The optimize attribute should be used for debugging purposes only. It is not 
suitable in production code."

> Some strong motivation/use cases why somebody needs to compile some functions 
> with -O2 and some with -O3?

This patch leaves O1 -O4 as noops, 
and really only does anything with O0 and the letter-based ones, so I don't 
know that we need to do that exercise until we want to make them actually do 
something. Similarly, we don't allow any of the `-f` flags like GCC does.

I don't insist on keeping this attribute specifically, but I like the fact that 
it gives us *one* attribute that we can use as a basis for all these various 
other ways of spelling optimization hints (optnone, #pragma optimize, minsize, 
etc). I think I'd ultimately like to see all of those other attributes as 
alternate spellings of this one and they just map to the appropriate internal 
"level".

(I'm totally fine with us not supporting optimization hints that the backend 
would struggle with, this is more about how we model the notion of a 
per-function user-provided optimization hint without adding a new attribute 
every time.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126100: Add sanitizer-specific GlobalValue attributes.

[Mitch Phillips via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
hctim marked an inline comment as done.
Closed by commit rG8db981d463ee: Add sanitizer-specific GlobalValue attributes. 
(authored by hctim).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126100/new/

https://reviews.llvm.org/D126100

Files:
  llvm/include/llvm/AsmParser/LLParser.h
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/GlobalValue.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/Globals.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/test/Assembler/globalvariable-attributes.ll
  llvm/test/Bitcode/compatibility.ll

Index: llvm/test/Bitcode/compatibility.ll
===
--- llvm/test/Bitcode/compatibility.ll
+++ llvm/test/Bitcode/compatibility.ll
@@ -203,6 +203,18 @@
 @llvm.global_dtors = appending global [1 x %pri.func.data] [%pri.func.data { i32 0, void ()* @g.f1, i8* @g.used3 }], section "llvm.metadata"
 ; CHECK: @llvm.global_dtors = appending global [1 x %pri.func.data] [%pri.func.data { i32 0, void ()* @g.f1, i8* @g.used3 }], section "llvm.metadata"
 
+; Global Variables -- sanitizers
+@g.no_sanitize_address = global i32 0, no_sanitize_address
+@g.no_sanitize_hwaddress = global i32 0, no_sanitize_hwaddress
+@g.no_sanitize_memtag = global i32 0, no_sanitize_memtag
+@g.no_sanitize_multiple = global i32 0, no_sanitize_address, no_sanitize_hwaddress, no_sanitize_memtag
+@g.sanitize_address_dyninit = global i32 0, sanitize_address_dyninit
+; CHECK: @g.no_sanitize_address = global i32 0, no_sanitize_address
+; CHECK: @g.no_sanitize_hwaddress = global i32 0, no_sanitize_hwaddress
+; CHECK: @g.no_sanitize_memtag = global i32 0, no_sanitize_memtag
+; CHECK: @g.no_sanitize_multiple = global i32 0, no_sanitize_address, no_sanitize_hwaddress, no_sanitize_memtag
+; CHECK: @g.sanitize_address_dyninit = global i32 0, sanitize_address_dyninit
+
 ;; Aliases
 ; Format: @ = [Linkage] [Visibility] [DLLStorageClass] [ThreadLocal]
 ;   [unnamed_addr] alias  @
Index: llvm/test/Assembler/globalvariable-attributes.ll
===
--- llvm/test/Assembler/globalvariable-attributes.ll
+++ llvm/test/Assembler/globalvariable-attributes.ll
@@ -4,6 +4,11 @@
 @g2 = global i32 2, align 4 "key3" = "value3"
 @g3 = global i32 2 #0
 @g4 = global i32 2, align 4 "key5" = "value5" #0
+@g5 = global i32 2, no_sanitize_address, align 4
+@g6 = global i32 2, no_sanitize_hwaddress, align 4
+@g7 = global i32 2, no_sanitize_memtag, align 4
+@g8 = global i32 2, sanitize_address_dyninit, align 4
+@g9 = global i32 2, no_sanitize_address, no_sanitize_hwaddress, no_sanitize_memtag, align 4
 
 attributes #0 = { "string" = "value" nobuiltin norecurse }
 
@@ -11,6 +16,11 @@
 ; CHECK: @g2 = global i32 2, align 4 #1
 ; CHECK: @g3 = global i32 2 #2
 ; CHECK: @g4 = global i32 2, align 4 #3
+; CHECK: @g5 = global i32 2, no_sanitize_address, align 4
+; CHECK: @g6 = global i32 2, no_sanitize_hwaddress, align 4
+; CHECK: @g7 = global i32 2, no_sanitize_memtag, align 4
+; CHECK: @g8 = global i32 2, sanitize_address_dyninit, align 4
+; CHECK: @g9 = global i32 2, no_sanitize_address, no_sanitize_hwaddress, no_sanitize_memtag, align 4
 
 ; CHECK: attributes #0 = { "key"="value" "key2"="value2" }
 ; CHECK: attributes #1 = { "key3"="value3" }
Index: llvm/lib/IR/LLVMContextImpl.h
===
--- llvm/lib/IR/LLVMContextImpl.h
+++ llvm/lib/IR/LLVMContextImpl.h
@@ -1503,6 +1503,9 @@
   /// Collection of per-GlobalValue partitions used in this context.
   DenseMap GlobalValuePartitions;
 
+  DenseMap
+  GlobalValueSanitizerMetadata;
+
   /// DiscriminatorTable - This table maps file:line locations to an
   /// integer representing the next DWARF path discriminator to assign to
   /// instructions in different blocks at the same location.
Index: llvm/lib/IR/Globals.cpp
===
--- llvm/lib/IR/Globals.cpp
+++ llvm/lib/IR/Globals.cpp
@@ -67,6 +67,10 @@
   setDLLStorageClass(Src->getDLLStorageClass());
   setDSOLocal(Src->isDSOLocal());
   setPartition(Src->getPartition());
+  if (Src->hasSanitizerMetadata())
+setSanitizerMetadata(Src->getSanitizerMetadata());
+  else
+removeSanitizerMetadata();
 }
 
 void GlobalValue::removeFromParent() {
@@ -217,6 +221,27 @@
   HasPartition = !S.empty();
 }
 
+using SanitizerMetadata = GlobalValue::SanitizerMetadata;
+const SanitizerMetadata &GlobalValue::getSanitizerMetadata() const {
+  assert(hasSanitizerMetadata());
+  assert(getContext().pImpl->GlobalValueSanitizerMetadata.count(this));
+  return getContext().pImpl->GlobalValueSanitizerMetadata[this];

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

"The optimize attribute should be used for debugging purposes only. It is not 
suitable in production code."

Until they (users) start and any change in pipeline may surprise them.

Personally I am bigger fan of more targeted attributes like we have noinline / 
noipa proposed but stalled /  and then we could have new ones to disable 
vectorizers, LICM, unroller, etc..

Yes, we could claim that attribute((optimize("-fno-slp-vectorize") then maps 
exactly to attribute((noslp)).

Still, I would like to hear some motivation words other than "gcc" has it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126651: [clang-diff] Fix getStmtValue when dealing with wide, UTF16 UTF32 chars

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

In D126651#3574290 , @johannes wrote:

> No idea why the conversion fails for the wide string.
> First step is to reproduce the problem. I guess we should try in a Ubuntu VM.
> Is there an easy way to see if other builders succeeded?

Unfortunately I think you would have to search through the history for it.

I can tell you that our PS4 Windows buildbot did succeed though. 
https://lab.llvm.org/buildbot/#/builders/216/builds/5492


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126651/new/

https://reviews.llvm.org/D126651

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

LLVM lab will be unavailable today starting 1:30 PM PST

[Galina Kistanova via cfe-commits]

Hello,

LLVM lab will be unavailable for a few hours today starting 1:30 PM PST for
maintenance.
I will send an update when it is completed.

Thank you for understanding.

Thanks

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

[PATCH] D126864: [clang] Introduce -fstrict-flex-arrays for stricter handling of flexible arrays

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 435900.
serge-sans-paille added a comment.

Cleanup testcase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126864/new/

https://reviews.llvm.org/D126864

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp
  clang/test/CodeGen/object-size-flex-array.c
  clang/test/SemaCXX/array-bounds-strict-flex-arrays.cpp

Index: clang/test/SemaCXX/array-bounds-strict-flex-arrays.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/array-bounds-strict-flex-arrays.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -verify -fstrict-flex-arrays %s
+
+// We cannot know for sure the size of a flexible array.
+void test() {
+  struct {
+int f;
+int a[];
+  } s2;
+  s2.a[2] = 0; // no-warning
+}
+
+// Under -fstrict-flex-arrays `a` is not a flexible array.
+void test1() {
+  struct {
+int f;
+int a[1]; // expected-note {{declared here}}
+  } s2;
+  s2.a[2] = 0; // expected-warning 1 {{array index 2 is past the end of the array (which contains 1 element)}}
+}
Index: clang/test/CodeGen/object-size-flex-array.c
===
--- /dev/null
+++ clang/test/CodeGen/object-size-flex-array.c
@@ -0,0 +1,97 @@
+// RUN: %clang -fstrict-flex-arrays-target x86_64-apple-darwin -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefix CHECK-STRICT %s
+// RUN: %clang -fno-strict-flex-arrays -target x86_64-apple-darwin -S -emit-llvm %s -o - 2>&1 | FileCheck %s
+
+#define OBJECT_SIZE_BUILTIN __builtin_object_size
+
+typedef struct {
+  float f;
+  double c[];
+} foo_t;
+
+typedef struct {
+  float f;
+  double c[0];
+} foo0_t;
+
+typedef struct {
+  float f;
+  double c[1];
+} foo1_t;
+
+typedef struct {
+  float f;
+  double c[2];
+} foo2_t;
+
+// CHECK-LABEL: @bar
+// CHECK-STRICT-LABEL: @bar
+unsigned bar(foo_t *f) {
+  // CHECK: ret i32 %
+  // CHECK-STRICT: ret i32 %
+  return OBJECT_SIZE_BUILTIN(f->c, 1);
+}
+
+// CHECK-LABEL: @bar0
+// CHECK-STRICT-LABEL: @bar0
+unsigned bar0(foo0_t *f) {
+  // CHECK: ret i32 %
+  // CHECK-STRICT: ret i32 0
+  return OBJECT_SIZE_BUILTIN(f->c, 1);
+}
+
+// CHECK-LABEL: @bar1
+// CHECK-STRICT-LABEL: @bar1
+unsigned bar1(foo1_t *f) {
+  // CHECK: ret i32 %
+  // CHECK-STRICT: ret i32 8
+  return OBJECT_SIZE_BUILTIN(f->c, 1);
+}
+
+// CHECK-LABEL: @bar2
+// CHECK-STRICT-LABEL: @bar2
+unsigned bar2(foo2_t *f) {
+  // CHECK: ret i32 %
+  // CHECK-STRICT: ret i32 16
+  return OBJECT_SIZE_BUILTIN(f->c, 1);
+}
+
+// Also checks for non-trailing flex-array like members
+
+typedef struct {
+  double c[0];
+  float f;
+} foofoo0_t;
+
+typedef struct {
+  double c[1];
+  float f;
+} foofoo1_t;
+
+typedef struct {
+  double c[2];
+  float f;
+} foofoo2_t;
+
+// CHECK-LABEL: @babar0
+// CHECK-STRICT-LABEL: @babar0
+unsigned babar0(foofoo0_t *f) {
+  // CHECK: ret i32 0
+  // CHECK-STRICT: ret i32 0
+  return OBJECT_SIZE_BUILTIN(f->c, 1);
+}
+
+// CHECK-LABEL: @babar1
+// CHECK-STRICT-LABEL: @babar1
+unsigned babar1(foofoo1_t *f) {
+  // CHECK: ret i32 8
+  // CHECK-STRICT: ret i32 8
+  return OBJECT_SIZE_BUILTIN(f->c, 1);
+}
+
+// CHECK-LABEL: @babar2
+// CHECK-STRICT-LABEL: @babar2
+unsigned babar2(foofoo2_t *f) {
+  // CHECK: ret i32 16
+  // CHECK-STRICT: ret i32 16
+  return OBJECT_SIZE_BUILTIN(f->c, 1);
+}
Index: clang/lib/StaticAnalyzer/Core/MemRegion.cpp
===
--- clang/lib/StaticAnalyzer/Core/MemRegion.cpp
+++ clang/lib/StaticAnalyzer/Core/MemRegion.cpp
@@ -789,6 +789,9 @@
   if (isa(AT))
 return true;
 
+  if (getContext().getLangOpts().StrictFlexArrays)
+return false;
+
   if (const auto *CAT = dyn_cast(AT)) {
 const llvm::APInt &Size = CAT->getSize();
 if (Size.isZero())
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -15722,6 +15722,9 @@
 /// commonly used to emulate flexible arrays in C89 code.
 static bool IsTailPaddedMemberArray(Sema &S, const llvm::APInt &Size,
 const NamedDecl *ND) {
+  if (S.getLangOpts().StrictFlexArrays)
+return false;
+
   if (Size != 1 || !ND) return false;
 
   const FieldDecl *FD = dyn_cast(ND);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6214,6 +6214,9 @@
   Args.AddLastArg(CmdArgs, options::OPT_funroll_loops,
 

[PATCH] D127532: [clang-format] Fix a bug in RemoveBracesLLVM

[Owen Pan via Phabricator via cfe-commits]

owenpan created this revision.
owenpan added reviewers: curdeius, HazardyKnusperkeks, MyDeveloperDay.
owenpan added a project: clang-format.
Herald added a project: All.
owenpan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Remove the braces of an `else` block only if the `r_brace` of the block is 
followed by an `if`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127532

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -25576,6 +25576,17 @@
"  g;",
Style);
 
+  verifyFormat("if (a) {\n"
+   "  b;\n"
+   "  c;\n"
+   "} else { // comment\n"
+   "  if (d) {\n"
+   "e;\n"
+   "f;\n"
+   "  }\n"
+   "}",
+   Style);
+
   verifyFormat("if (a)\n"
"  b;\n"
"else if (c)\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2610,6 +2610,7 @@
 nextToken();
 handleAttributes();
 if (FormatTok->is(tok::l_brace)) {
+  const bool FollowedByIf = Tokens->peekNextToken()->is(tok::kw_if);
   FormatTok->setFinalizedType(TT_ElseLBrace);
   ElseLeftBrace = FormatTok;
   CompoundStatementIndenter Indenter(this, Style, Line->Level);
@@ -2621,7 +2622,7 @@
 KeepElseBraces = KeepElseBraces ||
  ElseBlockKind == IfStmtKind::IfOnly ||
  ElseBlockKind == IfStmtKind::IfElseIf;
-  } else if (IfLBrace && !IfLBrace->Optional) {
+  } else if (FollowedByIf && IfLBrace && !IfLBrace->Optional) {
 KeepElseBraces = true;
 assert(ElseLeftBrace->MatchingParen);
 markOptionalBraces(ElseLeftBrace);


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -25576,6 +25576,17 @@
"  g;",
Style);
 
+  verifyFormat("if (a) {\n"
+   "  b;\n"
+   "  c;\n"
+   "} else { // comment\n"
+   "  if (d) {\n"
+   "e;\n"
+   "f;\n"
+   "  }\n"
+   "}",
+   Style);
+
   verifyFormat("if (a)\n"
"  b;\n"
"else if (c)\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2610,6 +2610,7 @@
 nextToken();
 handleAttributes();
 if (FormatTok->is(tok::l_brace)) {
+  const bool FollowedByIf = Tokens->peekNextToken()->is(tok::kw_if);
   FormatTok->setFinalizedType(TT_ElseLBrace);
   ElseLeftBrace = FormatTok;
   CompoundStatementIndenter Indenter(this, Style, Line->Level);
@@ -2621,7 +2622,7 @@
 KeepElseBraces = KeepElseBraces ||
  ElseBlockKind == IfStmtKind::IfOnly ||
  ElseBlockKind == IfStmtKind::IfElseIf;
-  } else if (IfLBrace && !IfLBrace->Optional) {
+  } else if (FollowedByIf && IfLBrace && !IfLBrace->Optional) {
 KeepElseBraces = true;
 assert(ElseLeftBrace->MatchingParen);
 markOptionalBraces(ElseLeftBrace);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 0fe88f9 - [PS4/PS5] Don't inherit base class alignment

[Paul Robinson via cfe-commits]

Author: Paul Robinson
Date: 2022-06-10T13:15:17-07:00
New Revision: 0fe88f9679ff6df5a7cce7e89038602c35a5e272

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

LOG: [PS4/PS5] Don't inherit base class alignment

Added: 


Modified: 
clang/lib/AST/RecordLayoutBuilder.cpp
clang/test/SemaCXX/alignment-of-derived-class.cpp

Removed: 




diff  --git a/clang/lib/AST/RecordLayoutBuilder.cpp 
b/clang/lib/AST/RecordLayoutBuilder.cpp
index 6e775baed147f..6f3ede2ce42a7 100644
--- a/clang/lib/AST/RecordLayoutBuilder.cpp
+++ b/clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1261,7 +1261,9 @@ ItaniumRecordLayoutBuilder::LayoutBase(const 
BaseSubobjectInfo *Base) {
   (!HasExternalLayout || Offset == CharUnits::Zero()) &&
   EmptySubobjects->CanPlaceBaseAtOffset(Base, CharUnits::Zero())) {
 setSize(std::max(getSize(), Layout.getSize()));
-UpdateAlignment(BaseAlign, UnpackedAlignTo, PreferredBaseAlign);
+// On PS4/PS5, don't update the alignment, to preserve compatibility.
+if (!Context.getTargetInfo().getTriple().isPS())
+  UpdateAlignment(BaseAlign, UnpackedAlignTo, PreferredBaseAlign);
 
 return CharUnits::Zero();
   }

diff  --git a/clang/test/SemaCXX/alignment-of-derived-class.cpp 
b/clang/test/SemaCXX/alignment-of-derived-class.cpp
index 28c1fa9144b78..ab28bc0a235f1 100644
--- a/clang/test/SemaCXX/alignment-of-derived-class.cpp
+++ b/clang/test/SemaCXX/alignment-of-derived-class.cpp
@@ -2,7 +2,7 @@
 // expected-no-diagnostics
 
 // Test that the alignment of a empty direct base class is correctly
-// inherited by the derived class.
+// inherited by the derived class, and correctly not inherited on PS4/PS5.
 
 struct A {
 } __attribute__ ((aligned(16)));
@@ -12,22 +12,38 @@ static_assert(__alignof(A) == 16, "A should be aligned to 
16 bytes");
 struct B1 : public A {
 };
 
+#if defined(__SCE__)
+static_assert(__alignof(B1) == 1, "B1 should be aligned to 1 byte");
+#else
 static_assert(__alignof(B1) == 16, "B1 should be aligned to 16 bytes");
+#endif
 
 struct B2 : public A {
 } __attribute__ ((aligned(2)));
 
+#if defined(__SCE__)
+static_assert(__alignof(B2) == 2, "B2 should be aligned to 2 bytes");
+#else
 static_assert(__alignof(B2) == 16, "B2 should be aligned to 16 bytes");
+#endif
 
 struct B3 : public A {
 } __attribute__ ((aligned(4)));
 
+#if defined(__SCE__)
+static_assert(__alignof(B3) == 4, "B3 should be aligned to 4 bytes");
+#else
 static_assert(__alignof(B3) == 16, "B3 should be aligned to 16 bytes");
+#endif
 
 struct B4 : public A {
 } __attribute__ ((aligned(8)));
 
+#if defined(__SCE__)
+static_assert(__alignof(B4) == 8, "B4 should be aligned to 8 bytes");
+#else
 static_assert(__alignof(B4) == 16, "B4 should be aligned to 16 bytes");
+#endif
 
 struct B5 : public A {
 } __attribute__ ((aligned(16)));



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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D126984#3574445 , @xbolva00 wrote:

> "The optimize attribute should be used for debugging purposes only. It is not 
> suitable in production code."
>
> Until they (users) start and any change in pipeline may surprise them.

Too bad for them? I guess my sympathy button is broken for users who use things 
in production code that are documented as not being suitable for production 
code. :-D

> Personally I am bigger fan of more targeted attributes like we have noinline 
> / noipa proposed but stalled /  and then we could have new ones to disable 
> vectorizers, LICM, unroller, etc..
>
> Yes, we could claim that attribute((optimize("-fno-slp-vectorize") then maps 
> exactly to attribute((noslp)).
>
> Still, I would like to hear some motivation words other than "gcc" has it.

What I want to avoid is the continued proliferation of semantic attributes 
related to optimizations that are otherwise controlled by command line flags. 
We have optnone, minsize, Stephen's original patch for the MSVC pragma added 
another one, you're talking about adding optsize, etc. All of these are 
semantically doing "the same thing", which is associating some coarse 
granularity optimization hints with a function definition that would otherwise 
be even more coarsely controlled via the command line. Having multiple semantic 
attributes makes supporting this more fragile because everywhere that wants to 
care about coarse-grained optimizations has to handle the combinatorial matrix 
of ways they can be mixed together and as that grows, we will invariably get it 
wrong by forgetting something.

What I don't have a strong opinion on is what attributes we surface to users so 
they can spell them in their source. I have no problem exposing GCC's 
attributes, and MSVC's attributes, and our own attributes in whatever fun 
combinations we want to allow. What I want is that all of those related 
attributes are semantically modeled via ONE attribute in the AST. When 
converting these parsed optimization attributes into semantic attributes, I 
want us to map whatever information is in the parsed attribute onto that single 
semantic attribute. When we merge attributes on a declaration, I want that one 
attribute to be updated instead of duplicated with different values. So at the 
end of the day, when we get to CodeGen, we can query for the one attribute and 
its semantic effects instead of querying for numerous attributes and trying to 
decide what to do when more than one attribute is present at that point.

That's why I pushed Stephen to make this patch. The fact that it also happens 
to expose a feature from GCC that is very closely related to what he's trying 
to do for the MSVC pragma was a nice added bonus.

This leaves a few questions:

1. Are you opposed to exposing #pragma optimize? 
(https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170) If 
yes, I think Stephen should run an RFC on Discourse to see if there's general 
agreement.
2. Are you opposed to the direction of condensing the optimization semantic 
attributes (the things in the AST) down into one? If yes, I'd like to 
understand why better.
3. Are you still opposed to exposing a neutered form of the GCC optimize 
attribute as a parsed attribute (the thing users write in their source)? If 
yes, that's fine by me, but then I'd still like to see most of this patch land, 
just without a way for the user to spell the attribute themselves. We can 
adjust the semantic attribute's enumeration to cover only the cases we want to 
support.
4. Or are you opposed to the notion of having one semantic attribute to control 
all of this and you prefer to see multiple individual semantic attributes and 
all that comes along with them in terms of combinations?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D127251: [Lex] Fix `fixits` for typo-corrections of preprocessing directives within skipped blocks

[Argyrios Kyrtzidis via Phabricator via cfe-commits]

akyrtzi updated this revision to Diff 436024.
akyrtzi added a comment.

Remove `// clang-format off` annotation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127251/new/

https://reviews.llvm.org/D127251

Files:
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/suggest-typoed-directive.c

Index: clang/test/Preprocessor/suggest-typoed-directive.c
===
--- clang/test/Preprocessor/suggest-typoed-directive.c
+++ clang/test/Preprocessor/suggest-typoed-directive.c
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -verify=pre-c2x-cpp2b %s
 // RUN: %clang_cc1 -std=c2x -fsyntax-only -verify=c2x-cpp2b %s
 // RUN: %clang_cc1 -x c++ -std=c++2b -fsyntax-only -verify=c2x-cpp2b %s
+// RUN: %clang_cc1 -x c++ -std=c++2b -fsyntax-only %s -fdiagnostics-parseable-fixits 2>&1 | FileCheck %s
 
 // id:pre-c2x-cpp2b-warning@+12 {{invalid preprocessing directive, did you mean '#if'?}}
 // ifd:   pre-c2x-cpp2b-warning@+12 {{invalid preprocessing directive, did you mean '#if'?}}
@@ -17,8 +18,8 @@
 #id
 #ifd
 #ifde
-#elf
-#elsif
+# elf
+#  elsif
 #elseif
 #elfidef
 #elfindef
@@ -38,6 +39,18 @@
 // els:   c2x-cpp2b-warning@-12 {{invalid preprocessing directive, did you mean '#else'?}}
 // endi:  c2x-cpp2b-warning@-12 {{invalid preprocessing directive, did you mean '#endif'?}}
 
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:4}:"if"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:5}:"if"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:6}:"ifdef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:3-[[@LINE-24]]:6}:"elif"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:4-[[@LINE-24]]:9}:"elif"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:8}:"elif"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:9}:"elifdef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:10}:"elifdef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:11}:"elifndef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:5}:"else"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:6}:"endif"
+
 #ifdef UNDEFINED
 #i // no diagnostic
 #endif
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -444,8 +444,7 @@
 }
 
 void Preprocessor::SuggestTypoedDirective(const Token &Tok,
-  StringRef Directive,
-  const SourceLocation &EndLoc) const {
+  StringRef Directive) const {
   // If this is a `.S` file, treat unknown # directives as non-preprocessor
   // directives.
   if (getLangOpts().AsmPreprocessor) return;
@@ -457,11 +456,14 @@
 Candidates.insert(Candidates.end(), {"elifdef", "elifndef"});
 
   if (Optional Sugg = findSimilarStr(Directive, Candidates)) {
-CharSourceRange DirectiveRange =
-CharSourceRange::getCharRange(Tok.getLocation(), EndLoc);
-std::string SuggValue = Sugg.getValue().str();
-
-auto Hint = FixItHint::CreateReplacement(DirectiveRange, "#" + SuggValue);
+// Directive cannot be coming from macro.
+assert(Tok.getLocation().isFileID());
+CharSourceRange DirectiveRange = CharSourceRange::getCharRange(
+Tok.getLocation(),
+Tok.getLocation().getLocWithOffset(Directive.size()));
+StringRef SuggValue = Sugg.getValue();
+
+auto Hint = FixItHint::CreateReplacement(DirectiveRange, SuggValue);
 Diag(Tok, diag::warn_pp_invalid_directive) << 1 << SuggValue << Hint;
   }
 }
@@ -596,7 +598,7 @@
/*foundnonskip*/false,
/*foundelse*/false);
   } else {
-SuggestTypoedDirective(Tok, Directive, endLoc);
+SuggestTypoedDirective(Tok, Directive);
   }
 } else if (Directive[0] == 'e') {
   StringRef Sub = Directive.substr(1);
@@ -758,10 +760,10 @@
   }
 }
   } else {
-SuggestTypoedDirective(Tok, Directive, endLoc);
+SuggestTypoedDirective(Tok, Directive);
   }
 } else {
-  SuggestTypoedDirective(Tok, Directive, endLoc);
+  SuggestTypoedDirective(Tok, Directive);
 }
 
 CurPPLexer->ParsingPreprocessorDirective = false;
Index: clang/include/clang/Lex/Preprocessor.h
===
--- clang/include/clang/Lex/Preprocessor.h
+++ clang/include/clang/Lex/Preprocessor.h
@@ -2243,10 +2243,7 @@
   ///
   /// \param Tok - Token that represents the directive
   /// \param Directive - String reference for the directive name
-  /// \param EndLoc - End location for fixit
-  void SuggestTypoedDirective(const Token &Tok,
-  StringRef Directive,
-  const SourceLocation &EndLoc) const;
+  void SuggestTypoedDirective(co

[clang] fbaa8b9 - [Lex] Fix `fixits` for typo-corrections of preprocessing directives within skipped blocks

[Argyrios Kyrtzidis via cfe-commits]

Author: Argyrios Kyrtzidis
Date: 2022-06-10T13:32:19-07:00
New Revision: fbaa8b9ae5f3c6637be7d4dae6adaab4be811625

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

LOG: [Lex] Fix `fixits` for typo-corrections of preprocessing directives within 
skipped blocks

The `EndLoc` parameter was always unset so no fixit was emitted. But it is also 
unnecessary for determining the range so we can remove it.

Differential Revision: https://reviews.llvm.org/D127251

Added: 


Modified: 
clang/include/clang/Lex/Preprocessor.h
clang/lib/Lex/PPDirectives.cpp
clang/test/Preprocessor/suggest-typoed-directive.c

Removed: 




diff  --git a/clang/include/clang/Lex/Preprocessor.h 
b/clang/include/clang/Lex/Preprocessor.h
index 6d8f03e3ceb1b..81d1481e88fa8 100644
--- a/clang/include/clang/Lex/Preprocessor.h
+++ b/clang/include/clang/Lex/Preprocessor.h
@@ -2243,10 +2243,7 @@ class Preprocessor {
   ///
   /// \param Tok - Token that represents the directive
   /// \param Directive - String reference for the directive name
-  /// \param EndLoc - End location for fixit
-  void SuggestTypoedDirective(const Token &Tok,
-  StringRef Directive,
-  const SourceLocation &EndLoc) const;
+  void SuggestTypoedDirective(const Token &Tok, StringRef Directive) const;
 
   /// We just read a \#if or related directive and decided that the
   /// subsequent tokens are in the \#if'd out portion of the

diff  --git a/clang/lib/Lex/PPDirectives.cpp b/clang/lib/Lex/PPDirectives.cpp
index 97d7466d79a19..1356dc097dfcc 100644
--- a/clang/lib/Lex/PPDirectives.cpp
+++ b/clang/lib/Lex/PPDirectives.cpp
@@ -444,8 +444,7 @@ SourceLocation Preprocessor::CheckEndOfDirective(const char 
*DirType,
 }
 
 void Preprocessor::SuggestTypoedDirective(const Token &Tok,
-  StringRef Directive,
-  const SourceLocation &EndLoc) const {
+  StringRef Directive) const {
   // If this is a `.S` file, treat unknown # directives as non-preprocessor
   // directives.
   if (getLangOpts().AsmPreprocessor) return;
@@ -457,11 +456,14 @@ void Preprocessor::SuggestTypoedDirective(const Token 
&Tok,
 Candidates.insert(Candidates.end(), {"elifdef", "elifndef"});
 
   if (Optional Sugg = findSimilarStr(Directive, Candidates)) {
-CharSourceRange DirectiveRange =
-CharSourceRange::getCharRange(Tok.getLocation(), EndLoc);
-std::string SuggValue = Sugg.getValue().str();
-
-auto Hint = FixItHint::CreateReplacement(DirectiveRange, "#" + SuggValue);
+// Directive cannot be coming from macro.
+assert(Tok.getLocation().isFileID());
+CharSourceRange DirectiveRange = CharSourceRange::getCharRange(
+Tok.getLocation(),
+Tok.getLocation().getLocWithOffset(Directive.size()));
+StringRef SuggValue = Sugg.getValue();
+
+auto Hint = FixItHint::CreateReplacement(DirectiveRange, SuggValue);
 Diag(Tok, diag::warn_pp_invalid_directive) << 1 << SuggValue << Hint;
   }
 }
@@ -596,7 +598,7 @@ void 
Preprocessor::SkipExcludedConditionalBlock(SourceLocation HashTokenLoc,
/*foundnonskip*/false,
/*foundelse*/false);
   } else {
-SuggestTypoedDirective(Tok, Directive, endLoc);
+SuggestTypoedDirective(Tok, Directive);
   }
 } else if (Directive[0] == 'e') {
   StringRef Sub = Directive.substr(1);
@@ -758,10 +760,10 @@ void 
Preprocessor::SkipExcludedConditionalBlock(SourceLocation HashTokenLoc,
   }
 }
   } else {
-SuggestTypoedDirective(Tok, Directive, endLoc);
+SuggestTypoedDirective(Tok, Directive);
   }
 } else {
-  SuggestTypoedDirective(Tok, Directive, endLoc);
+  SuggestTypoedDirective(Tok, Directive);
 }
 
 CurPPLexer->ParsingPreprocessorDirective = false;

diff  --git a/clang/test/Preprocessor/suggest-typoed-directive.c 
b/clang/test/Preprocessor/suggest-typoed-directive.c
index 8dd7ef4feaf69..cc15efee09e1c 100644
--- a/clang/test/Preprocessor/suggest-typoed-directive.c
+++ b/clang/test/Preprocessor/suggest-typoed-directive.c
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -verify=pre-c2x-cpp2b %s
 // RUN: %clang_cc1 -std=c2x -fsyntax-only -verify=c2x-cpp2b %s
 // RUN: %clang_cc1 -x c++ -std=c++2b -fsyntax-only -verify=c2x-cpp2b %s
+// RUN: %clang_cc1 -x c++ -std=c++2b -fsyntax-only %s 
-fdiagnostics-parseable-fixits 2>&1 | FileCheck %s
 
 // id:pre-c2x-cpp2b-warning@+12 {{invalid preprocessing directive, did 
you mean '#if'?}}
 // ifd:   pre-c2x-cpp2b-warning@+12 {{invalid preprocessing directive, did 
you mean '#if'?}}
@@ -17,8 +18,8 @@
 #id
 #ifd
 #i

[PATCH] D127251: [Lex] Fix `fixits` for typo-corrections of preprocessing directives within skipped blocks

[Argyrios Kyrtzidis via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfbaa8b9ae5f3: [Lex] Fix `fixits` for typo-corrections of 
preprocessing directives within… (authored by akyrtzi).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127251/new/

https://reviews.llvm.org/D127251

Files:
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/suggest-typoed-directive.c

Index: clang/test/Preprocessor/suggest-typoed-directive.c
===
--- clang/test/Preprocessor/suggest-typoed-directive.c
+++ clang/test/Preprocessor/suggest-typoed-directive.c
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -verify=pre-c2x-cpp2b %s
 // RUN: %clang_cc1 -std=c2x -fsyntax-only -verify=c2x-cpp2b %s
 // RUN: %clang_cc1 -x c++ -std=c++2b -fsyntax-only -verify=c2x-cpp2b %s
+// RUN: %clang_cc1 -x c++ -std=c++2b -fsyntax-only %s -fdiagnostics-parseable-fixits 2>&1 | FileCheck %s
 
 // id:pre-c2x-cpp2b-warning@+12 {{invalid preprocessing directive, did you mean '#if'?}}
 // ifd:   pre-c2x-cpp2b-warning@+12 {{invalid preprocessing directive, did you mean '#if'?}}
@@ -17,8 +18,8 @@
 #id
 #ifd
 #ifde
-#elf
-#elsif
+# elf
+#  elsif
 #elseif
 #elfidef
 #elfindef
@@ -38,6 +39,18 @@
 // els:   c2x-cpp2b-warning@-12 {{invalid preprocessing directive, did you mean '#else'?}}
 // endi:  c2x-cpp2b-warning@-12 {{invalid preprocessing directive, did you mean '#endif'?}}
 
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:4}:"if"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:5}:"if"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:6}:"ifdef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:3-[[@LINE-24]]:6}:"elif"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:4-[[@LINE-24]]:9}:"elif"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:8}:"elif"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:9}:"elifdef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:10}:"elifdef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:11}:"elifndef"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:5}:"else"
+// CHECK: fix-it:{{.*}}:{[[@LINE-24]]:2-[[@LINE-24]]:6}:"endif"
+
 #ifdef UNDEFINED
 #i // no diagnostic
 #endif
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -444,8 +444,7 @@
 }
 
 void Preprocessor::SuggestTypoedDirective(const Token &Tok,
-  StringRef Directive,
-  const SourceLocation &EndLoc) const {
+  StringRef Directive) const {
   // If this is a `.S` file, treat unknown # directives as non-preprocessor
   // directives.
   if (getLangOpts().AsmPreprocessor) return;
@@ -457,11 +456,14 @@
 Candidates.insert(Candidates.end(), {"elifdef", "elifndef"});
 
   if (Optional Sugg = findSimilarStr(Directive, Candidates)) {
-CharSourceRange DirectiveRange =
-CharSourceRange::getCharRange(Tok.getLocation(), EndLoc);
-std::string SuggValue = Sugg.getValue().str();
-
-auto Hint = FixItHint::CreateReplacement(DirectiveRange, "#" + SuggValue);
+// Directive cannot be coming from macro.
+assert(Tok.getLocation().isFileID());
+CharSourceRange DirectiveRange = CharSourceRange::getCharRange(
+Tok.getLocation(),
+Tok.getLocation().getLocWithOffset(Directive.size()));
+StringRef SuggValue = Sugg.getValue();
+
+auto Hint = FixItHint::CreateReplacement(DirectiveRange, SuggValue);
 Diag(Tok, diag::warn_pp_invalid_directive) << 1 << SuggValue << Hint;
   }
 }
@@ -596,7 +598,7 @@
/*foundnonskip*/false,
/*foundelse*/false);
   } else {
-SuggestTypoedDirective(Tok, Directive, endLoc);
+SuggestTypoedDirective(Tok, Directive);
   }
 } else if (Directive[0] == 'e') {
   StringRef Sub = Directive.substr(1);
@@ -758,10 +760,10 @@
   }
 }
   } else {
-SuggestTypoedDirective(Tok, Directive, endLoc);
+SuggestTypoedDirective(Tok, Directive);
   }
 } else {
-  SuggestTypoedDirective(Tok, Directive, endLoc);
+  SuggestTypoedDirective(Tok, Directive);
 }
 
 CurPPLexer->ParsingPreprocessorDirective = false;
Index: clang/include/clang/Lex/Preprocessor.h
===
--- clang/include/clang/Lex/Preprocessor.h
+++ clang/include/clang/Lex/Preprocessor.h
@@ -2243,10 +2243,7 @@
   ///
   /// \param Tok - Token that represents the directive
   /// \param Directive - String reference for the directive name
-  /// \param EndLoc - End location for fixit
-  void SuggestTypoedDirective(const Token &Tok,
-   

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added a comment.

I can't speak for @xbolva00 but the only part I'm against is the user-visible 
feature of

> - Added preliminary support for GCC's attribute `optimize`, which allows 
> functions to be compiled with different optimization options than what was 
> specified on the command line.

which implies that we're on the way to support per-function optimization levels 
(which we aren't)
the internal clang representation changes are all fine

and even for the MSVC pragma `#pragma optimize("t", on)`, what are we 
supporting if the user compiles their code with `-O0`? because right now we 
won't optimize anything with `-O0`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

[Vaibhav Yenamandra via Phabricator via cfe-commits]

vaibhav.y updated this revision to Diff 436030.
vaibhav.y added a comment.

Rebase on main branch from upstream git


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109701/new/

https://reviews.llvm.org/D109701

Files:
  clang/include/clang/Basic/Sarif.h
  clang/include/clang/Basic/SourceLocation.h
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Sarif.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/unittests/Basic/CMakeLists.txt
  clang/unittests/Basic/SarifTest.cpp

Index: clang/unittests/Basic/SarifTest.cpp
===
--- /dev/null
+++ clang/unittests/Basic/SarifTest.cpp
@@ -0,0 +1,315 @@
+//===- unittests/Basic/SarifTest.cpp - Test writing SARIF documents ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/Sarif.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/FileSystemOptions.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/VirtualFileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest-death-test.h"
+#include "gtest/gtest-matchers.h"
+#include "gtest/gtest.h"
+
+#include 
+
+using namespace clang;
+
+namespace {
+
+using LineCol = std::pair;
+
+static std::string serializeSarifDocument(llvm::json::Object &&Doc) {
+  std::string Output;
+  llvm::json::Value value(std::move(Doc));
+  llvm::raw_string_ostream OS{Output};
+  OS << llvm::formatv("{0}", value);
+  OS.flush();
+  return Output;
+}
+
+class SarifDocumentWriterTest : public ::testing::Test {
+protected:
+  SarifDocumentWriterTest()
+  : InMemoryFileSystem(new llvm::vfs::InMemoryFileSystem),
+FileMgr(FileSystemOptions(), InMemoryFileSystem),
+DiagID(new DiagnosticIDs()), DiagOpts(new DiagnosticOptions()),
+Diags(DiagID, DiagOpts.get(), new IgnoringDiagConsumer()),
+SourceMgr(Diags, FileMgr) {}
+
+  IntrusiveRefCntPtr InMemoryFileSystem;
+  FileManager FileMgr;
+  IntrusiveRefCntPtr DiagID;
+  IntrusiveRefCntPtr DiagOpts;
+  DiagnosticsEngine Diags;
+  SourceManager SourceMgr;
+  LangOptions LangOpts;
+
+  FileID registerSource(llvm::StringRef Name, const char *SourceText,
+bool IsMainFile = false) {
+std::unique_ptr SourceBuf =
+llvm::MemoryBuffer::getMemBuffer(SourceText);
+const FileEntry *SourceFile =
+FileMgr.getVirtualFile(Name, SourceBuf->getBufferSize(), 0);
+SourceMgr.overrideFileContents(SourceFile, std::move(SourceBuf));
+FileID FID = SourceMgr.getOrCreateFileID(SourceFile, SrcMgr::C_User);
+if (IsMainFile)
+  SourceMgr.setMainFileID(FID);
+return FID;
+  }
+
+  FullSourceRange getFakeFullSourceRange(FileID FID, LineCol Begin,
+ LineCol End) {
+auto BeginLoc = SourceMgr.translateLineCol(FID, Begin.first, Begin.second);
+auto EndLoc = SourceMgr.translateLineCol(FID, End.first, End.second);
+return FullSourceRange{FullSourceLoc{BeginLoc, SourceMgr},
+   FullSourceLoc{EndLoc, SourceMgr}};
+  }
+};
+
+TEST_F(SarifDocumentWriterTest, createEmptyDocument) {
+  // GIVEN:
+  SarifDocumentWriter Writer{LangOpts};
+
+  // WHEN:
+  const llvm::json::Object &EmptyDoc = Writer.createDocument();
+  std::vector Keys(EmptyDoc.size());
+  std::transform(EmptyDoc.begin(), EmptyDoc.end(), Keys.begin(),
+ [](auto item) { return item.getFirst(); });
+
+  // THEN:
+  ASSERT_THAT(Keys, testing::UnorderedElementsAre("$schema", "version"));
+}
+
+// Test that a newly inserted run will associate correct tool names
+TEST_F(SarifDocumentWriterTest, documentWithARun) {
+  // GIVEN:
+  SarifDocumentWriter Writer{LangOpts};
+  const char *ShortName = "sariftest";
+  const char *LongName = "sarif writer test";
+
+  // WHEN:
+  Writer.createRun(ShortName, LongName);
+  Writer.endRun();
+  const llvm::json::Object &Doc = Writer.createDocument();
+  const llvm::json::Array *Runs = Doc.getArray("runs");
+
+  // THEN:
+  // A run was created
+  ASSERT_THAT(Runs, testing::NotNull());
+
+  // It is the only run
+  ASSERT_EQ(Runs->size(), 1UL);
+
+  // The tool associated with the run was the tool
+  const llvm::json::Object *driver =
+  Runs->begin()->getAsObject()->getObject("tool")->getObject("driver");
+  ASSERT_THAT(driver, testing::NotNull());
+
+  ASSERT_TRUE(driver->getString("name").hasValue());
+  ASSERT_TR

[PATCH] D127313: [libc++] Implement P0618R0 (Deprecating )

[Nikolas Klauser via Phabricator via cfe-commits]

philnik updated this revision to Diff 436032.
philnik marked 3 inline comments as done.
philnik added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127313/new/

https://reviews.llvm.org/D127313

Files:
  libcxx/docs/ReleaseNotes.rst
  libcxx/docs/Status/Cxx17Papers.csv
  libcxx/include/codecvt
  libcxx/include/locale
  libcxx/src/locale.cpp
  
libcxx/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_mode.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf16.pass.cpp
  
libcxx/test/std/localization/locale.stdcvt/codecvt_utf16_always_noconv.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf16_encoding.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf16_in.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf16_length.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf16_max_length.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf16_out.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf16_unshift.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_always_noconv.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_encoding.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_in.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_length.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_max_length.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_out.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_unshift.pass.cpp
  
libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_utf16_always_noconv.pass.cpp
  
libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_utf16_encoding.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_utf16_in.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_utf16_length.pass.cpp
  
libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_utf16_max_length.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_utf16_out.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/codecvt_utf8_utf16_unshift.pass.cpp
  libcxx/test/std/localization/locale.stdcvt/depr.verify.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/ctor.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/depr.verify.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/overflow.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/pbackfail.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/rdbuf.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/seekoff.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/state.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/test.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/underflow.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/converted.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/ctor_codecvt.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/ctor_codecvt_state.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/ctor_copy.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/ctor_err_string.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/depr.verify.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/from_bytes.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/state.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/to_bytes.pass.cpp
  
libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/types.pass.cpp

Index: libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/types.pass.cpp
===
--- libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/types.pass.cpp
+++ libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.string/types.pass.cpp
@@ -8,6 +8,8 @@
 
 // 
 
+// ADDITIONAL_COMPILE_FLAGS: -D_LIBCPP_DISABLE_DEPRECATION_WARNINGS
+
 // template,
 //  class 

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

>> Are you opposed to exposing #pragma optimize? 
>> (https://docs.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170) 
>> If yes, I think Stephen should run an RFC on Discourse to see if there's 
>> general agreement.

No, I like it, seems more useful and general than "pragma clang optimize on/off"

>> Are you opposed to the direction of condensing the optimization semantic 
>> attributes (the things in the AST) down into one? If yes, I'd like to 
>> understand why better.

No :)

>> Are you still opposed to exposing a neutered form of the GCC optimize 
>> attribute as a parsed attribute (the thing users write in their source)? If 
>> yes, that's fine by me, but then I'd still like to see most of this patch 
>> land, just without a way for the user to spell the attribute themselves. We 
>> can adjust the semantic attribute's enumeration to cover only the cases we 
>> want to support.

Not entirely opposed, GCC optimize attribute could partially work fine, O0 maps 
to optnone, Os to optsize, Oz to minsize. I am more worried about next steps, 
see below.

>> Or are you opposed to the notion of having one semantic attribute to control 
>> all of this and you prefer to see multiple individual semantic attributes 
>> and all that comes along with them in terms of combinations?

Not strongly opposed, just some concerns how this could work together with 
LLVM. Example: attribute((optimize("-fno-licm"))) -> 'optimize="no-licm" '? 
This could work. Possibly also allow this form: attribute((optimize(no-licm,  
optsize))) ?

What about current attributes? Should/can we drop them and use  for example 
'optimize="no-ipa,no-clone" '? Not strongly opposed, but probably a lot of work.

But to use different pipeline for different functions (here I mean -O1, O2 
, O3 
) is a major change to LLVM pass 
manager and I think this use case does not justify it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

But where I think this feature could be very useful in following case from gcc 
test suite where there is some FP computation..
Imagine you compile you program with -ffast-math and then you have function:

  __attribute__ ((optimize ("no-associative-math"))) double
  fn3 (double h, double l) /* { dg-message "previous definition" } */
  {
return h + l;
  }

So in this case, codegen would just drop llvm attribute "reassoc".


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added inline comments.



Comment at: clang/test/CodeGen/attr-optimize.c:4
+
+__attribute__((optimize("O0"))) void f1(void) {}
+// O2: @f1{{.*}}[[ATTR_OPTNONE:#[0-9]+]]

No support for 
```
__attribute__ ((__optimize__ (0)))
```

? GCC supports it


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[PATCH] D126984: [clang] Add initial support for gcc's optimize function attribute

[Stephen Long via Phabricator via cfe-commits]

steplong added inline comments.



Comment at: clang/test/CodeGen/attr-optimize.c:4
+
+__attribute__((optimize("O0"))) void f1(void) {}
+// O2: @f1{{.*}}[[ATTR_OPTNONE:#[0-9]+]]

xbolva00 wrote:
> No support for 
> ```
> __attribute__ ((__optimize__ (0)))
> ```
> 
> ? GCC supports it
Nope, I only added support for one argument and only strings. I think gcc 
supports expressions, multiple args, -f args, and -O args. I wasn't sure how to 
implement it in Attr.td without making heavy changes.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126984/new/

https://reviews.llvm.org/D126984

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

[clang] ff4abe7 - [scan-build-py] Fix exception on shutdown with sarif-html output format

[Anders Waldenborg via cfe-commits]

Author: Anders Waldenborg
Date: 2022-06-10T23:21:09+02:00
New Revision: ff4abe755279a3a47cc416ef80dbc900d9a98a19

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

LOG: [scan-build-py] Fix exception on shutdown with sarif-html output format

When running scan-build-py's analyze-build script with output format set
to sarif & html it wants to print a message on how to look at the
defects mentioning the directory name twice.

But the path argument was only given once to the logging function,
causing "TypeError: not enough arguments for format string" exception.

Differential Revision: https://reviews.llvm.org/D126974

Added: 


Modified: 
clang/tools/scan-build-py/lib/libscanbuild/analyze.py

Removed: 




diff  --git a/clang/tools/scan-build-py/lib/libscanbuild/analyze.py 
b/clang/tools/scan-build-py/lib/libscanbuild/analyze.py
index 08802de81cc5..2633139fd523 100644
--- a/clang/tools/scan-build-py/lib/libscanbuild/analyze.py
+++ b/clang/tools/scan-build-py/lib/libscanbuild/analyze.py
@@ -357,6 +357,7 @@ def report_directory(hint, keep, output_format):
 try:
 yield name
 finally:
+args = (name,)
 if os.listdir(name):
 if output_format not in ['sarif', 'sarif-html']: # FIXME:
 # 'scan-view' currently does not support sarif format.
@@ -364,6 +365,7 @@ def report_directory(hint, keep, output_format):
 elif output_format == 'sarif-html':
 msg = "Run 'scan-view %s' to examine bug reports or see " \
 "merged sarif results at %s/results-merged.sarif."
+args = (name, name)
 else:
 msg = "View merged sarif results at %s/results-merged.sarif."
 keep = True
@@ -372,7 +374,7 @@ def report_directory(hint, keep, output_format):
 msg = "Report directory '%s' contains no report, but kept."
 else:
 msg = "Removing directory '%s' because it contains no report."
-logging.warning(msg, name)
+logging.warning(msg, *args)
 
 if not keep:
 os.rmdir(name)



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

[PATCH] D126974: [scan-build-py] Fix exception on shutdown with sarif-html output format

[Anders Waldenborg via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGff4abe755279: [scan-build-py] Fix exception on shutdown with 
sarif-html output format (authored by wanders).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126974/new/

https://reviews.llvm.org/D126974

Files:
  clang/tools/scan-build-py/lib/libscanbuild/analyze.py


Index: clang/tools/scan-build-py/lib/libscanbuild/analyze.py
===
--- clang/tools/scan-build-py/lib/libscanbuild/analyze.py
+++ clang/tools/scan-build-py/lib/libscanbuild/analyze.py
@@ -357,6 +357,7 @@
 try:
 yield name
 finally:
+args = (name,)
 if os.listdir(name):
 if output_format not in ['sarif', 'sarif-html']: # FIXME:
 # 'scan-view' currently does not support sarif format.
@@ -364,6 +365,7 @@
 elif output_format == 'sarif-html':
 msg = "Run 'scan-view %s' to examine bug reports or see " \
 "merged sarif results at %s/results-merged.sarif."
+args = (name, name)
 else:
 msg = "View merged sarif results at %s/results-merged.sarif."
 keep = True
@@ -372,7 +374,7 @@
 msg = "Report directory '%s' contains no report, but kept."
 else:
 msg = "Removing directory '%s' because it contains no report."
-logging.warning(msg, name)
+logging.warning(msg, *args)
 
 if not keep:
 os.rmdir(name)


Index: clang/tools/scan-build-py/lib/libscanbuild/analyze.py
===
--- clang/tools/scan-build-py/lib/libscanbuild/analyze.py
+++ clang/tools/scan-build-py/lib/libscanbuild/analyze.py
@@ -357,6 +357,7 @@
 try:
 yield name
 finally:
+args = (name,)
 if os.listdir(name):
 if output_format not in ['sarif', 'sarif-html']: # FIXME:
 # 'scan-view' currently does not support sarif format.
@@ -364,6 +365,7 @@
 elif output_format == 'sarif-html':
 msg = "Run 'scan-view %s' to examine bug reports or see " \
 "merged sarif results at %s/results-merged.sarif."
+args = (name, name)
 else:
 msg = "View merged sarif results at %s/results-merged.sarif."
 keep = True
@@ -372,7 +374,7 @@
 msg = "Report directory '%s' contains no report, but kept."
 else:
 msg = "Removing directory '%s' because it contains no report."
-logging.warning(msg, name)
+logging.warning(msg, *args)
 
 if not keep:
 os.rmdir(name)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127544: Add no_sanitize('hwaddress') (and 'memtag', but that's a no-op).

[Mitch Phillips via Phabricator via cfe-commits]

hctim created this revision.
hctim added a reviewer: pcc.
Herald added a reviewer: aaron.ballman.
Herald added a subscriber: Enna1.
Herald added a project: All.
hctim requested review of this revision.
Herald added projects: clang, Sanitizers.
Herald added subscribers: Sanitizers, cfe-commits.

Currently, __attribute__((no_sanitize('hwaddress'))) is not possible. Add this 
piece of plumbing, and now that we properly support copying attributes between 
an old and a new global variable, add a regression test for the GlobalOpt bug 
that previously lost the attribute.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127544

Files:
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/hwasan-globals.cpp
  compiler-rt/test/hwasan/TestCases/global-with-reduction.c
  compiler-rt/test/hwasan/TestCases/global.c

Index: compiler-rt/test/hwasan/TestCases/global.c
===
--- compiler-rt/test/hwasan/TestCases/global.c
+++ compiler-rt/test/hwasan/TestCases/global.c
@@ -14,9 +14,23 @@
 // RUN: %clang_hwasan -O2 %s -o %t
 // RUN: not %run %t 1 2>&1 | FileCheck --check-prefixes=CHECK,RSYM %s
 
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t && %run %t 0
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t && %run %t 1
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t -fno-pic && %run %t 1
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t -O2 && %run %t 1
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t -fno-pic -O2 && %run %t 1
+
 // REQUIRES: pointer-tagging
 
+#include 
+
+int a = 1;
+#ifdef USE_NOSANITIZE
+__attribute__((no_sanitize("hwaddress"))) int x = 1;
+#else // USE_NOSANITIZE
 int x = 1;
+#endif // USE_NOSANITIZE
+int b = 1;
 
 int atoi(const char *);
 
@@ -30,4 +44,5 @@
   // LNOSYM-NEXT: #0 0x{{.*}} ({{.*}}global.c.tmp+{{.*}})
   // CHECK-NOT: can not describe
   (&x)[atoi(argv[1])] = 1;
+  return 0;
 }
Index: compiler-rt/test/hwasan/TestCases/global-with-reduction.c
===
--- compiler-rt/test/hwasan/TestCases/global-with-reduction.c
+++ compiler-rt/test/hwasan/TestCases/global-with-reduction.c
@@ -14,20 +14,38 @@
 // RUN: %clang_hwasan -O2 %s -o %t
 // RUN: not %run %t 1 2>&1 | FileCheck --check-prefixes=CHECK,RSYM %s
 
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t && %run %t 0
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t && %run %t 1
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t -fno-pic && %run %t 1
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t -O2 && %run %t 1
+// RUN: %clang_hwasan -DUSE_NOSANITIZE %s -o %t -fno-pic -O2 && %run %t 1
+
 // REQUIRES: pointer-tagging
 
-int x = 1;
+#include 
 
-int atoi(const char *);
+// GlobalOpt may replace the current GV with a new boolean-typed GV. Previously,
+// this resulted in the "nosanitize" getting dropped because while the data/code
+// references to the GV were updated, the old metadata references weren't.
+int* f() {
+#ifdef USE_NOSANITIZE
+__attribute__((no_sanitize("hwaddress"))) static int x = 1;
+#else // USE_NOSANITIZE
+  static int x = 1;
+#endif // USE_NOSANITIZE
+  if (x == 1) x = 0;
+  return &x;
+}
 
 int main(int argc, char **argv) {
   // CHECK: Cause: global-overflow
-  // RSYM: is located 0 bytes to the right of 4-byte global variable x {{.*}} in {{.*}}global.c.tmp
+  // RSYM: is located 0 bytes to the right of 4-byte global variable f.x {{.*}} in {{.*}}global-with-reduction.c.tmp
   // RNOSYM: is located to the right of a 4-byte global variable in
-  // RNOSYM-NEXT: #0 0x{{.*}} ({{.*}}global.c.tmp+{{.*}})
-  // LSYM: is located 4 bytes to the left of 4-byte global variable x {{.*}} in {{.*}}global.c.tmp
+  // RNOSYM-NEXT: #0 0x{{.*}} ({{.*}}global-with-reduction.c.tmp+{{.*}})
+  // LSYM: is located 4 bytes to the left of 4-byte global variable f.x {{.*}} in {{.*}}global-with-reduction.c.tmp
   // LNOSYM: is located to the left of a 4-byte global variable in
-  // LNOSYM-NEXT: #0 0x{{.*}} ({{.*}}global.c.tmp+{{.*}})
+  // LNOSYM-NEXT: #0 0x{{.*}} ({{.*}}global-with-reduction.c.tmp+{{.*}})
   // CHECK-NOT: can not describe
-  (&x)[atoi(argv[1])] = 1;
+  f()[atoi(argv[1])] = 1;
+  return 0;
 }
Index: clang/test/CodeGen/hwasan-globals.cpp
===
--- /dev/null
+++ clang/test/CodeGen/hwasan-globals.cpp
@@ -0,0 +1,55 @@
+// RUN: echo "int extra_global;" > %t.extra-source.cpp
+// RUN: echo "global:*ignorelisted_global*" > %t.ignorelist
+// RUN: %clang_cc1 -include %t.extra-source.cpp -fsanitize=hwaddress -fsanitize-ignorelist=%t.ignorelist -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK
+// The ignorelist file uses regexps, so Windows path backslashes.
+// RUN: echo "src:%s" | sed -e 's/\\//g' > %t.ignorelist-src
+// RUN: %clang_cc1 -include %t.extra-source.cpp -fsanitize=hwaddress -fsanitize-ignorelist=%t.ignorelist-src -emit-llvm -o - %s | FileCheck %s --check-prefix=IGNORELIST
+
+int global;
+int __attribute__((no_sanitize("hwaddres