[PATCH] D127943: cmake: configure clang lit to use hmaptool from source directly

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov created this revision.
Herald added a subscriber: mgorny.
Herald added a project: All.
mizvekov published this revision for review.
mizvekov added reviewers: dyung, nikic.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127943

Files:
  clang/test/lit.cfg.py
  clang/utils/hmaptool/CMakeLists.txt


Index: clang/utils/hmaptool/CMakeLists.txt
===
--- clang/utils/hmaptool/CMakeLists.txt
+++ clang/utils/hmaptool/CMakeLists.txt
@@ -1,14 +1,5 @@
-# FIXME: ideally we would just provide CURRENT_TOOLS_DIR globally instead of
-#computing it just for function(configure_lit_site_cfg)
-set_llvm_build_mode()
-string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" CURRENT_TOOLS_DIR 
"${LLVM_RUNTIME_OUTPUT_INTDIR}")
-
-add_custom_command(OUTPUT "${CURRENT_TOOLS_DIR}/hmaptool"
-   COMMAND "${CMAKE_COMMAND}" -E copy 
"${CMAKE_CURRENT_SOURCE_DIR}/hmaptool" "${CURRENT_TOOLS_DIR}"
-   DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool")
-
 install(PROGRAMS hmaptool DESTINATION "${LLVM_TOOLS_INSTALL_DIR}" COMPONENT 
hmaptool)
-add_custom_target(hmaptool ALL DEPENDS "${CURRENT_TOOLS_DIR}/hmaptool")
+add_custom_target(hmaptool ALL DEPENDS "hmaptool")
 set_target_properties(hmaptool PROPERTIES FOLDER "Utils")
 
 if(NOT LLVM_ENABLE_IDE)
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -111,7 +111,7 @@
 
 config.substitutions.append(
 ('%hmaptool', "'%s' %s" % (config.python_executable,
- os.path.join(config.clang_tools_dir, 
'hmaptool'
+ os.path.join(config.clang_src_dir, 'utils', 
'hmaptool', 'hmaptool'
 
 config.substitutions.append(
 ('%deps-to-rsp',


Index: clang/utils/hmaptool/CMakeLists.txt
===
--- clang/utils/hmaptool/CMakeLists.txt
+++ clang/utils/hmaptool/CMakeLists.txt
@@ -1,14 +1,5 @@
-# FIXME: ideally we would just provide CURRENT_TOOLS_DIR globally instead of
-#computing it just for function(configure_lit_site_cfg)
-set_llvm_build_mode()
-string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" CURRENT_TOOLS_DIR "${LLVM_RUNTIME_OUTPUT_INTDIR}")
-
-add_custom_command(OUTPUT "${CURRENT_TOOLS_DIR}/hmaptool"
-   COMMAND "${CMAKE_COMMAND}" -E copy "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool" "${CURRENT_TOOLS_DIR}"
-   DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool")
-
 install(PROGRAMS hmaptool DESTINATION "${LLVM_TOOLS_INSTALL_DIR}" COMPONENT hmaptool)
-add_custom_target(hmaptool ALL DEPENDS "${CURRENT_TOOLS_DIR}/hmaptool")
+add_custom_target(hmaptool ALL DEPENDS "hmaptool")
 set_target_properties(hmaptool PROPERTIES FOLDER "Utils")
 
 if(NOT LLVM_ENABLE_IDE)
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -111,7 +111,7 @@
 
 config.substitutions.append(
 ('%hmaptool', "'%s' %s" % (config.python_executable,
- os.path.join(config.clang_tools_dir, 'hmaptool'
+ os.path.join(config.clang_src_dir, 'utils', 'hmaptool', 'hmaptool'
 
 config.substitutions.append(
 ('%deps-to-rsp',
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126308: cmake: use llvm dir variables for clang/utils/hmaptool

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

Hi @dyung, can you verify the solution I proposed in 
https://reviews.llvm.org/D127943 is good for you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126308

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

[PATCH] D127859: [clangd] Don't add inlay hints on std::move/forward

[Nathan Ridge via Phabricator via cfe-commits]

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

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127859

___
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.

Thanks for the update and the additional test cases!




Comment at: clang-tools-extra/clangd/AST.cpp:682
+  if (const auto *TTPD =
+  dyn_cast(TemplateParams.back())) {
+const auto *TTPT =

upsj wrote:
> nridge wrote:
> > I don't think there is any requirement that a pack be a trailing 
> > **template** parameter. For example, the following is valid:
> > 
> > ```
> > template 
> > void foo(A, B...);
> > 
> > void bar() {
> >   foo(1, 2, 3);
> > }
> > ```
> Do you have a suggestion for how to find this pack in general? I would like 
> to keep this function as efficient as possible, since it's used everywhere
> Do you have a suggestion for how to find this pack in general?

Just iterate backwards through `TemplateParams` rather than only considering 
`TemplateParams.back()`, I suppose.

> I would like to keep this function as efficient as possible, since it's used 
> everywhere

The `ParmVarDecl*` overload of `getPackTemplateParameter()` is called a lot via 
the `IsExpandedPack` lambdas, but this overload is only called once per depth 
level.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:541
 
+// Remove parameter names that occur multiple times completely.
+llvm::StringMap NameLastSeen;

upsj wrote:
> nridge wrote:
> > This is an interesting approach for handling `VariadicRecursive`.
> > 
> > I had in mind a different approach, something like keeping a 
> > `std::set SeenFunctionTemplates` in 
> > `resolveForwardingParameters()`, populating it with 
> > `CurrentFunction->getPrimaryTemplate()` on each iteration, and bailing if 
> > the same function template is seen more than once (indicating recursion). 
> > But this approach seems to work too, as a parameter name can't legitimately 
> > appear twice in a function declaration.
> > 
> > That said, maybe having such a `SeenFunctionTemplates` recursion guard 
> > would be helpful anyways, so that e.g. in `VariadicInfinite`, we would bail 
> > after a single recursion rather than going until `MaxDepth`?
> I see your point here - I would also like an AST based approach more than 
> this purely string-based one. The main issue is that if I deduplicate based 
> on the function templates, I would still be left with the first parameter 
> being named, which doesn't make much sense in something like make_tuple.
One idea is that we could return the original `Parameters` from 
`resolveFowardingParameters()` if we encounter recursion.


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] D127184: [clangd] Add to header map

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

Thanks for taking the time to do a systematic review!

In D127184#3577165 , 
@falbrechtskirchinger wrote:

> bits/mofunc_impl.h

I see this included from `bits/move_only_function.h`, so I think `` 
would make sense for it.

> bits/new_allocator.h

I see this included from ``, we could add that. 
(There are a few more implementation headers in `experimental/bits` which are 
included by standard headers in `` that we could consider 
adding.)

> bits/specfun.h

I see this included from ``.

> I've seen `*.tcc` files being mapped and have identified the following 
> missing files:
>
>   bits/regex.tcc
>   bits/regex_automaton.tcc
>   bits/regex_compiler.tcc
>   bits/regex_executor.tcc
>   bits/regex_scanner.tcc
>   bits/string_view.tcc
>
> Should these be added as well?

I think we can skip these as they only contain definitions, and code completion 
should choose the file containing the declaration.




Comment at: clang-tools-extra/clangd/index/CanonicalIncludes.cpp:197
   {"bits/basic_string.tcc", ""},
+  {"bits/boost_concept_check.h", ""},
   {"bits/char_traits.h", ""},

The choice of `` is pretty random here, as is already the case for 
`bits/concept_check.h`.

Given that these headers don't declare any standard symbols, only symbols which 
are pure libstdc++ implementation details, maybe we should just omit them from 
the list?


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] D127270: [clang-format] Add space in placement new expression

[omar ahmed via Phabricator via cfe-commits]

omarahmed updated this revision to Diff 437468.
omarahmed edited the summary of this revision.
omarahmed added a comment.

Add coverage for placement delete expressions and transform bool option to enum


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127270

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -10130,6 +10130,37 @@
 "void delete(link p);\n",
 format("void new (link p);\n"
"void delete (link p);\n"));
+
+  FormatStyle AfterPlacementOperator = getLLVMStyle();
+  AfterPlacementOperator.SpaceBeforeParens = FormatStyle::SBPO_Custom;
+  EXPECT_EQ(
+  AfterPlacementOperator.SpaceBeforeParensOptions.AfterPlacementOperator,
+  FormatStyle::SpaceBeforeParensCustom::APO_Always);
+  verifyFormat("new (buf) T;", AfterPlacementOperator);
+  verifyFormat("T *p = new (buf) T;", AfterPlacementOperator);
+  verifyFormat("T *p = new (buf) T(3);", AfterPlacementOperator);
+  verifyFormat("T *p = delete (buf)T(3);", AfterPlacementOperator);
+  verifyFormat("struct A {\n"
+   "  void *a;\n"
+   "  A(void *p) : a(new (p) int) {}\n"
+   "};",
+   AfterPlacementOperator);
+
+  AfterPlacementOperator.SpaceBeforeParensOptions.AfterPlacementOperator =
+  FormatStyle::SpaceBeforeParensCustom::APO_Never;
+  verifyFormat("new(buf) T;", AfterPlacementOperator);
+  verifyFormat("T *p = new(buf) T;", AfterPlacementOperator);
+  verifyFormat("T *p = delete(buf)T(3);", AfterPlacementOperator);
+  verifyFormat("struct A {\n"
+   "  void *a;\n"
+   "  A(void *p) : a(new(p) int) {}\n"
+   "};",
+   AfterPlacementOperator);
+
+  AfterPlacementOperator.SpaceBeforeParensOptions.AfterPlacementOperator =
+  FormatStyle::SpaceBeforeParensCustom::APO_Leave;
+  EXPECT_EQ("new (buf) T;", format("new (buf) T;", AfterPlacementOperator));
+  EXPECT_EQ("new(buf) T;", format("new(buf) T;", AfterPlacementOperator));
 }
 
 TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3393,6 +3393,18 @@
 if (Left.is(TT_IfMacro))
   return Style.SpaceBeforeParensOptions.AfterIfMacros ||
  spaceRequiredBeforeParens(Right);
+if (Style.SpaceBeforeParens == FormatStyle::SBPO_Custom &&
+Left.isOneOf(tok::kw_new, tok::kw_delete) &&
+Right.isNot(TT_OverloadedOperatorLParen) &&
+!(Line.MightBeFunctionDecl && Left.is(TT_FunctionDeclarationName))) {
+  if (Style.SpaceBeforeParensOptions.AfterPlacementOperator ==
+  FormatStyle::SpaceBeforeParensCustom::APO_Always ||
+  (Style.SpaceBeforeParensOptions.AfterPlacementOperator ==
+   FormatStyle::SpaceBeforeParensCustom::APO_Leave &&
+   Right.hasWhitespaceBefore()))
+return true;
+  return false;
+}
 if (Line.Type == LT_ObjCDecl)
   return true;
 if (Left.is(tok::semi))
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -936,6 +936,7 @@
Spacing.AfterFunctionDeclarationName);
 IO.mapOptional("AfterIfMacros", Spacing.AfterIfMacros);
 IO.mapOptional("AfterOverloadedOperator", Spacing.AfterOverloadedOperator);
+IO.mapOptional("AfterPlacementOperator", Spacing.AfterPlacementOperator);
 IO.mapOptional("AfterRequiresInClause", Spacing.AfterRequiresInClause);
 IO.mapOptional("AfterRequiresInExpression",
Spacing.AfterRequiresInExpression);
@@ -944,6 +945,22 @@
   }
 };
 
+template <>
+struct MappingTraits<
+FormatStyle::SpaceBeforeParensCustom::AfterPlacementOperatorStyle> {
+  static void
+  mapping(IO &IO,
+  FormatStyle::SpaceBeforeParensCustom::AfterPlacementOperatorStyle
+  &Value) {
+IO.enumCase(Value, "Always",
+FormatStyle::SpaceBeforeParensCustom::APO_Always);
+IO.enumCase(Value, "Never",
+FormatStyle::SpaceBeforeParensCustom::APO_Never);
+IO.enumCase(Value, "Leave",
+FormatStyle::SpaceBeforeParensCustom::APO_Leave);
+  }
+};
+
 template <> struct MappingTraits {
   static void mapping(IO &IO, FormatStyle::RawStringFormat &Format) {
 IO.mapOptional("Language", Format.Language);
Index: clang/include/clang/Format/Format.h
=

[PATCH] D127270: [clang-format] Add space in placement new expression

[omar ahmed via Phabricator via cfe-commits]

omarahmed added a comment.

In D127270#3584200 , @curdeius wrote:

> Does this patch really fix https://github.com/llvm/llvm-project/issues/54703?
> If so, please add test for it. Otherwise remove the link from the summary 
> (and if possible handle it in another review).

It should cover this case too, I have added a test to verify that it covers it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127270

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

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Sam Elliott via Phabricator via cfe-commits]

lenary added a comment.

Yes. Please submit a PR or Issue to the ACLE, explaining the use-case (the 
explanation here is good enough, I think).

Once the ACLE changes are merged, then you can proceed with a patch for clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127798

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

[PATCH] D122150: [clang][analyzer] Add checker for bad use of 'errno'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 437471.
balazske marked 7 inline comments as done.
balazske added a comment.

applied review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122150

Files:
  clang/docs/ReleaseNotes.rst
  clang/docs/analyzer/checkers.rst
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/ErrnoChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.h
  clang/lib/StaticAnalyzer/Checkers/ErrnoTesterChecker.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/errno-notes.c
  clang/test/Analysis/errno-options.c
  clang/test/Analysis/errno.c

Index: clang/test/Analysis/errno.c
===
--- clang/test/Analysis/errno.c
+++ clang/test/Analysis/errno.c
@@ -3,6 +3,7 @@
 // RUN:   -analyzer-checker=apiModeling.Errno \
 // RUN:   -analyzer-checker=debug.ExprInspection \
 // RUN:   -analyzer-checker=debug.ErrnoTest \
+// RUN:   -analyzer-checker=alpha.unix.Errno \
 // RUN:   -DERRNO_VAR
 
 // RUN: %clang_analyze_cc1 -verify %s \
@@ -10,8 +11,10 @@
 // RUN:   -analyzer-checker=apiModeling.Errno \
 // RUN:   -analyzer-checker=debug.ExprInspection \
 // RUN:   -analyzer-checker=debug.ErrnoTest \
+// RUN:   -analyzer-checker=alpha.unix.Errno \
 // RUN:   -DERRNO_FUNC
 
+#include "Inputs/system-header-simulator.h"
 #ifdef ERRNO_VAR
 #include "Inputs/errno_var.h"
 #endif
@@ -24,6 +27,7 @@
 int ErrnoTesterChecker_getErrno();
 int ErrnoTesterChecker_setErrnoIfError();
 int ErrnoTesterChecker_setErrnoIfErrorRange();
+int ErrnoTesterChecker_setErrnoCheckState();
 
 void something();
 
@@ -61,3 +65,185 @@
 clang_analyzer_eval(errno == 1); // expected-warning{{FALSE}} expected-warning{{TRUE}}
   }
 }
+
+void testErrnoCheck0() {
+  // If the function returns a success result code, value of 'errno'
+  // is unspecified and it is unsafe to make any decision with it.
+  // The function did not promise to not change 'errno' if no failure happens.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+if (errno) { // no warning for second time (analysis stops at the first warning)
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+errno = 0;
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+errno = 0;
+if (errno) { // no warning after overwritten 'errno'
+}
+  }
+}
+
+void testErrnoCheck1() {
+  // If the function returns error result code that is out-of-band (not a valid
+  // non-error return value) the value of 'errno' can be checked but it is not
+  // required to do so.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 1) {
+if (errno) { // no warning
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 1) {
+errno = 0; // no warning
+  }
+}
+
+void testErrnoCheck2() {
+  // If the function returns an in-band error result the value of 'errno' is
+  // required to be checked to verify if error happened.
+  // The same applies to other functions that can indicate failure only by
+  // change of 'errno'.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+if (errno) {
+}
+errno = 0; // no warning after 'errno' was read
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+errno = 0; // expected-warning{{Value of 'errno' was not checked and is overwritten here [alpha.unix.Errno]}}
+errno = 0;
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+errno = 0; // expected-warning{{Value of 'errno' was not checked and is overwritten here [alpha.unix.Errno]}}
+if (errno) {
+}
+  }
+}
+
+void testErrnoCheckUndefinedLoad() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+  }
+}
+
+void testErrnoNotCheckedAtSystemCall() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+printf("%i", 1); // expected-warning{{Value of 'errno' was not checked and may be overwritten by function 'printf' [alpha.unix.Errno]}}
+printf("%i", 1); // no warning ('printf' does not change errno state)
+  }
+}
+
+void testErrnoCheckStateInvalidate() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+something();
+if (errno) { // no warning after an invalidating function call
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+printf("%i", 1);
+if (errno) { // no warning after an invalidating

[PATCH] D122150: [clang][analyzer] Add checker for bad use of 'errno'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske added inline comments.



Comment at: clang/docs/analyzer/checkers.rst:2538-2539
+yet supported by the checker.
+The return values for the failure cases are documented in the standard Linux 
man
+pages of the functions.
+

steakhal wrote:
> Maybe place a crossref for this.
> 
> Also, am I right that there is a CERT rule about this issue?
> We should probably mention that, while placing a crossref too.
Probably there is not a preferred or "standard" site for man page lookup and it 
can be done from command line too. But I can include a  POSIX link 
https://pubs.opengroup.org/onlinepubs/9699919799/.



Comment at: clang/include/clang/StaticAnalyzer/Checkers/Checkers.td:550
+def ErrnoChecker : Checker<"Errno">,
+  HelpText<"Check not recommended uses of 'errno'">,
+  Dependencies<[ErrnoModeling]>,

steakhal wrote:
> antipatterns?
I like "improper use of `errno`" better, it is similar to `HelpText` of other 
checkers.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoChecker.cpp:101-102
+  break;
+default:
+  break;
+}

steakhal wrote:
> We should also handle `BinaryOperator` for conditional operators (EQ, NE, LT, 
> LE, ...). Or at least leave a FIXME about this.
> Have a test demonstrating the behavior.
The idea is here that this search does not stop at binary operators but goes up 
the AST until a condition is found.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp:261
+  if (unsigned EState = State->get())
+return static_cast(EState);
+  return Errno_Irrelevant;

steakhal wrote:
> I believe you no longer need to cast enums to numbers and back for enums and 
> other types.
> `get()` should return the right type.
> See D126801.
How to handle if no value exists?



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp:280
+  BR.markNotInteresting(ErrnoR);
+  return Message.c_str();
+}

steakhal wrote:
> 
I can not omit `c_str`, there is a compile error probably related to  lambda 
return type.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp:267-268
+  if (const auto *VD = dyn_cast_or_null(D))
+return VD->getIdentifier() &&
+   VD->getIdentifier()->getName() == ErrnoVarName;
+  if (const auto *FD = dyn_cast_or_null(D))

steakhal wrote:
> It looks odd that in the very next `if` block you have `II` and here you 
> don't.
I do not get what you mean here.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.h:34
+  /// value.
+  Errno_MustNotBeChecked = 2
+};

steakhal wrote:
> You don't need to prefix these with `Errno_`. It's already contained by a 
> specific namespace.
> https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
> > Unless the enumerators are defined in their own small namespace or inside a 
> > class, enumerators should have a prefix corresponding to the enum 
> > declaration name
Without `Errno_` these sound too generic. Probably have only `Errno` prefix, 
not `Errno_`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122150

___
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

[Andrzej Warzynski via Phabricator via cfe-commits]

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

LGTM, many thanks for this non trivial effort! :) I've left a few nits, feel 
free to ignore! @mstorsjo , are you also OK with this change?

[nit] "This is exactly what we do for Linux/Darwin, but the interface is 
slightly different (e.g. -libpath instead of -L)." -> Perhaps clarify what 
"interface" you have in mind (e.g. "Windows interface").




Comment at: flang/test/Driver/linker-flags.f90:12
 
-!
-! RUN COMMAND
-!
-! Use `--ld-path` so that the linker location (used in the LABEL below) is 
deterministic.
-! RUN: %flang -### -flang-experimental-exec --ld-path=/usr/bin/ld 
%S/Inputs/hello.f90 2>&1 | FileCheck %s
+! NOTE: Clang usually adds 'libcmt' and 'oldnames' on Windows, but
+!   they are not needed when compiling Fortran code and they might

This is a nit.


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] D126880: [clang-tidy] Add cppcoreguidelines-avoid-const-or-ref-data-members check

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

Kind ping to reviewers :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126880

___
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

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

From what I can see, the crash reason would be the mismatch depth and the 
setting of MultiLevelTemplateArgumentList. In `::CheckConstraintSatisfaction`, 
the depth of `RawCompletionToken ` is 0, while the depth of corresponding 
MultiLevelTemplateArgumentList is 2. So the compiler would get the outermost 
template argument incorrectly (which is a template pack in the example) in 
TransformTemplateTypeParmType.

The first though was that we should set the depth of `RawCompletionToken ` to 1 
correctly. But I felt this might not be good later since in the normal process 
of template instantiation (without concepts and constraints), the depth of 
`RawCompletionToken ` is 0 indeed. What is different that time is the depth of 
corresponding `MultiLevelTemplateArgumentList ` is 1. So it looks like the 
process is constructed on the fly. It makes sense for the perspective of 
compilation speed.

So I feel like what we should do here is in 
`Sema::CheckInstantiatedFunctionTemplateConstraints`, when we are computing the 
desired MultiLevelTemplateArgumentList, we should compute a result with depth 
of 1 in the particular case.

---

Another idea is to not do instantiation when we're checking constraints. But I 
need to think more about this.


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] D127270: [clang-format] Add space in placement new expression

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I think you are missing a PARSE unit test




Comment at: clang/docs/ClangFormatStyleOptions.rst:4261
 
+  **AfterPlacementOperator** (``AfterPlacementOperatorStyle``) 
:versionbadge:`clang-format 14`
+Defines in which cases to put a space between new/delete operators and 
opening parentheses.

Are you making this by hand or by running tools/docs/dump_format_style.py?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127270

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

[PATCH] D127873: [clang-format] Fix misplacemnt of `*` in declartion of pointer to struct

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/TokenAnnotatorTest.cpp:93
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[6], tok::star, TT_PointerOrReference);
 }

HazardyKnusperkeks wrote:
> MyDeveloperDay wrote:
> > Can you add a verifyFormat test that shows what you want? as well
> I think the annotator test is sufficient. Because it's just about annotating 
> the token, formatting is secondary (and dependent on style - these tests are 
> already in place).
I know where you are coming from, but actually if it wasn't for the 
`enable_if<>{} && ...` example in the unit tests then we'd have missed the && 
case and caused a regression. (that was ONLY covered by the small example code 
snippet)

Whilst I believe the TokenAnnotator tests are correct to have as well, I think 
we should be adding formatting examples just to ensure someone doesn't breaking 
the formatting rule that this depends on.  I always follow the Beyoncé rule... 
"If you like it you should have put a test on it!"

So If you don't want anyone to break your `*` placement after the `}` then I 
see no harm in adding a single verifyFormat(), but while you are at it please 
also test to ensure the Left/Middle/Right works with your example as you might 
expect. (just incase there are some rules about that, that could interfere with 
your setting)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127873

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

[PATCH] D127270: [clang-format] Add space in placement new expression

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/include/clang/Format/Format.h:3495
+/// \code
+///true:  false:
+///new (buf) T;vs.new(buf) T;

should this be `Always/Never`



Comment at: clang/lib/Format/Format.cpp:939
 IO.mapOptional("AfterOverloadedOperator", Spacing.AfterOverloadedOperator);
+IO.mapOptional("AfterPlacementOperator", Spacing.AfterPlacementOperator);
 IO.mapOptional("AfterRequiresInClause", Spacing.AfterRequiresInClause);

when you've fixed the code please mark the comment "done.."



Comment at: clang/lib/Format/TokenAnnotator.cpp:3396
  spaceRequiredBeforeParens(Right);
+if (Style.SpaceBeforeParens == FormatStyle::SBPO_Custom &&
+Left.isOneOf(tok::kw_new, tok::kw_delete) &&

shouldn't the very first part of this be? 


```
if (Style.SpaceBeforeParensOptions.AfterPlacementOperator != 
FormatStyle::SpaceBeforeParensCustom::APO_Leave)
{



}
```

i.e. don't we want a zero change if someone says "Leave"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127270

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

[clang-tools-extra] e984e1c - [clangd] Don't add inlay hints on std::move/forward

[Tobias Ribizel via cfe-commits]

Author: Tobias Ribizel
Date: 2022-06-16T12:24:16+02:00
New Revision: e984e1cd6137bb235ca8081b7b35e219c001f86d

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

LOG: [clangd] Don't add inlay hints on std::move/forward

This removes parameter inlay hints from a few builtin functions like 
std::move/std::forward

Reviewed By: nridge

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

Added: 


Modified: 
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/InlayHints.cpp 
b/clang-tools-extra/clangd/InlayHints.cpp
index 77dc727bba099..3afadb517cfc2 100644
--- a/clang-tools-extra/clangd/InlayHints.cpp
+++ b/clang-tools-extra/clangd/InlayHints.cpp
@@ -14,6 +14,7 @@
 #include "clang/AST/DeclarationName.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/Basic/Builtins.h"
 #include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/ScopeExit.h"
 
@@ -400,8 +401,9 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 NameVec ParameterNames = chooseParameterNames(Callee, ArgCount);
 
 // Exclude setters (i.e. functions with one argument whose name begins with
-// "set"), as their parameter name is also not likely to be interesting.
-if (isSetter(Callee, ParameterNames))
+// "set"), and builtins like std::move/forward/... as their parameter name
+// is also not likely to be interesting.
+if (isSetter(Callee, ParameterNames) || isSimpleBuiltin(Callee))
   return;
 
 for (size_t I = 0; I < ArgCount; ++I) {
@@ -440,6 +442,21 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 return WhatItIsSetting.equals_insensitive(ParamNames[0]);
   }
 
+  // Checks if the callee is one of the builtins
+  // addressof, as_const, forward, move(_if_noexcept)
+  static bool isSimpleBuiltin(const FunctionDecl *Callee) {
+switch (Callee->getBuiltinID()) {
+case Builtin::BIaddressof:
+case Builtin::BIas_const:
+case Builtin::BIforward:
+case Builtin::BImove:
+case Builtin::BImove_if_noexcept:
+  return true;
+default:
+  return false;
+}
+  }
+
   bool shouldHintName(const Expr *Arg, StringRef ParamName) {
 if (ParamName.empty())
   return false;

diff  --git a/clang-tools-extra/clangd/unittests/InlayHintTests.cpp 
b/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
index 8807cae64ce05..5644ae0d7cc1f 100644
--- a/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ b/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -555,6 +555,17 @@ TEST(ParameterHints, SetterFunctions) {
ExpectedHint{"timeout_millis: ", "timeout_millis"});
 }
 
+TEST(ParameterHints, BuiltinFunctions) {
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+void foo() {
+  int i;
+  std::forward(i);
+}
+  )cpp");
+}
+
 TEST(ParameterHints, IncludeAtNonGlobalScope) {
   Annotations FooInc(R"cpp(
 void bar() { foo(42); }



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

[PATCH] D127859: [clangd] Don't add inlay hints on std::move/forward

[Tobias Ribizel via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe984e1cd6137: [clangd] Don't add inlay hints on 
std::move/forward (authored by upsj).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127859

Files:
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp


Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -555,6 +555,17 @@
ExpectedHint{"timeout_millis: ", "timeout_millis"});
 }
 
+TEST(ParameterHints, BuiltinFunctions) {
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+void foo() {
+  int i;
+  std::forward(i);
+}
+  )cpp");
+}
+
 TEST(ParameterHints, IncludeAtNonGlobalScope) {
   Annotations FooInc(R"cpp(
 void bar() { foo(42); }
Index: clang-tools-extra/clangd/InlayHints.cpp
===
--- clang-tools-extra/clangd/InlayHints.cpp
+++ clang-tools-extra/clangd/InlayHints.cpp
@@ -14,6 +14,7 @@
 #include "clang/AST/DeclarationName.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/Basic/Builtins.h"
 #include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/ScopeExit.h"
 
@@ -400,8 +401,9 @@
 NameVec ParameterNames = chooseParameterNames(Callee, ArgCount);
 
 // Exclude setters (i.e. functions with one argument whose name begins with
-// "set"), as their parameter name is also not likely to be interesting.
-if (isSetter(Callee, ParameterNames))
+// "set"), and builtins like std::move/forward/... as their parameter name
+// is also not likely to be interesting.
+if (isSetter(Callee, ParameterNames) || isSimpleBuiltin(Callee))
   return;
 
 for (size_t I = 0; I < ArgCount; ++I) {
@@ -440,6 +442,21 @@
 return WhatItIsSetting.equals_insensitive(ParamNames[0]);
   }
 
+  // Checks if the callee is one of the builtins
+  // addressof, as_const, forward, move(_if_noexcept)
+  static bool isSimpleBuiltin(const FunctionDecl *Callee) {
+switch (Callee->getBuiltinID()) {
+case Builtin::BIaddressof:
+case Builtin::BIas_const:
+case Builtin::BIforward:
+case Builtin::BImove:
+case Builtin::BImove_if_noexcept:
+  return true;
+default:
+  return false;
+}
+  }
+
   bool shouldHintName(const Expr *Arg, StringRef ParamName) {
 if (ParamName.empty())
   return false;


Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -555,6 +555,17 @@
ExpectedHint{"timeout_millis: ", "timeout_millis"});
 }
 
+TEST(ParameterHints, BuiltinFunctions) {
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+void foo() {
+  int i;
+  std::forward(i);
+}
+  )cpp");
+}
+
 TEST(ParameterHints, IncludeAtNonGlobalScope) {
   Annotations FooInc(R"cpp(
 void bar() { foo(42); }
Index: clang-tools-extra/clangd/InlayHints.cpp
===
--- clang-tools-extra/clangd/InlayHints.cpp
+++ clang-tools-extra/clangd/InlayHints.cpp
@@ -14,6 +14,7 @@
 #include "clang/AST/DeclarationName.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/Basic/Builtins.h"
 #include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/ScopeExit.h"
 
@@ -400,8 +401,9 @@
 NameVec ParameterNames = chooseParameterNames(Callee, ArgCount);
 
 // Exclude setters (i.e. functions with one argument whose name begins with
-// "set"), as their parameter name is also not likely to be interesting.
-if (isSetter(Callee, ParameterNames))
+// "set"), and builtins like std::move/forward/... as their parameter name
+// is also not likely to be interesting.
+if (isSetter(Callee, ParameterNames) || isSimpleBuiltin(Callee))
   return;
 
 for (size_t I = 0; I < ArgCount; ++I) {
@@ -440,6 +442,21 @@
 return WhatItIsSetting.equals_insensitive(ParamNames[0]);
   }
 
+  // Checks if the callee is one of the builtins
+  // addressof, as_const, forward, move(_if_noexcept)
+  static bool isSimpleBuiltin(const FunctionDecl *Callee) {
+switch (Callee->getBuiltinID()) {
+case Builtin::BIaddressof:
+case Builtin::BIas_const:
+case Builtin::BIforward:
+case Builtin::BImove:
+case Builtin::BImove_if_noexcept:
+  retur

[PATCH] D127943: cmake: configure clang lit to use hmaptool from source directly

[Douglas Yung via Phabricator via cfe-commits]

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

I tried it on Windows building with both ninja and Visual Studio and both seem 
to work after your change. LGTM.

Thanks for looking into this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127943

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

[clang] e35096a - cmake: configure clang lit to use hmaptool from source directly

[Matheus Izvekov via cfe-commits]

Author: Matheus Izvekov
Date: 2022-06-16T13:08:50+02:00
New Revision: e35096ae961eb25843f0489847cdb6c1c586ad30

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

LOG: cmake: configure clang lit to use hmaptool from source directly

Signed-off-by: Matheus Izvekov 

Reviewed By: dyung

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

Added: 


Modified: 
clang/test/lit.cfg.py
clang/utils/hmaptool/CMakeLists.txt

Removed: 




diff  --git a/clang/test/lit.cfg.py b/clang/test/lit.cfg.py
index bf1fa141fc48b..fd86353c8cc36 100644
--- a/clang/test/lit.cfg.py
+++ b/clang/test/lit.cfg.py
@@ -111,7 +111,7 @@ def have_host_jit_support():
 
 config.substitutions.append(
 ('%hmaptool', "'%s' %s" % (config.python_executable,
- os.path.join(config.clang_tools_dir, 
'hmaptool'
+ os.path.join(config.clang_src_dir, 'utils', 
'hmaptool', 'hmaptool'
 
 config.substitutions.append(
 ('%deps-to-rsp',

diff  --git a/clang/utils/hmaptool/CMakeLists.txt 
b/clang/utils/hmaptool/CMakeLists.txt
index 1b77727fa791b..72915ec665044 100644
--- a/clang/utils/hmaptool/CMakeLists.txt
+++ b/clang/utils/hmaptool/CMakeLists.txt
@@ -1,14 +1,5 @@
-# FIXME: ideally we would just provide CURRENT_TOOLS_DIR globally instead of
-#computing it just for function(configure_lit_site_cfg)
-set_llvm_build_mode()
-string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" CURRENT_TOOLS_DIR 
"${LLVM_RUNTIME_OUTPUT_INTDIR}")
-
-add_custom_command(OUTPUT "${CURRENT_TOOLS_DIR}/hmaptool"
-   COMMAND "${CMAKE_COMMAND}" -E copy 
"${CMAKE_CURRENT_SOURCE_DIR}/hmaptool" "${CURRENT_TOOLS_DIR}"
-   DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool")
-
 install(PROGRAMS hmaptool DESTINATION "${LLVM_TOOLS_INSTALL_DIR}" COMPONENT 
hmaptool)
-add_custom_target(hmaptool ALL DEPENDS "${CURRENT_TOOLS_DIR}/hmaptool")
+add_custom_target(hmaptool ALL DEPENDS "hmaptool")
 set_target_properties(hmaptool PROPERTIES FOLDER "Utils")
 
 if(NOT LLVM_ENABLE_IDE)



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

[PATCH] D127943: cmake: configure clang lit to use hmaptool from source directly

[Matheus Izvekov 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 rGe35096ae961e: cmake: configure clang lit to use hmaptool 
from source directly (authored by mizvekov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127943

Files:
  clang/test/lit.cfg.py
  clang/utils/hmaptool/CMakeLists.txt


Index: clang/utils/hmaptool/CMakeLists.txt
===
--- clang/utils/hmaptool/CMakeLists.txt
+++ clang/utils/hmaptool/CMakeLists.txt
@@ -1,14 +1,5 @@
-# FIXME: ideally we would just provide CURRENT_TOOLS_DIR globally instead of
-#computing it just for function(configure_lit_site_cfg)
-set_llvm_build_mode()
-string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" CURRENT_TOOLS_DIR 
"${LLVM_RUNTIME_OUTPUT_INTDIR}")
-
-add_custom_command(OUTPUT "${CURRENT_TOOLS_DIR}/hmaptool"
-   COMMAND "${CMAKE_COMMAND}" -E copy 
"${CMAKE_CURRENT_SOURCE_DIR}/hmaptool" "${CURRENT_TOOLS_DIR}"
-   DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool")
-
 install(PROGRAMS hmaptool DESTINATION "${LLVM_TOOLS_INSTALL_DIR}" COMPONENT 
hmaptool)
-add_custom_target(hmaptool ALL DEPENDS "${CURRENT_TOOLS_DIR}/hmaptool")
+add_custom_target(hmaptool ALL DEPENDS "hmaptool")
 set_target_properties(hmaptool PROPERTIES FOLDER "Utils")
 
 if(NOT LLVM_ENABLE_IDE)
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -111,7 +111,7 @@
 
 config.substitutions.append(
 ('%hmaptool', "'%s' %s" % (config.python_executable,
- os.path.join(config.clang_tools_dir, 
'hmaptool'
+ os.path.join(config.clang_src_dir, 'utils', 
'hmaptool', 'hmaptool'
 
 config.substitutions.append(
 ('%deps-to-rsp',


Index: clang/utils/hmaptool/CMakeLists.txt
===
--- clang/utils/hmaptool/CMakeLists.txt
+++ clang/utils/hmaptool/CMakeLists.txt
@@ -1,14 +1,5 @@
-# FIXME: ideally we would just provide CURRENT_TOOLS_DIR globally instead of
-#computing it just for function(configure_lit_site_cfg)
-set_llvm_build_mode()
-string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" CURRENT_TOOLS_DIR "${LLVM_RUNTIME_OUTPUT_INTDIR}")
-
-add_custom_command(OUTPUT "${CURRENT_TOOLS_DIR}/hmaptool"
-   COMMAND "${CMAKE_COMMAND}" -E copy "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool" "${CURRENT_TOOLS_DIR}"
-   DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool")
-
 install(PROGRAMS hmaptool DESTINATION "${LLVM_TOOLS_INSTALL_DIR}" COMPONENT hmaptool)
-add_custom_target(hmaptool ALL DEPENDS "${CURRENT_TOOLS_DIR}/hmaptool")
+add_custom_target(hmaptool ALL DEPENDS "hmaptool")
 set_target_properties(hmaptool PROPERTIES FOLDER "Utils")
 
 if(NOT LLVM_ENABLE_IDE)
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -111,7 +111,7 @@
 
 config.substitutions.append(
 ('%hmaptool', "'%s' %s" % (config.python_executable,
- os.path.join(config.clang_tools_dir, 'hmaptool'
+ os.path.join(config.clang_src_dir, 'utils', 'hmaptool', 'hmaptool'
 
 config.substitutions.append(
 ('%deps-to-rsp',
___
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).

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:8849
 break;
-  
   // HLSL attributes:

hctim wrote:
> aaron.ballman wrote:
> > Spurious whitespace change?
> unfortunately there's no way in my editor to trim trailing whitespace only on 
> changed lines :(, so i end up fixing things like this drive-by.
> 
> let me know if you feel very strongly about this diff and I can kill it, but 
> I personally think the drive-by-fix isn't a huge problem and the alternative 
> of whitespace-fix-only commit seems a bit overkill
Personally, I don't feel very strongly because the chances of the whitespace 
being someone's entrypoint to git-blame is pretty minimal (especially given 
there's only one change here). However, we typically still ask for formatting 
changes to be separated out 
(https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access #2) rather 
than lumped in with functional changes so reviewers will ask for these sort of 
changes to be backed out, so this may crop up repeatedly if your editor doesn't 
give you the options you need.



Comment at: clang/test/CodeGen/hwasan-globals.cpp:1-2
+// 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

hctim wrote:
> aaron.ballman wrote:
> > Are these files automatically deleted when the test is done because we're 
> > using %t, or do we need to clean those up manually?
> AFAIK nothing is ever automatically deleted (e.g. the outputs of the 
> compiler). Is automated cleanup here necessary?
Necessary? Probably not (I'd expect these to go into the temp directory). A 
kindness so disks don't fill up? Probably. Because the content here is static 
anyway, these could just be files in the `Inputs` directory so they don't need 
to be created every time the test is run.



Comment at: compiler-rt/test/hwasan/TestCases/global-with-reduction.c:25
 
-int x = 1;
+#include 
 

hctim wrote:
> aaron.ballman wrote:
> > I'm not a compiler-rt expert, but is this valid? I assume this is using the 
> > system stdlib.h which is not something we usually want in lit tests.
> > 
> > I think that's why `atoi` was previously being forward declared; then we 
> > don't need to include the whole header file.
> I don't see there being any problem with including stdlib.h here, it's done 
> in lots of other compiler-rt tests.
> 
> I patched this up because the compiler actually complains about 
> forward-declaring c library functions (it's just silenced by llvm-lit by 
> default).
Ah, good point about other tests doing this (it's a restriction we have in 
Clang tests, but not here from what I can tell).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127544

___
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).

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Btw, precommit CI caught a failure:

  FAIL: Clang :: CodeGen/hwasan-globals.cpp (4495 of 15547)
   TEST 'Clang :: CodeGen/hwasan-globals.cpp' FAILED 

  Script:
  --
  : 'RUN: at line 1';   echo "int extra_global;" > 
C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.extra-source.cpp
  : 'RUN: at line 2';   echo "global:*ignorelisted_global*" > 
C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.ignorelist
  : 'RUN: at line 3';   
c:\ws\w3\llvm-project\premerge-checks\build\bin\clang.exe -cc1 
-internal-isystem 
c:\ws\w3\llvm-project\premerge-checks\build\lib\clang\15.0.0\include 
-nostdsysteminc -include 
C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.extra-source.cpp
 -fsanitize=hwaddress 
-fsanitize-ignorelist=C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.ignorelist
 -emit-llvm -o - 
C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp | 
c:\ws\w3\llvm-project\premerge-checks\build\bin\filecheck.exe 
C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp 
--check-prefixes=CHECK
  : 'RUN: at line 5';   echo 
"src:C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp"
 | sed -e 's/\\//g' > 
C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.ignorelist-src
  : 'RUN: at line 6';   
c:\ws\w3\llvm-project\premerge-checks\build\bin\clang.exe -cc1 
-internal-isystem 
c:\ws\w3\llvm-project\premerge-checks\build\lib\clang\15.0.0\include 
-nostdsysteminc -include 
C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.extra-source.cpp
 -fsanitize=hwaddress 
-fsanitize-ignorelist=C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.ignorelist-src
 -emit-llvm -o - 
C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp | 
c:\ws\w3\llvm-project\premerge-checks\build\bin\filecheck.exe 
C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp 
--check-prefix=IGNORELIST
  --
  Exit Code: 1
  
  Command Output (stdout):
  --
  $ ":" "RUN: at line 1"
  $ "echo" "int extra_global;"
  $ ":" "RUN: at line 2"
  $ "echo" "global:*ignorelisted_global*"
  $ ":" "RUN: at line 3"
  $ "c:\ws\w3\llvm-project\premerge-checks\build\bin\clang.exe" "-cc1" 
"-internal-isystem" 
"c:\ws\w3\llvm-project\premerge-checks\build\lib\clang\15.0.0\include" 
"-nostdsysteminc" "-include" 
"C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.extra-source.cpp"
 "-fsanitize=hwaddress" 
"-fsanitize-ignorelist=C:\ws\w3\llvm-project\premerge-checks\build\tools\clang\test\CodeGen\Output\hwasan-globals.cpp.tmp.ignorelist"
 "-emit-llvm" "-o" "-" 
"C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp"
  $ "c:\ws\w3\llvm-project\premerge-checks\build\bin\filecheck.exe" 
"C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp" 
"--check-prefixes=CHECK"
  # command stderr:
  
C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp:21:11:
 error: CHECK: expected string not found in input
  // CHECK: @{{.*}}extra_global{{.*}}.hwasan =
^
  :10:77: note: scanning from here
  @"?ignorelisted_global@@3HA" = dso_local global i32 0, no_sanitize_hwaddress, 
align 4
  ^
  :17:1: note: possible intended match here
  @"?extra_global@@3HA.hwasan" = private global { i32, [12 x i8] } { i32 0, [12 
x i8] c"\00\00\00\00\00\00\00\00\00\00\00\01" }, align 16
  ^
  
  Input file: 
  Check file: 
C:\ws\w3\llvm-project\premerge-checks\clang\test\CodeGen\hwasan-globals.cpp
  
  -dump-input=help explains the following input dump.
  
  Input was:
  <<
  .
  .
  .
  5:  
  6: $hwasan.module_ctor = comdat any 
  7:  
  8: @"?attributed_global@@3HA" = dso_local global i32 0, 
no_sanitize_hwaddress, align 4 
  9: @"?disable_instrumentation_global@@3HA" = dso_local global i32 
0, no_sanitize_hwaddress, align 4 
 10: @"?ignorelisted_global@@3HA" = dso_local global i32 0, 
no_sanitize_hwaddress, align 4 
  check:21'0
 X~ error: no match found
 11: @llvm.used = appending global [1 x ptr] [ptr 
@hwasan.module_ctor], section "llvm.metadata" 
  check:21'0 
~~~
 12: @llvm.global_ctors = appending global [1 x { i32, ptr, ptr }] 
[{ i32, ptr, ptr } { i32 0, ptr @hwasan.module_ctor,

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

[Tobias Ribizel via Phabricator via cfe-commits]

upsj updated this revision to Diff 437508.
upsj marked 4 inline comments as done.
upsj added a comment.

- remove inlay hints from std::forward in tests
- identify recursive variadic calls from template, not post-processing
- allow template parameter packs to appear at any place
- improve documentation


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124690

Files:
  clang-tools-extra/clangd/AST.cpp
  clang-tools-extra/clangd/AST.h
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -174,6 +174,43 @@
   )cpp");
 }
 
+TEST(ParameterHints, NoNameVariadicDeclaration) {
+  // No hint for anonymous variadic parameter
+  assertParameterHints(R"cpp(
+template 
+void foo(Args&& ...);
+void bar() {
+  foo(42);
+}
+  )cpp");
+}
+
+TEST(ParameterHints, NoNameVariadicForwarded) {
+  // No hint for anonymous variadic parameter
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+void foo(int);
+template 
+void bar(Args&&... args) { return foo(std::forward(args)...); }
+void baz() {
+  bar(42);
+}
+  )cpp");
+}
+
+TEST(ParameterHints, NoNameVariadicPlain) {
+  // No hint for anonymous variadic parameter
+  assertParameterHints(R"cpp(
+void foo(int);
+template 
+void bar(Args&&... args) { return foo(args...); }
+void baz() {
+  bar(42);
+}
+  )cpp");
+}
+
 TEST(ParameterHints, NameInDefinition) {
   // Parameter name picked up from definition if necessary.
   assertParameterHints(R"cpp(
@@ -186,6 +223,36 @@
ExpectedHint{"param: ", "param"});
 }
 
+TEST(ParameterHints, NamePartiallyInDefinition) {
+  // Parameter name picked up from definition if necessary.
+  assertParameterHints(R"cpp(
+void foo(int, int b);
+void bar() {
+  foo($param1[[42]], $param2[[42]]);
+}
+void foo(int a, int) {};
+  )cpp",
+   ExpectedHint{"a: ", "param1"},
+   ExpectedHint{"b: ", "param2"});
+}
+
+TEST(ParameterHints, NameInDefinitionVariadic) {
+  // Parameter name picked up from definition in a resolved forwarded parameter.
+  assertParameterHints(R"cpp(
+void foo(int, int);
+template 
+void bar(Args... args) {
+  foo(args...);
+}
+void baz() {
+  bar($param1[[42]], $param2[[42]]);
+}
+void foo(int a, int b) {};
+  )cpp",
+   ExpectedHint{"a: ", "param1"},
+   ExpectedHint{"b: ", "param2"});
+}
+
 TEST(ParameterHints, NameMismatch) {
   // Prefer name from declaration.
   assertParameterHints(R"cpp(
@@ -258,6 +325,349 @@
ExpectedHint{"param: ", "param"});
 }
 
+TEST(ParameterHints, VariadicForwardedConstructor) {
+  // Name hint for variadic parameter using std::forward in a constructor call
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+struct S { S(int a); };
+template 
+T bar(Args&&... args) { return T{std::forward(args)...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicPlainConstructor) {
+  // Name hint for variadic parameter in a constructor call
+  assertParameterHints(R"cpp(
+struct S { S(int a); };
+template 
+T bar(Args&&... args) { return T{args...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicForwardedNewConstructor) {
+  // Name hint for variadic parameter using std::forward in a new expression
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+struct S { S(int a); };
+template 
+T* bar(Args&&... args) { return new T{std::forward(args)...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicPlainNewConstructor) {
+  // Name hint for variadic parameter in a new expression
+  assertParameterHints(R"cpp(
+struct S { S(int a); };
+template 
+T* bar(Args&&... args) { return new T{args...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicForwarded) {
+  // Name for variadic paramete

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

[Tobias Ribizel via Phabricator via cfe-commits]

upsj added inline comments.



Comment at: clang-tools-extra/clangd/AST.cpp:682
+  if (const auto *TTPD =
+  dyn_cast(TemplateParams.back())) {
+const auto *TTPT =

nridge wrote:
> upsj wrote:
> > nridge wrote:
> > > I don't think there is any requirement that a pack be a trailing 
> > > **template** parameter. For example, the following is valid:
> > > 
> > > ```
> > > template 
> > > void foo(A, B...);
> > > 
> > > void bar() {
> > >   foo(1, 2, 3);
> > > }
> > > ```
> > Do you have a suggestion for how to find this pack in general? I would like 
> > to keep this function as efficient as possible, since it's used everywhere
> > Do you have a suggestion for how to find this pack in general?
> 
> Just iterate backwards through `TemplateParams` rather than only considering 
> `TemplateParams.back()`, I suppose.
> 
> > I would like to keep this function as efficient as possible, since it's 
> > used everywhere
> 
> The `ParmVarDecl*` overload of `getPackTemplateParameter()` is called a lot 
> via the `IsExpandedPack` lambdas, but this overload is only called once per 
> depth level.
Ah thanks, of course! I got tricked by my own overloads.


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] D127579: [clang][WIP] add option to keep types of ptr args for non-kernel functions in metadata

[Ilia Diachkov via Phabricator via cfe-commits]

iliya-diyachkov added a comment.

In D127579#3585411 , @Anastasia wrote:

> Also is there anything that we don't need from the metadata that are 
> currently emitted for the use case i.e. for example argument names? This 
> could reduce the number of metadata emitted...

Sure, I think we don't need all info. As I mentioned in TODO I'm going to leave 
only type info and remove other metadata emission. For this purpose I'll 
separate a new function (that emits the type info) from GenOpenCLArgMetadata.

In D127579#3586472 , @jcranmer-intel 
wrote:

> I haven't yet tested whether or not this patch is sufficient to support all 
> of the use cases I need for type scavenging for SPIR-V, but one of the things 
> I do see is that there's no support for return type information, which may be 
> a bit of an issue.

I think the return type information can be added in the next version of the 
patch, however it should be attached to function declarations (not definitions 
as it's done now), right? Do you think, declarations also require information 
about argument types?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127579

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

[PATCH] D127579: [clang][WIP] add option to keep types of ptr args for non-kernel functions in metadata

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D127579#3586092 , @nikic wrote:

> @Anastasia Thanks, that does sound like a legitimate reason to include the 
> information. I want to double check though, does linking the modules actually 
> fail if the functions have signatures that differ only by pointer types? At 
> least for normal LLVM IR this would work fine, and would just result in the 
> insertion of a bitcast during linking (and then typically the bitcast would 
> get shifted from the called function to the call arguments later).

If I use `spirv-link `with two modules that have mismatching pointee type in a 
function parameter I get an error:

  error: 0: Type mismatch on symbol "foo" between imported variable/function %6 
and exported variable/function %17. 

The way I understand a bitcast instruction in SPIR-V (`OpBitcast` in 
https://www.khronos.org/registry/SPIR-V/specs/unified1/SPIRV.html#_conversion_instructions)
 is that it can only apply to pointer types which are distinct from function 
types. Note that I believe that function pointers are illegal, at least we 
disallow them in OpenCL.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127579

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

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Gabor Marton via Phabricator via cfe-commits]

martong added subscribers: steakhal, NoQ.
martong added a comment.

@NoQ @steakhal FYI


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127923

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

[PATCH] D122150: [clang][analyzer] Add checker for bad use of 'errno'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 437513.
balazske added a comment.

Use typed state trait.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122150

Files:
  clang/docs/ReleaseNotes.rst
  clang/docs/analyzer/checkers.rst
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/ErrnoChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.h
  clang/lib/StaticAnalyzer/Checkers/ErrnoTesterChecker.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/errno-notes.c
  clang/test/Analysis/errno-options.c
  clang/test/Analysis/errno.c

Index: clang/test/Analysis/errno.c
===
--- clang/test/Analysis/errno.c
+++ clang/test/Analysis/errno.c
@@ -3,6 +3,7 @@
 // RUN:   -analyzer-checker=apiModeling.Errno \
 // RUN:   -analyzer-checker=debug.ExprInspection \
 // RUN:   -analyzer-checker=debug.ErrnoTest \
+// RUN:   -analyzer-checker=alpha.unix.Errno \
 // RUN:   -DERRNO_VAR
 
 // RUN: %clang_analyze_cc1 -verify %s \
@@ -10,8 +11,10 @@
 // RUN:   -analyzer-checker=apiModeling.Errno \
 // RUN:   -analyzer-checker=debug.ExprInspection \
 // RUN:   -analyzer-checker=debug.ErrnoTest \
+// RUN:   -analyzer-checker=alpha.unix.Errno \
 // RUN:   -DERRNO_FUNC
 
+#include "Inputs/system-header-simulator.h"
 #ifdef ERRNO_VAR
 #include "Inputs/errno_var.h"
 #endif
@@ -24,6 +27,7 @@
 int ErrnoTesterChecker_getErrno();
 int ErrnoTesterChecker_setErrnoIfError();
 int ErrnoTesterChecker_setErrnoIfErrorRange();
+int ErrnoTesterChecker_setErrnoCheckState();
 
 void something();
 
@@ -61,3 +65,185 @@
 clang_analyzer_eval(errno == 1); // expected-warning{{FALSE}} expected-warning{{TRUE}}
   }
 }
+
+void testErrnoCheck0() {
+  // If the function returns a success result code, value of 'errno'
+  // is unspecified and it is unsafe to make any decision with it.
+  // The function did not promise to not change 'errno' if no failure happens.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+if (errno) { // no warning for second time (analysis stops at the first warning)
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+errno = 0;
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+errno = 0;
+if (errno) { // no warning after overwritten 'errno'
+}
+  }
+}
+
+void testErrnoCheck1() {
+  // If the function returns error result code that is out-of-band (not a valid
+  // non-error return value) the value of 'errno' can be checked but it is not
+  // required to do so.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 1) {
+if (errno) { // no warning
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 1) {
+errno = 0; // no warning
+  }
+}
+
+void testErrnoCheck2() {
+  // If the function returns an in-band error result the value of 'errno' is
+  // required to be checked to verify if error happened.
+  // The same applies to other functions that can indicate failure only by
+  // change of 'errno'.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+if (errno) {
+}
+errno = 0; // no warning after 'errno' was read
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+errno = 0; // expected-warning{{Value of 'errno' was not checked and is overwritten here [alpha.unix.Errno]}}
+errno = 0;
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+errno = 0; // expected-warning{{Value of 'errno' was not checked and is overwritten here [alpha.unix.Errno]}}
+if (errno) {
+}
+  }
+}
+
+void testErrnoCheckUndefinedLoad() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+  }
+}
+
+void testErrnoNotCheckedAtSystemCall() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+printf("%i", 1); // expected-warning{{Value of 'errno' was not checked and may be overwritten by function 'printf' [alpha.unix.Errno]}}
+printf("%i", 1); // no warning ('printf' does not change errno state)
+  }
+}
+
+void testErrnoCheckStateInvalidate() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+something();
+if (errno) { // no warning after an invalidating function call
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+printf("%i", 1);
+if (errno) { // no warning after an invalidating standard function call
+}
+  }
+}
+
+vo

[PATCH] D126540: PowerPC] Emit warning for incompatible vector types that are currently diagnosed with -fno-lax-vector-conversions

[Lei Huang via Phabricator via cfe-commits]

lei added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:7716
+// This returns true if at least one of the types is an altivec vector.
+bool Sema::areAnyVectorTypesAltivec(QualType SrcTy, QualType DestTy) {
+  assert((DestTy->isVectorType() || SrcTy->isVectorType()) &&

maybe rename to `anyAltivecTypes()`?



Comment at: clang/lib/Sema/SemaExpr.cpp:7738
+// This returns true if both vectors have the same element type.
+bool Sema::areVectorTypesSameElmType(QualType SrcTy, QualType DestTy) {
+  assert((DestTy->isVectorType() || SrcTy->isVectorType()) &&

rename suggestion: haveSameVectorElemTypes()


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126540

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

[PATCH] D127579: [clang][WIP] add option to keep types of ptr args for non-kernel functions in metadata

[Alexey Bader via Phabricator via cfe-commits]

bader added a comment.

> The way I understand a bitcast instruction in SPIR-V (`OpBitcast` in 
> https://www.khronos.org/registry/SPIR-V/specs/unified1/SPIRV.html#_conversion_instructions)
>  is that it can only apply to pointer types which are distinct from function 
> types. Note that I believe that function pointers are illegal, at least we 
> disallow them in OpenCL.

FYI: we are experimenting with function pointers on Intel HW programmed via 
SPIR-V. Extension draft - 
https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_function_pointers.asciidoc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127579

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

[PATCH] D126540: PowerPC] Emit warning for incompatible vector types that are currently diagnosed with -fno-lax-vector-conversions

[Lei Huang via Phabricator via cfe-commits]

lei added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:7738
+// This returns true if both vectors have the same element type.
+bool Sema::areVectorTypesSameElmType(QualType SrcTy, QualType DestTy) {
+  assert((DestTy->isVectorType() || SrcTy->isVectorType()) &&

lei wrote:
> rename suggestion: haveSameVectorElemTypes()
> rename suggestion: haveSameVectorElemTypes()

actually maybe this:  areSameVectorElemTypes()


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126540

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

[PATCH] D127579: [clang][WIP] add option to keep types of ptr args for non-kernel functions in metadata

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D127579#3588651 , @bader wrote:

>> The way I understand a bitcast instruction in SPIR-V (`OpBitcast` in 
>> https://www.khronos.org/registry/SPIR-V/specs/unified1/SPIRV.html#_conversion_instructions)
>>  is that it can only apply to pointer types which are distinct from function 
>> types. Note that I believe that function pointers are illegal, at least we 
>> disallow them in OpenCL.
>
> FYI: we are experimenting with function pointers on Intel HW programmed via 
> SPIR-V. Extension draft - 
> https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_function_pointers.asciidoc.

Ok, I see. That confirms I am guessing that in the standard SPIR-V binary we 
won't be able to apply LLVM IR's trick.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127579

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

[PATCH] D124244: [analyzer] add StoreToImmutable and ModelConstQualifiedReturn checkers

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Sorry for my late reply.

It feels like we have some serious obstacles.
The `check::PostCall` handler wants to mark some memory region immutable. 
Currently, the checker creates a new //symbolic// memregion, spawned into the 
//immutable// memory space. After this it simply re-binds the return value.
However, only `eval::Call` handler is supposed (**must**) to bind the return 
value, so the current implementation cannot land.

I played with the trait idea, which was this:

1. Introduce a new program state trait with the 
`REGISTER_SET_WITH_PROGRAMSTATE(ImmutableRegions, const ento::MemRegion *)`. 
One should not bind values to these regions. (*)
2. The `check::PostCall` would simply insert into this set.
3. The `StoreToImmutableChecker`, at the `check::Bind` handler, would verify 
that the region is not contained by the set - otherwise emit a report...
4. Surface this new trait to be reachable by the `Core` infrastructure.
5. Refactor all the `Core` functions introducing or expecting 
`MemRegionManager::getGlobalsRegion`s to insert the region in question into 
this `ImmutableRegions` set associated with the current `State`, producing some 
new `State`.

The last point is the most critical. Now, by design, `MemRegionManager` does 
not refer to the `ProgramState`, hence we don't have one that we could mutate 
by inserting into the `ImmutableRegions` set. Passing a `ProgramStateRef` along 
all the functions is a nightmare. Trust me, I've tried it.
That being said, eradicating `GlobalImmutableSpaceRegion` seems to be 
challenging.

I've settled on using the custom trait, and the `GlobalImmutableSpaceRegion` 
memspace kind to detect if the store (bind) should be allowed or not.
F23475561: UsingTraitsForTrackingImmutability.patch 


WDYT @NoQ, how could we get rid of the `GlobalImmutableSpaceRegion`?

---

(*): Originally I wanted a set of `const MemSpaceRegion *`, but it turns out a 
default eval called function which returns a plain old mutable pointer is of 
`SymRegion{conj{}}` at the `UnknownSpaceRegion`. And we probably don't want to 
mark immutable the whole `UnknownSpaceRegion` xD.


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

https://reviews.llvm.org/D124244

___
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.

In D126907#3588417 , @ChuanqiXu wrote:

> From what I can see, the crash reason would be the mismatch depth and the 
> setting of MultiLevelTemplateArgumentList. In 
> `::CheckConstraintSatisfaction`, the depth of `RawCompletionToken ` is 0, 
> while the depth of corresponding MultiLevelTemplateArgumentList is 2. So the 
> compiler would get the outermost template argument incorrectly (which is a 
> template pack in the example) in TransformTemplateTypeParmType.
>
> The first though was that we should set the depth of `RawCompletionToken ` to 
> 1 correctly. But I felt this might not be good later since in the normal 
> process of template instantiation (without concepts and constraints), the 
> depth of `RawCompletionToken ` is 0 indeed. What is different that time is 
> the depth of corresponding `MultiLevelTemplateArgumentList ` is 1. So it 
> looks like the process is constructed on the fly. It makes sense for the 
> perspective of compilation speed.
>
> So I feel like what we should do here is in 
> `Sema::CheckInstantiatedFunctionTemplateConstraints`, when we are computing 
> the desired MultiLevelTemplateArgumentList, we should compute a result with 
> depth of 1 in the particular case.
>
> ---
>
> Another idea is to not do instantiation when we're checking constraints. But 
> I need to think more about this.

I don't know of the 'another idea'?  We have to do instantiation before 
checking, and if we do it too early, we aren't doing the deferred 
instantiation.  And the problem is that the RawCompletionToken uses a concept 
to refer to 'itself'.  However, this version of 'itself' isn't valid, since the 
'depth' is wrong once it tries to instantiate relative to the 'top level'.  
However, this IS happening during instantiation?

My latest thought is that perhaps the "IsEvaluatingAConstraint" should NOT 
happen at the Sema level (but at the instantiator level), since it ends up 
catching things it shouldn't?  I tried it and have a handful of failures of 
trying to check uninstantiated constraints, but I've not dug completely into it.


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] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Please, consider updating the summary to clearly specify the motivation for 
making this change.
It describes what this patch intends to do, but I'm about the why.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127923

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

[PATCH] D127961: [OpenCL] Reduce emitting candidate notes for builtins

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh created this revision.
svenvh added a reviewer: Anastasia.
svenvh added a project: clang.
Herald added subscribers: Naghasan, ldrumm, yaxunl.
Herald added a project: All.
svenvh requested review of this revision.
Herald added a subscriber: cfe-commits.

When overload resolution fails, clang emits a note diagnostic for each
candidate.  For OpenCL builtins this often leads to many repeated note
diagnostics with no new information.  Stop emitting such notes.

Update a test that was relying on counting those notes to check how
many builtins are available for certain extension configurations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127961

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -171,14 +171,14 @@
 // extension is disabled.  Test this by counting the number of notes about
 // candidate functions.
 void test_atomic_double_reporting(volatile __generic atomic_int *a) {
-  atomic_init(a);
+  atomic_init(a, a);
   // expected-error@-1{{no matching function for call to 'atomic_init'}}
 #if defined(NO_FP64)
   // Expecting 5 candidates: int, uint, long, ulong, float
-  // expected-note@-4 5 {{candidate function not viable: requires 2 arguments, 
but 1 was provided}}
+  // expected-note@-4 5 {{candidate function not viable: no known conversion}}
 #else
   // Expecting 6 candidates: int, uint, long, ulong, float, double
-  // expected-note@-7 6 {{candidate function not viable: requires 2 arguments, 
but 1 was provided}}
+  // expected-note@-7 6 {{candidate function not viable: no known conversion}}
 #endif
 }
 
@@ -198,7 +198,6 @@
 
   atomic_exchange_explicit(a_int, d, memory_order_seq_cst);
   // expected-error@-1{{no matching function for call to 
'atomic_exchange_explicit'}}
-  // expected-note@-2 + {{candidate function not viable}}
 
   atomic_exchange_explicit(a_int, d, memory_order_seq_cst, 
memory_scope_work_group);
 }
@@ -272,9 +271,7 @@
   res = read_imageh(image_read_only_image2d, i2);
 #if __OPENCL_C_VERSION__ < CL_VERSION_1_2 && !defined(__OPENCL_CPP_VERSION__)
   // expected-error@-3{{no matching function for call to 'read_imagef'}}
-  // expected-note@-4 + {{candidate function not viable}}
-  // expected-error@-4{{no matching function for call to 'read_imageh'}}
-  // expected-note@-5 + {{candidate function not viable}}
+  // expected-error@-3{{no matching function for call to 'read_imageh'}}
 #endif
   res = read_imageh(image_read_only_image2d, sampler, i2);
 
@@ -304,7 +301,6 @@
   write_imagef(image3dwo, i4, i, f4);
 #if __OPENCL_C_VERSION__ <= CL_VERSION_1_2 && !defined(__OPENCL_CPP_VERSION__)
   // expected-error@-2{{no matching function for call to 'write_imagef'}}
-  // expected-note@-3 + {{candidate function not viable}}
 #endif
 }
 
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -11218,6 +11218,13 @@
   if (shouldSkipNotingLambdaConversionDecl(Fn))
 return;
 
+  // There is no physical candidate declaration to point to for OpenCL 
builtins.
+  // Except for failed conversions, the notes are identical for each candidate,
+  // so do not generate such notes.
+  if (S.getLangOpts().OpenCL && Fn->isImplicit() &&
+  Cand->FailureKind != ovl_fail_bad_conversion)
+return;
+
   // Note deleted candidates, but only if they're viable.
   if (Cand->Viable) {
 if (Fn->isDeleted()) {


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -171,14 +171,14 @@
 // extension is disabled.  Test this by counting the number of notes about
 // candidate functions.
 void test_atomic_double_reporting(volatile __generic atomic_int *a) {
-  atomic_init(a);
+  atomic_init(a, a);
   // expected-error@-1{{no matching function for call to 'atomic_init'}}
 #if defined(NO_FP64)
   // Expecting 5 candidates: int, uint, long, ulong, float
-  // expected-note@-4 5 {{candidate function not viable: requires 2 arguments, but 1 was provided}}
+  // expected-note@-4 5 {{candidate function not viable: no known conversion}}
 #else
   // Expecting 6 candidates: int, uint, long, ulong, float, double
-  // expected-note@-7 6 {{candidate function not viable: requires 2 arguments, but 1 was provided}}
+  // expected-note@-7 6 {{candidate function not viable: no known conversion}}
 #endif
 }
 
@@ -198,7 +198,6 @@
 
   atomic_exchange_explicit(a_int, d, memory_order_seq_cst);
   // expected-error@-1{{no matching function for call to 'atomic_exchange_explicit'}}
-  // expected-note@-2 + {{candidate 

[PATCH] D122150: [clang][analyzer] Add checker for bad use of 'errno'.

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

It looks great.
Let me check the test coverage and the generated docs page it everything looks 
great.




Comment at: clang/docs/analyzer/checkers.rst:2538
+may change value of ``errno`` if the call does not fail.
+Therefore ``errno`` should only be used if it is known from the return value
+of a function that the call has failed.





Comment at: clang/docs/analyzer/checkers.rst:2540
+of a function that the call has failed.
+There are exceptions to this rule but the affected functions are not
+yet supported by the checker.

Please mention at least one of those functions.



Comment at: clang/include/clang/StaticAnalyzer/Checkers/Checkers.td:553-554
+  CheckerOptions<[
+CmdLineOptionisExternC() && CallF->isGlobal() &&
+  C.getSourceManager().isInSystemHeader(CallF->getLocation()) &&
+  !isErrno(CallF)) {

Does this refer to the callsite or to the Decl location?
I think the former, which would be a bug I think.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoChecker.cpp:46
+
+  /// Indicates if a read (load) of 'errno' is allowed in a non-conditional
+  /// statement.

martong wrote:
> Or `in a statement without a condition` ?
I don't really understand this comment. What is a //non-condition part of a 
statement//?



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp:280
+  BR.markNotInteresting(ErrnoR);
+  return Message.c_str();
+}

balazske wrote:
> steakhal wrote:
> > 
> I can not omit `c_str`, there is a compile error probably related to  lambda 
> return type.
Yes, you will need to specify explicitly the return type of the lambda: `-> 
std::string`.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp:267-268
+  if (const auto *VD = dyn_cast_or_null(D))
+return VD->getIdentifier() &&
+   VD->getIdentifier()->getName() == ErrnoVarName;
+  if (const auto *FD = dyn_cast_or_null(D))

balazske wrote:
> steakhal wrote:
> > It looks odd that in the very next `if` block you have `II` and here you 
> > don't.
> I do not get what you mean here.
I was thinking about this:
```lang=C++
bool isErrno(const Decl *D) {
  if (const auto *VD = dyn_cast_or_null(D))
if (const IdentifierInfo *II = VD->getIdentifier())
  return II->getName() == ErrnoVarName;
  if (const auto *FD = dyn_cast_or_null(D))
if (const IdentifierInfo *II = FD->getIdentifier())
  return llvm::is_contained(ErrnoLocationFuncNames, II->getName());
  return false;
}
```
This way both checks would follow the same pattern, symmetry.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.h:34
+  /// value.
+  Errno_MustNotBeChecked = 2
+};

balazske wrote:
> steakhal wrote:
> > You don't need to prefix these with `Errno_`. It's already contained by a 
> > specific namespace.
> > https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
> > > Unless the enumerators are defined in their own small namespace or inside 
> > > a class, enumerators should have a prefix corresponding to the enum 
> > > declaration name
> Without `Errno_` these sound too generic. Probably have only `Errno` prefix, 
> not `Errno_`?
But you always refer to it by it's qualified name: 
`errno_modeling::Errno_Irrelevant`.
In which case this prefix is just noise IMO. That's what I'm about.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122150

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

[PATCH] D127874: [analyzer] Reimplement UnreachableCodeChecker using worklists

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

> If some checker placed a sink node into some block, the successors of the 
> sink block was marked unreachable previously. This leads to an unpleasant 
> situation from the user's point of view since a different bugreport gets 
> correlated with the FPs caused by the sink node of that. This effectively 
> means that for each unconditional sink, we will also have (preferable) an 
> unreachable code report as well.

An example and/or a visualization would be useful for this.

> Now, we ignore unreachable nodes if the predecessor is reachable, but none of 
> its successors are.

Isn't there a contradiction here? The node's predecessor must have at least one 
reachable successor, the node itself; otherwise the node itself would be 
unreachable.

> the sweep-back part cannot be implemented correctly via a DFS visitation

What is the purpose of this sweep-back? You should summarize that here.

> ... Do a backward DFS to find the start of each unreachable CFG block chain 
> ...

How does it find the //start// if there is a cycle in the graph? Isn't it 
rather about finding strongly connected components?

> The sweep-back part cannot be implemented correctly via a DFS visitation ... 
> Why do we need to do the sweep-back part in BFS order?

Connected components can be found by both DFS or BFS. Please elaborate why 
should we prefer BFS? The problem you are trying to solve seems to be an 
unnecessarily convoluted problem to me. Shouldn't it be enough to simply pick 
one node (or all of them) from the connected component? It should not matter if 
we use DFS or BFS for finding the nodes in a connected component.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127874

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

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

[Aaron Ballman via Phabricator via cfe-commits]

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

In D126495#3574115 , 
@LegalizeAdulthood wrote:

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

We do:

https://releases.llvm.org/12.0.0/tools/clang/tools/extra/docs/
https://releases.llvm.org/11.0.0/tools/clang/tools/extra/docs/
and so on.

Giving my LG more officially now to unblock this, but I'd still appreciate some 
extra eyes on the Python changes.


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] D126891: [clang-tidy] The check should ignore final classes

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

@aaron.ballman @njames93


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126891

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

[PATCH] D122150: [clang][analyzer] Add checker for bad use of 'errno'.

[Balázs Benics via Phabricator via cfe-commits]

steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp:73
 
+REGISTER_TRAIT_WITH_PROGRAMSTATE(ErrnoState, ErrnoCheckState)
+

You will need this to get it compiled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122150

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

[PATCH] D127873: [clang-format] Fix misplacemnt of `*` in declaration of pointer to struct

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:2313
 
+if (PrevToken->is(tok::r_brace) && Tok.isOneOf(tok::amp, tok::ampamp))
+  return TT_BinaryOperator;

Instead of checking for `r_brace`, maybe it would be possible to check 
`PrevToken->MatchingParen` for being `TT_RecordLBrace`?
This way, we'd be precise.
WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127873

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

[PATCH] D127855: [OpenMP] Basic parse and sema support for modifiers in order clause

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

provide full context of the changes.




Comment at: clang/include/clang/AST/OpenMPClause.h:7646
 
-  /// A kind of the 'default' clause.
+  /// A kind of the 'order' clause.
   OpenMPOrderClauseKind Kind = OMPC_ORDER_unknown;

Commit as NFC change



Comment at: clang/include/clang/Sema/Scope.h:483-488
+  /// Determine whether this scope is some OpenMP directive with
+  /// order clause which specifies concurrent scope.
+  bool isOpenMPOrderClauseScope() const{
+return getFlags() & Scope::OpenMPOrderClauseScope;
+  }
+

Why do wee need new scope?



Comment at: clang/lib/Basic/OpenMPKinds.cpp:649-654
+  return DKind == OMPD_parallel_do || DKind == OMPD_parallel_do_simd ||
+ DKind == OMPD_parallel_for || DKind == OMPD_parallel_for_simd ||
+ DKind == OMPD_parallel_master ||
+ DKind == OMPD_parallel_master_taskloop ||
+ DKind == OMPD_parallel_master_taskloop_simd ||
+ DKind == OMPD_parallel_workshare || DKind == OMPD_parallel_sections;

C/C++ does not have do and workshare directives.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127855

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

[PATCH] D127910: [Clang][AArch64] Add SME C intrinsics for load and store

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added a comment.

Hi @sagarkulkarni19, this patch will have to wait until the ABI is implemented 
so that the builtins can be decorated with the attributes. A first patch 
proposing these attributes is in D127762 . 
LLVM patches that use these attributes to implement the ABI will follow soon. 
We could add you as reviewer to these patches if you'd like to help us with 
that?




Comment at: clang/include/clang/Basic/arm_sve.td:209
 def IsTupleSet: FlagType<0x4>;
+def IsSME : FlagType<0x8>;
+def IsSMELoadStore: FlagType<0x10>;

Is there value in having both `IsSME` and `IsSMELoadStore`?



Comment at: clang/lib/Basic/Targets/AArch64.cpp:342
+  if (HasSME)
+Builder.defineMacro("__ARM_FEATURE_SME", "1");
+

When this macro is non-zero, it suggests that the compiler implements the full 
SME ACLE. That is currently not yet the case, so until then we should leave 
this macro undefined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

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

[PATCH] D127579: [clang][WIP] add option to keep types of ptr args for non-kernel functions in metadata

[Joshua Cranmer via Phabricator via cfe-commits]

jcranmer-intel added a comment.

In D127579#3588607 , @iliya-diyachkov 
wrote:

> I think the return type information can be added in the next version of the 
> patch, however it should be attached to function declarations (not 
> definitions as it's done now), right? Do you think, declarations also require 
> information about argument types?

Function declarations are more useful to get information than function 
definitions. A lot of the failures I'm currently seeing in my side of things 
appear to be due to not getting pointer types right when calling OpenCL/SYCL 
builtins causing interesting things to happen later on.

There's another approach I've considered taking, which is rather than using a 
metadata-based approach, emitting `elementtype` for any pointer-valued 
arguments [it doesn't solve return values, though]. This does require more 
changes to LLVM to let such attributes work on non-intrinsic functions, but it 
may end up working smoother than trying to reparse C types as LLVM types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127579

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

[PATCH] D127976: [IR] Move vector.insert/vector.extract out of experimental namespace

[Bradley Smith via Phabricator via cfe-commits]

bsmith created this revision.
bsmith added reviewers: paulwalker-arm, peterwaller-arm, c-rhodes, sdesmalen.
Herald added subscribers: ctetreau, frasercrmck, jdoerfert, luismarques, 
apazos, sameer.abuasal, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, 
MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, niosHD, sabuasal, 
simoncook, johnrusso, rbar, asb, hiraditya.
Herald added a project: All.
bsmith requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, MaskRay.
Herald added projects: clang, LLVM.

These intrinsics are now fundemental for SVE code generation and have been
present for a year and a half, hence move them out of the experimental
namespace.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127976

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vlmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vset.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq-bfloat.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq.c
  clang/test/CodeGen/aarch64-sve-vls-arith-ops.c
  clang/test/CodeGen/aarch64-sve-vls-bitwise-ops.c
  clang/test/CodeGen/aarch64-sve-vls-compare-ops.c
  clang/test/CodeGen/aarch64-sve-vls-shift-ops.c
  clang/test/CodeGen/aarch64-sve-vls-subscript-ops.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_dup_neonq.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_get_neonq.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_set_neonq.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/IR/IRBuilder.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
  llvm/lib/Target/AArch64/SVEIntrinsicOpts.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/test/Analysis/CostModel/AArch64/sve-intrinsics.ll
  llvm/test/Analysis/CostModel/RISCV/rvv-shuffle.ll
  llvm/test/Bitcode/upgrade-vector-insert-extract-intrinsics.ll
  llvm/test/Bitcode/upgrade-vector-insert-extract-intrinsics.ll.bc
  llvm/test/CodeGen/AArch64/dag-combine-insert-subvector.ll
  llvm/test/CodeGen/AArch64/insert-subvector-res-legalization.ll
  llvm/test/CodeGen/AArch64/split-vector-insert.ll
  llvm/test/CodeGen/AArch64/sve-extract-fixed-from-scalable-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-fixed-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-scalable-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-vector-to-predicate-store.ll
  llvm/test/CodeGen/AArch64/sve-fixed-length-extract-subvector.ll
  llvm/test/CodeGen/AArch64/sve-insert-vector-to-predicate-load.ll
  llvm/test/CodeGen/AArch64/sve-insert-vector.ll
  llvm/test/CodeGen/AArch64/sve-no-typesize-warnings.ll
  llvm/test/CodeGen/AArch64/sve-punpklo-combine.ll
  llvm/test/CodeGen/AArch64/sve-vecreduce-fold.ll
  llvm/test/CodeGen/RISCV/rvv/extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/mgather-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/mscatter-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/vpload.ll
  llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-cmpne.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-extract.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-insert.ll
  llvm/test/Transforms/InstSimplify/extract-vector.ll
  llvm/test/Transforms/InstSimplify/insert-vector.ll
  llvm/test/Transforms/InterleavedAccess/AArch64/sve-interleaved-accesses.ll
  llvm/test/Verifier/extract-vector-mismatched-element-types.ll
  llvm/test/Verifier/insert-extract-intrinsics-invalid.ll
  llvm/test/Verifier/insert-vector-mismatched-element-types.ll

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

[PATCH] D127904: [AMDGPU] gfx11 new dot instruction codegen support

[Joe Nash via Phabricator via cfe-commits]

Joe_Nash updated this revision to Diff 437552.
Joe_Nash marked 3 inline comments as done.
Joe_Nash added a comment.

added builtin positive tests, removed clamp from intrinsic comments, combined 
gisel with normal codegen test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127904

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-gfx11.cl
  llvm/include/llvm/IR/IntrinsicsAMDGPU.td
  llvm/lib/Target/AMDGPU/AMDGPUGISel.td
  llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.cpp
  llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.h
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.h
  llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp
  llvm/lib/Target/AMDGPU/VOP3Instructions.td
  llvm/lib/Target/AMDGPU/VOP3PInstructions.td
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.fdot2.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.sudot4.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.sudot8.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.bf16.bf16.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.f16.f16.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.f32.bf16.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot4.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot8.ll

Index: llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot8.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot8.ll
@@ -0,0 +1,102 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -march=amdgcn -mcpu=gfx1100 -show-mc-encoding -verify-machineinstrs < %s | FileCheck %s --check-prefixes=GFX11
+
+declare i32 @llvm.amdgcn.sudot8(i1 %asign, i32 %a, i1 %bsign, i32 %b, i32 %c, i1 %clamp)
+
+define i32 @test_llvm_amdgcn_sudot8_uu(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_uu:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x1c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 0, i32 %a, i1 0, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+define i32 @test_llvm_amdgcn_sudot8_us(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_us:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 neg_lo:[0,1,0] ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x5c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 0, i32 %a, i1 1, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+define i32 @test_llvm_amdgcn_sudot8_su(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_su:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 neg_lo:[1,0,0] ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x3c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 1, i32 %a, i1 0, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+define i32 @test_llvm_amdgcn_sudot8_ss(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_ss:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 neg_lo:[1,1,0] ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x7c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 1, i32 %a, i1 1, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+
+
+define i32 @test_llvm_amdgcn_sudot8_uu_clamp(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_uu_clamp:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 clamp ; encoding: [0x00,0xc0,0x18,0xcc,0x00,0x03,0x0a,0x1c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 0, i32 %a, i1 0, i32 %b, i32 %c, i1 1)
+  ret i32 %ret
+}
+
+define i32 @tes

[PATCH] D127976: [IR] Move vector.insert/vector.extract out of experimental namespace

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

Maybe a line in the Release Notes of LLVM?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127976

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

[clang] f4f6adc - [clang] Don't emit IFUNC when targeting Fuchsia

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2022-06-16T15:38:12Z
New Revision: f4f6adc451a2dc901c08c2fdac81ef2cf98a5cc6

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

LOG: [clang] Don't emit IFUNC when targeting Fuchsia

Fuchsia's dynamic linker does not and will never support IFUNC's.

Differential revision: https://reviews.llvm.org/D127933

Added: 


Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/test/CodeGen/attr-target-mv-va-args.c

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 5877123dab249..32a330a044c45 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -1355,7 +1355,9 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   bool supportsMultiVersioning() const { return getTriple().isX86(); }
 
   /// Identify whether this target supports IFuncs.
-  bool supportsIFunc() const { return getTriple().isOSBinFormatELF(); }
+  bool supportsIFunc() const {
+return getTriple().isOSBinFormatELF() && !getTriple().isOSFuchsia();
+  }
 
   // Validate the contents of the __builtin_cpu_supports(const char*)
   // argument.

diff  --git a/clang/test/CodeGen/attr-target-mv-va-args.c 
b/clang/test/CodeGen/attr-target-mv-va-args.c
index db3f4da079cfb..c51eaffcdde74 100644
--- a/clang/test/CodeGen/attr-target-mv-va-args.c
+++ b/clang/test/CodeGen/attr-target-mv-va-args.c
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-linux-gnu -emit-llvm %s 
-o - | FileCheck %s --check-prefix=LINUX
-// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-windows-pc -emit-llvm %s 
-o - | FileCheck %s --check-prefix=WINDOWS
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-windows-pc -emit-llvm %s 
-o - | FileCheck %s --check-prefixes=NO-IFUNC,WINDOWS
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-fuchsia -emit-llvm %s -o 
- | FileCheck %s --check-prefixes=NO-IFUNC,FUCHSIA
 int __attribute__((target("sse4.2"))) foo(int i, ...) { return 0; }
 int __attribute__((target("arch=sandybridge"))) foo(int i, ...);
 int __attribute__((target("arch=ivybridge"))) foo(int i, ...) {return 1;}
@@ -27,19 +28,21 @@ int bar(void) {
 // LINUX: ret i32 (i32, ...)* @foo
 // LINUX: declare i32 @foo.arch_sandybridge(i32 noundef, ...)
 
-// WINDOWS: define dso_local i32 @foo.sse4.2(i32 noundef %i, ...)
-// WINDOWS: ret i32 0
-// WINDOWS: define dso_local i32 @foo.arch_ivybridge(i32 noundef %i, ...)
-// WINDOWS: ret i32 1
-// WINDOWS: define dso_local i32 @foo(i32 noundef %i, ...)
-// WINDOWS: ret i32 2
-// WINDOWS: define dso_local i32 @bar()
-// WINDOWS: call i32 (i32, ...) @foo.resolver(i32 noundef 1, i32 noundef 97, 
double
-// WINDOWS: call i32 (i32, ...) @foo.resolver(i32 noundef 2, double noundef 
2.2{{[0-9Ee+]+}}, i8* noundef getelementptr inbounds
+// NO-IFUNC: define dso_local i32 @foo.sse4.2(i32 noundef %i, ...)
+// NO-IFUNC: ret i32 0
+// NO-IFUNC: define dso_local i32 @foo.arch_ivybridge(i32 noundef %i, ...)
+// NO-IFUNC: ret i32 1
+// NO-IFUNC: define dso_local i32 @foo(i32 noundef %i, ...)
+// NO-IFUNC: ret i32 2
+// NO-IFUNC: define dso_local i32 @bar()
+// NO-IFUNC: call i32 (i32, ...) @foo.resolver(i32 noundef 1, i32 noundef 97, 
double
+// NO-IFUNC: call i32 (i32, ...) @foo.resolver(i32 noundef 2, double noundef 
2.2{{[0-9Ee+]+}}, i8* noundef getelementptr inbounds
 
 // WINDOWS: define weak_odr dso_local i32 @foo.resolver(i32 %0, ...) comdat
-// WINDOWS: musttail call i32 (i32, ...) @foo.arch_sandybridge
-// WINDOWS: musttail call i32 (i32, ...) @foo.arch_ivybridge
-// WINDOWS: musttail call i32 (i32, ...) @foo.sse4.2
-// WINDOWS: musttail call i32 (i32, ...) @foo
+// FUCHSIA: define weak_odr i32 @foo.resolver(i32 %0, ...) comdat
+// NO-IFUNC: musttail call i32 (i32, ...) @foo.arch_sandybridge
+// NO-IFUNC: musttail call i32 (i32, ...) @foo.arch_ivybridge
+// NO-IFUNC: musttail call i32 (i32, ...) @foo.sse4.2
+// NO-IFUNC: musttail call i32 (i32, ...) @foo
 // WINDOWS: declare dso_local i32 @foo.arch_sandybridge(i32 noundef, ...)
+// FUCHSIA: declare i32 @foo.arch_sandybridge(i32 noundef, ...)



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

[PATCH] D127933: [clang] Don't emit IFUNC when targeting Fuchsia

[Alex Brachet 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 rGf4f6adc451a2: [clang] Don't emit IFUNC when targeting 
Fuchsia (authored by abrachet).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127933

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/test/CodeGen/attr-target-mv-va-args.c


Index: clang/test/CodeGen/attr-target-mv-va-args.c
===
--- clang/test/CodeGen/attr-target-mv-va-args.c
+++ clang/test/CodeGen/attr-target-mv-va-args.c
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-linux-gnu -emit-llvm %s 
-o - | FileCheck %s --check-prefix=LINUX
-// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-windows-pc -emit-llvm %s 
-o - | FileCheck %s --check-prefix=WINDOWS
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-windows-pc -emit-llvm %s 
-o - | FileCheck %s --check-prefixes=NO-IFUNC,WINDOWS
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-fuchsia -emit-llvm %s -o 
- | FileCheck %s --check-prefixes=NO-IFUNC,FUCHSIA
 int __attribute__((target("sse4.2"))) foo(int i, ...) { return 0; }
 int __attribute__((target("arch=sandybridge"))) foo(int i, ...);
 int __attribute__((target("arch=ivybridge"))) foo(int i, ...) {return 1;}
@@ -27,19 +28,21 @@
 // LINUX: ret i32 (i32, ...)* @foo
 // LINUX: declare i32 @foo.arch_sandybridge(i32 noundef, ...)
 
-// WINDOWS: define dso_local i32 @foo.sse4.2(i32 noundef %i, ...)
-// WINDOWS: ret i32 0
-// WINDOWS: define dso_local i32 @foo.arch_ivybridge(i32 noundef %i, ...)
-// WINDOWS: ret i32 1
-// WINDOWS: define dso_local i32 @foo(i32 noundef %i, ...)
-// WINDOWS: ret i32 2
-// WINDOWS: define dso_local i32 @bar()
-// WINDOWS: call i32 (i32, ...) @foo.resolver(i32 noundef 1, i32 noundef 97, 
double
-// WINDOWS: call i32 (i32, ...) @foo.resolver(i32 noundef 2, double noundef 
2.2{{[0-9Ee+]+}}, i8* noundef getelementptr inbounds
+// NO-IFUNC: define dso_local i32 @foo.sse4.2(i32 noundef %i, ...)
+// NO-IFUNC: ret i32 0
+// NO-IFUNC: define dso_local i32 @foo.arch_ivybridge(i32 noundef %i, ...)
+// NO-IFUNC: ret i32 1
+// NO-IFUNC: define dso_local i32 @foo(i32 noundef %i, ...)
+// NO-IFUNC: ret i32 2
+// NO-IFUNC: define dso_local i32 @bar()
+// NO-IFUNC: call i32 (i32, ...) @foo.resolver(i32 noundef 1, i32 noundef 97, 
double
+// NO-IFUNC: call i32 (i32, ...) @foo.resolver(i32 noundef 2, double noundef 
2.2{{[0-9Ee+]+}}, i8* noundef getelementptr inbounds
 
 // WINDOWS: define weak_odr dso_local i32 @foo.resolver(i32 %0, ...) comdat
-// WINDOWS: musttail call i32 (i32, ...) @foo.arch_sandybridge
-// WINDOWS: musttail call i32 (i32, ...) @foo.arch_ivybridge
-// WINDOWS: musttail call i32 (i32, ...) @foo.sse4.2
-// WINDOWS: musttail call i32 (i32, ...) @foo
+// FUCHSIA: define weak_odr i32 @foo.resolver(i32 %0, ...) comdat
+// NO-IFUNC: musttail call i32 (i32, ...) @foo.arch_sandybridge
+// NO-IFUNC: musttail call i32 (i32, ...) @foo.arch_ivybridge
+// NO-IFUNC: musttail call i32 (i32, ...) @foo.sse4.2
+// NO-IFUNC: musttail call i32 (i32, ...) @foo
 // WINDOWS: declare dso_local i32 @foo.arch_sandybridge(i32 noundef, ...)
+// FUCHSIA: declare i32 @foo.arch_sandybridge(i32 noundef, ...)
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -1355,7 +1355,9 @@
   bool supportsMultiVersioning() const { return getTriple().isX86(); }
 
   /// Identify whether this target supports IFuncs.
-  bool supportsIFunc() const { return getTriple().isOSBinFormatELF(); }
+  bool supportsIFunc() const {
+return getTriple().isOSBinFormatELF() && !getTriple().isOSFuchsia();
+  }
 
   // Validate the contents of the __builtin_cpu_supports(const char*)
   // argument.


Index: clang/test/CodeGen/attr-target-mv-va-args.c
===
--- clang/test/CodeGen/attr-target-mv-va-args.c
+++ clang/test/CodeGen/attr-target-mv-va-args.c
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix=LINUX
-// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-windows-pc -emit-llvm %s -o - | FileCheck %s --check-prefix=WINDOWS
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-windows-pc -emit-llvm %s -o - | FileCheck %s --check-prefixes=NO-IFUNC,WINDOWS
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-fuchsia -emit-llvm %s -o - | FileCheck %s --check-prefixes=NO-IFUNC,FUCHSIA
 int __attribute__((target("sse4.2"))) foo(int i, ...) { return 0; }
 int __attribute__((target("arch=sandybridge"))) foo(int i, ...);
 int __attribute__((target("arch=ivybridge"))) foo(int i, ...) {return 1

[PATCH] D127886: [clang-tidy] Allow access to the SourceManager in clang-tidy checks

[Nicolas van Kempen via Phabricator via cfe-commits]

nicovank abandoned this revision.
nicovank added a comment.

Looks like `registerPPCallbacks` / `Result.Context->getSourceManager()` gives 
me the information I need. Thank you @gribozavr2 for your help!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127886

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

[PATCH] D127976: [IR] Move vector.insert/vector.extract out of experimental namespace

[Bradley Smith via Phabricator via cfe-commits]

bsmith updated this revision to Diff 437557.
bsmith added a comment.

- Add info to release notes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127976

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vlmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vset.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq-bfloat.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq.c
  clang/test/CodeGen/aarch64-sve-vls-arith-ops.c
  clang/test/CodeGen/aarch64-sve-vls-bitwise-ops.c
  clang/test/CodeGen/aarch64-sve-vls-compare-ops.c
  clang/test/CodeGen/aarch64-sve-vls-shift-ops.c
  clang/test/CodeGen/aarch64-sve-vls-subscript-ops.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_dup_neonq.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_get_neonq.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_set_neonq.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
  llvm/docs/LangRef.rst
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/IR/IRBuilder.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
  llvm/lib/Target/AArch64/SVEIntrinsicOpts.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/test/Analysis/CostModel/AArch64/sve-intrinsics.ll
  llvm/test/Analysis/CostModel/RISCV/rvv-shuffle.ll
  llvm/test/Bitcode/upgrade-vector-insert-extract-intrinsics.ll
  llvm/test/Bitcode/upgrade-vector-insert-extract-intrinsics.ll.bc
  llvm/test/CodeGen/AArch64/dag-combine-insert-subvector.ll
  llvm/test/CodeGen/AArch64/insert-subvector-res-legalization.ll
  llvm/test/CodeGen/AArch64/split-vector-insert.ll
  llvm/test/CodeGen/AArch64/sve-extract-fixed-from-scalable-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-fixed-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-scalable-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-vector-to-predicate-store.ll
  llvm/test/CodeGen/AArch64/sve-fixed-length-extract-subvector.ll
  llvm/test/CodeGen/AArch64/sve-insert-vector-to-predicate-load.ll
  llvm/test/CodeGen/AArch64/sve-insert-vector.ll
  llvm/test/CodeGen/AArch64/sve-no-typesize-warnings.ll
  llvm/test/CodeGen/AArch64/sve-punpklo-combine.ll
  llvm/test/CodeGen/AArch64/sve-vecreduce-fold.ll
  llvm/test/CodeGen/RISCV/rvv/extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/mgather-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/mscatter-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/vpload.ll
  llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-cmpne.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-extract.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-insert.ll
  llvm/test/Transforms/InstSimplify/extract-vector.ll
  llvm/test/Transforms/InstSimplify/insert-vector.ll
  llvm/test/Transforms/InterleavedAccess/AArch64/sve-interleaved-accesses.ll
  llvm/test/Verifier/extract-vector-mismatched-element-types.ll
  llvm/test/Verifier/insert-extract-intrinsics-invalid.ll
  llvm/test/Verifier/insert-vector-mismatched-element-types.ll

___
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 updated this revision to Diff 437566.
ahatanak added a comment.

Revert the changes made to SemaCoroutine.cpp.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125936

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/SemaStmtAsm.cpp
  clang/test/CodeGenCXX/asm.cpp
  clang/test/SemaTemplate/instantiate-expr-1.cpp

Index: clang/test/SemaTemplate/instantiate-expr-1.cpp
===
--- clang/test/SemaTemplate/instantiate-expr-1.cpp
+++ clang/test/SemaTemplate/instantiate-expr-1.cpp
@@ -190,3 +190,19 @@
 test_asm_tied(1.f); // expected-note {{instantiation of}}
   }
 }
+
+namespace TestAsmCleanup {
+struct S {
+  operator int() const { return 1; }
+  ~S();
+};
+
+template 
+void foo() {
+  __asm__ __volatile__("%[i]"
+   :
+   : [i] "r"(-S()));
+}
+
+void test() { foo(); }
+} // namespace TestAsmCleanup
Index: clang/test/CodeGenCXX/asm.cpp
===
--- clang/test/CodeGenCXX/asm.cpp
+++ clang/test/CodeGenCXX/asm.cpp
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fblocks -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: %[[STRUCT_A:.*]] = type { i8 }
 
 struct A
 {
@@ -12,3 +14,39 @@
 asm("" : : "r"(foo(a)) ); // rdar://8540491
 // CHECK: call void @_ZN1AD1Ev
 }
+
+namespace TestTemplate {
+// Check that the temporary is destructed after the first asm statement.
+
+// CHECK: define {{.*}}void @_ZN12TestTemplate4foo0IvEEvR1A(
+// CHECK: %[[AGG_TMP:.*]] = alloca %[[STRUCT_A]],
+// CHECK: %[[CALL:.*]] = call noundef i32 @_Z3foo1A({{.*}}%[[AGG_TMP]])
+// CHECK: call void asm sideeffect "", "r,~{dirflag},~{fpsr},~{flags}"(i32 %[[CALL]])
+// CHECK: call void @_ZN1AD1Ev({{.*}}%[[AGG_TMP]])
+// CHECK: call void asm sideeffect "",
+
+template 
+void foo0(A &a) {
+  asm("" : : "r"(foo(a)) );
+  asm("");
+}
+
+void test0(A &a) { foo0(a); }
+
+// Check that the block capture is destructed at the end of the enclosing scope.
+
+// CHECK: define {{.*}}void @_ZN12TestTemplate4foo1IvEEv1A(
+// CHECK: %[[BLOCK:.*]] = alloca <{ ptr, i32, i32, ptr, ptr, %[[STRUCT_A]] }>, align 4
+// CHECK: %[[BLOCK_CAPTURED:.*]] = getelementptr inbounds <{ ptr, i32, i32, ptr, ptr, %[[STRUCT_A]] }>, ptr %[[BLOCK]], i32 0, i32 5
+// CHECK: call void asm sideeffect "", "r,~{dirflag},~{fpsr},~{flags}"(i32 %{{.*}})
+// CHECK: call void asm sideeffect "", "~{dirflag},~{fpsr},~{flags}"()
+// CHECK: call void @_ZN1AD1Ev({{.*}} %[[BLOCK_CAPTURED]])
+
+template 
+void foo1(A a) {
+  asm("" : : "r"(^{ (void)a; return 0; }()));
+  asm("");
+}
+
+void test1(A &a) { foo1(a); }
+} // namespace TestTemplate
Index: clang/lib/Sema/SemaStmtAsm.cpp
===
--- clang/lib/Sema/SemaStmtAsm.cpp
+++ clang/lib/Sema/SemaStmtAsm.cpp
@@ -733,6 +733,9 @@
   }
   if (NS->isAsmGoto())
 setFunctionHasBranchIntoScope();
+
+  CleanupVarDeclMarking();
+  DiscardCleanupsInEvaluationContext();
   return NS;
 }
 
Index: clang/lib/Parse/ParseStmt.cpp
===
--- clang/lib/Parse/ParseStmt.cpp
+++ clang/lib/Parse/ParseStmt.cpp
@@ -300,7 +300,6 @@
 ProhibitAttributes(Attrs);
 bool msAsm = false;
 Res = ParseAsmStatement(msAsm);
-Res = Actions.ActOnFinishFullStmt(Res.get());
 if (msAsm) return Res;
 SemiError = "asm";
 break;
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2286,6 +2286,10 @@
 }
 
 void CodeGenFunction::EmitAsmStmt(const AsmStmt &S) {
+  // Temporaries created in GCC AsmStmts have to be destructed at the end of the
+  // statement.
+  CodeGenFunction::RunCleanupsScope Cleanups(*this);
+
   // Assemble the final asm string.
   std::string AsmString = S.generateAsmString(getContext());
 
___
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:
> 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.
Addressed by D127982.


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] D124093: [PowerPC] Fixing implicit castings in altivec for -fno-lax-vector-conversions

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15587
+
+bool isUnaligned = (BuiltinID == PPC::BI__builtin_altivec_vinsw ||
+BuiltinID == PPC::BI__builtin_altivec_vinsd)

This is strange. You don't need the ternary operator when you are simply 
setting a `bool` variable. This is simply:
```
bool isUnaligned = (BuiltinID == PPC::BI__builtin_altivec_vinsw ||
BuiltinID == PPC::BI__builtin_altivec_vinsd);
```
Same below.

Also, please be careful of the naming convention (i.e. variables start with 
upper case, functions with lowercase, etc.). I will not add further comments to 
this end but please apply this change to the entire patch.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15604
+// builtin called.
+int validMaxValue = isUnaligned ? is32bit ? 12 : 8 : is32bit ? 3 : 1;
+

This is certainly concise, but trying to parse it puts my brain into an 
infinite loop. Please write it as:
```
int ValidMaxValue = 0;
if (IsUnaligned)
  ValidMaxValue = ... ? ... : ...
else
  ValidMaxValue = ...
```



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15608
+std::string rangeErrMsg = isUnaligned ? "byte" : "element";
+rangeErrMsg += " number is outside of the valid range [0, ";
+rangeErrMsg += llvm::to_string(validMaxValue) + "]";

Since you are building a string from pieces here, might as well mention the 
value the user specified so it is something like:
`byte number 44 is outside of the valid range [0, 12]`



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15661
+Value *Op1 = EmitScalarExpr(E->getArg(1));
+llvm::Type *Int128Ty = llvm::IntegerType::get(getLLVMContext(), 128);
+Ops.push_back(

Why not simplify the bitcasts below by just creating a pointer to the vector 
type (call it say, `V1I128Ty`) here? Same in the next `case`.



Comment at: clang/lib/Headers/altivec.h:3211-3219
+   : (vector double)(__builtin_vsx_xvcvuxdsp(  
\
+ (vector unsigned long long)(__a)) *   
\
+ (vector float)(vector unsigned)((0x7f - (__b))
\
+ << 23)),  
\
  vector signed long long   
\
-   : (__builtin_vsx_xvcvsxdsp((vector signed long long)(__a)) *
\
-  (vector float)(vector unsigned)((0x7f - (__b)) << 23)))
+   : (vector double)(__builtin_vsx_xvcvsxdsp(  
\
+ (vector signed long long)(__a)) * 
\

This is wrong. Please see the documentation for what the result type should be 
under XL compat. I believe it needs to be `vector float` regardless of the 
input.



Comment at: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat.c:8
 // RUN:   -D__XL_COMPAT_ALTIVEC__ -target-cpu pwr8 | FileCheck %s
-// RUN: %clang_cc1 -no-opaque-pointers -target-feature +altivec 
-target-feature +vsx \
+// RUN: %clang_cc1 -flax-vector-conversions=none -no-opaque-pointers 
-target-feature +altivec -target-feature +vsx \
 // RUN:   -triple powerpc64le-unknown-linux-gnu -emit-llvm %s -o - \

I don't know why only one of the functions below has checks for this run line, 
but that needs to be fixed. Please add the `NOCOMPAT` checks on the other 
functions.



Comment at: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat.c:30
 // CHECK-NEXT:[[TMP1:%.*]] = call <4 x float> @llvm.ppc.vsx.xvcvsxdsp(<2 x 
i64> [[TMP0]])
 // CHECK-NEXT:fmul <4 x float> [[TMP1]], 
 

We compute a `vector float` but return a `vector double`. Something is wrong. 
Please see my comment regarding this in `altivec.h`.



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:746
 [IntrNoMem, ImmArg>]>;
+
   // P10 Vector Extract.

What happened here? Unrelated whitespace change. Please remove it before 
committing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124093

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

[PATCH] D127898: [clang][dataflow] Find unsafe locs after fixpoint

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:35
 
+using NoopDiags = std::tuple<>;
+

I'm not sure that this is valid style. It's essentially a unit type, which I 
quite like, but I've never seen this done before.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:64
+///
+/// `DiagsT` must have a default constructor.
+template 

Please describe this parameter.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:103
 
+  virtual void check(const Stmt *Stmt, Diags &E, const Lattice &L,
+ const Environment &Env) {}

The virtual function seems out of place here, given that everything else is 
statically resolved. Either drop `virtual` or move to the dyn. typed super 
class.

That said, I'm not clear on why this isn't a free function. I imagine a model 
of creating the analysis, running it and that results in blocks annotated with 
`Environment`s and custome lattices.  Then, you run any function you want over 
that using some visitor template helper. To account for state, we either make 
it an explicit parameter or take a `std::function`.



Comment at: clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h:52
+  /// Current set of diagnostics.
+  DiagsT &Diags;
+  const Environment &Env;

this implies that we want to support some form of accumulation. I'd argue that 
any accumulation should already occur in the lattice (or the environment) and 
this should be a straight read of the state and some output. So, the 
`TransferState` struct should be enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127898

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

[clang] a70b39a - [clang] Don't emit type test/assume for virtual classes that should never participate in WPD

[Arthur Eubanks via cfe-commits]

Author: Arthur Eubanks
Date: 2022-06-16T09:38:14-07:00
New Revision: a70b39abffb42eb85fd2dd7960ec9dc7ae38510c

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

LOG: [clang] Don't emit type test/assume for virtual classes that should never 
participate in WPD

Reviewed By: pcc

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

Added: 


Modified: 
clang/docs/LTOVisibility.rst
clang/lib/CodeGen/CGClass.cpp
clang/lib/CodeGen/CGVTables.cpp
clang/lib/CodeGen/CodeGenModule.h
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/test/CodeGenCXX/lto-visibility-inference.cpp

Removed: 




diff  --git a/clang/docs/LTOVisibility.rst b/clang/docs/LTOVisibility.rst
index cdc0b9cc0e19e..ebc4cc906aa6c 100644
--- a/clang/docs/LTOVisibility.rst
+++ b/clang/docs/LTOVisibility.rst
@@ -35,13 +35,14 @@ other classes receive hidden LTO visibility. Classes with 
internal linkage
 (e.g. classes declared in unnamed namespaces) also receive hidden LTO
 visibility.
 
-During the LTO link, all classes with public LTO visibility will be refined
-to hidden LTO visibility when the ``--lto-whole-program-visibility`` lld linker
-option is applied (``-plugin-opt=whole-program-visibility`` for gold). This 
flag
-can be used to defer specifying whether classes have hidden LTO visibility 
until
-link time, to allow bitcode objects to be shared by 
diff erent LTO links.
-Due to an implementation limitation, symbols associated with classes with 
hidden
-LTO visibility may still be exported from the binary when using this flag. It 
is
+During the LTO link, all classes with public LTO visibility but not marked with
+``[[clang::lto_visibility_public]]`` (see below) will be refined to hidden LTO
+visibility when the ``--lto-whole-program-visibility`` lld linker option is
+applied (``-plugin-opt=whole-program-visibility`` for gold).  This flag can be
+used to defer specifying whether classes have hidden LTO visibility until link
+time, to allow bitcode objects to be shared by 
diff erent LTO links.  Due to an
+implementation limitation, symbols associated with classes with hidden LTO
+visibility may still be exported from the binary when using this flag. It is
 unsafe to refer to these symbols, and their visibility may be relaxed to hidden
 in a future compiler release.
 

diff  --git a/clang/lib/CodeGen/CGClass.cpp b/clang/lib/CodeGen/CGClass.cpp
index cb16019c63508..153f299a1c4b4 100644
--- a/clang/lib/CodeGen/CGClass.cpp
+++ b/clang/lib/CodeGen/CGClass.cpp
@@ -2695,9 +2695,9 @@ void CodeGenFunction::EmitTypeMetadataCodeForVCall(const 
CXXRecordDecl *RD,
   if (SanOpts.has(SanitizerKind::CFIVCall))
 EmitVTablePtrCheckForCall(RD, VTable, CodeGenFunction::CFITCK_VCall, Loc);
   else if (CGM.getCodeGenOpts().WholeProgramVTables &&
-   // Don't insert type test assumes if we are forcing public std
+   // Don't insert type test assumes if we are forcing public
// visibility.
-   !CGM.HasLTOVisibilityPublicStd(RD)) {
+   !CGM.AlwaysHasLTOVisibilityPublic(RD)) {
 llvm::Metadata *MD =
 CGM.CreateMetadataIdentifierForType(QualType(RD->getTypeForDecl(), 0));
 llvm::Value *TypeId =

diff  --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index ab8a46b797bab..cdd40d2a6a2e8 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -1175,7 +1175,10 @@ void CodeGenModule::EmitDeferredVTables() {
   DeferredVTables.clear();
 }
 
-bool CodeGenModule::HasLTOVisibilityPublicStd(const CXXRecordDecl *RD) {
+bool CodeGenModule::AlwaysHasLTOVisibilityPublic(const CXXRecordDecl *RD) {
+  if (RD->hasAttr() || RD->hasAttr())
+return true;
+
   if (!getCodeGenOpts().LTOVisibilityPublicStd)
 return false;
 
@@ -1200,9 +1203,6 @@ bool CodeGenModule::HasHiddenLTOVisibility(const 
CXXRecordDecl *RD) {
   if (!isExternallyVisible(LV.getLinkage()))
 return true;
 
-  if (RD->hasAttr() || RD->hasAttr())
-return false;
-
   if (getTriple().isOSBinFormatCOFF()) {
 if (RD->hasAttr() || RD->hasAttr())
   return false;
@@ -1211,7 +1211,7 @@ bool CodeGenModule::HasHiddenLTOVisibility(const 
CXXRecordDecl *RD) {
   return false;
   }
 
-  return !HasLTOVisibilityPublicStd(RD);
+  return !AlwaysHasLTOVisibilityPublic(RD);
 }
 
 llvm::GlobalObject::VCallVisibility CodeGenModule::GetVCallVisibilityLevel(

diff  --git a/clang/lib/CodeGen/CodeGenModule.h 
b/clang/lib/CodeGen/CodeGenModule.h
index 779d94ad62d98..f5ae83a2faca9 100644
--- a/clang/lib/CodeGen/CodeGenModule.h
+++ b/clang/lib/CodeGen/CodeGenModule.h
@@ -1382,10 +1382,10 @@ class CodeGenModule : public CodeGenTypeCache {
   /// optimization.
   bool HasHiddenLTOVisibility(const CXXRecordDecl *RD);
 
-  /// Returns whether the given record has publ

[PATCH] D127876: [clang] Don't emit type test/assume for virtual classes that should never participate in WPD

[Arthur Eubanks 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 rGa70b39abffb4: [clang] Don't emit type test/assume for 
virtual classes that should never… (authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127876

Files:
  clang/docs/LTOVisibility.rst
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGVTables.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGenCXX/lto-visibility-inference.cpp

Index: clang/test/CodeGenCXX/lto-visibility-inference.cpp
===
--- clang/test/CodeGenCXX/lto-visibility-inference.cpp
+++ clang/test/CodeGenCXX/lto-visibility-inference.cpp
@@ -79,11 +79,11 @@
   // ITANIUM: type.test{{.*}}!"_ZTS2C4"
   // MS: type.test{{.*}}!"?AUC4@@"
   c4->f();
-  // ITANIUM: type.test{{.*}}!"_ZTS2C5"
-  // MS: type.test{{.*}}!"?AUC5@@"
+  // ITANIUM-NOT: type.test{{.*}}!"_ZTS2C5"
+  // MS-NOT: type.test{{.*}}!"?AUC5@@"
   c5->f();
-  // ITANIUM: type.test{{.*}}!"_ZTS2C6"
-  // MS: type.test{{.*}}!"?AUC6@@"
+  // ITANIUM-NOT: type.test{{.*}}!"_ZTS2C6"
+  // MS-NOT: type.test{{.*}}!"?AUC6@@"
   c6->f();
   // ITANIUM: type.test{{.*}}!"_ZTSSt2C7"
   // MS-STD: type.test{{.*}}!"?AUC7@std@@"
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -668,8 +668,8 @@
CGM.HasHiddenLTOVisibility(RD);
   bool ShouldEmitWPDInfo =
   CGM.getCodeGenOpts().WholeProgramVTables &&
-  // Don't insert type tests if we are forcing public std visibility.
-  !CGM.HasLTOVisibilityPublicStd(RD);
+  // Don't insert type tests if we are forcing public visibility.
+  !CGM.AlwaysHasLTOVisibilityPublic(RD);
   llvm::Value *VirtualFn = nullptr;
 
   {
Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1382,10 +1382,10 @@
   /// optimization.
   bool HasHiddenLTOVisibility(const CXXRecordDecl *RD);
 
-  /// Returns whether the given record has public std LTO visibility
-  /// and therefore may not participate in (single-module) CFI and whole-program
-  /// vtable optimization.
-  bool HasLTOVisibilityPublicStd(const CXXRecordDecl *RD);
+  /// Returns whether the given record has public LTO visibility (regardless of
+  /// -lto-whole-program-visibility) and therefore may not participate in
+  /// (single-module) CFI and whole-program vtable optimization.
+  bool AlwaysHasLTOVisibilityPublic(const CXXRecordDecl *RD);
 
   /// Returns the vcall visibility of the given type. This is the scope in which
   /// a virtual function call could be made which ends up being dispatched to a
Index: clang/lib/CodeGen/CGVTables.cpp
===
--- clang/lib/CodeGen/CGVTables.cpp
+++ clang/lib/CodeGen/CGVTables.cpp
@@ -1175,7 +1175,10 @@
   DeferredVTables.clear();
 }
 
-bool CodeGenModule::HasLTOVisibilityPublicStd(const CXXRecordDecl *RD) {
+bool CodeGenModule::AlwaysHasLTOVisibilityPublic(const CXXRecordDecl *RD) {
+  if (RD->hasAttr() || RD->hasAttr())
+return true;
+
   if (!getCodeGenOpts().LTOVisibilityPublicStd)
 return false;
 
@@ -1200,9 +1203,6 @@
   if (!isExternallyVisible(LV.getLinkage()))
 return true;
 
-  if (RD->hasAttr() || RD->hasAttr())
-return false;
-
   if (getTriple().isOSBinFormatCOFF()) {
 if (RD->hasAttr() || RD->hasAttr())
   return false;
@@ -1211,7 +1211,7 @@
   return false;
   }
 
-  return !HasLTOVisibilityPublicStd(RD);
+  return !AlwaysHasLTOVisibilityPublic(RD);
 }
 
 llvm::GlobalObject::VCallVisibility CodeGenModule::GetVCallVisibilityLevel(
Index: clang/lib/CodeGen/CGClass.cpp
===
--- clang/lib/CodeGen/CGClass.cpp
+++ clang/lib/CodeGen/CGClass.cpp
@@ -2695,9 +2695,9 @@
   if (SanOpts.has(SanitizerKind::CFIVCall))
 EmitVTablePtrCheckForCall(RD, VTable, CodeGenFunction::CFITCK_VCall, Loc);
   else if (CGM.getCodeGenOpts().WholeProgramVTables &&
-   // Don't insert type test assumes if we are forcing public std
+   // Don't insert type test assumes if we are forcing public
// visibility.
-   !CGM.HasLTOVisibilityPublicStd(RD)) {
+   !CGM.AlwaysHasLTOVisibilityPublic(RD)) {
 llvm::Metadata *MD =
 CGM.CreateMetadataIdentifierForType(QualType(RD->getTypeForDecl(), 0));
 llvm::Value *TypeId =
Index: clang/docs/LTOVisibility.rst
===
--- clang/docs/LTOVisibility.rst
+++ clang/docs/LTOVisibility.rst
@@ -35,13 +35,14 @@
 (e.g. classe

[PATCH] D127874: [analyzer] Reimplement UnreachableCodeChecker using worklists

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

In D127874#3588786 , @martong wrote:

>> If some checker placed a sink node into some block, the successors of the 
>> sink block was marked unreachable previously. This leads to an unpleasant 
>> situation from the user's point of view since a different bugreport gets 
>> correlated with the FPs caused by the sink node of that. This effectively 
>> means that for each unconditional sink, we will also have (preferable) an 
>> unreachable code report as well.
>
> An example and/or a visualization would be useful for this.

It's quite hard. I could add step numbers so that I could mark which block is 
being entered and exited the visitation in the recursion.

>> Now, we ignore unreachable nodes if the predecessor is reachable, but none 
>> of its successors are.
>
> Isn't there a contradiction here? The node's predecessor must have at least 
> one reachable successor, the node itself; otherwise the node itself would be 
> unreachable.

I tried to cheap out the mouthful definition. I'm not sure if it helps more 
than hinders this way.

>> the sweep-back part cannot be implemented correctly via a DFS visitation
>
> What is the purpose of this sweep-back? You should summarize that here.

Yea, done.

>> ... Do a backward DFS to find the start of each unreachable CFG block chain 
>> ...
>
> How does it find the //start// if there is a cycle in the graph? Isn't it 
> rather about finding strongly connected components?

I left circle detection to the reader. Now, I'm explicitly mentioning the 
maintenance of the //visited// block set.

>> The sweep-back part cannot be implemented correctly via a DFS visitation ...
>
> Why do we need to do the sweep-back part in BFS order?

Due to the recursive visitation order, the basic blocks get inserted to the 
//reachable// blocks set sooner, than another unreachable block would get 
visited.
In the `magic_clamp` example the recursive (DFS) visitation starts from `B0`, 
enters `B1`, recurses further up to `B2` then to `B4` and `B4`. This is when 
the algorithm starts popping frames (backtracking).
It backtracks, backtracks ... back to `B1`, where it has another 
//predecessor// (`B3`), hence it recurses on that path as well. But this time, 
it will find that the only predecessor of `B3` is **reachable**, hence it will 
leave `B3` as unreachable. And this is the problem, because we should not 
report a dead code bug there. Consequently, we should not extend the 
//reachable// blocks set in DFS visitation order. However, if we were using BFS 
visitation order, we can never end up in this situation.

> Connected components can be found by both DFS or BFS. Please elaborate why 
> should we prefer BFS? The problem you are trying to solve seems to be an 
> unnecessarily convoluted problem to me. Shouldn't it be enough to simply pick 
> one node (or all of them) from the connected component? It should not matter 
> if we use DFS or BFS for finding the nodes in a connected component.

I don't think any of the issues mentioned in this patch relates to //strongly 
connected components//, thus I don't think I can answer to this question.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127874

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

[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen updated this revision to Diff 437580.
sdesmalen marked 10 inline comments as done.
sdesmalen added a comment.

Addressed bunch of the review comments (though not all yet).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127762

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/aarch64-sme-intrinsics/aarch64-sme-attrs.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/aarch64-sme-attrs-no-sme.c
  clang/test/Sema/aarch64-sme-func-attrs.c

Index: clang/test/Sema/aarch64-sme-func-attrs.c
===
--- /dev/null
+++ clang/test/Sema/aarch64-sme-func-attrs.c
@@ -0,0 +1,166 @@
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -fsyntax-only -verify %s
+
+// Valid attributes
+
+__attribute__((arm_streaming)) void sme_arm_streaming(void);
+__attribute__((arm_streaming_compatible)) void sme_arm_streaming_compatible(void);
+
+__attribute__((arm_new_za)) void sme_arm_new_za(void);
+__attribute__((arm_shared_za)) void sme_arm_shared_za(void);
+__attribute__((arm_preserves_za)) void sme_arm_preserves_za(void);
+
+__attribute__((arm_streaming, arm_new_za)) void sme_arm_streaming_new_za(void);
+__attribute__((arm_streaming, arm_shared_za)) void sme_arm_streaming_shared_za(void);
+__attribute__((arm_streaming, arm_preserves_za)) void sme_arm_streaming_preserves_za(void);
+
+__attribute__((arm_streaming_compatible, arm_new_za)) void sme_arm_sc_new_za(void);
+__attribute__((arm_streaming_compatible, arm_shared_za)) void sme_arm_sc_shared_za(void);
+__attribute__((arm_streaming_compatible, arm_preserves_za)) void sme_arm_sc_preserves_za(void);
+
+__attribute__((arm_shared_za, arm_preserves_za)) void sme_arm_shared_preserves_za(void);
+
+__attribute__((arm_locally_streaming)) void sme_arm_locally_streaming(void) { }
+__attribute__((arm_locally_streaming, arm_streaming)) void sme_arm_streaming_and_locally_streaming(void) { }
+__attribute__((arm_locally_streaming, arm_streaming_compatible)) void sme_arm_streaming_and_streaming_compatible(void) { }
+
+__attribute__((arm_locally_streaming, arm_new_za)) void sme_arm_ls_new_za(void) { }
+__attribute__((arm_locally_streaming, arm_shared_za)) void sme_arm_ls_shared_za(void) { }
+__attribute__((arm_locally_streaming, arm_preserves_za)) void sme_arm_ls_preserves_za(void) { }
+
+// Valid attributes on function pointers
+
+void __attribute__((arm_streaming)) streaming_ptr(void);
+typedef __attribute__((arm_streaming)) void (*fptrty1) (void);
+fptrty1 call_streaming_func() { return streaming_ptr; }
+
+void __attribute__((arm_streaming_compatible)) streaming_compatible_ptr(void);
+typedef __attribute__((arm_streaming_compatible)) void (*fptrty2) (void);
+fptrty2 call_sc_func() { return streaming_compatible_ptr; }
+
+void __attribute__((arm_new_za)) new_za_ptr(void);
+typedef __attribute__((arm_new_za)) void (*fptrty3) (void);
+fptrty3 call_new_za_func() { return new_za_ptr; }
+
+void __attribute__((arm_shared_za)) shared_za_ptr(void);
+typedef __attribute__((arm_shared_za)) void (*fptrty4) (void);
+fptrty4 call_shared_za_func() { return shared_za_ptr; }
+
+void __attribute__((arm_preserves_za)) preserves_za_ptr(void);
+typedef __attribute__((arm_preserves_za)) void (*fptrty5) (void);
+fptrty5 call_preserve_za_func() { return preserves_za_ptr; }
+
+void __attribute__((arm_shared_za, arm_preserves_za)) shared_preserves_za_ptr(void);
+typedef __attribute__((arm_shared_za, arm_preserves_za)) void (*fptrty6) (void);
+fptrty6 call_shared_preserve_za_func() { return shared_preserves_za_ptr; }
+
+typedef void (*fptrty7) (void);
+fptrty7 cast_ls_func_to_normal() { return sme_arm_locally_streaming; }
+
+// FIXME: Add invalid function pointer assignments such as assigning:
+//   1. A streaming compatible function to a normal function pointer,
+//   2. A locally streaming function to a streaming function pointer,
+// etc.
+
+// Invalid attributes
+
+// expected-error@+2 {{'arm_streaming_compatible' and 'arm_streaming' attributes are not compatible}}
+// expected-note@+1 {{conflicting attribute is here}}
+__attribute__((arm_streaming, arm_streaming_compatible)) void streaming_mode(void);
+
+// expected-error@+2 {{'arm_streaming' and 'arm_streaming_compatible' attributes are not compatible}}
+// expected-note@+1 {{conflicting attribute is here}}
+__attribute__((arm_streaming_compatible, arm_streaming)) void streaming_compatible(void);
+
+// expected-error@+2 {{'arm_shared_za' and 'a

[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added a comment.

Thanks @aaron.ballman for your elaborate review, that was very helpful! I'm 
still working through some of your suggestions (although some of them weren't 
entirely clear to me), but I've addressed a number of them already.

In D127762#3582753 , @aaron.ballman 
wrote:

>> This patch adds all the language-level function attributes defined in:
>>
>> https://github.com/ARM-software/acle/pull/188
>
> This pull request has not yet been merged, so what are the chances that it 
> gets rejected or altered?

There has already been quite some discussion on the draft both online and 
offline, and we already started to implement it to get confidence that there's 
no big flaws in its design. Other than perhaps some minor changes, I expect it 
to land in its current form.

>> LLVM support for these attributes will follow later, so at the moment these 
>> attributes are non-functional.
>
> FWIW, I would rather we land the attributes once they're functional even if 
> we do a bunch of the review work up front. While rare, we have run into the 
> situation where attributes get added with intentions to make them useful 
> later but then something comes up and we're left with half the implementation 
> exposed to users.

I think that's fair. We'll share LLVM support for these attributes shortly, but 
I'm happy to wait landing this work until the LLVM support has landed. It would 
be nice if I can get this patch in a state where you and other reviewers are 
happy with it, so that it only needs a quick rebase once the LLVM support is 
there.




Comment at: clang/include/clang/AST/Type.h:3806-3811
+SME_NormalFunction = 0,
+SME_PStateSMEnabledMask = 1,
+SME_PStateSMCompatibleMask = 2,
+SME_PStateZANewMask = 4,
+SME_PStateZASharedMask = 8,
+SME_PStateZAPreservedMask = 16,

aaron.ballman wrote:
> Also, would it be better to use a bitmask enumeration here? 
> https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ADT/BitmaskEnum.h
Unless I'm misunderstanding its purpose, I'm not sure if using BitmaskEnum is 
worth it, because there's only little casting going on.



Comment at: clang/include/clang/AST/Type.h:4008
 bool HasTrailingReturn : 1;
+unsigned AArch64SMEAttributes : 8;
 Qualifiers TypeQuals;

aaron.ballman wrote:
> So functions without prototypes cannot have any of these attributes?
Yes, the ACLE explicitly states that 
[[https://github.com/ARM-software/acle/pull/188/commits/59751df91d9630400531a64108f179e3951c3b89#diff-516526d4a18101dc85300bc2033d0f86dc46c505b7510a7694baabea851aedfaR503|here]]:
> The function type attributes cannot be used with K&R-style “unprototyped” C 
> function types



Comment at: clang/include/clang/Basic/Attr.td:2322
 
+def ArmStreamingCompatible : DeclOrTypeAttr, TargetSpecificAttr 
{
+  let Spellings = [Clang<"arm_streaming_compatible">];

aaron.ballman wrote:
> `DeclOrTypeAttr` is only intended to be used for attributes which were 
> historically a declaration attribute but are semantically type attributes 
> (like calling conventions). It seems to me that each of these is purely a 
> type attribute and we shouldn't allow them to be written in the declaration 
> position. WDYT?
In this case, I believe the attribute is valid on both the type and the 
declaration, because the SME ACLE explicitly specifies that the attributes can 
be applied to both declarations and types.

The 
[[https://github.com/ARM-software/acle/pull/188/commits/ce878cf6c43fd824ffc634526e5dfec1ddc1839e#diff-516526d4a18101dc85300bc2033d0f86dc46c505b7510a7694baabea851aedfaR8283-R8294|specification]]
 says:
```Some of the attributes described in this section apply to function types.
Their semantics are as follows:

*   If the attribute is attached to a function declaration or definition,
it applies to the type of the function.

*   If the attribute is attached to a function type, it applies to that type.

*   If the attribute is attached to a pointer to a function type, it applies
to that function type.

*   Otherwise, the attribute is [ill-formed](#ill-formed).```



Comment at: clang/include/clang/Basic/Attr.td:2325
+  let Subjects = SubjectList<[FunctionLike], ErrorDiag>;
+  let Documentation = [Undocumented];
+}

aaron.ballman wrote:
> No new, undocumented attributes (same goes for the rest of the additions); 
> please add some docs to AttrDocs.td (it's okay to lightly document and point 
> to a canonical resource for more details).
Fair point, I've added some documentation.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:8109-8112
+  // Handle mutually exclusive SME function attributes:
+  //  -  arm_streaming & arm_streaming_compatible
+  //  -  arm_new_za & arm_preserves_za
+  //  -  arm_new_za & arm_shared_za

aaron.ballman wrote:
> This shoul

[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 437582.
serge-sans-paille retitled this revision from "[clang] Introduce 
-fstrict-flex-arrays for stricter handling of flexible arrays" to "[clang] 
Introduce -fstrict-flex-arrays= for stricter handling of flexible arrays".
serge-sans-paille edited the summary of this revision.
serge-sans-paille added a comment.

Update option and code to handle several level of conformance

Syndicate code across clang codebase to a single point

update test case accordingly


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/AST/Expr.h
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  clang/lib/AST/Expr.cpp
  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/bounds-checking.c
  clang/test/CodeGen/object-size-flex-array.c
  clang/test/CodeGenObjC/ubsan-array-bounds.m
  clang/test/Sema/array-bounds-ptr-arith.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=3 %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/Sema/array-bounds-ptr-arith.c
===
--- clang/test/Sema/array-bounds-ptr-arith.c
+++ clang/test/Sema/array-bounds-ptr-arith.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -verify -Warray-bounds-pointer-arithmetic %s
+// RUN: %clang_cc1 -verify -Warray-bounds-pointer-arithmetic -fstrict-flex-arrays=1 %s
 
 // Test case from PR10615
 struct ext2_super_block{
@@ -12,40 +12,3 @@
 {
 	 return (void *)es->s_uuid + 80; // expected-warning {{refers past the end of the array}}
 }
-
-// Test case reduced from PR11594
-struct S { int n; };
-void pr11594(struct S *s) {
-  int a[10];
-  int *p = a - s->n;
-}
-
-// Test case reduced from .  This resulted in
-// an assertion failure because of the typedef instead of an explicit
-// constant array type.
-struct RDar11387038 {};
-typedef struct RDar11387038 RDar11387038Array[1];
-struct RDar11387038_Table {
-  RDar11387038Array z;
-};
-typedef struct RDar11387038_Table * TPtr;
-typedef TPtr *TabHandle;
-struct RDar11387038_B { TabHandle x; };
-typedef struct RDar11387038_B RDar11387038_B;
-
-void radar11387038(void) {
-  RDar11387038_B *pRDar11387038_B;
-  struct RDar11387038* y = &(*pRDar11387038_B->x)->z[4];
-}
-
-void pr51682 (void) {
-  int arr [1];
-  switch (0) {
-case 0:
-  break;
-case 1:
-  asm goto (""::"r"(arr[42] >> 1)::failed); // no-warning
-  break;
-  }
-failed:;
-}
Index: clang/test/CodeGenObjC/ubsan-array-bounds.m
===
--- clang/test/CodeGenObjC/ubsan-array-bounds.m
+++ clang/test/CodeGenObjC/ubsan-array-bounds.m
@@ -14,46 +14,3 @@
   return FA1->chars[1];
   // CHECK: }
 }
-
-@interface FlexibleArray2 {
-@public
-  char chars[0];
-}
-@end
-@implementation FlexibleArray2 {
-@public
-  char chars2[0];
-}
-@end
-
-// CHECK-LABEL: test_FlexibleArray2_1
-char test_FlexibleArray2_1(FlexibleArray2 *FA2) {
-  // CHECK: !nosanitize
-  return FA2->chars[1];
-  // CHECK: }
-}
-
-// CHECK-LABEL: test_FlexibleArray2_2
-char test_FlexibleArray2_2(FlexibleArray2 *FA2) {
-  // CHECK-NOT: !nosanitize
-  return FA2->chars2[1];
-  // CHECK: }
-}
-
-@interface FlexibleArray3 {
-@public
-  char chars[0];
-}
-@end
-@implementation FlexibleArray3 {
-@public
-  int i;
-}
-@end
-
-// CHECK-LABEL: test_FlexibleArray3
-char test_FlexibleArray3(FlexibleArray3 *FA3) {
-  // CHECK: !nosanitize
-  return FA3->chars[1];
-  // CHECK: }
-}
Index: clang/test/CodeGen/object-size-flex-array.c
===
--- /dev/null
+++ clang/test/CodeGen/object-size-flex-array.c
@@ -0,0 +1,106 @@
+// RUN: %clang -fstrict-flex-arrays=3 -target x86_64-apple-darwin -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefixes=CHECK,CHECK-STRICT-3 %s
+// RUN: %clang -fstrict-flex-arrays=2 -target x86_64-apple-darwin -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefixes=CHECK,CHECK-STRICT-2 %s
+// RUN: %clang -fstrict-fl

[PATCH] D127904: [AMDGPU] gfx11 new dot instruction codegen support

[Joe Nash via Phabricator via cfe-commits]

Joe_Nash added inline comments.



Comment at: llvm/include/llvm/IR/IntrinsicsAMDGPU.td:1926
 
+// f16 %r = llvm.amdgcn.fdot2.f16.f16(v2f16 %a, v2f16 %b, f16 %c, i1 %clamp)
+//   %r = %a[0] * %b[0] + %a[1] * %b[1] + %c

rampitec wrote:
> I do not see clamp in the definition. Make a separate comment for the last 2?
I removed clamp from the comments.



Comment at: llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.fdot2.f16.f16.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1100 -verify-machineinstrs < %s 
| FileCheck %s --check-prefixes=GFX11
+

arsenm wrote:
> Is there actually a reason to split the globalisel and DAG tests? I expect 
> tests this simple to be identical
Ok, I have combined the tests and they are identical.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127904

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

[PATCH] D127898: [clang][dataflow] Find unsafe locs after fixpoint

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

C++ seems to be tied to templates. I wonder if super classes resp. inheritance  
would make your life easier. You can explicitly define the API and 
documentation. You could provide default implementations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127898

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

[PATCH] D122150: [clang][analyzer] Add checker for bad use of 'errno'.

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Awesome!

The generated doc section looks great. The test coverage it excellent, but I 
would recommend adding tests for covering the following lines:

- `ErrnoChecker.cpp:99`
- `ErrnoModeling.cpp:259`
- `ErrnoModeling.cpp:264`

There are two other uncovered cases, but those are mainly defensive checks, so 
I don't mind them.




Comment at: clang/docs/analyzer/checkers.rst:2565
+value is not used in a condition. For example ``errno`` can be stored into a
+variable without getting a warning from the checker.
+

by



Comment at: clang/docs/analyzer/checkers.rst:2586
+   or returned from a function.
+ - Documentation of function `lseek` is not clear about what happens if the
+   function returns different value than the expected file position but not -1.

I think it should be surrounded by double backticks. It looks ugly this way:
{F23478405}


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122150

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

[PATCH] D127142: [HIP] Link with clang_rt.builtins

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 437587.
yaxunl added a comment.

use compiler-rt as runtime lib by default for --hip-link


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

https://reviews.llvm.org/D127142

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/hip-runtime-libs-linux.hip
  clang/test/Driver/hip-runtime-libs-msvc.hip

Index: clang/test/Driver/hip-runtime-libs-msvc.hip
===
--- clang/test/Driver/hip-runtime-libs-msvc.hip
+++ clang/test/Driver/hip-runtime-libs-msvc.hip
@@ -2,9 +2,15 @@
 
 // RUN:  touch %t.o
 
+// Get compiler-rt library full path.
+// RUN: %clang -target x86_64-pc-windows-msvc -rtlib=compiler-rt \
+// RUN:   -print-libgcc-file-name >%t.1
+
 // Test HIP runtime lib args specified by --rocm-path.
 // RUN: %clang -### --hip-link -target x86_64-pc-windows-msvc \
-// RUN:   --rocm-path=%S/Inputs/rocm %t.o 2>&1 \
-// RUN:   | FileCheck %s
+// RUN:   --rocm-path=%S/Inputs/rocm %t.o >%t.2 2>&1
+// RUN: cat %t.1 %t.2 | FileCheck %s
 
+// CHECK: [[COMPILER_RT:.*clang_rt\.builtins.*]]
 // CHECK: "-libpath:{{.*Inputs.*rocm.*lib}}" "amdhip64.lib"
+// CHECK-SAME: "[[COMPILER_RT]]"
Index: clang/test/Driver/hip-runtime-libs-linux.hip
===
--- clang/test/Driver/hip-runtime-libs-linux.hip
+++ clang/test/Driver/hip-runtime-libs-linux.hip
@@ -2,15 +2,19 @@
 
 // RUN:  touch %t.o
 
+// Get compiler-rt library full path.
+// RUN: %clang -target x86_64-linux-gnu -rtlib=compiler-rt \
+// RUN:   -print-libgcc-file-name >%t.1
+
 // Test HIP runtime lib args specified by --rocm-path.
 // RUN: %clang -### --hip-link -target x86_64-linux-gnu \
-// RUN:   --rocm-path=%S/Inputs/rocm %t.o 2>&1 \
-// RUN:   | FileCheck -check-prefixes=ROCM-PATH %s
+// RUN:   --rocm-path=%S/Inputs/rocm %t.o >%t.2 2>&1
+// RUN: cat %t.1 %t.2 | FileCheck -check-prefixes=ROCM-PATH,COMMON %s
 
 // Test HIP runtime lib args specified by environment variable ROCM_PATH.
 // RUN: env ROCM_PATH=%S/Inputs/rocm %clang -### --hip-link \
-// RUN:   -target x86_64-linux-gnu %t.o 2>&1 \
-// RUN:   | FileCheck -check-prefixes=ROCM-PATH %s
+// RUN:   -target x86_64-linux-gnu %t.o >%t.2 2>&1
+// RUN: cat %t.1 %t.2 | FileCheck -check-prefixes=ROCM-PATH,COMMON %s
 
 // Test detecting latest /opt/rocm-{release} directory.
 // RUN: rm -rf %T/opt
@@ -18,26 +22,30 @@
 // RUN: cp -r %S/Inputs/rocm %T/opt/rocm-3.9.0-1234
 // RUN: cp -r %S/Inputs/rocm %T/opt/rocm-3.10.0
 // RUN: %clang -### --hip-link -target x86_64-linux-gnu \
-// RUN:   --sysroot=%T %t.o 2>&1 \
-// RUN:   | FileCheck -check-prefixes=ROCM-REL %s
+// RUN:   --sysroot=%T %t.o >%t.2 2>&1
+// RUN: cat %t.1 %t.2 | FileCheck -check-prefixes=ROCM-REL,COMMON %s
 
 // Test HIP runtime lib is not linked without --hip-link.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --rocm-path=%S/Inputs/rocm %t.o 2>&1 \
 // RUN:   | FileCheck -check-prefixes=NOHIPRT %s
 
-// Test HIP runtime lib is not linked with -nostdlib.
-// RUN: %clang -### --hip-link -nostdlib -target x86_64-linux-gnu \
+// Test HIP runtime lib is not linked with -rtlib=gcc.
+// RUN: %clang -### --hip-link -rtlib=gcc -target x86_64-linux-gnu \
 // RUN:   --rocm-path=%S/Inputs/rocm %t.o 2>&1 \
-// RUN:   | FileCheck -check-prefixes=NOHIPRT %s
+// RUN:   | FileCheck -check-prefixes=LIBGCC %s
 
 // Test HIP runtime lib is not linked with -no-hip-rt.
 // RUN: %clang -### --hip-link -no-hip-rt -target x86_64-linux-gnu \
 // RUN:   --rocm-path=%S/Inputs/rocm %t.o 2>&1 \
 // RUN:   | FileCheck -check-prefixes=NOHIPRT %s
 
+// COMMON: [[COMPILER_RT:/.*/libclang_rt\.builtins.*]]
 // ROCM-PATH: "-L[[HIPRT:.*/Inputs/rocm/lib]]" "-rpath" "[[HIPRT]]" "-lamdhip64"
 // ROCM-REL: "-L[[HIPRT:.*/opt/rocm-3.10.0/lib]]" "-rpath" "[[HIPRT]]" "-lamdhip64"
+// COMMON-SAME: "[[COMPILER_RT]]"
+
 // NOHIPRT-NOT: "-L{{.*/Inputs/rocm/lib}}"
 // NOHIPRT-NOT: "-rpath" "{{.*/Inputs/rocm/lib}}"
 // NOHIPRT-NOT: "-lamdhip64"
+// LIBGCC-NOT: "{{/[^"]*clang_rt\.builtins[^"]*}}"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -832,8 +832,12 @@
   if (runtimeLibType)
 return *runtimeLibType;
 
+  // HIP needs compier-rt for _Float16 conversion functions.
   const Arg* A = Args.getLastArg(options::OPT_rtlib_EQ);
-  StringRef LibName = A ? A->getValue() : CLANG_DEFAULT_RTLIB;
+  StringRef LibName =
+  A ? A->getValue()
+: (Args.hasArg(options::OPT_hip_link) ? "compiler-rt"
+  : CLANG_DEFAULT_RTLIB);
 
   // Only use "platform" in tests to override CLANG_DEFAULT_RTLIB!
   if (LibName == "compiler-rt")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Vang Thao via Phabricator via cfe-commits]

vangthao updated this revision to Diff 437593.
vangthao added a comment.

Update commit message to include the motivation behind the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127923

Files:
  clang/lib/Basic/Diagnostic.cpp
  clang/lib/Frontend/TextDiagnosticPrinter.cpp
  clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp
  clang/test/Analysis/padding_message.cpp

Index: clang/test/Analysis/padding_message.cpp
===
--- clang/test/Analysis/padding_message.cpp
+++ clang/test/Analysis/padding_message.cpp
@@ -1,11 +1,11 @@
 // RUN: %clang_analyze_cc1 -triple x86_64-unknown-linux -std=c++14 -analyzer-checker=optin.performance -analyzer-config optin.performance.Padding:AllowedPad=2 -verify %s
 
 // expected-warning@+7{{\
-Excessive padding in 'struct IntSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct IntSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct IntSandwich {
   char c1;
@@ -14,11 +14,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct TurDuckHen' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct TurDuckHen' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct TurDuckHen {
   char c1;
@@ -29,15 +29,15 @@
 #pragma pack(push)
 #pragma pack(2)
 // expected-warning@+11{{\
-Excessive padding in 'struct SmallIntSandwich' (4 padding bytes, where 0 is optimal). \
-Optimal fields order: \
-i1, \
-i2, \
-i3, \
-c1, \
-c2, \
-c3, \
-c4, \
+Excessive padding in 'struct SmallIntSandwich' (4 padding bytes, where 0 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i1, \n\
+i2, \n\
+i3, \n\
+c1, \n\
+c2, \n\
+c3, \n\
+c4, \n\
 }}
 struct SmallIntSandwich {
   char c1;
@@ -57,11 +57,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct HoldsAUnion' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-u, \
-c1, \
-c2, \
+Excessive padding in 'struct HoldsAUnion' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+u, \n\
+c1, \n\
+c2, \n\
 }}
 struct HoldsAUnion {
   char c1;
@@ -78,11 +78,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct StructSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-m, \
-s, \
-s2, \
+Excessive padding in 'struct StructSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+m, \n\
+s, \n\
+s2, \n\
 }}
 struct StructSandwich {
   struct SmallCharArray s;
@@ -91,11 +91,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'TypedefSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'TypedefSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 typedef struct {
   char c1;
@@ -104,11 +104,11 @@
 } TypedefSandwich;
 
 // expected-warning@+7{{\
-Excessive padding in 'struct StructAttrAlign' (10 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct StructAttrAlign' (10 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct StructAttrAlign {
   char c1;
@@ -117,12 +117,12 @@
 } __attribute__((aligned(8)));
 
 // expected-warning@+8{{\
-Excessive padding in 'struct OverlyAlignedChar' (8185 padding bytes, where 4089 is optimal). \
-Optimal fields order: \
-c, \
-c1, \
-c2, \
-x, \
+Excessive padding in 'struct OverlyAlignedChar' (8185 padding bytes, where 4089 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+c, \n\
+c1, \n\
+c2, \n\
+x, \n\
 }}
 struct OverlyAlignedChar {
   char c1;
@@ -132,11 +132,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct HoldsOverlyAlignedChar' (8190 padding bytes, where 4094 is optimal). \
-Optimal fields order: \
-o, \
-c1, \
-c2, \
+Excessive padding in 'struct HoldsOverlyAlignedChar' (8190 padding bytes, where 4094 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+o, \n\
+c1, \n\
+c2, \n\
 }}
 struct HoldsOverlyAlignedChar {
   char c1;
@@ -146,11 +146,11 @@
 
 void internalStructFunc() {
   // expected-warning@+7{{\
-Excessive padding in 'struct X' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-t, \
-c1, \
-c2, \
+Excessive padding in 'struct X' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+t, \n\
+c1, \n\
+c2, \n\
 }}
   struct X {
 char c1;
@@ -162,11 +162,11

[PATCH] D127873: [clang-format] Fix misplacemnt of `*` in declaration of pointer to struct

[Jack Huang via Phabricator via cfe-commits]

jackhong12 added a comment.

I think it's a good idea. When does `MatchingParen` bind? The value of 
`PrevToken->MatchingParen` is still NULL in `determineStarAmpUsage` function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127873

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

[PATCH] D125400: [clang][Analyzer] Add errno state to standard functions modeling.

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

In the `describeErrnoCheckState()` the `Errno_MustBeChecked` is uncovered by 
tests.




Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:410
+/// Many of the descendant classes use this value.
+errno_modeling::ErrnoCheckState const CheckState;
+

I would prefer the //west-const// style.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125400

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

[PATCH] D127904: [AMDGPU] gfx11 new dot instruction codegen support

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec accepted this revision.
rampitec 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/D127904/new/

https://reviews.llvm.org/D127904

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

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

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

In D126495#3588787 , @aaron.ballman 
wrote:

> In D126495#3574115 , 
> @LegalizeAdulthood wrote:
>
>> 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?
>
> We do:
>
> https://releases.llvm.org/12.0.0/tools/clang/tools/extra/docs/
> https://releases.llvm.org/11.0.0/tools/clang/tools/extra/docs/
> and so on.
>
> Giving my LG more officially now to unblock this, but I'd still appreciate 
> some extra eyes on the Python changes.

I tested by generating a new check and validating the links in the 
documentation as well as running `--update-docs` and checking that the updates 
were correct.  So functionally, there should be no problem and I tried to 
follow the existing style of the file, so should be good on style nits as well.


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] D125936: [Sema] Relax an assertion in BuildStmtExpr

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2291
+  // statement.
+  CodeGenFunction::RunCleanupsScope Cleanups(*this);
+

Do we need to do anything special when entering the full expressions to make 
sure that enclosing-block features like blocks and C compound literals have the 
right lifetime?


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

[PATCH] D127910: [Clang][AArch64] Add SME C intrinsics for load and store

[Sagar Kulkarni via Phabricator via cfe-commits]

sagarkulkarni19 added a comment.

In D127910#3589068 , @sdesmalen wrote:

> Hi @sagarkulkarni19, this patch will have to wait until the ABI is 
> implemented so that the builtins can be decorated with the attributes. A 
> first patch proposing these attributes is in D127762 
> . LLVM patches that use these attributes to 
> implement the ABI will follow soon. We could add you as reviewer to these 
> patches if you'd like to help us with that?

Hi @sdesmalen, sounds good. I can update this patch accordingly when the 
attributes patches are in. Sure, please add me as a reviewer to those patches. 
We are porting much of our downstream C intrinsics implementation to support 
the ACLE instead and can contribute this effort upstream. I have also created 
an article on discourse 
(https://discourse.llvm.org/t/clang-sme-acle-intrinsics/63223) for further 
discussion on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

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

[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

[Félix Cloutier via Phabricator via cfe-commits]

fcloutier added a comment.

Ping


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

https://reviews.llvm.org/D112579

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

[PATCH] D126224: Add DWARF string debug to clang release notes.

[Paul Kirth via Phabricator via cfe-commits]

paulkirth added a comment.

so do we want to land this? or are there some outstanding issues I'm unaware of?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126224

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

[PATCH] D126224: Add DWARF string debug to clang release notes.

[Mitch Phillips via Phabricator via cfe-commits]

hctim added a comment.

Yeah, I'll look at landing it today.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126224

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

[PATCH] D126224: Add DWARF string debug to clang release notes.

[Mitch Phillips via Phabricator via cfe-commits]

hctim added a comment.

(thanks for the bump - this one fell off the radar)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126224

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

[PATCH] D127910: [Clang][AArch64] Add SME C intrinsics for load and store

[Sagar Kulkarni via Phabricator via cfe-commits]

sagarkulkarni19 added inline comments.



Comment at: clang/include/clang/Basic/arm_sve.td:209
 def IsTupleSet: FlagType<0x4>;
+def IsSME : FlagType<0x8>;
+def IsSMELoadStore: FlagType<0x10>;

sdesmalen wrote:
> Is there value in having both `IsSME` and `IsSMELoadStore`?
`IsSME` flag is checked in the SveEmitter.cpp : createSMEHeader(...) to 
generate arm_sme.h with only the SME intrinsics, whereas `IsSMELoadStore` is 
used to correctly CodeGen (CGBuiltins.cpp) load and store intrinsics. 



Comment at: clang/lib/Basic/Targets/AArch64.cpp:342
+  if (HasSME)
+Builder.defineMacro("__ARM_FEATURE_SME", "1");
+

sdesmalen wrote:
> When this macro is non-zero, it suggests that the compiler implements the 
> full SME ACLE. That is currently not yet the case, so until then we should 
> leave this macro undefined.
Okay makes sense. But until all SME ACLE is implemented, do we need some sort 
of guard in the meantime while the SME intrinsics that are implemented 
incrementally? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

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

[clang] 2d43de1 - [AMDGPU] gfx11 new dot instruction codegen support

[Joe Nash via cfe-commits]

Author: Joe Nash
Date: 2022-06-16T14:19:34-04:00
New Revision: 2d43de13df03eab0fda1023b22b335b207afc507

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

LOG: [AMDGPU] gfx11 new dot instruction codegen support

Reviewed By: rampitec, #amdgpu

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

Added: 
clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-gfx11.cl
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.sudot4.ll
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.sudot8.ll
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.bf16.bf16.ll
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.f16.f16.ll
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.f32.bf16.ll
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot4.ll
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot8.ll

Modified: 
clang/include/clang/Basic/BuiltinsAMDGPU.def
clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
llvm/include/llvm/IR/IntrinsicsAMDGPU.td
llvm/lib/Target/AMDGPU/AMDGPUGISel.td
llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.cpp
llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.h
llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp
llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.h
llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp
llvm/lib/Target/AMDGPU/VOP3Instructions.td
llvm/lib/Target/AMDGPU/VOP3PInstructions.td
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.fdot2.ll

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsAMDGPU.def 
b/clang/include/clang/Basic/BuiltinsAMDGPU.def
index 19e4ea998aa47..bd188c7f34371 100644
--- a/clang/include/clang/Basic/BuiltinsAMDGPU.def
+++ b/clang/include/clang/Basic/BuiltinsAMDGPU.def
@@ -222,12 +222,17 @@ TARGET_BUILTIN(__builtin_amdgcn_ds_atomic_fadd_v2bf16, 
"V2sV2s*3V2s", "t", "gfx9
 
//===--===//
 
 TARGET_BUILTIN(__builtin_amdgcn_fdot2, "fV2hV2hfIb", "nc", "dot7-insts")
+TARGET_BUILTIN(__builtin_amdgcn_fdot2_f16_f16, "hV2hV2hh", "nc", "dot8-insts")
+TARGET_BUILTIN(__builtin_amdgcn_fdot2_bf16_bf16, "sV2sV2ss", "nc", 
"dot8-insts")
+TARGET_BUILTIN(__builtin_amdgcn_fdot2_f32_bf16, "fV2sV2sfIb", "nc", 
"dot8-insts")
 TARGET_BUILTIN(__builtin_amdgcn_sdot2, "SiV2SsV2SsSiIb", "nc", "dot2-insts")
 TARGET_BUILTIN(__builtin_amdgcn_udot2, "UiV2UsV2UsUiIb", "nc", "dot2-insts")
 TARGET_BUILTIN(__builtin_amdgcn_sdot4, "SiSiSiSiIb", "nc", "dot1-insts")
 TARGET_BUILTIN(__builtin_amdgcn_udot4, "UiUiUiUiIb", "nc", "dot7-insts")
+TARGET_BUILTIN(__builtin_amdgcn_sudot4, "iIbiIbiiIb", "nc", "dot8-insts")
 TARGET_BUILTIN(__builtin_amdgcn_sdot8, "SiSiSiSiIb", "nc", "dot1-insts")
 TARGET_BUILTIN(__builtin_amdgcn_udot8, "UiUiUiUiIb", "nc", "dot7-insts")
+TARGET_BUILTIN(__builtin_amdgcn_sudot8, "iIbiIbiiIb", "nc", "dot8-insts")
 
 
//===--===//
 // GFX10+ only builtins.

diff  --git a/clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl 
b/clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
index e7a71b5158859..ac732952b390b 100644
--- a/clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
+++ b/clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
@@ -8,29 +8,45 @@ typedef half __attribute__((ext_vector_type(2))) half2;
 typedef short __attribute__((ext_vector_type(2))) short2;
 typedef unsigned short __attribute__((ext_vector_type(2))) ushort2;
 
+#pragma OPENCL EXTENSION cl_khr_fp16 : enable
 kernel void builtins_amdgcn_dl_insts_err(
 global float *fOut, global int *siOut, global uint *uiOut,
-half2 v2hA, half2 v2hB, float fC,
-short2 v2ssA, short2 v2ssB, int siA, int siB, int siC,
-ushort2 v2usA, ushort2 v2usB, uint uiA, uint uiB, uint uiC) {
-  fOut[0] = __builtin_amdgcn_fdot2(v2hA, v2hB, fC, false); // 
expected-error {{'__builtin_amdgcn_fdot2' needs target feature dot7-insts}}
-  fOut[1] = __builtin_amdgcn_fdot2(v2hA, v2hB, fC, true);  // 
expected-error {{'__builtin_amdgcn_fdot2' needs target feature dot7-insts}}
+global short *sOut, global int *iOut, global half *hOut,
+half2 v2hA, half2 v2hB, float fC, half hC,
+short2 v2ssA, short2 v2ssB, short sC, int siA, int siB, int siC,
+ushort2 v2usA, ushort2 v2usB, uint uiA, uint uiB, uint uiC,
+int A, int B, int C) {
+  fOut[0] = __builtin_amdgcn_fdot2(v2hA, v2hB, fC, false);  // 
expected-error {{'__builtin_amdgcn_fdot2' needs target feature dot7-insts}}
+  fOut[1] = __builtin_amdgcn_fdot2(v2hA, v2hB, fC, true);   // 
expected-error {{'__builtin_amdgcn_fdot2' needs target feature dot7-insts}}
 
-  siOut[0] = __builtin_amdgcn_sdot2(v2ssA, v2ssB, siC, false); // 
expected-error {{'__builtin_amdgcn_sdot2' needs target feature dot2-insts}}
-  siOut[1] = __builtin_amdgcn_sdot2(v2ssA, v2ssB, si

[PATCH] D127904: [AMDGPU] gfx11 new dot instruction codegen support

[Joe Nash 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 rG2d43de13df03: [AMDGPU] gfx11 new dot instruction codegen 
support (authored by Joe_Nash).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127904

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-dl-insts-gfx11.cl
  llvm/include/llvm/IR/IntrinsicsAMDGPU.td
  llvm/lib/Target/AMDGPU/AMDGPUGISel.td
  llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.cpp
  llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.h
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.h
  llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp
  llvm/lib/Target/AMDGPU/VOP3Instructions.td
  llvm/lib/Target/AMDGPU/VOP3PInstructions.td
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.fdot2.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.sudot4.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.sudot8.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.bf16.bf16.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.f16.f16.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.fdot2.f32.bf16.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot4.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot8.ll

Index: llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot8.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AMDGPU/llvm.amdgcn.sudot8.ll
@@ -0,0 +1,102 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -march=amdgcn -mcpu=gfx1100 -show-mc-encoding -verify-machineinstrs < %s | FileCheck %s --check-prefixes=GFX11
+
+declare i32 @llvm.amdgcn.sudot8(i1 %asign, i32 %a, i1 %bsign, i32 %b, i32 %c, i1 %clamp)
+
+define i32 @test_llvm_amdgcn_sudot8_uu(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_uu:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x1c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 0, i32 %a, i1 0, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+define i32 @test_llvm_amdgcn_sudot8_us(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_us:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 neg_lo:[0,1,0] ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x5c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 0, i32 %a, i1 1, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+define i32 @test_llvm_amdgcn_sudot8_su(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_su:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 neg_lo:[1,0,0] ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x3c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 1, i32 %a, i1 0, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+define i32 @test_llvm_amdgcn_sudot8_ss(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_ss:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 neg_lo:[1,1,0] ; encoding: [0x00,0x40,0x18,0xcc,0x00,0x03,0x0a,0x7c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 1, i32 %a, i1 1, i32 %b, i32 %c, i1 0)
+  ret i32 %ret
+}
+
+
+
+define i32 @test_llvm_amdgcn_sudot8_uu_clamp(i32 %a, i32 %b, i32 %c) {
+; GFX11-LABEL: test_llvm_amdgcn_sudot8_uu_clamp:
+; GFX11:   ; %bb.0: ; %entry
+; GFX11-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) ; encoding: [0x00,0x00,0x89,0xbf]
+; GFX11-NEXT:s_waitcnt_vscnt null, 0x0 ; encoding: [0x00,0x00,0x7c,0xbc]
+; GFX11-NEXT:v_dot8_i32_iu4 v0, v0, v1, v2 clamp ; encoding: [0x00,0xc0,0x18,0xcc,0x00,0x03,0x0a,0x1c]
+; GFX11-NEXT:s_setpc_b64 s[30:31] ; encoding: [0x1e,0x48,0x80,0xbe]
+entry:
+  %ret = call i32 @llvm.amdgcn.sudot8(i1 0, i32 %a, i1 0, i32 %b, i32 %c, i1 1)
+  ret i32 %ret
+}
+
+defi

[PATCH] D126194: [Concepts] Implement overload resolution for destructors (P0848)

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson updated this revision to Diff 437656.
royjacobson added a comment.

Update the PR to now handle triviality, which turned out to require a different 
approach.
On the bright side it is now easier to see how to implemenet the rest of P0848.

Added an AST dump test that checks the bitfields of structs and some derived 
traits.

Also fixed the OpenCL test error - their destructor model is quite incompatible 
with clang
and already broken in some ways, so I tried my best to continue the current 
behaviour.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126194

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/AST/ast-dump-decl.cpp
  clang/test/AST/overloaded-destructors.cpp
  clang/test/CXX/class/class.dtor/p4.cpp
  clang/test/CXX/over/over.match/over.match.viable/p3.cpp
  clang/test/SemaTemplate/destructor-template.cpp

Index: clang/test/SemaTemplate/destructor-template.cpp
===
--- clang/test/SemaTemplate/destructor-template.cpp
+++ clang/test/SemaTemplate/destructor-template.cpp
@@ -98,7 +98,7 @@
   template 
   ~S(); // expected-error{{destructor cannot be declared as a template}}
 };
-struct T : S {// expected-note{{destructor of 'T' is implicitly deleted because base class 'PR38671::S' has no destructor}}
-  ~T() = default; // expected-warning{{explicitly defaulted destructor is implicitly deleted}}
+struct T : S {
+  ~T() = default;
 };
 } // namespace PR38671
Index: clang/test/CXX/over/over.match/over.match.viable/p3.cpp
===
--- clang/test/CXX/over/over.match/over.match.viable/p3.cpp
+++ clang/test/CXX/over/over.match/over.match.viable/p3.cpp
@@ -49,7 +49,6 @@
   S(A) requires false;
   S(double) requires true;
   ~S() requires false;
-  // expected-note@-1 2{{because 'false' evaluated to false}}
   ~S() requires true;
   operator int() requires true;
   operator int() requires false;
@@ -58,11 +57,7 @@
 void bar() {
   WrapsStatics::foo(A{});
   S{1.}.foo(A{});
-  // expected-error@-1{{invalid reference to function '~S': constraints not satisfied}}
-  // Note - this behavior w.r.t. constrained dtors is a consequence of current
-  // wording, which does not invoke overload resolution when a dtor is called.
-  // P0848 is set to address this issue.
+
   S s = 1;
-  // expected-error@-1{{invalid reference to function '~S': constraints not satisfied}}
   int a = s;
 }
Index: clang/test/CXX/class/class.dtor/p4.cpp
===
--- /dev/null
+++ clang/test/CXX/class/class.dtor/p4.cpp
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+template 
+struct A {
+  ~A() = delete;  // expected-note {{explicitly marked deleted}}
+  ~A() requires(N == 1) = delete; // expected-note {{explicitly marked deleted}}
+};
+
+// FIXME: We should probably make it illegal to mix virtual and non-virtual methods
+// this way. See CWG2488 and some discussion in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105699.
+template 
+struct B {
+  ~B() requires(N == 1) = delete; // expected-note {{explicitly marked deleted}}
+  virtual ~B() = delete;  // expected-note {{explicitly marked deleted}}
+};
+
+template 
+concept CO1 = N == 1;
+
+template 
+concept CO2 = N >
+0;
+
+template 
+struct C {
+  ~C() = delete; // expected-note {{explicitly marked deleted}}
+  ~C() requires(CO1) = delete;
+  ~C() requires(CO1 &&CO2) = delete; // expected-note {{explicitly marked deleted}}
+};
+
+template 
+struct D {
+  ~D() requires(N != 0) = delete; // expected-note {{explicitly marked deleted}}
+  // expected-note@-1 {{candidate function has been explicitly deleted}}
+  // expected-note@-2 {{candidate function not viable: constraints not satisfied}}
+  // expected-note@-3 {{evaluated to false}}
+  ~D() requires(N == 1) = delete;
+  // expected-note@-1 {{candidate function has been explicitly deleted}}
+  // expected-note@-2 {{candidate function not viable: constraints not satisfied}}
+  // expected-note@-3 {{evaluated to false}}
+};
+
+template 
+concept Foo = requires(T t) {
+  {t.foo()};
+};
+
+template 
+struct E {
+  void foo();
+  ~E();
+  ~E() requires Foo = delete; // expected-note {{explicitly marked deleted}}
+};
+
+template struct A<1>;
+template struct A<2>;
+template struct B<1>;
+template struct B<2>;
+template struct C<1>;
+template struct C<2>;
+template struct D<0>; // expected-error {{no viable destructor found for class 'D<0>

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via Phabricator via cfe-commits]

mingmingl added a comment.

In D127798#3588283 , @lenary wrote:

> Yes. Please submit a PR or Issue to the ACLE, explaining the use-case (the 
> explanation here is good enough, I think).
>
> Once the ACLE changes are merged, then you can proceed with a patch for clang.

This makes sense to me. I created 
https://github.com/ARM-software/acle/pull/199, yet not able to add reviewer 
(which is WAI since I don't have write permission).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127798

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

[PATCH] D127998: [CI test] D127593

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson created this revision.
Herald added a project: All.
royjacobson requested review of this revision.
Herald added projects: clang, clang-tools-extra.
Herald added a subscriber: cfe-commits.

Testing D127593  by Javier varez to see if 
the CI failures are random or not


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127998

Files:
  clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-const.cpp
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.h
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/drs/dr21xx.cpp
  clang/test/CXX/special/class.copy/p12-0x.cpp
  clang/test/CXX/special/class.copy/p25-0x.cpp
  clang/www/cxx_dr_status.html

Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -12840,7 +12840,7 @@
 https://wg21.link/cwg2171";>2171
 CD4
 Triviality of copy constructor with less-qualified parameter
-Unknown
+Clang 15
   
   
 https://wg21.link/cwg2172";>2172
Index: clang/test/CXX/special/class.copy/p25-0x.cpp
===
--- clang/test/CXX/special/class.copy/p25-0x.cpp
+++ clang/test/CXX/special/class.copy/p25-0x.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++11 -verify %s
+// RUN: %clang_cc1 -std=c++11 -verify %s -fclang-abi-compat=14 -DCLANG_ABI_COMPAT=14
 
 // expected-no-diagnostics
 
@@ -31,7 +32,30 @@
 struct NonConstCopy {
   NonConstCopy &operator=(NonConstCopy &) = default;
 };
+#if defined(CLANG_ABI_COMPAT) && CLANG_ABI_COMPAT <= 14
+// Up until (and including) Clang 14, non-const copy assignment operators were not trivial because
+// of dr2171
 using _ = not_trivially_assignable;
+#else
+// In the latest Clang version, all defaulted assignment operators are trivial, even if non-const,
+// because dr2171 is fixed
+static_assert(__has_trivial_assign(NonConstCopy), "");
+static_assert(__is_trivially_assignable(NonConstCopy &, NonConstCopy &), "");
+static_assert(!__is_trivially_assignable(NonConstCopy &, const NonConstCopy &), "");
+static_assert(!__is_trivially_assignable(NonConstCopy &, NonConstCopy), "");
+static_assert(!__is_trivially_assignable(NonConstCopy &, NonConstCopy &&), "");
+static_assert(__is_trivially_assignable(NonConstCopy &&, NonConstCopy &), "");
+static_assert(!__is_trivially_assignable(NonConstCopy &&, const NonConstCopy &), "");
+static_assert(!__is_trivially_assignable(NonConstCopy &&, NonConstCopy), "");
+static_assert(!__is_trivially_assignable(NonConstCopy &&, NonConstCopy &&), "");
+
+struct DefaultedSpecialMembers {
+  DefaultedSpecialMembers &operator=(const DefaultedSpecialMembers &) = default;
+  DefaultedSpecialMembers &operator=(DefaultedSpecialMembers &) = default;
+  DefaultedSpecialMembers &operator=(DefaultedSpecialMembers &&) = default;
+};
+using _ = trivially_assignable;
+#endif
 
 // class X has no virtual functions
 struct VFn {
Index: clang/test/CXX/special/class.copy/p12-0x.cpp
===
--- clang/test/CXX/special/class.copy/p12-0x.cpp
+++ clang/test/CXX/special/class.copy/p12-0x.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++11 -verify %s -Wno-defaulted-function-deleted
+// RUN: %clang_cc1 -std=c++11 -verify %s -Wno-defaulted-function-deleted -fclang-abi-compat=14 -DCLANG_ABI_COMPAT=14
 
 // expected-no-diagnostics
 
@@ -28,7 +29,25 @@
 struct NonConstCopy {
   NonConstCopy(NonConstCopy &) = default;
 };
+#if defined(CLANG_ABI_COMPAT) && CLANG_ABI_COMPAT <= 14
+// Up until (and including) Clang 14, non-const copy constructors were not trivial because of dr2171
 using _ = not_trivially_copyable;
+#else
+// In the latest Clang version, all defaulted constructors are trivial, even if non-const, because
+// dr2171 is fixed.
+static_assert(__has_trivial_copy(NonConstCopy), "");
+static_assert(__is_trivially_constructible(NonConstCopy, NonConstCopy &), "");
+static_assert(!__is_trivially_constructible(NonConstCopy, NonConstCopy), "");
+static_assert(!__is_trivially_constructible(NonConstCopy, const NonConstCopy &), "");
+static_assert(!__is_trivially_constructible(NonConstCopy, NonConstCopy &&), "");
+
+struct DefaultedSpecialMembers {
+  DefaultedSpecialMembers(const DefaultedSpecialMembers &) = default;
+  DefaultedSpecialMembers(DefaultedSpecialMembers &) = default;
+  DefaultedSpecialMembers(DefaultedSpecialMembers &&) = default;
+};
+using _ = trivially_copyable;
+#endif
 
 // class X has no virtual functions
 struct VFn {
Index: clang/test/CXX/drs/dr21xx.cpp
===
--- clang/test/CXX/drs/dr21xx.cpp
+++ clang/test/CXX/drs/dr21xx.cpp
@@ -140,6 +140,33 @@
 #endif
 }
 
+namespace dr2171 { // dr2171: 15
+#if __cplusplus >= 201103L
+
+struct NonConstCopy {
+  NonConstCopy(NonConstCopy &) = default;
+  NonConstCopy &operator=(NonConstCopy &) = de

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/test/Preprocessor/aarch64-target-features.c:22
 // CHECK-NOT: __ARM_FEATURE_CRC32 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_CRYPTO 1

The list is alphabetical. RCPC should be moved below.



Comment at: clang/test/Preprocessor/aarch64-target-features.c:566
+
+// RUN: %clang -target aarch64-none-linux-gnu -march=armv8.2-a+rcpc -x c -E 
-dM %s -o - | FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1

`--target=aarch64`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127798

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

[PATCH] D126194: [Concepts] Implement overload resolution for destructors (P0848)

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

I probably need to spend more time on this at one point, but first look seemed 
fine to me.  I think the approach is about right, and the solution is there.

@aaron.ballman  is messing with the constexpr-ness of SM functions, so there is 
likely some collaboration that needs to be doen to make sure we get THIS right 
as well.




Comment at: clang/docs/ReleaseNotes.rst:434
 
+- As per "Conditionally Trivial Special Member Functions" (P0848), it is
+  now possible to overload destructors using concepts. Note that the rest

Do we have enough to update cxx_status.html?



Comment at: clang/include/clang/AST/DeclBase.h:1603
+/// [class.mem.special].
+uint64_t IsIneligibleOrNotSelected : 1;
+

Hrumph... its a shame to lose the bit here later.  I wonder if at one point in 
a future patch we should figure out which of these flags can be moved to an 
'allocated in Trailing-storage ONLY if required' type deal, like we just did 
with FunctionTypeBitFields...



Comment at: clang/include/clang/AST/DeclCXX.h:1430
+  /// out of which one will be selected at the end.
+  /// This is called separately from addedMember because it has to be deferred
+  /// to the completion of the class.

@aaron.ballman  is messing around with addedMember recently... I wonder if 
there are OTHER decisions that need to be updated/moved here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126194

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

[PATCH] D127233: [CodeGen] Sort llvm.global_ctors by lexical order before emission

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

gentle ping..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127233

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

[PATCH] D127259: [CodeGen] guarantee templated static variables are initialized in the reverse instantiation order

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

gentle ping..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127259

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

[PATCH] D127802: [HLSL] Support HLSL vector initializers

[Chris Bieneman via Phabricator via cfe-commits]

beanz updated this revision to Diff 437670.
beanz added a comment.

Updates based on feedback from @aaron.ballman.

Thank you for all the test suggestions, it caught an extra-odd AST generation. 
Fix included :).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127802

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/AST/HLSL/vector-constructors.hlsl
  clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl

Index: clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
===
--- /dev/null
+++ clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -fsyntax-only -verify %s
+
+typedef float float2 __attribute__((ext_vector_type(2)));
+typedef float float3 __attribute__((ext_vector_type(3)));
+
+struct S { float f; };
+struct S2 { float f; int i; };
+
+[numthreads(1,1,1)]
+void entry() {
+  float2 LilVec = float2(1.0, 2.0);
+  float2 BrokenVec = float2(1.0, 2.0, 3.0); // expected-error{{excess elements in vector initializer}}
+  float3 NormieVec = float3(LilVec, 3.0, 4.0); // expected-error{{excess elements in vector initializer}}
+  float3 BrokenNormie = float3(3.0, 4.0); // expected-error{{too few elements in vector initialization (expected 3 elements, have 2)}}
+  float3 OverwhemledNormie = float3(3.0, 4.0, 5.0, 6.0); // expected-error{{excess elements in vector initializer}}
+
+  // These _should_ work in HLSL but aren't yet supported.
+  S s;
+  float2 GettingStrange = float2(s, s); // expected-error{{no viable conversion from 'S' to 'float'}} expected-error{{no viable conversion from 'S' to 'float'}}
+  S2 s2;
+  float2 EvenStranger = float2(s2); // expected-error{{no viable conversion from 'S2' to 'float'}} expected-error{{too few elements in vector initialization (expected 2 elements, have 1)}}
+}
Index: clang/test/AST/HLSL/vector-constructors.hlsl
===
--- /dev/null
+++ clang/test/AST/HLSL/vector-constructors.hlsl
@@ -0,0 +1,143 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -ast-dump -o - %s | FileCheck %s 
+
+typedef float float2 __attribute__((ext_vector_type(2)));
+typedef float float3 __attribute__((ext_vector_type(3)));
+
+[numthreads(1,1,1)]
+void entry() {
+  float2 Vec2 = float2(1.0, 2.0);
+  float3 Vec3 = float3(Vec2, 3.0);
+  float3 Vec3b = float3(1.0, 2.0, 3.0);
+
+// For the float2 vector, we just expect a conversion from constructor
+// parameters to an initialization list
+// CHECK: VarDecl 0x{{[0-9a-fA-F]+}}  col:10 used Vec2 'float2':'float __attribute__((ext_vector_type(2)))' cinit
+// CHECK-NEXT: CXXFunctionalCastExpr 0x{{[0-9a-fA-F]+}}  'float2':'float __attribute__((ext_vector_type(2)))' functional cast to float2 
+// CHECK-NEXT: InitListExpr 0x{{[0-9a-fA-F]+}}  'float2':'float __attribute__((ext_vector_type(2)))'
+// CHECK-NEXT: ImplicitCastExpr 0x{{[0-9a-fA-F]+}}  'float' 
+// CHECK-NEXT: FloatingLiteral 0x{{[0-9a-fA-F]+}}  'double' 1.00e+00
+// CHECK-NEXT: ImplicitCastExpr 0x{{[0-9a-fA-F]+}}  'float' 
+// CHECK-NEXT: FloatingLiteral 0x{{[0-9a-fA-F]+}}  'double' 2.00e+00
+
+
+// For the float 3 things get fun...
+// Here we expect accesses to the vec2 to provide the first and second
+// components using ArraySubscriptExpr
+// CHECK: VarDecl 0x{{[0-9a-fA-F]+}}  col:10 Vec3 'float3':'float __attribute__((ext_vector_type(3)))' cinit
+// CHECK-NEXT: CXXFunctionalCastExpr 0x{{[0-9a-fA-F]+}}  'float3':'float __attribute__((ext_vector_type(3)))' functional cast to float3 
+// CHECK-NEXT: InitListExpr 0x{{[0-9a-fA-F]+}}  'float3':'float __attribute__((ext_vector_type(3)))'
+// CHECK-NEXT: ImplicitCastExpr 0x{{[0-9a-fA-F]+}} > 'float' 
+// CHECK-NEXT: ArraySubscriptExpr 0x{{[0-9a-fA-F]+}} > 'float' lvalue
+// CHECK-NEXT: DeclRefExpr 0x{{[0-9a-fA-F]+}}  'float2':'float __attribute__((ext_vector_type(2)))' lvalue Var 0x{{[0-9a-fA-F]+}} 'Vec2' 'float2':'float __attribute__((ext_vector_type(2)))'
+// CHECK-NEXT: IntegerLiteral 0x{{[0-9a-fA-F]+}} <> 'int' 0
+// CHECK-NEXT: ImplicitCastExpr 0x{{[0-9a-fA-F]+}} > 'float' 
+// CHECK-NEXT: ArraySubscriptExpr 0x{{[0-9a-fA-F]+}} > 'float' lvalue
+// CHECK-NEXT: DeclRefExpr 0x{{[0-9a-fA-F]+}}  'float2':'float __attribute__((ext_vector_type(2)))' lvalue Var 0x{{[0-9a-fA-F]+}} 'Vec2' 'float2':'float __attribute__((ext_vector_type(2)))'
+// CHECK-NEXT: IntegerLiteral 0x{{[0-9a-fA-F]+}} <> 'int' 1
+// CHECK-NEXT: ImplicitCastExpr 0x{{[0-9a-fA-F]+}}  'float' 
+// CHECK-NEXT: FloatingLiteral 0x{{[0-9a-fA-F]+}}  'double' 3.00e+00
+
+// CHECK: VarDecl 0x{{[0-9a-fA-F]+}}  col:10 Vec3b 'float3':'float __attribute__((ext_vector_type(3)))' cinit
+// CHECK-NEXT: CXXFunctionalCastExpr 0x{{[0-9a-fA-F]+}}  'float3':'float __attribute__((ext_vector_type(3)))' functional cast to float3 
+// CHECK-NEXT: InitListExpr 0x{{[0-9a-fA-F]

[PATCH] D127890: [Docs] Update clang & llvm release notes for HLSL

[Chris Bieneman via Phabricator via cfe-commits]

beanz updated this revision to Diff 437672.
beanz added a comment.

Updates based on review feedback. Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127890

Files:
  clang/docs/ReleaseNotes.rst
  llvm/docs/ReleaseNotes.rst


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -110,6 +110,16 @@
 
 * ...
 
+Changes to the DirectX Backend
+--
+
+* DirectX has been added as an experimental target. Specify
+`-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=DirectX` in your CMake configuration to
+  enable it. The target is not packaged in pre-built binaries.
+* The DirectX backend supports the ``dxil`` architecture which is based on LLVM
+  3.6 IR encoded as bitcode and is the format used for DirectX GPU Shader
+  programs.
+
 Changes to the Hexagon Backend
 --
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -68,6 +68,12 @@
 
   Randomizing structure layout is a C-only feature.
 
+- Experimental support for HLSL has been added. The implementation is
+  incomplete and highly experimental. For more information about the ongoing
+  work to support HLSL see the `documentation
+  `_, or the `GitHub project
+  `_.
+
 Bug Fixes
 -
 - ``CXXNewExpr::getArraySize()`` previously returned a ``llvm::Optional``


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -110,6 +110,16 @@
 
 * ...
 
+Changes to the DirectX Backend
+--
+
+* DirectX has been added as an experimental target. Specify
+`-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=DirectX` in your CMake configuration to
+  enable it. The target is not packaged in pre-built binaries.
+* The DirectX backend supports the ``dxil`` architecture which is based on LLVM
+  3.6 IR encoded as bitcode and is the format used for DirectX GPU Shader
+  programs.
+
 Changes to the Hexagon Backend
 --
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -68,6 +68,12 @@
 
   Randomizing structure layout is a C-only feature.
 
+- Experimental support for HLSL has been added. The implementation is
+  incomplete and highly experimental. For more information about the ongoing
+  work to support HLSL see the `documentation
+  `_, or the `GitHub project
+  `_.
+
 Bug Fixes
 -
 - ``CXXNewExpr::getArraySize()`` previously returned a ``llvm::Optional``
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127270: [clang-format] Add space in placement new expression

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added inline comments.



Comment at: clang/include/clang/Format/Format.h:3495
+/// \code
+///true:  false:
+///new (buf) T;vs.new(buf) T;

MyDeveloperDay wrote:
> should this be `Always/Never`
Nope, this should be removed. :)



Comment at: clang/include/clang/Format/Format.h:3559
   AfterFunctionDefinitionName(false), AfterIfMacros(false),
-  AfterOverloadedOperator(false), AfterRequiresInClause(false),
-  AfterRequiresInExpression(false), BeforeNonEmptyParentheses(false) {}
+  AfterOverloadedOperator(false), AfterPlacementOperator(APO_Always),
+  AfterRequiresInClause(false), AfterRequiresInExpression(false),

As said in the other comment, there is code that depends on setting to never in 
the default constructor, so please do.



Comment at: clang/unittests/Format/FormatTest.cpp:10142
+  verifyFormat("T *p = new (buf) T(3);", AfterPlacementOperator);
+  verifyFormat("T *p = delete (buf)T(3);", AfterPlacementOperator);
+  verifyFormat("struct A {\n"

Can this be valid code?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127270

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

[PATCH] D124093: [PowerPC] Fixing implicit castings in altivec for -fno-lax-vector-conversions

[Lei Huang via Phabricator via cfe-commits]

lei marked an inline comment as not done.
lei added inline comments.



Comment at: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat.c:8
 // RUN:   -D__XL_COMPAT_ALTIVEC__ -target-cpu pwr8 | FileCheck %s
-// RUN: %clang_cc1 -no-opaque-pointers -target-feature +altivec 
-target-feature +vsx \
+// RUN: %clang_cc1 -flax-vector-conversions=none -no-opaque-pointers 
-target-feature +altivec -target-feature +vsx \
 // RUN:   -triple powerpc64le-unknown-linux-gnu -emit-llvm %s -o - \

nemanjai wrote:
> I don't know why only one of the functions below has checks for this run 
> line, but that needs to be fixed. Please add the `NOCOMPAT` checks on the 
> other functions.
Can we address this on a followup patch? Since it's not related to the work 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124093

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

[PATCH] D127890: [Docs] Update clang & llvm release notes for HLSL

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: llvm/docs/ReleaseNotes.rst:117
+* DirectX has been added as an experimental target. Specify
+`-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=DirectX` in your CMake configuration to
+  enable it. The target is not packaged in pre-built binaries.

Fix indentation and use two backsticks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127890

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

[PATCH] D127593: [clang] Fix trivially copyable for copy constructor and copy assignment operator

[Javier Alvarez via Phabricator via cfe-commits]

Javier-varez added a comment.

I did try this locally and the built test binaries seem to crash with a 
segmentation fault. I run one of them in lldb to check the error and I got this 
backtrace:

  llvm-project/build on  fix-trivially-copyable-check [?⇕] via △ v3.22.3 took 
3s ❯ lldb 
/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp
  (lldb) target create 
"/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp"
  Current executable set to 
'/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp'
 (arm64).
  (lldb) r
  Process 61339 launched: 
'/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp'
 (arm64)
  Process 61339 stopped
  * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x10)
  frame #0: 0x000100362f54 libomp.dylib`::__kmp_get_global_thread_id() 
at kmp_runtime.cpp:201:8
 198
 199  /* dynamically updated stack window for uber threads to avoid 
get_specific
 200 call */
  -> 201  if (!TCR_4(other_threads[i]->th.th_info.ds.ds_stackgrow)) {
 202KMP_FATAL(StackOverflow, i);
 203  }
 204
  Target 0: (omp_single_copyprivate.c.tmp) stopped.
  (lldb) bt
  * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x10)
* frame #0: 0x000100362f54 libomp.dylib`::__kmp_get_global_thread_id() 
at kmp_runtime.cpp:201:8
  frame #1: 0x0001003b8c60 libomp.dylib`void 
__kmp_release_template >(flag=0x00016fdff0b8) at 
kmp_wait_release.h:790:39
  frame #2: 0x0001003b8c20 
libomp.dylib`::__kmp_release_64(flag=0x00016fdff0b8) at 
kmp_wait_release.cpp:25:46
  frame #3: 0x0001003798d0 
libomp.dylib`__kmp_reap_thread(thread=0x000101010a40, is_root=0) at 
kmp_runtime.cpp:6146:9
  frame #4: 0x00010037497c libomp.dylib`__kmp_internal_end() at 
kmp_runtime.cpp:6334:7
  frame #5: 0x0001003745ec 
libomp.dylib`::__kmp_internal_end_library(gtid_req=-1) at kmp_runtime.cpp:6498:3
  frame #6: 0x000100374258 libomp.dylib`::__kmp_internal_end_atexit() 
at kmp_runtime.cpp:6115:3
  frame #7: 0x000100374218 libomp.dylib`::__kmp_internal_end_dtor() at 
kmp_runtime.cpp:6083:3
  frame #8: 0x000189359dc4 libsystem_c.dylib`__cxa_finalize_ranges + 464
  frame #9: 0x000189359b68 libsystem_c.dylib`exit + 44
  frame #10: 0x00018947aec4 
libdyld.dylib`dyld4::LibSystemHelpers::exit(int) const + 20
  frame #11: 0x0001000150d4 dyld`start + 592
  (lldb)

Not sure how to proceed from here though... I'm really not familiar with OpenMP


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127593

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

[PATCH] D127593: [clang] Fix trivially copyable for copy constructor and copy assignment operator

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D127593#3590072 , @Javier-varez 
wrote:

> I did try this locally and the built test binaries seem to crash with a 
> segmentation fault. I run one of them in lldb to check the error and I got 
> this backtrace:
>
>   llvm-project/build on  fix-trivially-copyable-check [?⇕] via △ v3.22.3 
> took 3s ❯ lldb 
> /Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp
>   (lldb) target create 
> "/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp"
>   Current executable set to 
> '/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp'
>  (arm64).
>   (lldb) r
>   Process 61339 launched: 
> '/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp'
>  (arm64)
>   Process 61339 stopped
>   * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=1, address=0x10)
>   frame #0: 0x000100362f54 
> libomp.dylib`::__kmp_get_global_thread_id() at kmp_runtime.cpp:201:8
>  198
>  199/* dynamically updated stack window for uber threads to avoid 
> get_specific
>  200   call */
>   -> 201if (!TCR_4(other_threads[i]->th.th_info.ds.ds_stackgrow)) {
>  202  KMP_FATAL(StackOverflow, i);
>  203}
>  204
>   Target 0: (omp_single_copyprivate.c.tmp) stopped.
>   (lldb) bt
>   * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=1, address=0x10)
> * frame #0: 0x000100362f54 
> libomp.dylib`::__kmp_get_global_thread_id() at kmp_runtime.cpp:201:8
>   frame #1: 0x0001003b8c60 libomp.dylib`void 
> __kmp_release_template >(flag=0x00016fdff0b8) at 
> kmp_wait_release.h:790:39
>   frame #2: 0x0001003b8c20 
> libomp.dylib`::__kmp_release_64(flag=0x00016fdff0b8) at 
> kmp_wait_release.cpp:25:46
>   frame #3: 0x0001003798d0 
> libomp.dylib`__kmp_reap_thread(thread=0x000101010a40, is_root=0) at 
> kmp_runtime.cpp:6146:9
>   frame #4: 0x00010037497c libomp.dylib`__kmp_internal_end() at 
> kmp_runtime.cpp:6334:7
>   frame #5: 0x0001003745ec 
> libomp.dylib`::__kmp_internal_end_library(gtid_req=-1) at 
> kmp_runtime.cpp:6498:3
>   frame #6: 0x000100374258 libomp.dylib`::__kmp_internal_end_atexit() 
> at kmp_runtime.cpp:6115:3
>   frame #7: 0x000100374218 libomp.dylib`::__kmp_internal_end_dtor() 
> at kmp_runtime.cpp:6083:3
>   frame #8: 0x000189359dc4 libsystem_c.dylib`__cxa_finalize_ranges + 
> 464
>   frame #9: 0x000189359b68 libsystem_c.dylib`exit + 44
>   frame #10: 0x00018947aec4 
> libdyld.dylib`dyld4::LibSystemHelpers::exit(int) const + 20
>   frame #11: 0x0001000150d4 dyld`start + 592
>   (lldb)
>
> Not sure how to proceed from here though... I'm really not familiar with 
> OpenMP

If you remove your patch, does the OMP failure still happen?  Or does this 
patch cause it?  If so, you might find that you need to see the difference 
between the two generated executables and see if something obvious has changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127593

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

[PATCH] D127860: [msan] Allow KMSAN to use -fsanitize-memory-param-retval

[Alexander Potapenko via Phabricator via cfe-commits]

glider updated this revision to Diff 437678.
glider added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127860

Files:
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/CodeGen/kmsan-param-retval.c
  clang/test/Driver/fsanitize-memory-param-retval.c


Index: clang/test/Driver/fsanitize-memory-param-retval.c
===
--- clang/test/Driver/fsanitize-memory-param-retval.c
+++ clang/test/Driver/fsanitize-memory-param-retval.c
@@ -3,6 +3,8 @@
 // RUN: %clang -target aarch64-linux-gnu %s -fsanitize=memory 
-fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
 // RUN: %clang -target riscv32-linux-gnu %s -fsanitize=memory 
-fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
 // RUN: %clang -target riscv64-linux-gnu %s -fsanitize=memory 
-fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
+// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=kernel-memory 
-fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
+
 // CHECK: "-fsanitize-memory-param-retval"
 
 // RUN: %clang -target aarch64-linux-gnu -fsyntax-only %s -fsanitize=memory 
-fsanitize-memory-param-retval -c -### 2>&1 | FileCheck --check-prefix=11 %s
Index: clang/test/CodeGen/kmsan-param-retval.c
===
--- /dev/null
+++ clang/test/CodeGen/kmsan-param-retval.c
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -S -emit-llvm -O2 
-fsanitize=kernel-memory -no-enable-noundef-analysis -o - %s | \
+// RUN: FileCheck %s --check-prefix=CLEAN
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -S -emit-llvm -O2 
-fsanitize=kernel-memory -o - %s | \
+// RUN: FileCheck %s --check-prefixes=NOUNDEF,NOUNDEF_ONLY
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -S -emit-llvm -O2 
-fsanitize=kernel-memory -mllvm -msan-eager-checks -o - %s | \
+// RUN: FileCheck %s --check-prefixes=NOUNDEF,EAGER
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -S -emit-llvm -O2 
-fsanitize=kernel-memory -no-enable-noundef-analysis 
-fsanitize-memory-param-retval -o - %s | \
+// RUN: FileCheck %s --check-prefixes=CLEAN
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -S -emit-llvm -O2 
-fsanitize=kernel-memory -fsanitize-memory-param-retval -o - %s | \
+// RUN: FileCheck %s --check-prefixes=NOUNDEF,EAGER
+
+void foo();
+
+void bar(int x) {
+  if (x)
+foo();
+}
+
+
+// CLEAN:   define dso_local void @bar(i32 %x)
+// NOUNDEF: define dso_local void @bar(i32 noundef %x)
+//
+// %param_shadow assignment gets optimized away with -O2, because it is at the 
beginning of the
+// struct returned by __msan_get_context_state(). Use %param_origin as a sign 
that the shadow of
+// the first argument is being used.
+//
+// Without noundef analysis, KMSAN emits metadata checks for the function 
parameter.
+// CLEAN:load i32, ptr %param_origin
+//
+// With noundef analysis enabled, but without eager checks, KMSAN still emits 
metadata checks,
+// although the parameter is known to be defined.
+// NOUNDEF_ONLY: load i32, ptr %param_origin
+//
+// With noundef analysis and eager checks enabled, KMSAN won't emit metadata 
checks for function
+// parameters.
+// EAGER-NOT:load i32, ptr %param_origin
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -648,6 +648,11 @@
 options::OPT_fno_sanitize_memory_param_retval, MsanParamRetval);
 NeedPIE |= !(TC.getTriple().isOSLinux() &&
  TC.getTriple().getArch() == llvm::Triple::x86_64);
+  } else if (AllAddedKinds & SanitizerKind::KernelMemory) {
+MsanUseAfterDtor = false;
+MsanParamRetval = Args.hasFlag(
+options::OPT_fsanitize_memory_param_retval,
+options::OPT_fno_sanitize_memory_param_retval, MsanParamRetval);
   } else {
 MsanUseAfterDtor = false;
 MsanParamRetval = false;


Index: clang/test/Driver/fsanitize-memory-param-retval.c
===
--- clang/test/Driver/fsanitize-memory-param-retval.c
+++ clang/test/Driver/fsanitize-memory-param-retval.c
@@ -3,6 +3,8 @@
 // RUN: %clang -target aarch64-linux-gnu %s -fsanitize=memory -fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
 // RUN: %clang -target riscv32-linux-gnu %s -fsanitize=memory -fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
 // RUN: %clang -target riscv64-linux-gnu %s -fsanitize=memory -fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
+// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=kernel-memory -fsanitize-memory-param-retval -c -### 2>&1 | FileCheck %s
+
 // CHECK: "-fsanitize-memory-param-retval"
 
 // RUN: %clang -target aarch64-linux-gnu -fsyntax-only %s -fsanitize=memory -fsanitize-memory-param-retval -c -### 2>&1 | FileCheck --check-prefi

[PATCH] D127259: [CodeGen] guarantee templated static variables are initialized in the reverse instantiation order

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a subscriber: aaron.ballman.
rnk added a comment.

I think Richard had some concerns in the other review that this may not be 
enough to really guarantee initialization order within the TU. I couldn't say 
either way, I shouldn't review this code. Conceptually, this change seems small 
enough to me. Can we ask @aaron.ballman to take a look?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127259

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

[PATCH] D127593: [clang] Fix trivially copyable for copy constructor and copy assignment operator

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson added a comment.

I started to get those errors on D126194  as 
well, definitely annoying.

They both do spooky things with type triviality so maybe this is somehow 
related? I'm not sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127593

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

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via Phabricator via cfe-commits]

mingmingl updated this revision to Diff 437691.
mingmingl marked an inline comment as done.
mingmingl added a comment.

In clang/test/Preprocessor/aarch64-target-features.c, move `__ARM_FEATURE_RCPC` 
to keep the alphabetical list, and use `-target=aarch64..` (the join style) 
rather than legacy while-space separated style (key value).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127798

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/test/Preprocessor/aarch64-target-features.c


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -26,6 +26,7 @@
 // CHECK: __ARM_FEATURE_IDIV 1
 // CHECK: __ARM_FEATURE_LDREX 0xF
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_SHA2 1
 // CHECK-NOT: __ARM_FEATURE_SHA3 1
 // CHECK-NOT: __ARM_FEATURE_SHA512 1
@@ -561,3 +562,6 @@
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_COMPLEX 1
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_JCVT 1
 // CHECK-BEFORE-V85-NOT: __ARM_FEATURE_FRINT 1
+
+// RUN: %clang -target=aarch64-none-linux-gnu -march=armv8.2-a+rcpc -x c -E 
-dM %s -o - | FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1
Index: clang/lib/Basic/Targets/AArch64.h
===
--- clang/lib/Basic/Targets/AArch64.h
+++ clang/lib/Basic/Targets/AArch64.h
@@ -54,6 +54,7 @@
   bool HasLSE;
   bool HasFlagM;
   bool HasMOPS;
+  bool HasRCPC;
 
   llvm::AArch64::ArchKind ArchKind;
 
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -341,6 +341,9 @@
   if (HasCRC)
 Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
 
+  if (HasRCPC)
+Builder.defineMacro("__ARM_FEATURE_RCPC", "1");
+
   // The __ARM_FEATURE_CRYPTO is deprecated in favor of finer grained feature
   // macros for AES, SHA2, SHA3 and SM4
   if (HasAES && HasSHA2)
@@ -544,6 +547,7 @@
   HasMatmulFP32 = false;
   HasLSE = false;
   HasMOPS = false;
+  HasRCPC = false;
 
   ArchKind = llvm::AArch64::ArchKind::INVALID;
 
@@ -593,6 +597,8 @@
 }
 if (Feature == "+crc")
   HasCRC = true;
+if (Feature == "+rcpc")
+  HasRCPC = true;
 if (Feature == "+aes")
   HasAES = true;
 if (Feature == "+sha2")


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -26,6 +26,7 @@
 // CHECK: __ARM_FEATURE_IDIV 1
 // CHECK: __ARM_FEATURE_LDREX 0xF
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_SHA2 1
 // CHECK-NOT: __ARM_FEATURE_SHA3 1
 // CHECK-NOT: __ARM_FEATURE_SHA512 1
@@ -561,3 +562,6 @@
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_COMPLEX 1
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_JCVT 1
 // CHECK-BEFORE-V85-NOT: __ARM_FEATURE_FRINT 1
+
+// RUN: %clang -target=aarch64-none-linux-gnu -march=armv8.2-a+rcpc -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1
Index: clang/lib/Basic/Targets/AArch64.h
===
--- clang/lib/Basic/Targets/AArch64.h
+++ clang/lib/Basic/Targets/AArch64.h
@@ -54,6 +54,7 @@
   bool HasLSE;
   bool HasFlagM;
   bool HasMOPS;
+  bool HasRCPC;
 
   llvm::AArch64::ArchKind ArchKind;
 
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -341,6 +341,9 @@
   if (HasCRC)
 Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
 
+  if (HasRCPC)
+Builder.defineMacro("__ARM_FEATURE_RCPC", "1");
+
   // The __ARM_FEATURE_CRYPTO is deprecated in favor of finer grained feature
   // macros for AES, SHA2, SHA3 and SM4
   if (HasAES && HasSHA2)
@@ -544,6 +547,7 @@
   HasMatmulFP32 = false;
   HasLSE = false;
   HasMOPS = false;
+  HasRCPC = false;
 
   ArchKind = llvm::AArch64::ArchKind::INVALID;
 
@@ -593,6 +597,8 @@
 }
 if (Feature == "+crc")
   HasCRC = true;
+if (Feature == "+rcpc")
+  HasRCPC = true;
 if (Feature == "+aes")
   HasAES = true;
 if (Feature == "+sha2")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via Phabricator via cfe-commits]

mingmingl marked an inline comment as done.
mingmingl added inline comments.



Comment at: clang/test/Preprocessor/aarch64-target-features.c:22
 // CHECK-NOT: __ARM_FEATURE_CRC32 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_CRYPTO 1

MaskRay wrote:
> The list is alphabetical. RCPC should be moved below.
good catch. done.



Comment at: clang/test/Preprocessor/aarch64-target-features.c:566
+
+// RUN: %clang -target aarch64-none-linux-gnu -march=armv8.2-a+rcpc -x c -E 
-dM %s -o - | FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1

MaskRay wrote:
> `--target=aarch64`
done. thanks for pointing this out!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127798

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