[PATCH] D112720: [clang-tidy] Use globs in HeaderFilter

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

So after some thoughts, I came up with the following plan:

- This patch adds: `HeaderFilter`, `HeaderFilterMode`. `HeaderFilter` is 
intended to replace `HeaderFilterRegex` and we inform that `HeaderFilterRegex` 
is deprecated and will be removed in 2 releases. However during the transition 
period, both `HeaderFilter` and `HeaderFilterRegex` are accepted. 
`HeaderFilterMode` can take values: `regex` (default) or `glob`, and describes 
the behavior of `HeaderFilter` or `HeaderFilterRegex`. This allows people to 
use globs, while not breaking existing functionality.

- After 2 releases, we remove `HeaderFilterRegex` and set `HeaderFilterMode` as 
default to `glob`. We communicate that `HeaderFilterMode` is deprecated and 
will be removed in 2 releases.

- After (another) 2 releases, we remove `HeaderFilterMode`. The result is then 
what this patch looks like it is right now. Do we need to wait 2 more releases 
to remove `HeaderFilterMode` or can we do it already in the above step?

Does that sound good? Looking forward to your feedback.


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

https://reviews.llvm.org/D112720

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

[PATCH] D109215: [RISCV] Fix arch string parsing for multi-character extensions

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 383732.
eopXD added a comment.

rebase.`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109215

Files:
  clang/test/Driver/riscv-arch.c
  llvm/lib/Support/RISCVISAInfo.cpp


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -71,6 +71,28 @@
   return Ext.consume_front("experimental-");
 }
 
+// This function finds the first character that doesn't belong to a version
+// (e.g. zbe0p93 is extension 'zbe' of version '0p93'). So the function will
+// consume [0-9]*p[0-9]* starting from the backward. An extension name will not
+// end with a digit or the letter 'p', so this function will parse correctly.
+// NOTE: This function is NOT able to take empty strings or strings that only
+// have version numbers and no extension name. It assumes the extension name
+// will be at least more than one character.
+static size_t findFirstNonVersionCharacter(const StringRef &Ext) {
+  if (Ext.size() == 0)
+llvm_unreachable("Already guarded by if-statement in ::parseArchString");
+
+  int Pos = Ext.size() - 1;
+  while (Pos > 0 && isDigit(Ext[Pos]))
+Pos--;
+  if (Pos > 0 && Ext[Pos] == 'p' && isDigit(Ext[Pos - 1])) {
+Pos--;
+while (Pos > 0 && isDigit(Ext[Pos]))
+  Pos--;
+  }
+  return Pos;
+}
+
 struct FindByName {
   FindByName(StringRef Ext) : Ext(Ext){};
   StringRef Ext;
@@ -637,7 +659,7 @@
 
 StringRef Type = getExtensionType(Ext);
 StringRef Desc = getExtensionTypeDesc(Ext);
-auto Pos = Ext.find_if(isDigit);
+size_t Pos = findFirstNonVersionCharacter(Ext) + 1;
 StringRef Name(Ext.substr(0, Pos));
 StringRef Vers(Ext.substr(Pos));
 
Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,7 +392,7 @@
 
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0zbp0p93 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE %s
-// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 
'rv32izbb1p0zbp0p93', multi-character extensions must be separated by 
underscores
+// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 
'rv32izbb1p0zbp0p93', unsupported version number 0.93 for extension 'zbb1p0zbp'
 
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izba1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-ZBA %s


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -71,6 +71,28 @@
   return Ext.consume_front("experimental-");
 }
 
+// This function finds the first character that doesn't belong to a version
+// (e.g. zbe0p93 is extension 'zbe' of version '0p93'). So the function will
+// consume [0-9]*p[0-9]* starting from the backward. An extension name will not
+// end with a digit or the letter 'p', so this function will parse correctly.
+// NOTE: This function is NOT able to take empty strings or strings that only
+// have version numbers and no extension name. It assumes the extension name
+// will be at least more than one character.
+static size_t findFirstNonVersionCharacter(const StringRef &Ext) {
+  if (Ext.size() == 0)
+llvm_unreachable("Already guarded by if-statement in ::parseArchString");
+
+  int Pos = Ext.size() - 1;
+  while (Pos > 0 && isDigit(Ext[Pos]))
+Pos--;
+  if (Pos > 0 && Ext[Pos] == 'p' && isDigit(Ext[Pos - 1])) {
+Pos--;
+while (Pos > 0 && isDigit(Ext[Pos]))
+  Pos--;
+  }
+  return Pos;
+}
+
 struct FindByName {
   FindByName(StringRef Ext) : Ext(Ext){};
   StringRef Ext;
@@ -637,7 +659,7 @@
 
 StringRef Type = getExtensionType(Ext);
 StringRef Desc = getExtensionTypeDesc(Ext);
-auto Pos = Ext.find_if(isDigit);
+size_t Pos = findFirstNonVersionCharacter(Ext) + 1;
 StringRef Name(Ext.substr(0, Pos));
 StringRef Vers(Ext.substr(Pos));
 
Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,7 +392,7 @@
 
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0zbp0p93 -menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE %s
-// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 'rv32izbb1p0zbp0p93', multi-character extensions must be separated by underscores
+// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 'rv32izbb1p0zbp0p93', unsupported version number 0.93 for extension 'zbb1

[PATCH] D112088: [clang][deps] Keep #pragma push_macro, pop_macro and include_alias when minimizing source code.

[Jan Svoboda via Phabricator via cfe-commits]

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

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112088

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

[PATCH] D112359: [RISCV] Unify depedency check and extension implication parsing logics

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 383733.
eopXD added a comment.

rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112359

Files:
  clang/test/CodeGen/RISCV/riscv-metadata.c
  clang/test/CodeGen/RISCV/riscv32-ilp32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64-lp64f-lp64d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64f-lp64d-abi.c
  clang/test/CodeGen/riscv32-ilp32d-abi.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/test/MC/RISCV/attribute-arch.s

Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -33,44 +33,41 @@
 .attribute arch, "rv32ima2p0_fdc"
 # CHECK: attribute  5, "rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
-.attribute arch, "rv32iv"
+.attribute arch, "rv32iv0p10"
 # CHECK: attribute  5, "rv32i2p0_v0p10_zvlsseg0p10"
 
-.attribute arch, "rv32izba"
+.attribute arch, "rv32izba1p0"
 # CHECK: attribute  5, "rv32i2p0_zba1p0"
 
-.attribute arch, "rv32izbb"
+.attribute arch, "rv32izbb1p0"
 # CHECK: attribute  5, "rv32i2p0_zbb1p0"
 
-.attribute arch, "rv32izbc"
+.attribute arch, "rv32izbc1p0"
 # CHECK: attribute  5, "rv32i2p0_zbc1p0"
 
-.attribute arch, "rv32izbe"
+.attribute arch, "rv32izbe0p93"
 # CHECK: attribute  5, "rv32i2p0_zbe0p93"
 
-.attribute arch, "rv32izbf"
+.attribute arch, "rv32izbf0p93"
 # CHECK: attribute  5, "rv32i2p0_zbf0p93"
 
-.attribute arch, "rv32izbm"
+.attribute arch, "rv32izbm0p93"
 # CHECK: attribute  5, "rv32i2p0_zbm0p93"
 
-.attribute arch, "rv32izbp"
+.attribute arch, "rv32izbp0p93"
 # CHECK: attribute  5, "rv32i2p0_zbp0p93"
 
-.attribute arch, "rv32izbr"
+.attribute arch, "rv32izbr0p93"
 # CHECK: attribute  5, "rv32i2p0_zbr0p93"
 
-.attribute arch, "rv32izbs"
+.attribute arch, "rv32izbs1p0"
 # CHECK: attribute  5, "rv32i2p0_zbs1p0"
 
-.attribute arch, "rv32izbt"
+.attribute arch, "rv32izbt0p93"
 # CHECK: attribute  5, "rv32i2p0_zbt0p93"
 
-.attribute arch, "rv32ifzfh"
+.attribute arch, "rv32ifzfh0p1"
 # CHECK: attribute  5, "rv32i2p0_f2p0_zfh0p1"
 
-.attribute arch, "rv32ivzvamo_zvlsseg"
-# CHECK: attribute  5, "rv32i2p0_v0p10_zvamo0p10_zvlsseg0p10"
-
-.attribute arch, "rv32iv_zvamo0p10_zvlsseg"
+.attribute arch, "rv32iv0p10zvamo0p10_zvlsseg0p10"
 # CHECK: attribute  5, "rv32i2p0_v0p10_zvamo0p10_zvlsseg0p10"
Index: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
===
--- llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -2062,7 +2062,11 @@
 "unexpected token in '.attribute' directive"))
 return true;
 
-  if (Tag == RISCVAttrs::ARCH) {
+  if (IsIntegerValue)
+getTargetStreamer().emitAttribute(Tag, IntegerValue);
+  else if (Tag != RISCVAttrs::ARCH)
+getTargetStreamer().emitTextAttribute(Tag, StringValue);
+  else {
 StringRef Arch = StringValue;
 for (auto Feature : RISCVFeatureKV)
   if (llvm::RISCVISAInfo::isSupportedExtensionFeature(Feature.Key))
@@ -2070,7 +2074,7 @@
 
 auto ParseResult = llvm::RISCVISAInfo::parseArchString(
 StringValue, /*EnableExperimentalExtension=*/true,
-/*ExperimentalExtensionVersionCheck=*/false);
+/*ExperimentalExtensionVersionCheck=*/true);
 if (!ParseResult) {
   std::string Buffer;
   raw_string_ostream OutputErrMsg(Buffer);
@@ -2093,35 +2097,9 @@
   setFeatureBits(RISCV::Feature64Bit, "64bit");
 else
   return Error(ValueExprLoc, "bad arch string " + Arch);
-  }
 
-  if (IsIntegerValue)
-getTargetStreamer().emitAttribute(Tag, IntegerValue);
-  else {
-if (Tag != RISCVAttrs::ARCH) {
-  getTargetStreamer().emitTextAttribute(Tag, StringValue);
-} else {
-  std::vector FeatureVector;
-  RISCVFeatures::toFeatureVector(FeatureVector, getSTI().getFeatureBits());
-
-  // Parse that by RISCVISAInfo->
-  unsigned XLen = getFeatureBits(RISCV::Feature64Bit) ? 64 : 32;
-  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeatureVector);
-  if (!ParseResult) {
-std::string Buffer;
-raw_string_ostream OutputErrMsg(Buffer);
-handleAllErrors(ParseResult.takeError(),
-[&](llvm::StringError &ErrMsg) {
-  OutputErrMsg << ErrMsg.getMessage();
-});
-
-return Error(ValueExprLoc, OutputErrMsg.str());
-  }
-  auto &ISAInfo = *ParseResult;
-
-  // Then emit the arch string.
-  getTargetStreamer().emitTextAttribute(Tag, ISAInfo->toString());
- 

[PATCH] D95168: [clang-format] Add InsertBraces option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 383744.
MyDeveloperDay added a reviewer: HazardyKnusperkeks.
MyDeveloperDay added a comment.

I'd like to carry the mantle for this, before making any further changes I'd 
like to address some of the review comments

1. Add documentation warning about a modifying change (as agreed by the RFC)
2. Add version introduced information
3. Fix issue with Macro continuation (don't add the \n before the } unless you 
see a \\ line comment, otherwise let clang-format deal with the \n depending on 
the BraceWrapping style
4. Add unit tests for Macro continuation and Comment handling
5. Allow InsertBraces in other languages

TODO:

- break out into its own file (Format.cpp is getting too big)
- Look further into possible Removal (I have an idea for how this might be 
possible, and super useful for LLVM where we don't like single if {} ), I'd 
like to round out on this before introducing the options rather than having to 
change them later

- Should we add the possibility of removal should we change the option name to 
"AutomaticBraces" (thoughts?)
- @tiagoma please add your name and email addreess to this review so when the 
time comes to land this I can attribute to you as "Author".


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

https://reviews.llvm.org/D95168

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -72,7 +72,10 @@
 EXPECT_EQ(Expected.str(), format(Expected, Style))
 << "Expected code is not stable";
 EXPECT_EQ(Expected.str(), format(Code, Style));
-if (Style.Language == FormatStyle::LK_Cpp) {
+// clang::format::internal::reformat does not run any of the options that
+// modify code for ObjC
+if (Style.Language == FormatStyle::LK_Cpp &&
+Style.InsertBraces == FormatStyle::BIS_Never) {
   // Objective-C++ is a superset of C++, so everything checked for C++
   // needs to be checked for Objective-C++ as well.
   FormatStyle ObjCStyle = Style;
@@ -18758,6 +18761,12 @@
   CHECK_PARSE("IndentExternBlock: false", IndentExternBlock,
   FormatStyle::IEBS_NoIndent);
 
+  Style.InsertBraces = FormatStyle::BIS_Never;
+  CHECK_PARSE("InsertBraces: Always", InsertBraces, FormatStyle::BIS_Always);
+  CHECK_PARSE("InsertBraces: WrapLikely", InsertBraces,
+  FormatStyle::BIS_WrapLikely);
+  CHECK_PARSE("InsertBraces: Never", InsertBraces, FormatStyle::BIS_Never);
+
   Style.BitFieldColonSpacing = FormatStyle::BFCS_None;
   CHECK_PARSE("BitFieldColonSpacing: Both", BitFieldColonSpacing,
   FormatStyle::BFCS_Both);
@@ -22397,6 +22406,271 @@
   EXPECT_EQ(Code, format(Code, Style));
 }
 
+TEST_F(FormatTest, InsertBraces) {
+  FormatStyle Style = getLLVMStyle();
+
+  StringRef IfSourceShort = "if (condition)\n"
+"  call_function(arg, arg);";
+  verifyFormat(IfSourceShort);
+
+  StringRef IfSourceLong = "if (condition)\n"
+   "  call_function(arg, arg, arg, arg, arg, arg);";
+  verifyFormat(IfSourceLong);
+
+  StringRef IfElseSourceShort = "if (condition)\n"
+"  a_function(arg, arg);\n"
+"else\n"
+"  another_function(arg, arg);";
+  verifyFormat(IfElseSourceShort);
+
+  StringRef IfElseSourceLong =
+  "if (condition)\n"
+  "  a_function(arg, arg, arg, arg, arg, arg);\n"
+  "else\n"
+  "  another_function(arg, arg, arg, arg, arg, arg);";
+  verifyFormat(IfElseSourceLong);
+
+  StringRef ForSourceShort = "for (auto val : container)\n"
+ "  call_function(arg, arg);";
+  verifyFormat(ForSourceShort);
+
+  StringRef ForSourceLong = "for (auto val : container)\n"
+"  call_function(arg, arg, arg, arg, arg, arg);";
+  verifyFormat(ForSourceLong);
+
+  StringRef WhileShort = "while (condition)\n"
+ "  call_function(arg, arg);";
+  verifyFormat(WhileShort);
+
+  StringRef WhileLong = "while (condition)\n"
+"  call_function(arg, arg, arg, arg, arg, arg);";
+  verifyFormat(WhileLong);
+
+  StringRef DoShort = "do\n"
+  "  call_function(arg, arg);\n"
+  "while (condition);";
+  verifyFormat(DoShort);
+
+  StringRef DoLong = "do\n"
+ "  call_function(arg, arg, arg, arg, arg, arg);\n"
+ "while (condition);";
+  verifyFormat(DoLong);
+
+  StringRef ChainedConditionals = "if (A)\n"
+  "  if (B)\n"
+  "callAB();\n"
+  "  else\n"
+

[PATCH] D112913: Misleading bidirectional detection

[serge via Phabricator via cfe-commits]

serge-sans-paille created this revision.
Herald added subscribers: carlosgalvezp, mgorny.
serge-sans-paille requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

This patch implements detection of incomplete bidirectional sequence withing 
comments and string literals within clang-tidy.

It detects the bidi part of https://www.trojansource.codes/trojan-source.pdf


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112913

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/clang-tidy/misc/MisleadingBidirectional.cpp
  clang-tools-extra/clang-tidy/misc/MisleadingBidirectional.h
  clang-tools-extra/test/clang-tidy/check_clang_tidy.py
  clang-tools-extra/test/clang-tidy/checkers/misc-misleading-bidirectional.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-misleading-bidirectional.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-misleading-bidirectional.cpp
@@ -0,0 +1,9 @@
+// RUN: %check_clang_tidy %s misc-misleading-bidirectional %t
+
+void func(void) {
+  int admin = 0;
+  /*‮ }⁦if(admin)⁩ ⁦ begin*/
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: comment contains misleading bidirectional Unicode characters [misc-misleading-bidirectional]
+  const char msg[] = "‮⁦if(admin)⁩ ⁦tes";
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: string literal contains misleading bidirectional Unicode characters [misc-misleading-bidirectional]
+}
Index: clang-tools-extra/test/clang-tidy/check_clang_tidy.py
===
--- clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -34,7 +34,7 @@
 
 
 def write_file(file_name, text):
-  with open(file_name, 'w') as f:
+  with open(file_name, 'w', encoding="utf-8") as f:
 f.write(text)
 f.truncate()
 
@@ -82,7 +82,7 @@
   if resource_dir is not None:
 clang_extra_args.append('-resource-dir=%s' % resource_dir)
 
-  with open(input_file_name, 'r') as input_file:
+  with open(input_file_name, 'r', encoding="utf-8") as input_file:
 input_text = input_file.read()
 
   check_fixes_prefixes = []
Index: clang-tools-extra/clang-tidy/misc/MisleadingBidirectional.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/misc/MisleadingBidirectional.h
@@ -0,0 +1,38 @@
+//===--- MisleadingBidirectionalCheck.h - clang-tidy *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGBIDIRECTIONALCHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGBIDIRECTIONALCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+class MisleadingBidirectionalCheck : public ClangTidyCheck {
+public:
+  MisleadingBidirectionalCheck(StringRef Name, ClangTidyContext *Context);
+  ~MisleadingBidirectionalCheck();
+
+  void registerPPCallbacks(const SourceManager &SM, Preprocessor *PP,
+   Preprocessor *ModuleExpanderPP) override;
+
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+
+private:
+  class MisleadingBidirectionalHandler;
+  std::unique_ptr Handler;
+};
+
+} // namespace misc
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGBIDIRECTIONALCHECK_H
Index: clang-tools-extra/clang-tidy/misc/MisleadingBidirectional.cpp
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/misc/MisleadingBidirectional.cpp
@@ -0,0 +1,132 @@
+//===--- MisleadingBidirectional.cpp - clang-tidy ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "MisleadingBidirectional.h"
+
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/Preprocessor.h"
+#include "llvm/Support/ConvertUTF.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+static bool ContainsMisleadingBidi(StringRef Buffer, bool HonorLineBreaks=true) {
+  const char* CurPtr = Buffer.begin();
+  unsigned EmbeddingOverride = 0, Isolate = 0;
+  unsigned i = 0;
+
+  enum {
+LS = 0x2028,
+  

[PATCH] D112401: [Clang] Mutate printf bulitin names under IEEE128 on PPC64

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:100
+  static SmallDenseMap F128Builtins{
+  {Builtin::BI__builtin_printf, "__printfieee128"},
+  {Builtin::BI__builtin_vsnprintf, "__vsnprintfieee128"},

jsji wrote:
> Why only these printf builtins? I think there are full list of similar 
> libcalls in `GLIBC_2.32` and later?
Yes, Glibc redirects all these functions depending on long double semantics, 
and GCC has corresponding builtins for almost all library functions 
(https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html).

But currently clang doesn't have all of these builtins (for example, 
`__builtin_scanf`). It seems beyond this patch's scope to make the list 
complete.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:117
+if (getTriple().isPPC64() &&
+&getTarget().getLongDoubleFormat() == &llvm::APFloat::IEEEquad() &&
+F128Builtins.find(BuiltinID) != F128Builtins.end())

jsji wrote:
> How do we deal with the glibc version? Do we assume that user has glibc newer 
> than GLIBC_2.32?
I notice not all libcall symbols are implemented in compiler-rt, which means we 
don't need to always expect all libcalls emitted are available in current libc?

It's surprising that libc version are not checked in clang/driver/toolchain 
part. The only place checking libc version is in 
[sanitizer](https://github.com/llvm/llvm-project/blob/81441cf44c145e1d90a10c743e0190a44fbf8fcb/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L170).
 Maybe we can use that to emit warnings, like D112906.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:119
+F128Builtins.find(BuiltinID) != F128Builtins.end())
+  Name = F128Builtins[BuiltinID];
+else

jsji wrote:
> Do we have to do it here? Can we just update the libcall names in 
> `RuntimeLibcalls.def` or `setLibcallName` similar to others?
I think we cannot fill these calls in backend's runtime libcall list, because 
it contains supplementary routine names for legalizing IR 
instruction/intrinsics. Here the builtins are just converted into normal 
function calls in IR.


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

https://reviews.llvm.org/D112401

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

[PATCH] D112914: Misleading identifier detection

[serge via Phabricator via cfe-commits]

serge-sans-paille created this revision.
Herald added subscribers: carlosgalvezp, mgorny.
serge-sans-paille requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Detect identifiers with right-to-left ordering through clang-tidy.
It detects a class of attack similar to the ones described in 
https://www.trojansource.codes/trojan-source.pdf


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112914

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.cpp
  clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.h
  clang-tools-extra/test/clang-tidy/checkers/misc-misleading-identifier.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-misleading-identifier.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-misleading-identifier.cpp
@@ -0,0 +1,15 @@
+// RUN: %check_clang_tidy %s misc-misleading-identifier %t
+
+#include 
+
+// CHECK-MESSAGES: :[[@LINE+1]]:1: warning: identifier has right-to-left codepoints
+short int א = (short int)0;
+// CHECK-MESSAGES: :[[@LINE+1]]:1: warning: identifier has right-to-left codepoints
+short int ג = (short int)12345;
+
+int main() {
+  // CHECK-MESSAGES: :[[@LINE+1]]:5: warning: identifier has right-to-left codepoints
+  int א = ג; // a local variable, set to zero?
+  printf("ג is %d\n", ג);
+  printf("א is %d\n", א);
+}
Index: clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.h
@@ -0,0 +1,32 @@
+//===--- MisleadingIdentifierCheck.h - clang-tidy *- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGIDENTIFIERCHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGIDENTIFIERCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+class MisleadingIdentifierCheck : public ClangTidyCheck {
+public:
+  MisleadingIdentifierCheck(StringRef Name, ClangTidyContext *Context);
+  ~MisleadingIdentifierCheck();
+
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+};
+
+} // namespace misc
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGIDENTIFIERCHECK_H
Index: clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.cpp
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.cpp
@@ -0,0 +1,164 @@
+//===--- MisleadingIdentifier.cpp - clang-tidy
+//===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "MisleadingIdentifier.h"
+
+#include "clang/Frontend/CompilerInstance.h"
+#include "llvm/Support/ConvertUTF.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+// see https://www.unicode.org/Public/14.0.0/ucd/extracted/DerivedBidiClass.txt
+static bool isUnassignedAL(llvm::UTF32 CP) {
+  return (0x0600 <= CP && CP <= 0x07BF) || (0x0860 <= CP && CP <= 0x08FF) ||
+ (0xFB50 <= CP && CP <= 0xFDCF) || (0xFDF0 <= CP && CP <= 0xFDFF) ||
+ (0xFE70 <= CP && CP <= 0xFEFF) ||
+ (0x00010D00 <= CP && CP <= 0x00010D3F) ||
+ (0x00010F30 <= CP && CP <= 0x00010F6F) ||
+ (0x0001EC70 <= CP && CP <= 0x0001ECBF) ||
+ (0x0001ED00 <= CP && CP <= 0x0001ED4F) ||
+ (0x0001EE00 <= CP && CP <= 0x0001EEFF);
+}
+
+// see https://www.unicode.org/Public/14.0.0/ucd/extracted/DerivedBidiClass.txt
+static bool isUnassignedR(llvm::UTF32 CP) {
+  return (0x0590 <= CP && CP <= 0x05FF) || (0x07C0 <= CP && CP <= 0x085F) ||
+ (0xFB1D <= CP && CP <= 0xFB4F) ||
+ (0x00010800 <= CP && CP <= 0x00010CFF) ||
+ (0x00010D40 <= CP && CP <= 0x00010F2F) ||
+ (0x00010F70 <= CP && CP <= 0x00010FFF) ||
+ (0x0001E800 <= CP && CP <= 0x0001EC6F) ||
+ (0x0001ECC0 <= CP && CP <= 0x0001ECFF) ||
+ (0x0001ED50 <= CP && CP <= 0x0001EDFF) ||
+ (0x0001EF00 <= CP && CP <= 0x0001EFFF);
+}
+
+// see https://www.unicode.org/Public/14.0.0/ucd/extracted/DerivedBidiClass.txt
+static bool isR(llvm::UTF32 CP) {
+  return (CP == 0x0590) || (CP ==

[PATCH] D112915: WIP: [clang][modules] Granular tracking of includes

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith, vsapsai, rsmith.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When building a module consisting of submodules, the preprocessor keeps a 
"global" state that for each header file (`HeaderFileInfo`) tracks (amongst 
other things) the number of times it was included/imported. This information is 
serialized into the PCM file.

When importing such module (either the top-level module or any of its 
submodules), this number is merged into the state of the importing preprocessor.

This can incorrectly prevent imports of headers. Consider that submodule `M.A` 
imports header `H`. If a TU imports submodule `M.B` (that didn't import header 
`H`), subsequent import of header `H` in the current TU will be skipped, since 
the preprocessor thinks it already imported that header. However, submodule 
`M.B` doesn't contain the AST of header `H`, which leads to compilation errors.

This patch fixes this bug by making the number of times a header was included 
more granular and tracks it on per-submodule basis.

(This patch is an alternative approach to the same issue addressed in 
https://reviews.llvm.org/D104344.)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112915

Files:
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/Inputs/import-submodule-visibility/A.framework/Headers/A.h
  
clang/test/Modules/Inputs/import-submodule-visibility/A.framework/Modules/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/B.framework/Headers/B1.h
  clang/test/Modules/Inputs/import-submodule-visibility/B.framework/Headers/B2.h
  
clang/test/Modules/Inputs/import-submodule-visibility/B.framework/Modules/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/C/C.h
  clang/test/Modules/Inputs/import-submodule-visibility/C/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/D/D1.h
  clang/test/Modules/Inputs/import-submodule-visibility/D/D2.h
  clang/test/Modules/Inputs/import-submodule-visibility/D/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/Textual.h
  clang/test/Modules/import-submodule-visibility.c

Index: clang/test/Modules/import-submodule-visibility.c
===
--- /dev/null
+++ clang/test/Modules/import-submodule-visibility.c
@@ -0,0 +1,58 @@
+// RUN: rm -rf %t && mkdir -p %t
+
+// This test checks that imports of headers that appeared in a different submodule than
+// what is imported by the current TU don't affect the compilation.
+
+// Framework "A" includes "Textual.h" in the top-level module.
+// This test checks that simply specifying the PCM file on the command line (without actually importing "A") does not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility \
+// RUN:   -emit-module %S/Inputs/import-submodule-visibility/A.framework/Modules/module.modulemap -fmodule-name=A -o %t/A.pcm
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility -fsyntax-only %s -DA \
+// RUN:   -fmodule-file=%t/A.pcm -fmodule-map-file=%S/Inputs/import-submodule-visibility/A.framework/Modules/module.modulemap
+
+// Framework "B" includes "Textual.h" in the "B1" submodule and its "B2" submodule does not include "Textual.h" at all.
+// This test checks that specifying the PCM file on the command line and importing "B2" in the source does not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility \
+// RUN:   -emit-module %S/Inputs/import-submodule-visibility/B.framework/Modules/module.modulemap -fmodule-name=B -o %t/B.pcm
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility -fsyntax-only %s -DB -iframework %S/Inputs/import-submodule-visibility \
+// RUN:   -fmodule-file=%t/B.pcm -fmodule-map-file=%S/Inputs/import-submodule-visibility/B.framework/Modules/module.modulemap
+
+// Module "C" includes "Textual.h" in the top level module.
+// This is a module-only version of the test with framework A.
+//
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility \
+// RUN:   -emit-module %S/Inputs/import-submodule-visibility/C/module.modulemap -fmodule-name=C -o %t/C.pcm
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility -fsyntax-only %s -DC \
+// RUN:   -fmodule-file=%t/C.pcm -fmodule-map-file=%S/Inputs/import-submodule-visibility/C/module.modulemap
+
+// Module "D" incl

[PATCH] D112916: Confusable identifiers detection

[serge via Phabricator via cfe-commits]

serge-sans-paille created this revision.
Herald added subscribers: carlosgalvezp, mgrang, mgorny.
serge-sans-paille requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

This patch implements detection of confusable identifiers within clang-tidy. It 
only considers identifiers whose declaration scope may conflict with.

It detects the homoglyph part of 
https://www.trojansource.codes/trojan-source.pdf


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112916

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/ConfusableTable/build_confusable_table.cpp
  clang-tools-extra/clang-tidy/misc/ConfusableTable/confusables.txt
  clang-tools-extra/clang-tidy/misc/Homoglyph.cpp
  clang-tools-extra/clang-tidy/misc/Homoglyph.h
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/test/clang-tidy/check_clang_tidy.py
  clang-tools-extra/test/clang-tidy/checkers/misc-homoglyph.cpp

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

[PATCH] D111654: [analyzer] Retrieve a value from list initialization of multi-dimensional array declaration.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov updated this revision to Diff 383751.
ASDenysPetrov added a comment.

Changed test to fix a buildbot failure.


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

https://reviews.llvm.org/D111654

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/initialization.c
  clang/test/Analysis/initialization.cpp

Index: clang/test/Analysis/initialization.cpp
===
--- clang/test/Analysis/initialization.cpp
+++ clang/test/Analysis/initialization.cpp
@@ -14,13 +14,6 @@
   clang_analyzer_eval(sarr[i].a); // expected-warning{{UNKNOWN}}
 }
 
-int const arr[2][2] = {};
-void arr2init() {
-  int i = 1;
-  // FIXME: Should recognize that it is 0.
-  clang_analyzer_eval(arr[i][0]); // expected-warning{{UNKNOWN}}
-}
-
 int const glob_arr1[3] = {};
 void glob_array_index1() {
   clang_analyzer_eval(glob_arr1[0] == 0); // expected-warning{{TRUE}}
@@ -60,23 +53,18 @@
   return glob_arr3[0]; // no-warning (garbage or undefined)
 }
 
-// TODO: Support multidimensional array.
 int const glob_arr4[4][2] = {};
 void glob_array_index2() {
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr4[1][0] == 0); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr4[1][1] == 0); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(glob_arr4[0][0] == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr4[1][0] == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr4[1][1] == 0); // expected-warning{{TRUE}}
 }
 
-// TODO: Support multidimensional array.
 void glob_invalid_index3() {
   int idx = -42;
-  // FIXME: Should warn {{garbage or undefined}}.
-  auto x = glob_arr4[1][idx]; // no-warning
+  auto x = glob_arr4[1][idx]; // expected-warning{{garbage or undefined}}
 }
 
-// TODO: Support multidimensional array.
 void glob_invalid_index4() {
   const int *ptr = glob_arr4[1];
   int idx = -42;
@@ -84,28 +72,18 @@
   auto x = ptr[idx]; // no-warning
 }
 
-// TODO: Support multidimensional array.
 int const glob_arr5[4][2] = {{1}, 3, 4, 5};
 void glob_array_index3() {
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[0][0] == 1); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[0][1] == 0); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[1][0] == 3); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[1][1] == 4); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[2][0] == 5); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[2][1] == 0); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[3][0] == 0); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(glob_arr5[3][1] == 0); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(glob_arr5[0][0] == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr5[0][1] == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr5[1][0] == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr5[1][1] == 4); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr5[2][0] == 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr5[2][1] == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr5[3][0] == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr5[3][1] == 0); // expected-warning{{TRUE}}
 }
 
-// TODO: Support multidimensional array.
 void glob_ptr_index2() {
   int const *ptr = glob_arr5[1];
   // FIXME: Should be TRUE.
@@ -120,19 +98,16 @@
   clang_analyzer_eval(ptr[4] == 0); // expected-warning{{UNKNOWN}}
 }
 
-// TODO: Support multidimensional array.
 void glob_invalid_index5() {
   int idx = -42;
-  // FIXME: Should warn {{garbage or undefined}}.
-  auto x = glob_arr5[1][idx]; // no-warning
+  auto x = glob_arr5[1][idx]; // expected-warning{{garbage or undefined}}
 }
 
-// TODO: Support multidimensional array.
 void glob_invalid_index6() {
   int const *ptr = &glob_arr5[1][0];
   int idx = 42;
   // FIXME: Should warn {{garbage or undefined}}.
-  auto x = ptr[idx]; // // no-warning
+  auto x = ptr[idx]; // no-warning
 }
 
 extern const int glob_arr_no_init[10];
@@ -253,3 +228,31 @@
   clang_analyzer_eval(glob_ptr12[2] == 'c');  // expected-warning{{TRUE}}
   clang_analyzer_eval(glob_ptr12[3] == '\0'); // expected-warning{{TRUE}}
 }
+
+typedef int Int;
+typedef Int const CInt;
+typedef CInt Arr[2];
+typedef Arr Arr2[4];
+Arr2 glob_arr8 = {{1}, 3, 4, 5}; // const int[4][2]
+void glob_array_typedef1() {
+  clang_analyzer_eval(glob_arr8[0][0] == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr8[0][1] == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr8[1][0] == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr8[1][1] == 4); 

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D107049#3096807 , @v.g.vassilev 
wrote:

> Can you share your cmake config line, the target triple and architecture?

CC='/mycompiler/compiler-clang/bin/clang -march=corei7' 
CXX='/mycompiler/compiler-clang/bin/clang++ -march=corei7' 
LDFLAGS='-L/mycompiler/compiler-clang/lib64 
-Wl,--disable-new-dtags,-R/mycompiler/compiler-clang/lib/x86_64-unknown-linux-gnu/c++:/mycompiler/compiler-clang/lib64:/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64
 -ldl' cmake /repo/llvm --debug-trycompile -G Ninja -DCMAKE_MAKE_PROGRAM=ninja 
-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' 
-DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
-DCMAKE_INSTALL_PREFIX=/compiler-clang -DLLVM_APPEND_VC_REV=OFF 
-DLLVM_CCACHE_DIR=/repo/.ccache -DLLVM_CCACHE_BUILD=ON 
-DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache 
-DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo 
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON 
-DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' -DLLVM_ENABLE_Z3_SOLVER=ON 
-DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 
-DLLVM_LIT_ARGS='-sv --threads 14' -DLLVM_ENABLE_PLUGINS=OFF 
-DLLVM_USE_SANITIZER='Address' -DLLVM_ENABLE_LIBPFM=OFF 
-DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF 
-DLLVM_STATIC_LINK_CXX_STDLIB=ON -DCLANG_ENABLE_ARCMT=OFF 
-DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF -DCLANG_ROUND_TRIP_CC1_ARGS=OFF


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

https://reviews.llvm.org/D107049

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

[PATCH] D112915: WIP: [clang][modules] Granular tracking of includes

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added a comment.

I'm interested in hearing some feedback whether the direction I'm taking here 
makes sense.

There are a couple of TODOs (mostly on optimizing away unnecessary maps) and a 
few modules-ts tests are failing.

@rsmith left a suggestion on D104344  to 
track this information in `Preprocessor::SubmoduleState`, which has similar 
semantics to what I'm doing with `Preprocessor::IncludeMap` (dividing the state 
during submodule compilation). The issue is that it 
(`Preprocessor::Submodules`) is really only enabled when Clang gets invoked 
with `-fmodules-local-submodule-visibility`. To keep its current semantics and 
make it usable for our use-case (which needs to work even without the flag), I 
think we'd need to **always** track the submodule state and conditionally 
**merge** the outer and local macro states as we now do for `IncludeMap` in 
`PPLexerChange.cpp`. I'm not really sure this is correct/feasible.

Any opinions on this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112915

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

[PATCH] D112001: [Clang] Add min/max reduction builtins.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 383756.
fhahn added a comment.

rebase on top of recent changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112001

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-reduction-math.c
  clang/test/Sema/builtins-reduction-math.c

Index: clang/test/Sema/builtins-reduction-math.c
===
--- /dev/null
+++ clang/test/Sema/builtins-reduction-math.c
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 %s -pedantic -verify -triple=x86_64-apple-darwin9
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+typedef int int3 __attribute__((ext_vector_type(3)));
+typedef unsigned unsigned4 __attribute__((ext_vector_type(4)));
+
+struct Foo {
+  char *p;
+};
+
+void test_builtin_reduce_max(int i, float4 v, int3 iv) {
+  struct Foo s = __builtin_reduce_max(iv);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'int3' (vector of 3 'int' values)}}
+
+  i = __builtin_reduce_max(v, v);
+  // expected-error@-1 {{too many arguments to function call, expected 1, have 2}}
+
+  i = __builtin_reduce_max();
+  // expected-error@-1 {{too few arguments to function call, expected 1, have 0}}
+
+  i = __builtin_reduce_max(i);
+  // expected-error@-1 {{1st argument must be a vector type (was 'int')}}
+}
+
+void test_builtin_reduce_min(int i, float4 v, int3 iv) {
+  struct Foo s = __builtin_reduce_min(iv);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'int3' (vector of 3 'int' values)}}
+
+  i = __builtin_reduce_min(v, v);
+  // expected-error@-1 {{too many arguments to function call, expected 1, have 2}}
+
+  i = __builtin_reduce_min();
+  // expected-error@-1 {{too few arguments to function call, expected 1, have 0}}
+
+  i = __builtin_reduce_min(i);
+  // expected-error@-1 {{1st argument must be a vector type (was 'int')}}
+}
Index: clang/test/CodeGen/builtins-reduction-math.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-reduction-math.c
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin %s -emit-llvm -disable-llvm-passes -o - | FileCheck %s
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+typedef short int si8 __attribute__((ext_vector_type(8)));
+typedef unsigned int u4 __attribute__((ext_vector_type(4)));
+
+__attribute__((address_space(1))) float4 vf1_as_one;
+
+void test_builtin_reduce_max(float4 vf1, si8 vi1, u4 vu1) {
+  // CHECK-LABEL: define void @test_builtin_reduce_max(
+  // CHECK:  [[VF1:%.+]] = load <4 x float>, <4 x float>* %vf1.addr, align 16
+  // CHECK-NEXT: call float @llvm.vector.reduce.fmax.v4f32(<4 x float> [[VF1]])
+  float r1 = __builtin_reduce_max(vf1);
+
+  // CHECK:  [[VI1:%.+]] = load <8 x i16>, <8 x i16>* %vi1.addr, align 16
+  // CHECK-NEXT: call i16 @llvm.vector.reduce.smax.v8i16(<8 x i16> [[VI1]])
+  short r2 = __builtin_reduce_max(vi1);
+
+  // CHECK:  [[VU1:%.+]] = load <4 x i32>, <4 x i32>* %vu1.addr, align 16
+  // CHECK-NEXT: call i32 @llvm.vector.reduce.umax.v4i32(<4 x i32> [[VU1]])
+  unsigned r3 = __builtin_reduce_max(vu1);
+
+  // CHECK:  [[VF1_AS1:%.+]] = load <4 x float>, <4 x float> addrspace(1)* @vf1_as_one, align 16
+  // CHECK-NEXT: [[RDX1:%.+]] = call float @llvm.vector.reduce.fmax.v4f32(<4 x float> [[VF1_AS1]])
+  // CHECK-NEXT: fpext float [[RDX1]] to double
+  const double r4 = __builtin_reduce_max(vf1_as_one);
+
+  // CHECK:  [[CVI1:%.+]] = load <8 x i16>, <8 x i16>* %cvi1, align 16
+  // CHECK-NEXT: [[RDX2:%.+]] = call i16 @llvm.vector.reduce.smax.v8i16(<8 x i16> [[CVI1]])
+  // CHECK-NEXT: sext i16 [[RDX2]] to i64
+  const si8 cvi1 = vi1;
+  unsigned long long r5 = __builtin_reduce_max(cvi1);
+}
+
+void test_builtin_reduce_min(float4 vf1, si8 vi1, u4 vu1) {
+  // CHECK-LABEL: define void @test_builtin_reduce_min(
+  // CHECK:  [[VF1:%.+]] = load <4 x float>, <4 x float>* %vf1.addr, align 16
+  // CHECK-NEXT: call float @llvm.vector.reduce.fmin.v4f32(<4 x float> [[VF1]])
+  float r1 = __builtin_reduce_min(vf1);
+
+  // CHECK:  [[VI1:%.+]] = load <8 x i16>, <8 x i16>* %vi1.addr, align 16
+  // CHECK-NEXT: call i16 @llvm.vector.reduce.smin.v8i16(<8 x i16> [[VI1]])
+  short r2 = __builtin_reduce_min(vi1);
+
+  // CHECK:  [[VU1:%.+]] = load <4 x i32>, <4 x i32>* %vu1.addr, align 16
+  // CHECK-NEXT: call i32 @llvm.vector.reduce.umin.v4i32(<4 x i32> [[VU1]])
+  unsigned r3 = __builtin_reduce_min(vu1);
+
+  // CHECK:  [[VF1_AS1:%.+]] = load <4 x float>, <4 x float> addrspace(1)* @vf1_as_one, align 16
+  // CHECK-NEXT: [[RDX1:%.+]] = call float @llvm.vector.reduce.fmin.v4f32(<4 x float> [[VF1_AS1]])
+  // CHECK-NEXT: fpe

[PATCH] D95168: [clang-format] Add InsertBraces option

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

HazardyKnusperkeks added a comment.

In D95168#3099739 , @MyDeveloperDay 
wrote:

> I'd like to carry the mantle for this, before making any further changes I'd 
> like to address some of the review comments
>
> 1. Add documentation warning about a modifying change (as agreed by the RFC)
> 2. Add version introduced information
> 3. Fix issue with Macro continuation (don't add the \n before the } unless 
> you see a \\ line comment, otherwise let clang-format deal with the \n 
> depending on the BraceWrapping style
> 4. Add unit tests for Macro continuation and Comment handling
> 5. Allow InsertBraces in other languages
>
> TODO:
>
> - break out into its own file (Format.cpp is getting too big)

This also holds for FormatTest.cpp.

> - Look further into possible Removal (I have an idea for how this might be 
> possible, and super useful for LLVM where we don't like single if {} ), I'd 
> like to round out on this before introducing the options rather than having 
> to change them later

Yeah we should have that.

> - Should we add the possibility of removal should we change the option name 
> to "AutomaticBraces" (thoughts?)

Name change is good, the options then also need to be renamed.

> - @tiagoma please add your name and email addreess to this review so when the 
> time comes to land this I can attribute to you as "Author".






Comment at: clang/include/clang/Format/Format.h:999
+  /// The default is the disabled value of ``BIS_Never``.
+  /// \warning
+  ///  Setting ``InsertBraces``  to something other than `Never`, COULD

Could we just add a big notification on top, that some specially marked options 
may break the code, and then only mark them, so one does not need to write that 
much for all possible options?


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

https://reviews.llvm.org/D95168

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

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

If we run without z3 it still fails, but in another way:

  [ RUN  ] InterpreterTest.CatchException
  JIT session error: Symbols not found: [ __gxx_personality_v0, 
_ZSt9terminatev, _ZTVN10__cxxabiv117__class_type_infoE, 
__cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, 
__cxa_free_exception ]
  Failure value returned from cantFail wrapped call
  Failed to materialize symbols: { (main, { __clang_call_terminate, 
_ZN16custom_exceptionC2EPKc, throw_exception, _ZTS16custom_exception, 
_ZTI16custom_exception }) }
  UNREACHABLE executed at 
/repo/uabelho/master-github/llvm/include/llvm/Support/Error.h:788!
   #0 0x0051c0fb backtrace 
/repo/uabelho/flacc_6.144/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4205:13
   #1 0x0186f144 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:565:13
   #2 0x01867cf8 llvm::sys::RunSignalHandlers() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Signals.cpp:0:5
   #3 0x0186ff78 SignalHandler(int) 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:0:3
   #4 0x7fdcac5bd630 __restore_rt sigaction.c:0:0
   #5 0x7fdcab8e0387 raise (/lib64/libc.so.6+0x36387)
   #6 0x7fdcab8e1a78 abort (/lib64/libc.so.6+0x37a78)
   #7 0x01708875 operator<< 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../include/llvm/Support/raw_ostream.h:221:7
   #8 0x01708875 operator<< 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../include/llvm/Support/raw_ostream.h:231:18
   #9 0x01708875 llvm::llvm_unreachable_internal(char const*, char 
const*, unsigned int) 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/ErrorHandling.cpp:204:19
  #10 0x00590b65 unsigned long llvm::cantFail(llvm::Expected, char const*) 
/repo/uabelho/master-github/llvm/include/llvm/Support/Error.h:777:12
  #11 0x0058e5b8 (anonymous 
namespace)::InterpreterTest_CatchException_Test::TestBody() 
/repo/uabelho/master-github/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:0:0
  #12 0x018abce8 os_stack_trace_getter 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:5635:7
  #13 0x018abce8 testing::Test::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:2515:9
  #14 0x018aeb03 testing::TestInfo::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:11
  #15 0x018aff71 testing::TestSuite::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:28
  #16 0x018dfaa9 testing::internal::UnitTestImpl::RunAllTests() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:44
  #17 0x018ddc8e testing::UnitTest::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:4925:10
  #18 0x0188fbce main 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/UnitTestMain/TestMain.cpp:50:3
  #19 0x7fdcab8cc555 __libc_start_main (/lib64/libc.so.6+0x22555)
  #20 0x004e59c7 _start 
(/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0x4e59c7)


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

https://reviews.llvm.org/D107049

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

[PATCH] D95168: [clang-format] Add InsertBraces option

[Owen Pan via Phabricator via cfe-commits]

owenpan added a comment.

In D95168#3099739 , @MyDeveloperDay 
wrote:

> - Look further into possible Removal (I have an idea for how this might be 
> possible, and super useful for LLVM where we don't like single if {} ), I'd 
> like to round out on this before introducing the options rather than having 
> to change them later
>
> - Should we add the possibility of removal should we change the option name 
> to "AutomaticBraces" (thoughts?)

As mentioned in D95168#3039033 , I 
think it would be better to handle the removal separately. The LLVM Coding 
Standards has an entire section 

 about this. Some of the listed exceptions/examples there can make things more 
difficult.


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

https://reviews.llvm.org/D95168

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

[PATCH] D100810: Use `GNUInstallDirs` to support custom installation dirs. -- LLVM

[John Ericson via Phabricator via cfe-commits]

Ericson2314 updated this revision to Diff 383602.
Ericson2314 added a comment.

Simple rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100810

Files:
  clang/tools/scan-build/CMakeLists.txt
  libclc/CMakeLists.txt
  lldb/cmake/modules/FindLibEdit.cmake
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/AddSphinxTarget.cmake
  llvm/cmake/modules/CMakeLists.txt
  llvm/cmake/modules/LLVMInstallSymlink.cmake
  llvm/docs/CMake.rst
  llvm/examples/Bye/CMakeLists.txt
  llvm/include/llvm/CMakeLists.txt
  llvm/tools/llvm-config/BuildVariables.inc.in
  llvm/tools/llvm-config/llvm-config.cpp
  llvm/tools/lto/CMakeLists.txt
  llvm/tools/opt-viewer/CMakeLists.txt
  llvm/tools/remarks-shlib/CMakeLists.txt
  openmp/runtime/src/CMakeLists.txt

Index: openmp/runtime/src/CMakeLists.txt
===
--- openmp/runtime/src/CMakeLists.txt
+++ openmp/runtime/src/CMakeLists.txt
@@ -323,7 +323,7 @@
 install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E copy \"${LIBOMP_LIB_FILE}\"
   \"${alias}${LIBOMP_LIBRARY_SUFFIX}\" WORKING_DIRECTORY \${CMAKE_INSTALL_PREFIX}/bin)")
 install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E copy \"${LIBOMP_IMP_LIB_FILE}\"
-  \"${alias}${CMAKE_STATIC_LIBRARY_SUFFIX}\" WORKING_DIRECTORY \${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR})")
+  \"${alias}${CMAKE_STATIC_LIBRARY_SUFFIX}\" WORKING_DIRECTORY \"\${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR}\")")
   endforeach()
 else()
 
@@ -335,7 +335,7 @@
 foreach(alias IN LISTS LIBOMP_ALIASES)
   install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E create_symlink \"${LIBOMP_LIB_FILE}\"
 \"${alias}${LIBOMP_LIBRARY_SUFFIX}\" WORKING_DIRECTORY
-\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR})")
+\"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR}\")")
 endforeach()
   endif()
 endif()
Index: llvm/tools/remarks-shlib/CMakeLists.txt
===
--- llvm/tools/remarks-shlib/CMakeLists.txt
+++ llvm/tools/remarks-shlib/CMakeLists.txt
@@ -19,7 +19,7 @@
   endif()
   
   install(FILES ${LLVM_MAIN_INCLUDE_DIR}/llvm-c/Remarks.h
-DESTINATION include/llvm-c
+DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/llvm-c"
 COMPONENT Remarks)
 
   if (APPLE)
Index: llvm/tools/opt-viewer/CMakeLists.txt
===
--- llvm/tools/opt-viewer/CMakeLists.txt
+++ llvm/tools/opt-viewer/CMakeLists.txt
@@ -8,7 +8,7 @@
 
 foreach (file ${files})
   install(PROGRAMS ${file}
-DESTINATION share/opt-viewer
+DESTINATION "${CMAKE_INSTALL_DATADIR}/opt-viewer"
 COMPONENT opt-viewer)
 endforeach (file)
 
Index: llvm/tools/lto/CMakeLists.txt
===
--- llvm/tools/lto/CMakeLists.txt
+++ llvm/tools/lto/CMakeLists.txt
@@ -33,7 +33,7 @@
 ${SOURCES} DEPENDS intrinsics_gen)
 
 install(FILES ${LLVM_MAIN_INCLUDE_DIR}/llvm-c/lto.h
-  DESTINATION include/llvm-c
+  DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/llvm-c"
   COMPONENT LTO)
 
 if (APPLE)
Index: llvm/tools/llvm-config/llvm-config.cpp
===
--- llvm/tools/llvm-config/llvm-config.cpp
+++ llvm/tools/llvm-config/llvm-config.cpp
@@ -357,10 +357,16 @@
 ("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot + "/include");
   } else {
 ActivePrefix = CurrentExecPrefix;
-ActiveIncludeDir = ActivePrefix + "/include";
-SmallString<256> path(LLVM_TOOLS_INSTALL_DIR);
-sys::fs::make_absolute(ActivePrefix, path);
-ActiveBinDir = std::string(path.str());
+{
+  SmallString<256> Path(LLVM_INSTALL_INCLUDEDIR);
+  sys::fs::make_absolute(ActivePrefix, Path);
+  ActiveIncludeDir = std::string(Path.str());
+}
+{
+  SmallString<256> Path(LLVM_INSTALL_BINDIR);
+  sys::fs::make_absolute(ActivePrefix, Path);
+  ActiveBinDir = std::string(Path.str());
+}
 ActiveLibDir = ActivePrefix + "/lib" + LLVM_LIBDIR_SUFFIX;
 ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
 ActiveIncludeOption = "-I" + ActiveIncludeDir;
Index: llvm/tools/llvm-config/BuildVariables.inc.in
===
--- llvm/tools/llvm-config/BuildVariables.inc.in
+++ llvm/tools/llvm-config/BuildVariables.inc.in
@@ -23,6 +23,8 @@
 #define LLVM_CXXFLAGS "@LLVM_CXXFLAGS@"
 #define LLVM_BUILDMODE "@LLVM_BUILDMODE@"
 #define LLVM_LIBDIR_SUFFIX "@LLVM_LIBDIR_SUFFIX@"
+#define LLVM_INSTALL_BINDIR "@CMAKE_INSTALL_BINDIR@"
+#define LLVM_INSTALL_INCLUDEDIR "@CMAKE_INSTALL_INCLUDEDIR@"
 #define LLVM_TARGETS_BUILT "@LLVM_TARGETS_BUILT@"
 #define LLVM_SYSTEM_LIBS "@LLVM_SYSTEM_LIBS@"
 #define LLVM_BUILD_SYSTEM "@LLVM_BUILD_SYSTEM@"
Index: llvm/include/llvm/CMakeLists.t

[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

[John Ericson via Phabricator via cfe-commits]

Ericson2314 updated this revision to Diff 383603.
Ericson2314 added a comment.

Rebase, and catch two more `DESTINATION bin`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99484

Files:
  clang-tools-extra/clang-doc/tool/CMakeLists.txt
  clang-tools-extra/clang-include-fixer/find-all-symbols/tool/CMakeLists.txt
  clang-tools-extra/clang-include-fixer/tool/CMakeLists.txt
  clang-tools-extra/clang-tidy/CMakeLists.txt
  clang-tools-extra/clang-tidy/tool/CMakeLists.txt
  clang-tools-extra/modularize/CMakeLists.txt
  clang/CMakeLists.txt
  clang/cmake/modules/AddClang.cmake
  clang/tools/c-index-test/CMakeLists.txt
  clang/tools/clang-format/CMakeLists.txt
  clang/tools/clang-nvlink-wrapper/CMakeLists.txt
  clang/tools/clang-rename/CMakeLists.txt
  clang/tools/libclang/CMakeLists.txt
  clang/tools/scan-build-py/CMakeLists.txt
  clang/tools/scan-build/CMakeLists.txt
  clang/tools/scan-view/CMakeLists.txt
  clang/utils/hmaptool/CMakeLists.txt
  compiler-rt/cmake/base-config-ix.cmake
  flang/CMakeLists.txt
  flang/cmake/modules/AddFlang.cmake
  flang/tools/f18/CMakeLists.txt
  flang/tools/flang-driver/CMakeLists.txt
  libc/CMakeLists.txt
  libcxx/CMakeLists.txt
  libcxx/cmake/Modules/HandleLibCXXABI.cmake
  libcxx/include/CMakeLists.txt
  libcxxabi/CMakeLists.txt
  libunwind/CMakeLists.txt
  lld/CMakeLists.txt
  lld/cmake/modules/AddLLD.cmake
  lld/tools/lld/CMakeLists.txt
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  mlir/CMakeLists.txt
  mlir/cmake/modules/AddMLIR.cmake
  openmp/CMakeLists.txt
  openmp/libompd/src/CMakeLists.txt
  openmp/runtime/src/CMakeLists.txt
  openmp/tools/multiplex/CMakeLists.txt
  polly/CMakeLists.txt
  polly/cmake/CMakeLists.txt
  polly/lib/External/CMakeLists.txt
  pstl/CMakeLists.txt

Index: pstl/CMakeLists.txt
===
--- pstl/CMakeLists.txt
+++ pstl/CMakeLists.txt
@@ -7,6 +7,8 @@
 #===--===##
 cmake_minimum_required(VERSION 3.13.4)
 
+include(GNUInstallDirs)
+
 set(PARALLELSTL_VERSION_FILE "${CMAKE_CURRENT_SOURCE_DIR}/include/pstl/internal/pstl_config.h")
 file(STRINGS "${PARALLELSTL_VERSION_FILE}" PARALLELSTL_VERSION_SOURCE REGEX "#define _PSTL_VERSION .*$")
 string(REGEX REPLACE "#define _PSTL_VERSION (.*)$" "\\1" PARALLELSTL_VERSION_SOURCE "${PARALLELSTL_VERSION_SOURCE}")
@@ -90,10 +92,10 @@
   "${CMAKE_CURRENT_BINARY_DIR}/ParallelSTLConfigVersion.cmake"
 DESTINATION lib/cmake/ParallelSTL)
 install(DIRECTORY include/
-DESTINATION include
+DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
 PATTERN "*.in" EXCLUDE)
 install(FILES "${PSTL_CONFIG_SITE_PATH}"
-DESTINATION include)
+DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}")
 
 add_custom_target(install-pstl
   COMMAND "${CMAKE_COMMAND}" -P "${PROJECT_BINARY_DIR}/cmake_install.cmake" -DCOMPONENT=ParallelSTL)
Index: polly/lib/External/CMakeLists.txt
===
--- polly/lib/External/CMakeLists.txt
+++ polly/lib/External/CMakeLists.txt
@@ -290,7 +290,7 @@
 install(DIRECTORY
   ${ISL_SOURCE_DIR}/include/
   ${ISL_BINARY_DIR}/include/
-  DESTINATION include/polly
+  DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/polly"
   FILES_MATCHING
   PATTERN "*.h"
   PATTERN "CMakeFiles" EXCLUDE
Index: polly/cmake/CMakeLists.txt
===
--- polly/cmake/CMakeLists.txt
+++ polly/cmake/CMakeLists.txt
@@ -83,14 +83,15 @@
 set(POLLY_CONFIG_LLVM_CMAKE_DIR "${LLVM_BINARY_DIR}/${LLVM_INSTALL_PACKAGE_DIR}")
 set(POLLY_CONFIG_CMAKE_DIR "${POLLY_INSTALL_PREFIX}/${POLLY_INSTALL_PACKAGE_DIR}")
 set(POLLY_CONFIG_LIBRARY_DIRS "${POLLY_INSTALL_PREFIX}/lib${LLVM_LIBDIR_SUFFIX}")
+get_filename_component(base_includedir "${CMAKE_INSTALL_INCLUDEDIR}" ABSOLUTE BASE_DIR "${POLLY_INSTALL_PREFIX}")
 if (POLLY_BUNDLED_ISL)
   set(POLLY_CONFIG_INCLUDE_DIRS
-"${POLLY_INSTALL_PREFIX}/include"
-"${POLLY_INSTALL_PREFIX}/include/polly"
+"${base_includedir}"
+"${base_includedir}/polly"
 )
 else()
   set(POLLY_CONFIG_INCLUDE_DIRS
-"${POLLY_INSTALL_PREFIX}/include"
+"${base_includedir}"
 ${ISL_INCLUDE_DIRS}
 )
 endif()
@@ -100,12 +101,12 @@
 foreach(tgt IN LISTS POLLY_CONFIG_EXPORTED_TARGETS)
   get_target_property(tgt_type ${tgt} TYPE)
   if (tgt_type STREQUAL "EXECUTABLE")
-set(tgt_prefix "bin/")
+set(tgt_prefix "${CMAKE_INSTALL_FULL_BINDIR}/")
   else()
-set(tgt_prefix "lib/")
+set(tgt_prefix "${CMAKE_INSTALL_FULL_LIBDIR}/")
   endif()
 
-  set(tgt_path "${CMAKE_INSTALL_PREFIX}/${tgt_prefix}$")
+  set(tgt_path "${tgt_prefix}$")
   file(RELATIVE_PATH tgt_path ${POLLY_CONFIG_CMAKE_DIR} ${tgt_path})
 
   if (NOT tgt_type STREQUAL "INTERFACE_LIBRARY")
Index: polly/CMa

[PATCH] D112221: Mark ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT as deprecated

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Ping


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

https://reviews.llvm.org/D112221

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

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D107049#3099816 , @uabelho wrote:

> In D107049#3096807 , @v.g.vassilev 
> wrote:
>
>> Can you share your cmake config line, the target triple and architecture?
>
> CC='/mycompiler/compiler-clang/bin/clang -march=corei7' 
> CXX='/mycompiler/compiler-clang/bin/clang++ -march=corei7' 
> LDFLAGS='-L/mycompiler/compiler-clang/lib64 
> -Wl,--disable-new-dtags,-R/mycompiler/compiler-clang/lib/x86_64-unknown-linux-gnu/c++:/mycompiler/compiler-clang/lib64:/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64
>  -ldl' cmake /repo/llvm --debug-trycompile -G Ninja 
> -DCMAKE_MAKE_PROGRAM=ninja -DCMAKE_BUILD_TYPE=Release 
> -DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' 
> -DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
> -DCMAKE_INSTALL_PREFIX=/compiler-clang -DLLVM_APPEND_VC_REV=OFF 
> -DLLVM_CCACHE_DIR=/repo/.ccache -DLLVM_CCACHE_BUILD=ON 
> -DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache 
> -DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo 
> -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON 
> -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' 
> -DLLVM_ENABLE_Z3_SOLVER=ON 
> -DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 
> -DLLVM_LIT_ARGS='-sv --threads 14' -DLLVM_ENABLE_PLUGINS=OFF 
> -DLLVM_USE_SANITIZER='Address' -DLLVM_ENABLE_LIBPFM=OFF 
> -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF 
> -DLLVM_STATIC_LINK_CXX_STDLIB=ON -DCLANG_ENABLE_ARCMT=OFF 
> -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF -DCLANG_ROUND_TRIP_CC1_ARGS=OFF

Can you also paste the configure output of cmake?


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

https://reviews.llvm.org/D107049

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

[PATCH] D109372: [RISCV][RFC] Add Clang support for RISC-V overlay system

[Edward Jones via Phabricator via cfe-commits]

edward-jones added a comment.
Herald added subscribers: VincentWu, luke957.

I reverted some of the previous changes I made so that this patch matches the 
spec as currently written - this means it's two attributes again, and the 
diagnostic messages have been updated a bit too. The two Clang attributes match 
to the same LLVM attribute internally though.

This is at a stage where more review would be nice. Obviously this is gated on 
patches to other toolchain components, but I hope that these changes won't 
change too much now unless the spec also changes.


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

https://reviews.llvm.org/D109372

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

[PATCH] D112773: Allow __attribute__((swift_attr)) in attribute push pragmas

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D112773#3097730 , @beccadax wrote:

> In D112773#3096185 , @aaron.ballman 
> wrote:
>
>> `swift_attr` has no subjects, so this will attempt to spray the attribute 
>> onto literally *everything*. That makes this incredibly risky to use with 
>> the pragma approach (not to mention what it could do to memory consumption 
>> of large ASTs). I'm not certain I'm comfortable allowing this without an 
>> explicit set of subjects for the attribute.
>
> What exactly is the risk here? In my testing, omitting `apply_to` or setting 
> it to `any` or `any()` caused clang to apply the attribute to nothing, not 
> everything. If there is a way I didn't find, perhaps we could address that by 
> emitting a warning if you use the "match anything" subject with an attribute 
> that has an empty subject list.

Oo, that is not what my expectations were. I thought we would be applying 
it to anything in this situation. That we're not is possibly a bug, but I 
happen to like the behavior in this case.

>> Can we add subjects to this attribute to try to limit the damage somewhat?
>
> I don't think we can, because `swift_attr` is by design very widely 
> applicable—it allows you to apply arbitrary Swift language features to the 
> imported representation of any Clang declaration. Any declaration Swift 
> imports, including types and typedefs, functions, non-local variables, and 
> parameters, ought to accept it.
>
> Looking through the subject matchers available, almost everything would at 
> least //theoretically// be a reasonable target for `swift_attr` 
> (`variable(is_local)` is the only exception I noticed). We could restrict it 
> to only declarations we're currently using it for, but many of these (e.g. 
> C++ declarations) are likely to be supported in the future, so this would 
> create clang churn and integration issues as Swift's capabilities expand.

That sounds like a good reason to not give it a subject list.

> So I don't think the risk you're worried about is really there, and I don't 
> think adding a subject list would mitigate it very much. But if I've missed 
> something, please point it out.

I'd like some confirmation of that. My reading of 
https://clang.llvm.org/docs/LanguageExtensions.html#specifying-an-attribute-for-multiple-declarations-pragma-clang-attribute
 suggests that `any()` /could/ apply to everything. (`The any rule applies 
attributes to all declarations that are matched by at least one of the rules in 
the any.`) My recollection of the discussions when we adopted #pragma clang 
attribute is that we tried our best to limit the damage from the pragma 
over-applying attributes, but I don't recall if we explicitly talked about 
any() with no subjects. What would make me comfortable with this patch is 1) 
doing some archeology to find the original reviews for pragma clang attribute 
to see if we made any sort of explicit decision here but forgot to document it. 
If we didn't make an explicit decision in this area, we should make one now. We 
can either decide "any() with no subjects applies to everything", "any() with 
no subjects is dangerous and
will apply to nothing", or "any() with no subjects is dangerous and we will 
diagnose if the user tries this" (probably other ideas we could consider). 
Ultimately, I would like to see the pragma clang attribute documentation 
updated before/when we land this bit so that our documentation clearly sets 
user expectations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112773

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

[PATCH] D112001: [Clang] Add min/max reduction builtins.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Precommit CI looks to be failing.

  
/var/lib/buildkite-agent/builds/llvm-project/clang/test/CodeGen/builtins-reduction-math.c:13:9:
 error: initializing 'float' with an expression of incompatible type 'float4' 
(vector of 4 'float' values)
  
float r1 = __builtin_reduce_max(vf1);


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112001

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

[PATCH] D109372: [RISCV][RFC] Add Clang support for RISC-V overlay system

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

In D109372#3099947 , @edward-jones 
wrote:

> I reverted some of the previous changes I made so that this patch matches the 
> spec as currently written - this means it's two attributes again, and the 
> diagnostic messages have been updated a bit too. The two Clang attributes 
> match to the same LLVM attribute internally though.
>
> This is at a stage where more review would be nice. Obviously this is gated 
> on patches to other toolchain components, but I hope that these changes won't 
> change too much now unless the spec also changes.

The whole point of putting it up for review is so you get feedback about the 
entire direction of the spec, which was written by people who are not experts 
when it comes to toolchains. You’re supposed to take our feedback, relay it to 
them and get the draft spec revised. Otherwise, if the spec written by people 
who don’t know what makes sense for toolchains is regarded as holy and 
immutable then I’m just going to NACK this as poorly designed and something 
LLVM shouldn’t bow to implementing, and you’ve wasted my time asking for a full 
review.


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

https://reviews.llvm.org/D109372

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[wangpc via Phabricator via cfe-commits]

pcwang-thead created this revision.
Herald added subscribers: lxfind, dang.
pcwang-thead requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Since C++14 has been released for about seven years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
For tests assumed that sized deallocation is disabled, just force them
to disable this feature by adding -fno-sized-deallocation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112921

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/AST/ast-dump-expr.cpp
  clang/test/CodeGenCXX/cxx1y-sized-deallocation.cpp
  clang/test/CodeGenCXX/cxx2a-destroying-delete.cpp
  clang/test/CodeGenCXX/delete-two-arg.cpp
  clang/test/CodeGenCXX/delete.cpp
  clang/test/CodeGenCXX/new.cpp
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-cleanup.cpp
  clang/test/CodeGenCoroutines/coro-gro.cpp
  clang/test/SemaCXX/builtin-operator-new-delete.cpp
  clang/test/SemaCXX/unavailable_aligned_allocation.cpp
  clang/unittests/StaticAnalyzer/CallEventTest.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -578,12 +578,11 @@
 
 
 
-(7): In Clang 3.7 and later, sized deallocation is only enabled
-if the user passes the -fsized-deallocation flag. The user must
-supply definitions of the sized deallocation functions, either by providing them
-explicitly or by using a C++ standard library that does. libstdc++
-added these functions in version 5.0, and libc++ added them in
-version 3.7.
+(7): The user must supply definitions of the sized deallocation
+functions, either by providing them explicitly or by using a C++ standard library
+that does. libstdc++ added these functions in version 5.0, and
+libc++ added them in version 3.7. The user can also use the
+-fno-sized-deallocation option to disable sized deallocation.
 
 
 
Index: clang/unittests/StaticAnalyzer/CallEventTest.cpp
===
--- clang/unittests/StaticAnalyzer/CallEventTest.cpp
+++ clang/unittests/StaticAnalyzer/CallEventTest.cpp
@@ -81,7 +81,7 @@
 }
   )",
  Diags));
-  EXPECT_EQ(Diags, "test.CXXDeallocator: NumArgs: 1\n");
+  EXPECT_EQ(Diags, "test.CXXDeallocator: NumArgs: 2\n");
 }
 
 } // namespace
Index: clang/test/SemaCXX/unavailable_aligned_allocation.cpp
===
--- clang/test/SemaCXX/unavailable_aligned_allocation.cpp
+++ clang/test/SemaCXX/unavailable_aligned_allocation.cpp
@@ -1,15 +1,15 @@
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DMACOS %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DMACOS %s
-// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DIOS %s
-// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DTVOS %s
-// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple armv7k-apple-watchos3.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DWATCHOS %s
-// RUN: %clang_cc1 -triple armv7k-apple-watchos3.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DZOS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DZOS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DMACOS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -std=c++1z -verify -DNO_ERRORS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DMACOS %s
+// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fno-sized-deallocation -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DIOS %s
+// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fno-sized-deallocation -fexceptions -std=c++1z -verify -DNO_ERRORS %s
+// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fno-siz

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D99#3097692 , @dblaikie wrote:

> In D99#3096124 , @aaron.ballman 
> wrote:
>
>> In D99#3095623 , 
>> @yonghong-song wrote:
>>
 Ah, yeah, I see what you mean - that does seem sort of unfortunate. Is it 
 possible these attributes could only appear on typedefs and they'd be more 
 readily carried through that without needing extra typeloc tracking? 
 (sorry for not having read back through the rest of the review - which 
 may've started there and ended up here as a more general form of the 
 attribute?)
>>>
>>> For the question, "is it possible these attributes could only appear on 
>>> typedefs?" The answer is "not really possible". We are targeting existing 
>>> linux kernel where existing type attributes (__user, __rcu, ...) have been 
>>> used in places other than typedef quite extensively (e.g., function 
>>> argument type, function return type, field type, etc.).
>>>
>>> In one of my earlier prototypes, I put the tag string itself in 
>>> AttributedType and with this we can avoid TypeLoc, but I understand this is 
>>> not conventional usage and that is why we do through TypeLoc mechanism. 
>>> @aaron.ballman can further comment on this.
>>
>> FWIW, I made that request because AttributedTypeLoc stores the Attr * for 
>> the attributed type, so we can get the attribute argument information from 
>> that rather than having to duplicate it within a new TypeLoc object.
>
> So could the debug info code be done with AttributedType (I guess currently 
> CGDebugInfo skips over those - but we could not skip over them and check if 
> it's one of these attributes, otherwise skip) rather than passing around the 
> extra TypeLoc?

That's my hope, but I wasn't certain if there were type modifications happening 
where we need to calculate a `TypeLoc` that's different from what we would get 
out of the type itself. I would expect that doesn't happen during CodeGen 
(seems awfully late to be changing types), but wasn't 100% sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

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

[PATCH] D112491: Add `LambdaCapture`-related matchers.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D112491#3096935 , @sammccall wrote:

> This looks really sensible to me too. Some naming bikeshedding, but my main 
> question is migration.
>
> Supporting two things is indeed annoying and confusing. I agree it's not 
> worth keeping the old way forever just to avoid writing `refersToVarDecl`.
> The question is: how soon can we get rid of it? We should consider whether we 
> can do it in this patch: just replace the old matcher with this one.
>
> AFAICT the old matcher has no uses in-tree beyond tests/registration. FWIW it 
> has no uses in our out-of-tree repo either (which generally is a heavy 
> matchers user).
> I'm sure it has users somewhere, but probably few, and the mechanical 
> difficulty of updating them is low. Given that I think we should just break 
> them, rather than deal with overloading and deprecation warnings and future 
> cleanup just to put off breaking them for one more release cycle.
>
> This is a tradeoff, to me it seems but reasonable people can disagree on the 
> importance of stability. Aaron, happy to go with whatever you decide.

I did some looking around to see if I could find any uses of the matcher in the 
wild, and I can't spot any that aren't in a Clang fork. I think there's plenty 
of time for us to get feedback from early adopters if removing the old 
interface causes severe pain for anyone. So I'm on board with replacing the old 
APIs, but we should definitely have a release note explaining what's happening.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112491

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

[PATCH] D109215: [RISCV] Fix arch string parsing for multi-character extensions

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 383773.
eopXD added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109215

Files:
  clang/test/Driver/riscv-arch.c
  llvm/lib/Support/RISCVISAInfo.cpp


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -71,6 +71,28 @@
   return Ext.consume_front("experimental-");
 }
 
+// This function finds the first character that doesn't belong to a version
+// (e.g. zbe0p93 is extension 'zbe' of version '0p93'). So the function will
+// consume [0-9]*p[0-9]* starting from the backward. An extension name will not
+// end with a digit or the letter 'p', so this function will parse correctly.
+// NOTE: This function is NOT able to take empty strings or strings that only
+// have version numbers and no extension name. It assumes the extension name
+// will be at least more than one character.
+static size_t findFirstNonVersionCharacter(const StringRef &Ext) {
+  if (Ext.size() == 0)
+llvm_unreachable("Already guarded by if-statement in ::parseArchString");
+
+  int Pos = Ext.size() - 1;
+  while (Pos > 0 && isDigit(Ext[Pos]))
+Pos--;
+  if (Pos > 0 && Ext[Pos] == 'p' && isDigit(Ext[Pos - 1])) {
+Pos--;
+while (Pos > 0 && isDigit(Ext[Pos]))
+  Pos--;
+  }
+  return Pos;
+}
+
 struct FindByName {
   FindByName(StringRef Ext) : Ext(Ext){};
   StringRef Ext;
@@ -637,7 +659,7 @@
 
 StringRef Type = getExtensionType(Ext);
 StringRef Desc = getExtensionTypeDesc(Ext);
-auto Pos = Ext.find_if(isDigit);
+size_t Pos = findFirstNonVersionCharacter(Ext) + 1;
 StringRef Name(Ext.substr(0, Pos));
 StringRef Vers(Ext.substr(Pos));
 
Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,7 +392,7 @@
 
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0zbp0p93 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE %s
-// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 
'rv32izbb1p0zbp0p93', multi-character extensions must be separated by 
underscores
+// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 
'rv32izbb1p0zbp0p93', unsupported version number 0.93 for extension 'zbb1p0zbp'
 
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izba1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-ZBA %s


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -71,6 +71,28 @@
   return Ext.consume_front("experimental-");
 }
 
+// This function finds the first character that doesn't belong to a version
+// (e.g. zbe0p93 is extension 'zbe' of version '0p93'). So the function will
+// consume [0-9]*p[0-9]* starting from the backward. An extension name will not
+// end with a digit or the letter 'p', so this function will parse correctly.
+// NOTE: This function is NOT able to take empty strings or strings that only
+// have version numbers and no extension name. It assumes the extension name
+// will be at least more than one character.
+static size_t findFirstNonVersionCharacter(const StringRef &Ext) {
+  if (Ext.size() == 0)
+llvm_unreachable("Already guarded by if-statement in ::parseArchString");
+
+  int Pos = Ext.size() - 1;
+  while (Pos > 0 && isDigit(Ext[Pos]))
+Pos--;
+  if (Pos > 0 && Ext[Pos] == 'p' && isDigit(Ext[Pos - 1])) {
+Pos--;
+while (Pos > 0 && isDigit(Ext[Pos]))
+  Pos--;
+  }
+  return Pos;
+}
+
 struct FindByName {
   FindByName(StringRef Ext) : Ext(Ext){};
   StringRef Ext;
@@ -637,7 +659,7 @@
 
 StringRef Type = getExtensionType(Ext);
 StringRef Desc = getExtensionTypeDesc(Ext);
-auto Pos = Ext.find_if(isDigit);
+size_t Pos = findFirstNonVersionCharacter(Ext) + 1;
 StringRef Name(Ext.substr(0, Pos));
 StringRef Vers(Ext.substr(Pos));
 
Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,7 +392,7 @@
 
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0zbp0p93 -menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE %s
-// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 'rv32izbb1p0zbp0p93', multi-character extensions must be separated by underscores
+// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 'rv32izbb1p0zbp0p93', unsupported version number 0.93 for extension 'zbb1p0

[PATCH] D112359: [RISCV] Unify depedency check and extension implication parsing logics

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 383775.
eopXD added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112359

Files:
  clang/test/CodeGen/RISCV/riscv-metadata.c
  clang/test/CodeGen/RISCV/riscv32-ilp32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64-lp64f-lp64d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64f-lp64d-abi.c
  clang/test/CodeGen/riscv32-ilp32d-abi.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/test/MC/RISCV/attribute-arch.s

Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -33,44 +33,41 @@
 .attribute arch, "rv32ima2p0_fdc"
 # CHECK: attribute  5, "rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
-.attribute arch, "rv32iv"
+.attribute arch, "rv32iv0p10"
 # CHECK: attribute  5, "rv32i2p0_v0p10_zvlsseg0p10"
 
-.attribute arch, "rv32izba"
+.attribute arch, "rv32izba1p0"
 # CHECK: attribute  5, "rv32i2p0_zba1p0"
 
-.attribute arch, "rv32izbb"
+.attribute arch, "rv32izbb1p0"
 # CHECK: attribute  5, "rv32i2p0_zbb1p0"
 
-.attribute arch, "rv32izbc"
+.attribute arch, "rv32izbc1p0"
 # CHECK: attribute  5, "rv32i2p0_zbc1p0"
 
-.attribute arch, "rv32izbe"
+.attribute arch, "rv32izbe0p93"
 # CHECK: attribute  5, "rv32i2p0_zbe0p93"
 
-.attribute arch, "rv32izbf"
+.attribute arch, "rv32izbf0p93"
 # CHECK: attribute  5, "rv32i2p0_zbf0p93"
 
-.attribute arch, "rv32izbm"
+.attribute arch, "rv32izbm0p93"
 # CHECK: attribute  5, "rv32i2p0_zbm0p93"
 
-.attribute arch, "rv32izbp"
+.attribute arch, "rv32izbp0p93"
 # CHECK: attribute  5, "rv32i2p0_zbp0p93"
 
-.attribute arch, "rv32izbr"
+.attribute arch, "rv32izbr0p93"
 # CHECK: attribute  5, "rv32i2p0_zbr0p93"
 
-.attribute arch, "rv32izbs"
+.attribute arch, "rv32izbs1p0"
 # CHECK: attribute  5, "rv32i2p0_zbs1p0"
 
-.attribute arch, "rv32izbt"
+.attribute arch, "rv32izbt0p93"
 # CHECK: attribute  5, "rv32i2p0_zbt0p93"
 
-.attribute arch, "rv32ifzfh"
+.attribute arch, "rv32ifzfh0p1"
 # CHECK: attribute  5, "rv32i2p0_f2p0_zfh0p1"
 
-.attribute arch, "rv32ivzvamo_zvlsseg"
-# CHECK: attribute  5, "rv32i2p0_v0p10_zvamo0p10_zvlsseg0p10"
-
-.attribute arch, "rv32iv_zvamo0p10_zvlsseg"
+.attribute arch, "rv32iv0p10zvamo0p10_zvlsseg0p10"
 # CHECK: attribute  5, "rv32i2p0_v0p10_zvamo0p10_zvlsseg0p10"
Index: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
===
--- llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -2062,7 +2062,11 @@
 "unexpected token in '.attribute' directive"))
 return true;
 
-  if (Tag == RISCVAttrs::ARCH) {
+  if (IsIntegerValue)
+getTargetStreamer().emitAttribute(Tag, IntegerValue);
+  else if (Tag != RISCVAttrs::ARCH)
+getTargetStreamer().emitTextAttribute(Tag, StringValue);
+  else {
 StringRef Arch = StringValue;
 for (auto Feature : RISCVFeatureKV)
   if (llvm::RISCVISAInfo::isSupportedExtensionFeature(Feature.Key))
@@ -2070,7 +2074,7 @@
 
 auto ParseResult = llvm::RISCVISAInfo::parseArchString(
 StringValue, /*EnableExperimentalExtension=*/true,
-/*ExperimentalExtensionVersionCheck=*/false);
+/*ExperimentalExtensionVersionCheck=*/true);
 if (!ParseResult) {
   std::string Buffer;
   raw_string_ostream OutputErrMsg(Buffer);
@@ -2093,35 +2097,9 @@
   setFeatureBits(RISCV::Feature64Bit, "64bit");
 else
   return Error(ValueExprLoc, "bad arch string " + Arch);
-  }
 
-  if (IsIntegerValue)
-getTargetStreamer().emitAttribute(Tag, IntegerValue);
-  else {
-if (Tag != RISCVAttrs::ARCH) {
-  getTargetStreamer().emitTextAttribute(Tag, StringValue);
-} else {
-  std::vector FeatureVector;
-  RISCVFeatures::toFeatureVector(FeatureVector, getSTI().getFeatureBits());
-
-  // Parse that by RISCVISAInfo->
-  unsigned XLen = getFeatureBits(RISCV::Feature64Bit) ? 64 : 32;
-  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeatureVector);
-  if (!ParseResult) {
-std::string Buffer;
-raw_string_ostream OutputErrMsg(Buffer);
-handleAllErrors(ParseResult.takeError(),
-[&](llvm::StringError &ErrMsg) {
-  OutputErrMsg << ErrMsg.getMessage();
-});
-
-return Error(ValueExprLoc, OutputErrMsg.str());
-  }
-  auto &ISAInfo = *ParseResult;
-
-  // Then emit the arch string.
-  getTargetStreamer().emitTextAttribute(Tag, ISAInfo->toString());
- 

[PATCH] D112923: [clang][deps] Reset some benign codegen options

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Some command-line codegen arguments are likely to differ between identical 
modules discovered from different translation units. This patch removes them to 
make builds deterministic and/or reduce the number of built modules.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112923

Files:
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/Inputs/removed-args/cdb.json.template
  clang/test/ClangScanDeps/removed-args.c


Index: clang/test/ClangScanDeps/removed-args.c
===
--- clang/test/ClangScanDeps/removed-args.c
+++ clang/test/ClangScanDeps/removed-args.c
@@ -1,6 +1,8 @@
 // Some command-line arguments used for compiling translation units are not
-// compatible with the semantics of modules and should be removed. In this test
-// case, the command-lines for modules should drop the '-include' argument.
+// compatible with the semantics of modules or are likely to differ between
+// identical modules discovered from different translation units. This test
+// checks such arguments are removed from the command-lines: '-include',
+// '-dwarf-debug-flag' and '-main-file-name'.
 
 // RUN: rm -rf %t && mkdir %t
 // RUN: cp %S/Inputs/removed-args/* %t
@@ -18,6 +20,8 @@
 // CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
 // CHECK-NEXT:   "command-line": [
 // CHECK-NEXT: "-cc1"
+// CHECK-NOT:  "-dwarf-debug-flags"
+// CHECK-NOT:  "-main-file-name"
 // CHECK-NOT:  "-include"
 // CHECK:],
 // CHECK-NEXT:   "context-hash": "[[HASH_MOD_HEADER:.*]]",
Index: clang/test/ClangScanDeps/Inputs/removed-args/cdb.json.template
===
--- clang/test/ClangScanDeps/Inputs/removed-args/cdb.json.template
+++ clang/test/ClangScanDeps/Inputs/removed-args/cdb.json.template
@@ -1,7 +1,7 @@
 [
   {
 "directory": "DIR",
-"command": "clang -fsyntax-only DIR/tu.c -fmodules -fimplicit-module-maps 
-fmodules-cache-path=DIR/cache -include DIR/header.h -o DIR/tu.o",
+"command": "clang -fsyntax-only DIR/tu.c -fmodules -fimplicit-module-maps 
-fmodules-cache-path=DIR/cache -include DIR/header.h -grecord-command-line -o 
DIR/tu.o",
 "file": "DIR/tu.c"
   }
 ]
Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -37,9 +37,13 @@
   CI.getLangOpts()->resetNonModularOptions();
   CI.getPreprocessorOpts().resetNonModularOptions();
 
-  // Remove options incompatible with explicit module build.
+  // Remove options incompatible with explicit module build or are likely to
+  // differ between identical modules discovered from different translation
+  // units.
   CI.getFrontendOpts().Inputs.clear();
   CI.getFrontendOpts().OutputFile.clear();
+  CI.getCodeGenOpts().MainFileName.clear();
+  CI.getCodeGenOpts().DwarfDebugFlags.clear();
 
   CI.getFrontendOpts().ProgramAction = frontend::GenerateModule;
   CI.getLangOpts()->ModuleName = Deps.ID.ModuleName;


Index: clang/test/ClangScanDeps/removed-args.c
===
--- clang/test/ClangScanDeps/removed-args.c
+++ clang/test/ClangScanDeps/removed-args.c
@@ -1,6 +1,8 @@
 // Some command-line arguments used for compiling translation units are not
-// compatible with the semantics of modules and should be removed. In this test
-// case, the command-lines for modules should drop the '-include' argument.
+// compatible with the semantics of modules or are likely to differ between
+// identical modules discovered from different translation units. This test
+// checks such arguments are removed from the command-lines: '-include',
+// '-dwarf-debug-flag' and '-main-file-name'.
 
 // RUN: rm -rf %t && mkdir %t
 // RUN: cp %S/Inputs/removed-args/* %t
@@ -18,6 +20,8 @@
 // CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
 // CHECK-NEXT:   "command-line": [
 // CHECK-NEXT: "-cc1"
+// CHECK-NOT:  "-dwarf-debug-flags"
+// CHECK-NOT:  "-main-file-name"
 // CHECK-NOT:  "-include"
 // CHECK:],
 // CHECK-NEXT:   "context-hash": "[[HASH_MOD_HEADER:.*]]",
Index: clang/test/ClangScanDeps/Inputs/removed-args/cdb.json.template
===
--- clang/test/ClangScanDeps/Inputs/removed-args/cdb.json.template
+++ clang/test/ClangScanDeps/Inputs/removed-args/cdb.json.template
@@ -1,7 +1,7 @@
 [
   {
 "directory": "DIR",
-"command": "clang -fsyntax-only DIR/tu.c 

[clang] 0b83a18 - [AArch64] Enablement of Cortex-X2

[David Green via cfe-commits]

Author: Mubashar Ahmad
Date: 2021-11-01T11:55:24Z
New Revision: 0b83a18a2b9db9c23082e8751c3a66ef37fc626f

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

LOG: [AArch64] Enablement of Cortex-X2

Enables support for Cortex-X2 cores.

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/test/Driver/aarch64-cpus.c
clang/test/Misc/target-invalid-cpu-note.c
llvm/include/llvm/Support/AArch64TargetParser.def
llvm/lib/Target/AArch64/AArch64.td
llvm/lib/Target/AArch64/AArch64Subtarget.cpp
llvm/lib/Target/AArch64/AArch64Subtarget.h
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index b4595b20def53..ba15803e6f482 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -193,6 +193,8 @@ Arm and AArch64 Support in Clang
 
 - Support has been added for the following processors (command-line 
identifiers in parentheses):
   - Arm Cortex-A510 (``cortex-a510``)
+  - Arm Cortex-X2 (``cortex-x2``)
+
 - The -mtune flag is no longer ignored for AArch64. It is now possible to
   tune code generation for a particular CPU with -mtune without setting any
   architectural features. For example, compiling with
@@ -200,7 +202,6 @@ Arm and AArch64 Support in Clang
   architecture features, but will enable certain optimizations specific to
   Cortex-A57 CPUs and enable the use of a more accurate scheduling model.
 
-
 Internal API Changes
 
 

diff  --git a/clang/test/Driver/aarch64-cpus.c 
b/clang/test/Driver/aarch64-cpus.c
index 4f049c79dac1b..1c64e34608377 100644
--- a/clang/test/Driver/aarch64-cpus.c
+++ b/clang/test/Driver/aarch64-cpus.c
@@ -404,6 +404,15 @@
 // RUN: %clang -target aarch64 -mcpu=cortex-a510+crypto -### -c %s 2>&1 | 
FileCheck -check-prefix=CORTEX-A510-CRYPTO %s
 // CORTEX-A510-CRYPTO: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+sm4" "-target-feature" "+sha3" "-target-feature" "+sha2" 
"-target-feature" "+aes"
 
+// RUN: %clang -target aarch64 -mcpu=cortex-x2 -### -c %s 2>&1 | FileCheck 
-check-prefix=CORTEX-X2 %s
+// CORTEX-X2: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "cortex-x2"
+// CORTEX-X2-NOT: "-target-feature" "{{[+-]}}sm4"
+// CORTEX-X2-NOT: "-target-feature" "{{[+-]}}sha3"
+// CORTEX-X2-NOT: "-target-feature" "{{[+-]}}aes"
+// CORTEX-X2-SAME: {{$}}
+// RUN: %clang -target aarch64 -mcpu=cortex-x2+crypto -### -c %s 2>&1 | 
FileCheck -check-prefix=CORTEX-X2-CRYPTO %s
+// CORTEX-X2-CRYPTO: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+sm4" "-target-feature" "+sha3" "-target-feature" "+sha2" "-target-feature" 
"+aes"
+
 // RUN: %clang -target aarch64_be -mcpu=cortex-a57 -### -c %s 2>&1 | FileCheck 
-check-prefix=CA57-BE %s
 // RUN: %clang -target aarch64 -mbig-endian -mcpu=cortex-a57 -### -c %s 2>&1 | 
FileCheck -check-prefix=CA57-BE %s
 // RUN: %clang -target aarch64_be -mbig-endian -mcpu=cortex-a57 -### -c %s 
2>&1 | FileCheck -check-prefix=CA57-BE %s

diff  --git a/clang/test/Misc/target-invalid-cpu-note.c 
b/clang/test/Misc/target-invalid-cpu-note.c
index efdc92263e7e9..62aabab678172 100644
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ b/clang/test/Misc/target-invalid-cpu-note.c
@@ -5,11 +5,11 @@
 
 // RUN: not %clang_cc1 -triple arm64--- -target-cpu not-a-cpu -fsyntax-only %s 
2>&1 | FileCheck %s --check-prefix AARCH64
 // AARCH64: error: unknown target CPU 'not-a-cpu'
-// AARCH64-NEXT: note: valid target CPU values are: cortex-a34, cortex-a35, 
cortex-a53, cortex-a55, cortex-a510, cortex-a57, cortex-a65, cortex-a65ae, 
cortex-a72, cortex-a73, cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, 
cortex-a78, cortex-a78c, cortex-r82, cortex-x1, neoverse-e1, neoverse-n1, 
neoverse-n2, neoverse-512tvb, neoverse-v1, cyclone, apple-a7, apple-a8, 
apple-a9, apple-a10, apple-a11, apple-a12, apple-a13, apple-a14, apple-m1, 
apple-s4, apple-s5, exynos-m3, exynos-m4, exynos-m5, falkor, saphira, kryo, 
thunderx2t99, thunderx3t110, thunderx, thunderxt88, thunderxt81, thunderxt83, 
tsv110, a64fx, carmel{{$}}
+// AARCH64-NEXT: note: valid target CPU values are: cortex-a34, cortex-a35, 
cortex-a53, cortex-a55, cortex-a510, cortex-a57, cortex-a65, cortex-a65ae, 
cortex-a72, cortex-a73, cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, 
cortex-a78, cortex-a78c, cortex-r82, cortex-x1, cortex-x2, neoverse-e1, 
neoverse-n1, neoverse-n2, neoverse-512tvb, neoverse-v1, cyclone, apple-a7, 
apple-a8, apple-a9, apple-a10, apple-a11, apple-a12, apple-a13, apple-a14, 
apple-m1, apple-s4, apple-s5, exynos-m3, exynos-m4, exynos-m5, falkor, saphira, 
kryo, thunderx2t99, thunderx3t110, thunderx, thunderxt88, thunderxt81, 
thunderxt83, tsv110, a64fx, carmel{

[PATCH] D112459: [AArch64] Enablement of Cortex-X2

[Dave Green 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 rG0b83a18a2b9d: [AArch64] Enablement of Cortex-X2 (authored by 
mubashar_, committed by dmgreen).

Changed prior to commit:
  https://reviews.llvm.org/D112459?vs=382309&id=383780#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112459

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/Driver/aarch64-cpus.c
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1008,6 +1008,17 @@
  AArch64::AEK_DOTPROD | AArch64::AEK_RCPC |
  AArch64::AEK_SSBS,
  "8.2-A"),
+ARMCPUTestParams("cortex-x2", "armv9-a", "neon-fp-armv8",
+ AArch64::AEK_CRC | AArch64::AEK_FP |
+ AArch64::AEK_SIMD | AArch64::AEK_RAS |
+ AArch64::AEK_LSE | AArch64::AEK_RDM |
+ AArch64::AEK_RCPC | AArch64::AEK_SVE2 |
+ AArch64::AEK_DOTPROD | AArch64::AEK_MTE |
+ AArch64::AEK_PAUTH | AArch64::AEK_I8MM |
+ AArch64::AEK_BF16 | AArch64::AEK_SVE2BITPERM |
+ AArch64::AEK_SSBS | AArch64::AEK_SB |
+ AArch64::AEK_FP16FML,
+ "9-A"),
 ARMCPUTestParams("cyclone", "armv8-a", "crypto-neon-fp-armv8",
  AArch64::AEK_NONE | AArch64::AEK_CRYPTO |
  AArch64::AEK_FP | AArch64::AEK_SIMD,
@@ -1197,7 +1208,7 @@
  AArch64::AEK_LSE | AArch64::AEK_RDM,
  "8.2-A")));
 
-static constexpr unsigned NumAArch64CPUArchs = 50;
+static constexpr unsigned NumAArch64CPUArchs = 51;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.h
+++ llvm/lib/Target/AArch64/AArch64Subtarget.h
@@ -62,6 +62,7 @@
 CortexA78C,
 CortexR82,
 CortexX1,
+CortexX2,
 ExynosM3,
 Falkor,
 Kryo,
Index: llvm/lib/Target/AArch64/AArch64Subtarget.cpp
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -104,6 +104,10 @@
   case CortexX1:
 PrefFunctionLogAlignment = 4;
 break;
+  case CortexX2:
+PrefFunctionLogAlignment = 4;
+VScaleForTuning = 1;
+break;
   case A64FX:
 CacheLineSize = 256;
 PrefFunctionLogAlignment = 3;
Index: llvm/lib/Target/AArch64/AArch64.td
===
--- llvm/lib/Target/AArch64/AArch64.td
+++ llvm/lib/Target/AArch64/AArch64.td
@@ -691,6 +691,12 @@
   FeatureFuseAES,
   FeaturePostRAScheduler]>;
 
+def TuneX2 : SubtargetFeature<"cortex-x2", "ARMProcFamily", "CortexX2",
+  "Cortex-X2 ARM processors", [
+  FeatureFuseAES,
+  FeaturePostRAScheduler,
+  FeatureCmpBccFusion]>;
+
 def TuneA64FX : SubtargetFeature<"a64fx", "ARMProcFamily", "A64FX",
  "Fujitsu A64FX processors", [
  FeaturePostRAScheduler,
@@ -941,6 +947,10 @@
   list X1   = [HasV8_2aOps, FeatureCrypto, FeatureFPARMv8,
  FeatureNEON, FeatureRCPC, FeaturePerfMon,
  FeatureSPE, FeatureFullFP16, FeatureDotProd];
+  list X2   = [HasV9_0aOps, FeatureNEON, FeaturePerfMon,
+ FeatureMatMulInt8, FeatureBF16, FeatureAM,
+ FeatureMTE, FeatureETE, FeatureSVE2BitPerm,
+ FeatureFP16FML];
   list A64FX= [HasV8_2aOps, FeatureFPARMv8, FeatureNEON,
  FeatureSHA2, FeaturePerfMon, FeatureFullFP16,
  FeatureSVE, FeatureComplxNum];
@@ -1049,6 +1059,8 @@
  [TuneR82]>;
 def : ProcessorModel<"cortex-x1", CortexA57Model, ProcessorFeatures.X1,
  [TuneX1]>;
+def : ProcessorModel<"cortex-x2", CortexA57Model, ProcessorF

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D107049#3099941 , @v.g.vassilev 
wrote:

> Can you also paste the configure output of cmake?

Attached in file.txt F20006228: file.txt 


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

https://reviews.llvm.org/D107049

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[wangpc via Phabricator via cfe-commits]

pcwang-thead updated this revision to Diff 383781.
pcwang-thead added a comment.
Herald added a project: clang-tools-extra.

Fix errors in 
clang-tools-extra\test\clang-tidy\checkers\misc-new-delete-overloads.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

Files:
  clang-tools-extra/test/clang-tidy/checkers/misc-new-delete-overloads.cpp
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/AST/ast-dump-expr.cpp
  clang/test/CodeGenCXX/cxx1y-sized-deallocation.cpp
  clang/test/CodeGenCXX/cxx2a-destroying-delete.cpp
  clang/test/CodeGenCXX/delete-two-arg.cpp
  clang/test/CodeGenCXX/delete.cpp
  clang/test/CodeGenCXX/new.cpp
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-cleanup.cpp
  clang/test/CodeGenCoroutines/coro-gro.cpp
  clang/test/SemaCXX/builtin-operator-new-delete.cpp
  clang/test/SemaCXX/unavailable_aligned_allocation.cpp
  clang/unittests/StaticAnalyzer/CallEventTest.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -578,12 +578,11 @@
 
 
 
-(7): In Clang 3.7 and later, sized deallocation is only enabled
-if the user passes the -fsized-deallocation flag. The user must
-supply definitions of the sized deallocation functions, either by providing them
-explicitly or by using a C++ standard library that does. libstdc++
-added these functions in version 5.0, and libc++ added them in
-version 3.7.
+(7): The user must supply definitions of the sized deallocation
+functions, either by providing them explicitly or by using a C++ standard library
+that does. libstdc++ added these functions in version 5.0, and
+libc++ added them in version 3.7. The user can also use the
+-fno-sized-deallocation option to disable sized deallocation.
 
 
 
Index: clang/unittests/StaticAnalyzer/CallEventTest.cpp
===
--- clang/unittests/StaticAnalyzer/CallEventTest.cpp
+++ clang/unittests/StaticAnalyzer/CallEventTest.cpp
@@ -81,7 +81,7 @@
 }
   )",
  Diags));
-  EXPECT_EQ(Diags, "test.CXXDeallocator: NumArgs: 1\n");
+  EXPECT_EQ(Diags, "test.CXXDeallocator: NumArgs: 2\n");
 }
 
 } // namespace
Index: clang/test/SemaCXX/unavailable_aligned_allocation.cpp
===
--- clang/test/SemaCXX/unavailable_aligned_allocation.cpp
+++ clang/test/SemaCXX/unavailable_aligned_allocation.cpp
@@ -1,15 +1,15 @@
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DMACOS %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DMACOS %s
-// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DIOS %s
-// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DTVOS %s
-// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple armv7k-apple-watchos3.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DWATCHOS %s
-// RUN: %clang_cc1 -triple armv7k-apple-watchos3.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DZOS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DZOS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DMACOS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -std=c++1z -verify -DNO_ERRORS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DMACOS %s
+// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fno-sized-deallocation -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DIOS %s
+// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fno-sized-deallocation -fexceptions -std=c++1z -verify -DNO_ERRORS %s
+// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fno-sized-deallocation -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DTVOS %s
+// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fno-si

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added reviewers: rsmith, rjmccall, erichkeane, aaron.ballman.
aaron.ballman added a comment.

Adding some reviewers for visibility.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

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

[PATCH] D112903: [C++20] [Module] Fix front end crashes when trying to export a type out of a module

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: erichkeane.
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7784-7785
   "because namespace %1 does not enclose namespace %2">;
+def err_invalid_declarator_in_export : Error<"cannot export %0 here "
+  "because it had be declared in %1.">;
 def err_invalid_declarator_global_scope : Error<

I think this diagnostic text is more clear based on the standards text you 
cited. This would also come with a note diagnostic to point to the previous 
declaration.



Comment at: clang/lib/Sema/SemaDecl.cpp:5748-5750
+else if (isa(Cur))
+  Diag(Loc, diag::err_invalid_declarator_in_export)
+  << Name << cast(DC) << SS.getRange();

I don't believe this is sufficient to cover [module.interface]p6. I tried out 
the example from the paragraph in the standard and we still silently accept it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112903

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

[PATCH] D109372: [RISCV][RFC] Add Clang support for RISC-V overlay system

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

There are still unhandled comments in the patch, btw.




Comment at: clang/include/clang/Basic/Attr.td:1797
+def RISCVOverlayCall : InheritableAttr {
+  let Spellings = [GCC<"overlaycall">];
+  let Subjects = SubjectList<[Function]>;

aaron.ballman wrote:
> Does GCC support this attribute? If not, this should be using the `Clang` 
> spelling (same below).
> 
> Also, `overlaycall` is pretty hard to read; why not `overlay_call` and 
> `overlay_data`?
Still wondering about the naming choice.



Comment at: clang/include/clang/Basic/Attr.td:1798
+  let Spellings = [GCC<"overlaycall">];
+  let Subjects = SubjectList<[Function]>;
+  let LangOpts = [RISCVOverlayFunctions];

aaron.ballman wrote:
> What about Objective-C methods?
And still wondering about ObjC methods for `RISCVOverlayCallAttr`.



Comment at: clang/include/clang/Basic/AttrDocs.td:2149
+  let Content = [{
+``__attribute__((overlaycall))`` indicates that a function resides in an
+overlay and therefore any calls to or from that function must be handled

edward-jones wrote:
> jrtc27 wrote:
> > Why not just a single attribute that DTRT based on the type?
> Good point. I'll see if I can do that. The fact we used multiple attributes 
> is mainly a consequence of how we put this together rather than any inherent 
> technical need I think.
I'm confused as to why this is two attributes again. I think using a single 
attribute makes more sense if they're both documented to be exactly the same 
thing.

Also, this is missing information about the data overlay restrictions (that it 
be a global constant variable), and examples. Further, these docs aren't really 
telling me why I'd use this attribute. Are there other docs we should be 
linking to that describe what an overlay is, etc?



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1883-1885
+  // Overlay functions must have a minimum 4-byte alignment.
+  if (F->getAlignment() < 4 && D->hasAttr())
+F->setAlignment(llvm::Align(4));

We should probably document that this attribute changes the function alignment.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:2043-2047
+  if (!S.getLangOpts().Overlay) {
+S.Diag(AL.getRange().getBegin(), diag::warn_attribute_ignored_overlay)
+<< AL;
+return;
+  }

This should be a `LangOpt` in Attr.td and not use a custom diagnostic. However, 
there is an interesting feature idea hiding in here for a follow-up patch, 
which is to generate a better diagnostic about which lang opt is required to 
enable the attribute.


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

https://reviews.llvm.org/D109372

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

[PATCH] D112221: Mark ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT as deprecated

[Erich Keane via Phabricator via cfe-commits]

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

These look fine, I was hoping that someone else from library would take a look, 
but it looks right ot me.


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

https://reviews.llvm.org/D112221

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[wangpc via Phabricator via cfe-commits]

pcwang-thead updated this revision to Diff 383789.
pcwang-thead added a comment.
Herald added subscribers: usaxena95, kadircet, arphaman.

Add `-fno-sized-allocation` to:

- `clang\test\AST\ast-dump-expr-json.cpp`
- `clang\test\AST\ast-dump-stmt-json.cpp`
- `clang\test\CodeGenCXX\dllimport.cpp`
- `clang\test\SemaCXX\MicrosoftExtensions.cpp`
- `clang-tools-extra/clangd/unittests/FindTargetTests.cpp`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

Files:
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/test/clang-tidy/checkers/misc-new-delete-overloads.cpp
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/AST/ast-dump-expr-json.cpp
  clang/test/AST/ast-dump-expr.cpp
  clang/test/AST/ast-dump-stmt-json.cpp
  clang/test/CodeGenCXX/cxx1y-sized-deallocation.cpp
  clang/test/CodeGenCXX/cxx2a-destroying-delete.cpp
  clang/test/CodeGenCXX/delete-two-arg.cpp
  clang/test/CodeGenCXX/delete.cpp
  clang/test/CodeGenCXX/dllimport.cpp
  clang/test/CodeGenCXX/new.cpp
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-cleanup.cpp
  clang/test/CodeGenCoroutines/coro-gro.cpp
  clang/test/SemaCXX/MicrosoftExtensions.cpp
  clang/test/SemaCXX/builtin-operator-new-delete.cpp
  clang/test/SemaCXX/unavailable_aligned_allocation.cpp
  clang/unittests/StaticAnalyzer/CallEventTest.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -578,12 +578,11 @@
 
 
 
-(7): In Clang 3.7 and later, sized deallocation is only enabled
-if the user passes the -fsized-deallocation flag. The user must
-supply definitions of the sized deallocation functions, either by providing them
-explicitly or by using a C++ standard library that does. libstdc++
-added these functions in version 5.0, and libc++ added them in
-version 3.7.
+(7): The user must supply definitions of the sized deallocation
+functions, either by providing them explicitly or by using a C++ standard library
+that does. libstdc++ added these functions in version 5.0, and
+libc++ added them in version 3.7. The user can also use the
+-fno-sized-deallocation option to disable sized deallocation.
 
 
 
Index: clang/unittests/StaticAnalyzer/CallEventTest.cpp
===
--- clang/unittests/StaticAnalyzer/CallEventTest.cpp
+++ clang/unittests/StaticAnalyzer/CallEventTest.cpp
@@ -81,7 +81,7 @@
 }
   )",
  Diags));
-  EXPECT_EQ(Diags, "test.CXXDeallocator: NumArgs: 1\n");
+  EXPECT_EQ(Diags, "test.CXXDeallocator: NumArgs: 2\n");
 }
 
 } // namespace
Index: clang/test/SemaCXX/unavailable_aligned_allocation.cpp
===
--- clang/test/SemaCXX/unavailable_aligned_allocation.cpp
+++ clang/test/SemaCXX/unavailable_aligned_allocation.cpp
@@ -1,15 +1,15 @@
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DMACOS %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DMACOS %s
-// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DIOS %s
-// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DTVOS %s
-// RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple armv7k-apple-watchos3.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DWATCHOS %s
-// RUN: %clang_cc1 -triple armv7k-apple-watchos3.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DZOS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple s390x-none-zos -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DZOS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DMACOS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -std=c++1z -verify -DNO_ERRORS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fno-sized-deallocation -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify -DMACOS %s
+// RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fno-siz

[PATCH] D112491: Add `LambdaCapture`-related matchers.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

+1 to removing the old versions of these matchers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112491

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

[PATCH] D112491: Add `LambdaCapture`-related matchers.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:4630-4632
+/// lambdaExpr(hasAnyCapture(lambdaCapture(refersToVarDecl(hasName("x",
+/// refersToVarDecl(hasName("x")) matches `int x` and `x = 1`.
+AST_MATCHER_P(LambdaCapture, capturesVar, internal::Matcher,

update to new matcher name.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:4650
+/// \endcode
+/// lambdaExpr(hasAnyCapture(lambdaCapture(refersToThis(
+///   matches `[this]() { return cc; }`.





Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:4629-4630
+///   matches `[x](){}`.
+AST_MATCHER_P(LambdaCapture, refersToVarDecl, internal::Matcher,
+  InnerMatcher) {
+  auto *capturedVar = Node.getCapturedVar();

aaron.ballman wrote:
> jcking1034 wrote:
> > aaron.ballman wrote:
> > > jcking1034 wrote:
> > > > ymandel wrote:
> > > > > aaron.ballman wrote:
> > > > > > The name here is a bit unclear -- whether it is the matcher 
> > > > > > matching `int x;` or the `x` from the capture is not clear from the 
> > > > > > name. The comment suggests it's matching `x` from the capture, but 
> > > > > > I think it's actually matching the `int x;` variable declaration.
> > > > > > 
> > > > > > Being clear on what's matched here is important when we think about 
> > > > > > initializers:
> > > > > > ```
> > > > > > void foo() {
> > > > > >   int x = 12;
> > > > > >   auto f = [x = 100](){};
> > > > > > }
> > > > > > ```
> > > > > > and
> > > > > > ```
> > > > > > lambdaExpr(hasAnyCapture(lambdaCapture(refersToVarDecl(hasName("x"),
> > > > > >  hasInitializer(integerLiteral(equals(100))
> > > > > > ```
> > > > > > Would you expect this to match? (This might be a good test case to 
> > > > > > add.)
> > > > > In a similar vein, do we want a separate matcher on the name of the 
> > > > > capture itself? e.g. an overload of `hasName`? And what about 
> > > > > matchers for the initializers?  Those don't have to land in this 
> > > > > patch, but do you think those would be doable?
> > > > I would expect @aaron.ballman's initializer example to match, and I 
> > > > added a similar test case to the one  described. I think that if a 
> > > > capture does not have an initializer, then `refersToVarDecl` will match 
> > > > on the variable declaration before the lambda. However, if a capture 
> > > > does have an initializer, that initializer itself seems to be 
> > > > represented as a `VarDecl` in the AST, which is the `VarDecl` that gets 
> > > > matched.
> > > > 
> > > > For that reason, I think we may not need to have a separate matcher on 
> > > > the name of the capture itself. Additionally, since captures 
> > > > with/without initializers are both represented the same way, there may 
> > > > not be a good way to distinguish between them, so matchers for 
> > > > initializers may not be possible.
> > > > I think that if a capture does not have an initializer, then 
> > > > refersToVarDecl will match on the variable declaration before the 
> > > > lambda. However, if a capture does have an initializer, that 
> > > > initializer itself seems to be represented as a VarDecl in the AST, 
> > > > which is the VarDecl that gets matched.
> > > 
> > > Oof, that'd be confusing! :-(
> > > 
> > > > For that reason, I think we may not need to have a separate matcher on 
> > > > the name of the capture itself.
> > > 
> > > Er, but there are init captures where you can introduce a whole new 
> > > declaration. I think we do want to be able to match on that, right? e.g.,
> > > ```
> > > [x = 12](){ return x; }();
> > > ```
> > > 
> > > > Additionally, since captures with/without initializers are both 
> > > > represented the same way, there may not be a good way to distinguish 
> > > > between them, so matchers for initializers may not be possible.
> > > 
> > > That's a bummer! :-( If this turns out to be a limitation, we should 
> > > probably document it as such.
> > For the example you've provided, these can be matched with the 
> > `refersToVarDecl` matcher, as seen in the test 
> > `LambdaCaptureTest_BindsToCaptureWithInitializer`. I've gone ahead and 
> > updated the documentation to include an example with an initializer.
> > 
> > Having that limitation with initializer representation is definitely a 
> > concern, though. Looking through the [[ 
> > https://clang.llvm.org/doxygen/LambdaCapture_8h_source.html | source ]] for 
> > the `LambdaCapture` class, the documentation for the `DeclAndBits` (line 
> > 42-48) suggests that there isn't a distinguishment between the two cases. 
> > However, do you think it's feasible to update the classes related to 
> > `LambdaCapture` obtain and store this information (possibly through 
> > updating the `LambdaCaptureKind` enum, updating the constructor/fields of 
> > the class, etc)?
> > However, do you think it's feasible to update the classes related t

[PATCH] D112906: [PowerPC] Emit warning for ieeelongdouble on older GNU toolchain

[Jinsong Ji via Phabricator via cfe-commits]

jsji added inline comments.



Comment at: clang/test/Driver/ppc-float-abi-warning.cpp:2
+// REQUIRES: powerpc-registered-target
+// RUN: %clang -### -x c++ -target powerpc64le-unknown-linux-gnu %s 
-mabi=ieeelongdouble
+

Can we add RUN line to test when we are using libc++?



Comment at: clang/test/Driver/ppc-float-abi-warning.cpp:4
+
+// expected-warning{{float ABI 'ieeelongdouble' is not supported by current 
C++ stdlib}}
+

So this assume that all our buildbots are using old glibc? What if we have 
mixed envs, eg: some with newer glibc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112906

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

[clang] 838d8d1 - [AIX][NFC] Unsupported object-c test

[Jinsong Ji via cfe-commits]

Author: Jinsong Ji
Date: 2021-11-01T13:44:23Z
New Revision: 838d8d1e2b93ae89d4edfdc5da58f7622f1b1c71

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

LOG: [AIX][NFC] Unsupported object-c test

Added: 


Modified: 
clang/test/Modules/merge-objc-interface-visibility.m

Removed: 




diff  --git a/clang/test/Modules/merge-objc-interface-visibility.m 
b/clang/test/Modules/merge-objc-interface-visibility.m
index 181a2c716c6b3..a075611a420c8 100644
--- a/clang/test/Modules/merge-objc-interface-visibility.m
+++ b/clang/test/Modules/merge-objc-interface-visibility.m
@@ -4,6 +4,7 @@
 // RUN:-fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t/modules.cache
 // RUN: %clang_cc1 -emit-llvm -o %t/test.bc -F%t/Frameworks %t/test.m 
-DHIDDEN_FIRST=0 \
 // RUN:-fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t/modules.cache
+// UNSUPPORTED: -zos, -aix
 
 // Test a case when Objective-C interface is imported both as hidden and as 
visible.
 



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

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:1936
+if (LangOpts.SYCLIsDevice || (LangOpts.OpenMP && LangOpts.OpenMPIsDevice))
+  CheckDeviceType(Ty);
+

erichkeane wrote:
> Should this be a return, or do we still intend the device invocations to go 
> through the below checks too?  
> 
> If so, please write a test for that.
It should be fine either way. New diagnostics are disabled if 
`TI.hasLongDoubleType` and `TI.hasFPReturn` return "true", as expected for SYCL 
and OpenMP device targets.

Added a test for SYCL, OpenMP already has tests with `long double` type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic updated this revision to Diff 383794.
asavonic added a comment.

- Added a test for SYCL.
- Excluded functions marked with C++ `delete` from the check.
- Moved the check function from `ActOnFunctionDeclarator` to 
`ActOnFinishFunctionBody`, because the deleted/defaulted property is not yet 
available in `ActOnFunctionDeclarator`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/x86-no-x87.cpp
  clang/test/Sema/x86_64-no-x87.cpp
  clang/test/SemaSYCL/float128.cpp

Index: clang/test/SemaSYCL/float128.cpp
===
--- clang/test/SemaSYCL/float128.cpp
+++ clang/test/SemaSYCL/float128.cpp
@@ -22,6 +22,8 @@
   C.field1 = A;
 }
 
+long double ld_func(long double arg);
+
 void usage() {
   // expected-note@+1 3{{'A' defined here}}
   __float128 A;
@@ -48,6 +50,9 @@
 float F2 = 0.1f;
 // expected-error@+1 3{{expression requires 128 bit size '__float128' type support, but target 'spir64' does not support it}}
 float F3 = ((__float128)F1 * (__float128)F2) / 2.0f;
+
+// assume that long double is supported
+float F4 = ld_func(F3);
   };
 
   // expected-note@+1 {{called by 'usage'}}
Index: clang/test/Sema/x86_64-no-x87.cpp
===
--- /dev/null
+++ clang/test/Sema/x86_64-no-x87.cpp
@@ -0,0 +1,145 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple x86_64-linux-gnu -target-feature -x87
+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple x86_64-linux-gnu -DNOERROR
+
+#ifdef NOERROR
+// expected-no-diagnostics
+#endif
+
+typedef long double long_double;
+
+// Declaration is fine, unless it is called or defined.
+double decl(long_double x, long_double y);
+
+template 
+T decl_ld_del(T);
+
+// No code is generated for deleted functions
+long_double decl_ld_del(long_double) = delete;
+double decl_ld_del(double) = delete;
+float decl_ld_del(float) = delete;
+
+#ifndef NOERROR
+// expected-error@+4{{'def' requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+// expected-note@+3{{'def' defined here}}
+// expected-note@+2{{'x' defined here}}
+#endif
+int def(long_double x) {
+#ifndef NOERROR
+// expected-error@+2{{'x' requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+#endif
+  return (int)x;
+}
+
+#ifndef NOERROR
+// expected-note@+3{{'ld_args' defined here}}
+// expected-note@+2{{'ld_args' defined here}}
+#endif
+int ld_args(long_double x, long_double y);
+
+int call1(float x, float y) {
+#ifndef NOERROR
+  // expected-error@+2 2{{'ld_args' requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+#endif
+  return ld_args(x, y);
+}
+
+#ifndef NOERROR
+// expected-note@+2{{'ld_ret' defined here}}
+#endif
+long_double ld_ret(double x, double y);
+
+int call2(float x, float y) {
+#ifndef NOERROR
+  // expected-error@+2{{'ld_ret' requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+#endif
+  return (int)ld_ret(x, y);
+}
+
+int binop(double x, double y) {
+#ifndef NOERROR
+  // expected-error@+2 2{{expression requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+#endif
+  double z = (long_double)x * (long_double)y;
+  return (int)z;
+}
+
+void assign1(long_double *ret, double x) {
+#ifndef NOERROR
+  // expected-error@+2{{expression requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+#endif
+  *ret = x;
+}
+
+struct st_long_double1 {
+#ifndef NOERROR
+  // expected-note@+2{{'ld' defined here}}
+#endif
+  long_double ld;
+};
+
+struct st_long_double2 {
+#ifndef NOERROR
+  // expected-note@+2{{'ld' defined here}}
+#endif
+  long_double ld;
+};
+
+struct st_long_double3 {
+#ifndef NOERROR
+  // expected-note@+2{{'ld' defined here}}
+#endif
+  long_double ld;
+};
+
+void assign2() {
+  struct st_long_double1 st;
+#ifndef NOERROR
+  // expected-error@+3{{expression requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+  // expected-error@+2{{'ld' requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-gnu' does not support it}}
+#endif
+  st.ld = 0.42;
+}
+
+void assign3() {
+  struct st_long_double2 st;
+#ifndef NOERROR
+  // expected-error@+3{{expression requires  'long_double' (aka 'long double') type support, but target 'x86_64-unknown-linux-g

[PATCH] D112645: [OpenMP] Fix: opposite attributes could be set by -fno-inline

[Joseph Huber via Phabricator via cfe-commits]

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

LGTM.




Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:5370
   if (CGM.getCodeGenOpts().OptimizationLevel != 0)
 Fn->addFnAttr(llvm::Attribute::AlwaysInline);
   return Fn;

igor.kirillov wrote:
> I noticed that here we set this attribute on the same function that is 
> created by `emitOutlinedFunctionPrologue` but there AlwaysInline attribute is 
> guaranteed to be set under same condition. So I suppose we could remove this 
> piece of code?
Yeah, you can remove this.



Comment at: clang/test/OpenMP/parallel_for_noinline.cpp:1
+// RUN: %clang -O0 -fopenmp -fno-inline %s -S -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-O0
+// RUN: %clang -O1 -fopenmp -fno-inline %s -S -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-O1

This can probably be merged with the other test added in D107649 since it's the 
same problem, just add another run line and run the update script.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112645

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Hyeongyu Kim via Phabricator via cfe-commits]

hyeongyukim added a comment.

I checked the reason for failure in address sanitizer tests on the 2-stage 
aarch64 buildbots.
The buildbot failure was occured because the `internal_clone` function of the 
`compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp` file is being compiled 
incorrectly.
The `internal_clone` function is a simple function that calls the clone system 
call of Linux. Its original return value should be the PID of the newly created 
process, but the actual returned value is 220 (which is the `__NR_clone` value.)

The aarch64 assembly changed by this patch is as follows.

  // before
  84: d2801b88  mov x8, #0xdc                   // #0xdc(220): system call 
number of clone
  88: d401  svc #0x0                        // system call
  ...
  a4: a9434ff4  ldp x20, x19, [sp, #48]
  a8: a94257f6  ldp x22, x21, [sp, #32]
  ac: a9415ff8  ldp x24, x23, [sp, #16]
  b0: a8c467fe  ldp x30, x25, [sp], #64
  b4: d65f03c0  ret
  
  =
  // after
  88: d2801b88  mov x8, #0xdc                   // #0xdc(220): system call 
number of clone
  8c: d401  svc #0x0                        // system call
  ...
  a8: a9434ff4  ldp x20, x19, [sp, #48]
  ac: aa0803e0  mov x0, x8                      // return value(x0) was 
overwritten by 0xdc(220)
  b0: a94257f6  ldp x22, x21, [sp, #32]
  b4: a9415ff8  ldp x24, x23, [sp, #16]
  b8: a8c467fe  ldp x30, x25, [sp], #64
  bc: d65f03c0  ret

Does anyone know why the `internal_clone` function of aarch64 is affected by 
this patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D112401: [Clang] Mutate printf bulitin names under IEEE128 on PPC64

[Jinsong Ji via Phabricator via cfe-commits]

jsji accepted this revision as: jsji.
jsji added a comment.
This revision is now accepted and ready to land.

LGTM. Please hold a few days to see whether there are inputs from other 
reviewers. Thanks.




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:100
+  static SmallDenseMap F128Builtins{
+  {Builtin::BI__builtin_printf, "__printfieee128"},
+  {Builtin::BI__builtin_vsnprintf, "__vsnprintfieee128"},

qiucf wrote:
> jsji wrote:
> > Why only these printf builtins? I think there are full list of similar 
> > libcalls in `GLIBC_2.32` and later?
> Yes, Glibc redirects all these functions depending on long double semantics, 
> and GCC has corresponding builtins for almost all library functions 
> (https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html).
> 
> But currently clang doesn't have all of these builtins (for example, 
> `__builtin_scanf`). It seems beyond this patch's scope to make the list 
> complete.
OK. Thanks. Can we add a TODO note.


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

https://reviews.llvm.org/D112401

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

[PATCH] D112881: [clang-tidy] Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

Please mention improvement in Release Notes, in `Changes in existing checks` 
section. See example 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112881

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

[PATCH] D112847: [AIX][Clang] Fix XL product name in AIX XL compatibility warning

[Rafik Zurob via Phabricator via cfe-commits]

rzurob requested changes to this revision.
rzurob added a comment.
This revision now requires changes to proceed.

Please change to "IBM XL C/C++ for AIX 16.1.0".  i.e. No ", V".  Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112847

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

[PATCH] D111443: [Driver] Fix ToolChain::getSanitizerArgs

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

ping. I have made changes so that the diagnostics about sanitizer args are only 
emitted once. Any further changes or concerns? Thanks.


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

https://reviews.llvm.org/D111443

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

[PATCH] D112492: [HIP] Do not use kernel handle for MSVC target

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

ping


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

https://reviews.llvm.org/D112492

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

[PATCH] D112929: [Clang] For VFE, emit vtable ranges in !vcall_visibility metadata

[Kuba (Brecka) Mracek via Phabricator via cfe-commits]

kubamracek created this revision.
kubamracek added reviewers: rjmccall, pcc, fhahn.
kubamracek added a project: clang.
kubamracek requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112929

Files:
  clang/lib/CodeGen/CGVTables.cpp
  clang/test/CodeGenCXX/vcall-visibility-metadata-ranges.cpp
  clang/test/CodeGenCXX/vcall-visibility-metadata.cpp

Index: clang/test/CodeGenCXX/vcall-visibility-metadata.cpp
===
--- clang/test/CodeGenCXX/vcall-visibility-metadata.cpp
+++ clang/test/CodeGenCXX/vcall-visibility-metadata.cpp
@@ -8,7 +8,7 @@
 
 // Anonymous namespace.
 namespace {
-// CHECK: @_ZTVN12_GLOBAL__N_11AE = {{.*}} !vcall_visibility [[VIS_TU:![0-9]+]]
+// CHECK: @_ZTVN12_GLOBAL__N_11AE = {{.*}} !vcall_visibility [[VIS_TU_A:![0-9]+]]
 // CHECK-MS: @anon.{{.*}} = private unnamed_addr constant {{.*}}struct.(anonymous namespace)::A{{.*}} !vcall_visibility [[VIS_TU:![0-9]+]]
 struct A {
   A() {}
@@ -21,7 +21,7 @@
 
 
 // Hidden visibility.
-// CHECK: @_ZTV1B = {{.*}} !vcall_visibility [[VIS_DSO:![0-9]+]]
+// CHECK: @_ZTV1B = {{.*}} !vcall_visibility [[VIS_DSO_B:![0-9]+]]
 // CHECK-MS: @anon.{{.*}} = private unnamed_addr constant {{.*}}struct.B{{.*}} !vcall_visibility [[VIS_DSO:![0-9]+]]
 struct __attribute__((visibility("hidden"))) B {
   B() {}
@@ -100,8 +100,8 @@
 
 // CHECK-MS-DAG: [[VIS_DSO]] = !{i64 1}
 // CHECK-MS-DAG: [[VIS_TU]] = !{i64 2}
-// CHECK-DAG: [[VIS_DSO]] = !{i64 1}
-// CHECK-DAG: [[VIS_TU]] = !{i64 2}
+// CHECK-DAG: [[VIS_DSO_B]] = !{i64 1, i64 16, i64 24}
+// CHECK-DAG: [[VIS_TU_A]] = !{i64 2, i64 16, i64 24}
 // CHECK-VFE-DAG: !{i32 1, !"Virtual Function Elim", i32 1}
 // CHECK-NOVFE-DAG: !{i32 1, !"Virtual Function Elim", i32 0}
 
Index: clang/test/CodeGenCXX/vcall-visibility-metadata-ranges.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/vcall-visibility-metadata-ranges.cpp
@@ -0,0 +1,85 @@
+// RUN: %clang_cc1 -flto -flto-unit -triple x86_64-unknown-linux -emit-llvm -fvirtual-function-elimination -fwhole-program-vtables -fno-rtti -o - %s | FileCheck %s
+
+//
+// (1) Base class with DSO visibility
+//
+
+class __attribute__((visibility("hidden"))) Base1 {
+  virtual void baseFunc() { }
+};
+void *new_Base1() { return new Base1(); }
+
+// CHECK:  @_ZTV5Base1 = {{.*}} constant { [3 x i8*] } { [3 x i8*] [
+// CHECK-SAME:   i8* null
+// CHECK-SAME:   i8* null
+// CHECK-SAME:   i8* bitcast (void (%class.Base1*)* @_ZN5Base18baseFuncEv to i8*)
+// CHECK-SAME: ] }, {{.*}} !vcall_visibility [[VIS_BASE1:![0-9]+]]
+
+
+
+//
+// (2) A subclass with TU visibility, so the vtable should have one part with DSO visibility (from the superclass) and one part with TU visibility
+//
+
+namespace {
+class Sub : public Base1 {
+  virtual void baseFunc() { }
+  virtual void subOnlyFunc() { }
+};
+}
+void *new_Sub() { return new Sub(); }
+
+// CHECK:  @_ZTVN12_GLOBAL__N_13SubE = {{.*}} constant { [4 x i8*] } { [4 x i8*] [
+// CHECK-SAME:   i8* null
+// CHECK-SAME:   i8* null
+// CHECK-SAME:   i8* bitcast (void (%"class.(anonymous namespace)::Sub"*)* @_ZN12_GLOBAL__N_13Sub8baseFuncEv to i8*)
+// CHECK-SAME:   i8* bitcast (void (%"class.(anonymous namespace)::Sub"*)* @_ZN12_GLOBAL__N_13Sub11subOnlyFuncEv to i8*)
+// CHECK-SAME: ] }, {{.*}}, !vcall_visibility [[VIS_SUB:![0-9]+]]
+
+
+
+//
+// (3) A subclass with multiple inheritance
+//
+
+namespace {
+struct __attribute__((visibility("hidden"))) Base2 {
+  virtual void secondBaseFunc() { }
+};
+}
+void *new_Base2() { return new Base2(); }
+
+namespace {
+class MultipleInheritanceSub : public Base1, public Base2 {
+  virtual void baseFunc() { }
+  virtual void secondBaseFunc() { }
+  virtual void anotherSubOnlyFunc() { }
+};
+}
+void *new_MultipleInheritanceSub() { return new MultipleInheritanceSub(); }
+
+// CHECK:  @_ZTVN12_GLOBAL__N_122MultipleInheritanceSubE = {{.*}} constant { [5 x i8*], [3 x i8*] } {
+// CHECK-SAME:   [5 x i8*] [
+// CHECK-SAME: i8* null,
+// CHECK-SAME  i8* null, 
+// CHECK-SAME: i8* bitcast (void (%"class.(anonymous namespace)::MultipleInheritanceSub"*)* @_ZN12_GLOBAL__N_122MultipleInheritanceSub8baseFuncEv to i8*), 
+// CHECK-SAME: i8* bitcast (void (%"class.(anonymous namespace)::MultipleInheritanceSub"*)* @_ZN12_GLOBAL__N_122MultipleInheritanceSub14secondBaseFuncEv to i8*), 
+// CHECK-SAME: i8* bitcast (void (%"class.(anonymous namespace)::MultipleInheritanceSub"*)* @_ZN12_GLOBAL__N_122MultipleInheritanceSub18anotherSubOnlyFuncEv to i8*)
+// CHECK-SAME:   ],
+// CHECK-SAME:   [3 x i8*] [
+// CHECK-SAME: i8* inttoptr (i64 -8 to i8*),
+// CHECK-SAME: i8* null, 
+// CHECK-SAME: i8* bitcast (void (%"class.(anonymous namespace)::MultipleInheritanceSub"*)* @_ZThn8_N12_GLOBAL__N_122MultipleInheritanceSub14secondBaseFuncEv to i8*)
+// CHECK-SAME:   ]
+// CHECK-SAME: }, {{.*}}, !vcall_visibility [[VIS_MUL_BASE1:![0-9]+]], !vcall_vi

[PATCH] D112647: [clang-apply-replacements] Correctly handle relative paths

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

Overall, this looks ok, but I don't feel like I'm qualified to approve this 
patch, since I'm not really familiar w/ how this tool is used in practice. Some 
comments nonetheless:

> Those relative paths are meant to be resolved relative to the corresponding 
> build directory.

Is this behavior documented somewhere?




Comment at: 
clang-tools-extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:156
+const tooling::TranslationUnitDiagnostics *SourceTU,
+const std::string *buildDir) {
 // Use the file manager to deduplicate paths. FileEntries are

let's use an optional -- when populated, we have to copy it anyhow, so there's 
nothing gained by passing by pointer, and it comes at the cost of a nullable 
pointer.



Comment at: 
clang-tools-extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:159
 // automatically canonicalized.
+auto &WorkingDir = SM.getFileManager().getFileSystemOpts().WorkingDir;
+auto PrevWorkingDir = WorkingDir;

Why are you capturing this as a reference? This is a subtle and IMO error prone 
pattern, since it's not obvious in the code below that you're mutating a deeply 
nested element of the filesystem.  Can  you instead use a local variable and 
just set this right before you need it?



Comment at: 
clang-tools-extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:162
+if (buildDir) {
+  WorkingDir = *buildDir;
+}

assuming this is now an optional.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112647

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

[PATCH] D112847: [AIX][Clang] Fix XL product name in AIX XL compatibility warning

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA updated this revision to Diff 383804.
ZarkoCA added a comment.

- Remove V from version number


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112847

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/test/Sema/aix-attr-align.c


Index: clang/test/Sema/aix-attr-align.c
===
--- clang/test/Sema/aix-attr-align.c
+++ clang/test/Sema/aix-attr-align.c
@@ -10,11 +10,11 @@
 };
 
 struct T {
-  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with AIX XL 16.1 and older}}
+  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with IBM XL C/C++ for AIX, 16.1.0 and older}}
 };
 
 struct U {
-  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with AIX XL 16.1 and older}}
+  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with IBM XL C/C++ for AIX, 16.1.0 and older}}
 };
 
 int a[8] __attribute__((aligned(8)));  // no-warning
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3277,7 +3277,8 @@
   InGroup>;
 def warn_not_xl_compatible
 : Warning<"requesting an alignment of 16 bytes or greater for struct"
-  " members is not binary compatible with AIX XL 16.1 and older">,
+  " members is not binary compatible with IBM XL C/C++ for AIX,"
+  " 16.1.0 and older">,
   InGroup;
 def warn_redeclaration_without_attribute_prev_attribute_ignored : Warning<
   "%q0 redeclared without %1 attribute: previous %1 ignored">,


Index: clang/test/Sema/aix-attr-align.c
===
--- clang/test/Sema/aix-attr-align.c
+++ clang/test/Sema/aix-attr-align.c
@@ -10,11 +10,11 @@
 };
 
 struct T {
-  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with AIX XL 16.1 and older}}
+  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX, 16.1.0 and older}}
 };
 
 struct U {
-  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with AIX XL 16.1 and older}}
+  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX, 16.1.0 and older}}
 };
 
 int a[8] __attribute__((aligned(8)));  // no-warning
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3277,7 +3277,8 @@
   InGroup>;
 def warn_not_xl_compatible
 : Warning<"requesting an alignment of 16 bytes or greater for struct"
-  " members is not binary compatible with AIX XL 16.1 and older">,
+  " members is not binary compatible with IBM XL C/C++ for AIX,"
+  " 16.1.0 and older">,
   InGroup;
 def warn_redeclaration_without_attribute_prev_attribute_ignored : Warning<
   "%q0 redeclared without %1 attribute: previous %1 ignored">,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112847: [AIX][Clang] Fix XL product name in AIX XL compatibility warning

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA updated this revision to Diff 383805.
ZarkoCA added a comment.

- Remove comma from product name


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112847

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/test/Sema/aix-attr-align.c


Index: clang/test/Sema/aix-attr-align.c
===
--- clang/test/Sema/aix-attr-align.c
+++ clang/test/Sema/aix-attr-align.c
@@ -10,11 +10,11 @@
 };
 
 struct T {
-  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with AIX XL 16.1 and older}}
+  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with IBM XL C/C++ for AIX 16.1.0 and older}}
 };
 
 struct U {
-  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with AIX XL 16.1 and older}}
+  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with IBM XL C/C++ for AIX 16.1.0 and older}}
 };
 
 int a[8] __attribute__((aligned(8)));  // no-warning
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3277,7 +3277,8 @@
   InGroup>;
 def warn_not_xl_compatible
 : Warning<"requesting an alignment of 16 bytes or greater for struct"
-  " members is not binary compatible with AIX XL 16.1 and older">,
+  " members is not binary compatible with IBM XL C/C++ for AIX"
+  " 16.1.0 and older">,
   InGroup;
 def warn_redeclaration_without_attribute_prev_attribute_ignored : Warning<
   "%q0 redeclared without %1 attribute: previous %1 ignored">,


Index: clang/test/Sema/aix-attr-align.c
===
--- clang/test/Sema/aix-attr-align.c
+++ clang/test/Sema/aix-attr-align.c
@@ -10,11 +10,11 @@
 };
 
 struct T {
-  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with AIX XL 16.1 and older}}
+  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX 16.1.0 and older}}
 };
 
 struct U {
-  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with AIX XL 16.1 and older}}
+  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX 16.1.0 and older}}
 };
 
 int a[8] __attribute__((aligned(8)));  // no-warning
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3277,7 +3277,8 @@
   InGroup>;
 def warn_not_xl_compatible
 : Warning<"requesting an alignment of 16 bytes or greater for struct"
-  " members is not binary compatible with AIX XL 16.1 and older">,
+  " members is not binary compatible with IBM XL C/C++ for AIX"
+  " 16.1.0 and older">,
   InGroup;
 def warn_redeclaration_without_attribute_prev_attribute_ignored : Warning<
   "%q0 redeclared without %1 attribute: previous %1 ignored">,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D95168: [clang-format] Add InsertBraces option

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

HazardyKnusperkeks added a comment.

In D95168#3099920 , @owenpan wrote:

> In D95168#3099739 , @MyDeveloperDay 
> wrote:
>
>> - Look further into possible Removal (I have an idea for how this might be 
>> possible, and super useful for LLVM where we don't like single if {} ), I'd 
>> like to round out on this before introducing the options rather than having 
>> to change them later
>>
>> - Should we add the possibility of removal should we change the option name 
>> to "AutomaticBraces" (thoughts?)
>
> As mentioned in D95168#3039033 , I 
> think it would be better to handle the removal separately. The LLVM Coding 
> Standards has an entire section 
> 
>  about this. Some of the listed exceptions/examples there can make things 
> more difficult.

Difficult, yes. But I think it should be in one option.
It hasn't to be implemented everything right from the start. And we could give 
all those cases a name and a different setting, so that the entire document 
would be mappable to a `.clang-format` with a convenience setting for all 
options at once.


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

https://reviews.llvm.org/D95168

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

[PATCH] D112932: [WIP] Use llvm.is_fpclass to implement FP classification functions

[Serge Pavlov via Phabricator via cfe-commits]

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

Builtin floating-point number classification functions:

- __builtin_isnan,
- __builtin_isinf,
- __builtin_finite, and
- __builtin_isnormal

now are implemented using `llvm.is_fpclass`. New builtin functions were
added:

- __builtin_issubnormal,
- __builtin_iszero, and
- __builtin_issignaling.

They represent corresponding standard C library finctions and are also
implemented using `llvm.is_fpclass`.
The hook `testFPKind` from `TargetInfo` is removed.

New builting function `__builtin_isfpclass` is added. It is called as:

  __builtin_isfpclass(, )

and returns integer value, which is non-zero if the floating point
argument belongs to one of the classes specified by the first argument,
and zero otherwise. The first argument is an integer value, where each
value class is represented by one bit. There are ten data classes, as
defined by the IEEE-754 standard.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112932

Files:
  clang/include/clang/Basic/Builtins.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h

Index: clang/lib/CodeGen/TargetInfo.h
===
--- clang/lib/CodeGen/TargetInfo.h
+++ clang/lib/CodeGen/TargetInfo.h
@@ -127,16 +127,6 @@
 return Address;
   }
 
-  /// Performs a target specific test of a floating point value for things
-  /// like IsNaN, Infinity, ... Nullptr is returned if no implementation
-  /// exists.
-  virtual llvm::Value *
-  testFPKind(llvm::Value *V, unsigned BuiltinID, CGBuilderTy &Builder,
- CodeGenModule &CGM) const {
-assert(V->getType()->isFloatingPointTy() && "V should have an FP type.");
-return nullptr;
-  }
-
   /// Corrects the low-level LLVM type for a given constraint and "usual"
   /// type.
   ///
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -7319,48 +7319,6 @@
   SystemZTargetCodeGenInfo(CodeGenTypes &CGT, bool HasVector, bool SoftFloatABI)
   : TargetCodeGenInfo(
 std::make_unique(CGT, HasVector, SoftFloatABI)) {}
-
-  llvm::Value *testFPKind(llvm::Value *V, unsigned BuiltinID,
-  CGBuilderTy &Builder,
-  CodeGenModule &CGM) const override {
-assert(V->getType()->isFloatingPointTy() && "V should have an FP type.");
-// Only use TDC in constrained FP mode.
-if (!Builder.getIsFPConstrained())
-  return nullptr;
-
-llvm::Type *Ty = V->getType();
-if (Ty->isFloatTy() || Ty->isDoubleTy() || Ty->isFP128Ty()) {
-  llvm::Module &M = CGM.getModule();
-  auto &Ctx = M.getContext();
-  llvm::Function *TDCFunc =
-  llvm::Intrinsic::getDeclaration(&M, llvm::Intrinsic::s390_tdc, Ty);
-  unsigned TDCBits = 0;
-  switch (BuiltinID) {
-  case Builtin::BI__builtin_isnan:
-TDCBits = 0xf;
-break;
-  case Builtin::BIfinite:
-  case Builtin::BI__finite:
-  case Builtin::BIfinitef:
-  case Builtin::BI__finitef:
-  case Builtin::BIfinitel:
-  case Builtin::BI__finitel:
-  case Builtin::BI__builtin_isfinite:
-TDCBits = 0xfc0;
-break;
-  case Builtin::BI__builtin_isinf:
-TDCBits = 0x30;
-break;
-  default:
-break;
-  }
-  if (TDCBits)
-return Builder.CreateCall(
-TDCFunc,
-{V, llvm::ConstantInt::get(llvm::Type::getInt64Ty(Ctx), TDCBits)});
-}
-return nullptr;
-  }
 };
 }
 
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -2223,6 +2223,82 @@
   }
 }
 
+static Value *callIsFPClass(CodeGenFunction *CGF, const CallExpr *E,
+StringRef Check) {
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(*CGF, E);
+  const Expr *Arg = E->getNumArgs() == 1 ? E->getArg(0) : E->getArg(1);
+  Value *V = CGF->EmitScalarExpr(Arg);
+  Function *F = CGF->CGM.getIntrinsic(Intrinsic::is_fpclass, V->getType());
+  auto MDArg = llvm::MDString::get(CGF->getLLVMContext(), Check);
+  return CGF->Builder.CreateCall(
+  F, {V, MetadataAsValue::get(CGF->getLLVMContext(), MDArg)});
+}
+
+enum FPClassCheck {
+  fcBad = 0,
+  fcSNan = 0x0001,
+  fcQNan = 0x0002,
+  fcNegInf = 0x0004,
+  fcNegNormal = 0x0008,
+  fcNegSubnormal = 0x0010,
+  fcNegZero = 0x0020,
+  fcPosZero = 0x0040,
+  fcPosSubnormal = 0x0080,
+  fcPosNormal = 0x0100,
+  fcPosInf = 0x0200,
+
+  fcNan = fcSNan | fcQNan,
+  fcInf = fcPosInf | fcNegInf,
+  fcNormal = fcPosNormal | fcNegNormal,
+  fcSubnormal = fcPosSubnormal | fcNegSubnormal,
+  fcZero = fcPosZero | fcNegZero,
+  fcPosFinite = fcPosNormal | f

[PATCH] D112850: [clang] 'unused-but-set-variable' warning should not apply to __block objective-c pointers

[Michael Benfield via Phabricator via cfe-commits]

mbenfield added a comment.

This seems reasonable to me, but I don't know Objective C. Presumably someone 
who does should accept.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112850

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

[PATCH] D110927: [analyzer] Access stored value of a constant array through a pointer to another type

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov updated this revision to Diff 383812.
ASDenysPetrov added a comment.

Updated according to comments.
TODO: make the feature `-fno-strict-aliasing` dependent.


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

https://reviews.llvm.org/D110927

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/initialization.cpp

Index: clang/test/Analysis/initialization.cpp
===
--- clang/test/Analysis/initialization.cpp
+++ clang/test/Analysis/initialization.cpp
@@ -4,6 +4,10 @@
 void clang_analyzer_dump(T x);
 void clang_analyzer_eval(int);
 
+namespace std {
+enum class byte : unsigned char {};
+};
+
 struct S {
   int a = 3;
 };
@@ -256,3 +260,55 @@
   clang_analyzer_eval(glob_arr9[1][2] == 7); // expected-warning{{TRUE}}
   clang_analyzer_eval(glob_arr9[1][3] == 0); // expected-warning{{TRUE}}
 }
+
+void glob_cast_same1() {
+  auto *ptr = (int *)glob_arr2;
+  auto x1 = ptr[0]; // no-warning
+  auto x2 = ptr[1]; // no-warning
+}
+
+void glob_cast_char1() {
+  const auto *ptr = (char *)glob_arr2; // 1-dim array to char*
+  auto x1 = ptr[0];// no-warning
+  auto x2 = ptr[1];// expected-warning{{garbage or undefined}}
+}
+
+void glob_cast_char2() {
+  const auto *ptr = (char *)glob_arr5; // 2-dim array to char*
+  auto x1 = ptr[0];// no-warning
+  // FIXME: Should warn {{garbage or undefined}}.
+  auto x2 = ptr[1]; // no-warning
+}
+
+void glob_cast_uchar1() {
+  auto *ptr = (unsigned char *)glob_arr2;
+  auto x1 = ptr[0]; // no-warning
+  auto x2 = ptr[1]; // expected-warning{{garbage or undefined}}
+}
+
+void glob_cast_byte1() {
+  auto *ptr = (const std::byte *)glob_arr2;
+  auto x1 = ptr[0]; // no-warning
+  auto x2 = ptr[1]; // expected-warning{{garbage or undefined}}
+}
+
+void glob_cast_opposite_sign1() {
+  auto *ptr = (unsigned int *)glob_arr2;
+  auto x1 = ptr[0]; // no-warning
+  auto x2 = ptr[1]; // expected-warning{{garbage or undefined}}
+}
+
+void glob_cast_invalid1() {
+  auto *ptr = (signed char *)glob_arr2;
+  auto x = ptr[0]; // expected-warning{{garbage or undefined}}
+}
+
+void glob_cast_invalid2() {
+  using T = short *;
+  auto x = ((T)glob_arr2)[0]; // expected-warning{{garbage or undefined}}
+}
+
+void glob_cast_invalid3() {
+  auto *ptr = (char32_t *)glob_arr2;
+  auto x = ptr[0]; // expected-warning{{garbage or undefined}}
+}
Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -446,6 +446,8 @@
   QualType ElemT);
   SVal getSValFromStringLiteral(const StringLiteral *SL, uint64_t Offset,
 QualType ElemT);
+  bool canAccessStoredValue(QualType OrigT, QualType ThroughT,
+uint64_t Index) const;
 
 public: // Part of public interface to class.
 
@@ -1651,6 +1653,20 @@
   return Extents;
 }
 
+/// This is a helper function for `getConstantValFromConstArrayInitializer`.
+///
+/// Return a root type of the n-dimensional array.
+///
+/// E.g. for `const int[1][2][3];` returns `int`.
+QualType getConstantArrayRootElement(const ConstantArrayType *CAT) {
+  assert(CAT && "ConstantArrayType should not be null");
+  while (const auto *DummyCAT =
+ dyn_cast(CAT->getElementType())) {
+CAT = DummyCAT;
+  }
+  return CAT->getElementType();
+}
+
 /// This is a helper function for `getConstantValFromConstArrayInitializer`.
 ///
 /// Return an array of offsets from nested ElementRegions. The array is never
@@ -1736,6 +1752,60 @@
   return None;
 }
 
+/// Returns true if the stored value can be accessed through the pointer to
+/// another type.
+///
+/// C++20 7.2.1.11 [basic.lval] (excerpt):
+///  A program can access the stored value of an object through:
+///  - the same type of the object;
+///  - a signed or unsigned type corresponding to the type of the
+///object;
+///  - a char, unsigned char, std::byte. (NOTE:
+///  Otherwise, the behavior is undefined.
+///
+/// Example:
+///  const int arr[42] = {};
+///  auto* pchar = (char*)arr;
+///  auto* punsigned = (unsigned int*)arr;
+///  auto* pshort= (short*)arr;
+///  auto x1 = pchar[0]; // valid
+///  auto x2 = pchar[1]; // UB
+///  auto x3 = punsigned[0]; // valid
+///  auto x4 = pshort[0];// UB
+bool RegionStoreManager::canAccessStoredValue(QualType OrigT, QualType ThroughT,
+  uint64_t Index) const {
+  // Remove cv-qualifiers.
+  OrigT = OrigT->getCanonicalTypeUnqualified();
+  ThroughT = ThroughT->getCanonicalTypeUnqualified();
+
+  // - is same
+  if (OrigT == ThroughT)
+return true;
+
+  // NOTE: C++20 6.8.2(3.4) [basic.compound]:
+  //  An object of type T that is not an array element is considered to
+  //  belong to an array with ONE el

[PATCH] D112732: [ASan] Removed AddressSanitizerPass function pass class and rolled it into the module pass for the new pass mangager only.

[Kirill Stoimenov via Phabricator via cfe-commits]

kstoimenov updated this revision to Diff 383819.
kstoimenov added a comment.

Fixed remaing 2 tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112732

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Passes/PassRegistry.def
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/SanitizerCoverage/tracing-comdat.ll
  llvm/test/Other/new-pm-print-pipeline.ll
  llvm/tools/opt/NewPMDriver.cpp

Index: llvm/tools/opt/NewPMDriver.cpp
===
--- llvm/tools/opt/NewPMDriver.cpp
+++ llvm/tools/opt/NewPMDriver.cpp
@@ -340,19 +340,16 @@
   PB.registerPipelineParsingCallback(
   [](StringRef Name, ModulePassManager &MPM,
  ArrayRef) {
-AddressSanitizerOptions Opts;
 if (Name == "asan-pipeline") {
   MPM.addPass(
   RequireAnalysisPass());
-  MPM.addPass(
-  createModuleToFunctionPassAdaptor(AddressSanitizerPass(Opts)));
   MPM.addPass(ModuleAddressSanitizerPass());
   return true;
 } else if (Name == "asan-function-pipeline") {
+  // FIXME: now this is the same as asan-pipeline and can me removed.
   MPM.addPass(
   RequireAnalysisPass());
-  MPM.addPass(
-  createModuleToFunctionPassAdaptor(AddressSanitizerPass(Opts)));
+  MPM.addPass(ModuleAddressSanitizerPass());
   return true;
 }
 return false;
Index: llvm/test/Other/new-pm-print-pipeline.ll
===
--- llvm/test/Other/new-pm-print-pipeline.ll
+++ llvm/test/Other/new-pm-print-pipeline.ll
@@ -46,8 +46,8 @@
 ; RUN: opt -disable-output -disable-verify -print-pipeline-passes -passes='module(hwasan<>,hwasan)' < %s | FileCheck %s --match-full-lines --check-prefixes=CHECK-14
 ; CHECK-14: hwasan<>,hwasan
 
-; RUN: opt -disable-output -disable-verify -print-pipeline-passes -passes='function(asan<>,asan)' < %s | FileCheck %s --match-full-lines --check-prefixes=CHECK-15
-; CHECK-15: function(asan<>,asan)
+; RUN: opt -disable-output -disable-verify -print-pipeline-passes -passes='module(asan-module<>,asan-module)' < %s | FileCheck %s --match-full-lines --check-prefixes=CHECK-15
+; CHECK-15: asan-module<>,asan-module
 
 ; RUN: opt -disable-output -disable-verify -print-pipeline-passes -passes='module(loop-extract<>,loop-extract)' < %s | FileCheck %s --match-full-lines --check-prefixes=CHECK-16
 ; CHECK-16: loop-extract<>,loop-extract
Index: llvm/test/Instrumentation/SanitizerCoverage/tracing-comdat.ll
===
--- llvm/test/Instrumentation/SanitizerCoverage/tracing-comdat.ll
+++ llvm/test/Instrumentation/SanitizerCoverage/tracing-comdat.ll
@@ -2,7 +2,7 @@
 ; Make sure asan does not instrument __sancov_gen_
 
 ; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=3 -sanitizer-coverage-trace-pc-guard  -S  | FileCheck %s
-; RUN: opt < %s -passes='module(require,sancov-module,asan-module),function(asan)' -sanitizer-coverage-level=3 -sanitizer-coverage-trace-pc-guard  -S  | FileCheck %s
+; RUN: opt < %s -passes='module(require,sancov-module,asan-module)' -sanitizer-coverage-level=3 -sanitizer-coverage-trace-pc-guard  -S  | FileCheck %s
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
 $Foo = comdat any
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -1254,35 +1254,6 @@
   return GlobalsMetadata(M);
 }
 
-PreservedAnalyses AddressSanitizerPass::run(Function &F,
-AnalysisManager &AM) {
-  auto &MAMProxy = AM.getResult(F);
-  Module &M = *F.getParent();
-  if (auto *R = MAMProxy.getCachedResult(M)) {
-const TargetLibraryInfo *TLI = &AM.getResult(F);
-AddressSanitizer Sanitizer(M, R, Options.CompileKernel, Options.Recover,
-   Options.UseAfterScope, Options.UseAfterReturn);
-if (Sanitizer.instrumentFunction(F, TLI))
-  return PreservedAnalyses::none();
-return PreservedAnalyses::all();
-  }
-
-  report_fatal_error(
-  "The ASanGlobalsMetadataAnalysis is required to run before "
-  "AddressSanitizer can run");
-  return PreservedAnalyses::all();
-}
-
-void AddressSanitizerPass::printPipeline(
-raw_ostream &OS, function_ref MapClassName2PassName) {
-  static_cast *>(this)->printPipeline(
-  OS, MapClassName2PassName);
-  OS << "<";
-  if (Options.CompileKernel)
-OS << "kernel";
-  OS << ">";
-}
-
 void ModuleAddressSanitizerPass::

[PATCH] D112491: Add `LambdaCapture`-related matchers.

[James King via Phabricator via cfe-commits]

jcking1034 updated this revision to Diff 383823.
jcking1034 marked 4 inline comments as done.
jcking1034 added a comment.

Update missed names; remove original implementations of `hasAnyCapture`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112491

Files:
  clang/docs/LibASTMatchersReference.html
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ASTTypeTraits.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
  clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -563,26 +563,6 @@
   objcMessageExpr(hasReceiver(declRefExpr(to(varDecl(hasName("x";
 }
 
-TEST(Matcher, HasAnyCapture) {
-  auto HasCaptureX = lambdaExpr(hasAnyCapture(varDecl(hasName("x";
-  EXPECT_TRUE(matches("void f() { int x = 3; [x](){}; }", HasCaptureX));
-  EXPECT_TRUE(matches("void f() { int x = 3; [&x](){}; }", HasCaptureX));
-  EXPECT_TRUE(notMatches("void f() { [](){}; }", HasCaptureX));
-  EXPECT_TRUE(notMatches("void f() { int z = 3; [&z](){}; }", HasCaptureX));
-  EXPECT_TRUE(
-  notMatches("struct a { void f() { [this](){}; }; };", HasCaptureX));
-}
-
-TEST(Matcher, CapturesThis) {
-  auto HasCaptureThis = lambdaExpr(hasAnyCapture(cxxThisExpr()));
-  EXPECT_TRUE(
-  matches("struct a { void f() { [this](){}; }; };", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { [](){}; }", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { int x = 3; [x](){}; }", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { int x = 3; [&x](){}; }", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { int z = 3; [&z](){}; }", HasCaptureThis));
-}
-
 TEST(Matcher, MatchesMethodsOnLambda) {
   StringRef Code = R"cpp(
 struct A {
Index: clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -2237,6 +2237,65 @@
  varDecl(hasName("ss"), hasTypeLoc(elaboratedTypeLoc();
 }
 
+TEST_P(ASTMatchersTest, LambdaCaptureTest) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [cc](){ return cc; }; }",
+  lambdaExpr(hasAnyCapture(lambdaCapture();
+}
+
+TEST_P(ASTMatchersTest, LambdaCaptureTest_BindsToCaptureOfVarDecl) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(
+  hasAnyCapture(lambdaCapture(capturesVar(varDecl(hasName("cc"));
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [cc](){ return cc; }; }",
+  matcher));
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [&cc](){ return cc; }; }",
+  matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [=](){ return cc; }; }", matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [&](){ return cc; }; }", matcher));
+}
+
+TEST_P(ASTMatchersTest, LambdaCaptureTest_BindsToCaptureWithInitializer) {
+  if (!GetParam().isCXX14OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(hasAnyCapture(lambdaCapture(capturesVar(
+  varDecl(hasName("cc"), hasInitializer(integerLiteral(equals(1;
+  EXPECT_TRUE(
+  matches("int main() { auto lambda = [cc = 1] {return cc;}; }", matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc = 2; auto lambda = [cc = 1] {return cc;}; }",
+  matcher));
+}
+
+TEST_P(ASTMatchersTest, LambdaCaptureTest_DoesNotBindToCaptureOfVarDecl) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(
+  hasAnyCapture(lambdaCapture(capturesVar(varDecl(hasName("cc"));
+  EXPECT_FALSE(matches("int main() { auto f = [](){ return 5; }; }", matcher));
+  EXPECT_FALSE(matches("int main() { int xx; auto f = [xx](){ return xx; }; }",
+   matcher));
+}
+
+TEST_P(ASTMatchersTest,
+   LambdaCaptureTest_DoesNotBindToCaptureWithInitializerAndDifferentName) {
+  if (!GetParam().isCXX14OrLater()) {
+return;
+  }
+  EXPECT_FALSE(matches(
+  "int main() { auto lambda = [xx = 1] {return xx;}; }",
+  lambdaExpr(hasAnyCapture(lambdaCapture(capturesVar(varDecl(
+  hasName("cc"), hasInitializer(integerLiteral(equals(1));
+}
+
 TEST(ASTMatchersTestObjC, ObjCMessageExpr) {
   // Don't find ObjCMessageExpr where none are present.
   EXPECT_TRUE(notMatchesObjC("", objcMessageExpr(anything(;
Index: clang/unittests/ASTM

[clang] 5a8c173 - [clang] Fortify warning for scanf calls with field width too big.

[Michael Benfield via cfe-commits]

Author: Michael Benfield
Date: 2021-11-01T17:17:37Z
New Revision: 5a8c1736289f2b1df10df38e7a9e4d208a7586a6

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

LOG: [clang] Fortify warning for scanf calls with field width too big.

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

Added: 
clang/test/Sema/warn-fortify-scanf.c

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaChecking.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d37c8e9266e9b..8a098d37ec4c3 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -833,6 +833,10 @@ def warn_fortify_source_format_overflow : Warning<
   " but format string expands to at least %2">,
   InGroup;
 
+def warn_fortify_scanf_overflow : Warning<
+  "'%0' may overflow; destination buffer in argument %1 has size "
+  "%2, but the corresponding specifier may require size %3">,
+  InGroup;
 
 /// main()
 // static main() is not an error in C, just in C++.

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index bf458f914c111..8bf696a721027 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -408,6 +408,61 @@ static bool SemaBuiltinCallWithStaticChain(Sema &S, 
CallExpr *BuiltinCall) {
 
 namespace {
 
+class ScanfDiagnosticFormatHandler
+: public analyze_format_string::FormatStringHandler {
+  // Accepts the argument index (relative to the first destination index) of 
the
+  // argument whose size we want.
+  using ComputeSizeFunction =
+  llvm::function_ref(unsigned)>;
+
+  // Accepts the argument index (relative to the first destination index), the
+  // destination size, and the source size).
+  using DiagnoseFunction =
+  llvm::function_ref;
+
+  ComputeSizeFunction ComputeSizeArgument;
+  DiagnoseFunction Diagnose;
+
+public:
+  ScanfDiagnosticFormatHandler(ComputeSizeFunction ComputeSizeArgument,
+   DiagnoseFunction Diagnose)
+  : ComputeSizeArgument(ComputeSizeArgument), Diagnose(Diagnose) {}
+
+  bool HandleScanfSpecifier(const analyze_scanf::ScanfSpecifier &FS,
+const char *StartSpecifier,
+unsigned specifierLen) override {
+unsigned NulByte = 0;
+switch ((FS.getConversionSpecifier().getKind())) {
+default:
+  return true;
+case analyze_format_string::ConversionSpecifier::sArg:
+case analyze_format_string::ConversionSpecifier::ScanListArg:
+  NulByte = 1;
+  break;
+case analyze_format_string::ConversionSpecifier::cArg:
+  break;
+}
+
+auto OptionalFW = FS.getFieldWidth();
+if (OptionalFW.getHowSpecified() !=
+analyze_format_string::OptionalAmount::HowSpecified::Constant)
+  return true;
+
+unsigned SourceSize = OptionalFW.getConstantAmount() + NulByte;
+
+auto DestSizeAPS = ComputeSizeArgument(FS.getArgIndex());
+if (!DestSizeAPS)
+  return true;
+
+unsigned DestSize = DestSizeAPS->getZExtValue();
+
+if (DestSize < SourceSize)
+  Diagnose(FS.getArgIndex(), DestSize, SourceSize);
+
+return true;
+  }
+};
+
 class EstimateSizeFormatHandler
 : public analyze_format_string::FormatStringHandler {
   size_t Size;
@@ -615,9 +670,12 @@ void 
Sema::checkFortifiedBuiltinMemoryFunction(FunctionDecl *FD,
 // (potentially) more strict checking mode. Otherwise, conservatively 
assume
 // type 0.
 int BOSType = 0;
-if (const auto *POS =
-FD->getParamDecl(Index)->getAttr())
-  BOSType = POS->getType();
+// This check can fail for variadic functions.
+if (Index < FD->getNumParams()) {
+  if (const auto *POS =
+  FD->getParamDecl(Index)->getAttr())
+BOSType = POS->getType();
+}
 
 const Expr *ObjArg = TheCall->getArg(Index);
 uint64_t Result;
@@ -642,6 +700,20 @@ void 
Sema::checkFortifiedBuiltinMemoryFunction(FunctionDecl *FD,
   unsigned DiagID = 0;
   bool IsChkVariant = false;
 
+  auto GetFunctionName = [&]() {
+StringRef FunctionName = getASTContext().BuiltinInfo.getName(BuiltinID);
+// Skim off the details of whichever builtin was called to produce a better
+// diagnostic, as it's unlikely that the user wrote the __builtin
+// explicitly.
+if (IsChkVariant) {
+  FunctionName = FunctionName.drop_front(std::strlen("__builtin___"));
+  FunctionName = FunctionName.drop_back(std::strlen("_chk"));
+} else if (FunctionName.startswith("__builtin_")) {
+  FunctionName = FunctionName.drop_front(std::strlen("__builtin_"));
+}
+return FunctionName;
+  };
+
   switch (BuiltinID) {
   def

[PATCH] D111833: [clang] Fortify warning for scanf calls with field width too big.

[Michael Benfield via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5a8c1736289f: [clang] Fortify warning for scanf calls with 
field width too big. (authored by mbenfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111833

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/warn-fortify-scanf.c

Index: clang/test/Sema/warn-fortify-scanf.c
===
--- /dev/null
+++ clang/test/Sema/warn-fortify-scanf.c
@@ -0,0 +1,63 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify
+
+typedef struct _FILE FILE;
+extern int scanf(const char *format, ...);
+extern int fscanf(FILE *f, const char *format, ...);
+extern int sscanf(const char *input, const char *format, ...);
+
+void call_scanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  scanf("%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding specifier may require size 11}}
+  scanf("%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding specifier may require size 12}}
+  scanf("%4s %5s %9s", buf20, buf30, buf10);
+  scanf("%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding specifier may require size 21}}
+  scanf("%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding specifier may require size 22}}
+  scanf("%19s %5s %9s", buf20, buf30, buf10);
+  scanf("%19s %29s %9s", buf20, buf30, buf10);
+
+  scanf("%4[a] %5[a] %10[a]", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding specifier may require size 11}}
+  scanf("%4[a] %5[a] %11[a]", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding specifier may require size 12}}
+  scanf("%4[a] %5[a] %9[a]", buf20, buf30, buf10);
+  scanf("%20[a] %5[a] %9[a]", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding specifier may require size 21}}
+  scanf("%21[a] %5[a] %9[a]", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding specifier may require size 22}}
+  scanf("%19[a] %5[a] %9[a]", buf20, buf30, buf10);
+  scanf("%19[a] %29[a] %9[a]", buf20, buf30, buf10);
+
+  scanf("%4c %5c %10c", buf20, buf30, buf10);
+  scanf("%4c %5c %11c", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding specifier may require size 11}}
+  scanf("%4c %5c %9c", buf20, buf30, buf10);
+  scanf("%20c %5c %9c", buf20, buf30, buf10);
+  scanf("%21c %5c %9c", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding specifier may require size 21}}
+
+  // Don't warn for other specifiers.
+  int x;
+  scanf("%12d", &x);
+}
+
+void call_sscanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  sscanf("a b c", "%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding specifier may require size 11}}
+  sscanf("a b c", "%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding specifier may require size 12}}
+  sscanf("a b c", "%4s %5s %9s", buf20, buf30, buf10);
+  sscanf("a b c", "%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding specifier may require size 21}}
+  sscanf("a b c", "%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding specifier may require size 22}}
+  sscanf("a b c", "%19s %5s %9s", buf20, buf30, buf10);
+  sscanf("a b c", "%19s %29s %9s", buf20, buf30, buf10);
+}
+
+void call_fscanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  fscanf(0, "%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding specifier may require size 11}}
+  fscanf(0, "%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding specifier may require size 12}}
+  fscanf(0, "%

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

Please add a note to clang/docs/ReleaseNotes.rst about the behavior change.

The clangd test failure seems related to this change, and the other ones could 
be as well.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:6405
+  // by default.
+  if (Arg *A = Args.getLastArg(options::OPT_fsized_deallocation,
+   options::OPT_fno_sized_deallocation)) {

Can this be `Args.AddLastArg(CmdArgs, ...);`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

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

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a subscriber: dblaikie.
rnk added a comment.

So, to back up a bit, do I understand correctly that this change adds tests to 
the check-clang test suite that JIT compiles C++ code for the host and throws 
C++ exceptions? Can we reconsider that?

We have a policy of not running execution tests in the clang test suite because 
we know they always turn out to be unreliable, flaky, and highly dependent on 
the environment rather than the code under test. Integration tests are great, 
everyone needs them, but they should definitely not be part of the default set 
of tests that developers run anywhere and everywhere and expect to work out of 
the box, regardless of the environment. +@dblaikie to confirm if I am off base 
here about our testing strategy, and maybe Lang can advise us about past JIT 
testing strategies.


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

https://reviews.llvm.org/D107049

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

[PATCH] D112890: headers: optionalise some generated resource headers

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I think this seems reasonable.

Generally speaking, we have tests in clang that generate IR for targets that 
are not enabled in LLVM. It is kind of nice: you don't have to mark the IRGen 
tests with `REQUIRES: foo-registered-target`. If we want to test these ARM and 
RISCV intrinsic tests in clang, now, they will have to be conditioned on the 
relevant target being enabled. I think that's fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112890

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

[PATCH] D112491: Add `LambdaCapture`-related matchers.

[Matt Kulukundis via Phabricator via cfe-commits]

fowles added a comment.

This is great!




Comment at: clang/docs/LibASTMatchersReference.html:8368
+lambdaExpr(hasAnyCapture(lambdaCapture(capturesVar(hasName("x",
+capturesVar(hasName("x")) matches `int x` and `x = 1`.
 

I think this should be "matches `x` and `x = 1`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112491

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

[PATCH] D112847: [AIX][Clang] Fix XL product name in AIX XL compatibility warning

[Rafik Zurob via Phabricator via cfe-commits]

rzurob accepted this revision.
rzurob 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/D112847/new/

https://reviews.llvm.org/D112847

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

[PATCH] D111863: [libunwind] Add an interface for dynamic .eh_frame registration

[Lang Hames via Phabricator via cfe-commits]

lhames accepted this revision.
lhames added a comment.

@joerg @dim @emaste Any further comments on this?

I'd like @housel to be able to land this this week if possible. It will 
significantly improve the usability of libunwind for JIT clients by giving us 
an API with behavior that is consistent across platforms.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111863

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

[PATCH] D112399: Get Bazel building `//clang` on Windows with clang-cl.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: utils/bazel/.bazelrc:81
+build:windows --copt=/Oi --host_copt=/Oi
+build:windows --cxxopt=/Zc:rvalueCast --host_cxxopt=/Zc:rvalueCast
+

Try adding `/permissive-` to get more conforming behavior from clang-cl. If 
that doesn't work, try `/Zc:twoPhase-`, aka `-fno-delayed-template-parsing`.



Comment at: utils/bazel/.bazelrc:84
+# Use the more flexible bigobj format for C++ files that have lots of symbols.
+build:windows --cxxopt=/bigobj --host_cxxopt=/bigobj
 

This is only necessary for MSVC. LLVM MC auto-detects when bigobj is needed. 
IMO, less flags is always better.



Comment at: utils/bazel/llvm-project-overlay/clang/BUILD.bazel:1828
 ],
-copts = [
-"-Wno-uninitialized",
-],
+copts = select({
+"@bazel_tools//src/conditions:windows": [],

Enabling warnings is good, but what made this change necessary? The `-Wno-` 
flag should have worked with clang-cl. If this change isn't necessary, maybe go 
ahead and delete this copt in a separate commit.



Comment at: 
utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h:81
 /* The LLVM product name and version */
 #define BACKEND_PACKAGE_STRING "LLVM 12.0.0git"
 

chandlerc wrote:
> GMNGeoffrey wrote:
> > rnk wrote:
> > > Unrelated to your change, but is this stale?
> > Yes and we don't currently have a good way to keep it up to date. The 
> > overall problem of how to make sure we keep up to date with CMake configure 
> > knobs is unsolved. I wonder if we could run CMake in some limited capacity, 
> > but that's a whole can of worms...
> I'll just commit an update to this separately. I assume that doesn't need 
> separate review? ;]
Nope, ship it.


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

https://reviews.llvm.org/D112399

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

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab created this revision.
ab added reviewers: rjmccall, ahatanak, bruno, pcc, apazos, kristof.beyls, 
t.p.northover, pbarrio, chill, danielkiss, psmith.
ab added a project: clang.
Herald added subscribers: dexonsmith, zzheng, dang, mgorny.
ab requested review of this revision.

Building on D90868 , this defines the basic 
set of pointer authentication clang builtins (provided in a new header, 
`ptrauth.h`), with diagnostics and IRGen support.
The availability of the builtins is gated on a new flag `-fptrauth-intrinsics`, 
which is enabled by default by the driver for darwin arm64e.

Note that this only includes the basic intrinsics (matching D90868 
), and notably excludes 
`ptrauth_sign_constant`, and 
`ptrauth_type_discriminator`/`ptrauth_string_discriminator`, which need extra 
logic to be fully supported.  If it helps, I can bring the header/sema support 
here so that we can review all builtins together, and do full IRGen later.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112941

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/ptrauth.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/ptrauth-intrinsics.c
  clang/test/Driver/arch-arm64e.c
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h
  clang/test/Modules/ptrauth-include-from-darwin.m
  clang/test/Preprocessor/ptrauth_feature.c
  clang/test/Sema/ptrauth-intrinsics-macro.c
  clang/test/Sema/ptrauth.c

Index: clang/test/Sema/ptrauth.c
===
--- /dev/null
+++ clang/test/Sema/ptrauth.c
@@ -0,0 +1,126 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify -fptrauth-intrinsics %s
+
+#if __has_feature(ptrauth_intrinsics)
+#warning Pointer authentication enabled!
+// expected-warning@-1 {{Pointer authentication enabled!}}
+#endif
+
+#if __aarch64__
+#define VALID_CODE_KEY 0
+#define VALID_DATA_KEY 2
+#define INVALID_KEY 200
+#else
+#error Provide these constants if you port this test
+#endif
+
+#define NULL ((void*) 0)
+struct A { int x; } mismatched_type;
+
+extern int dv;
+extern int fv(int);
+
+void test_strip(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_strip(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_strip(dp, VALID_DATA_KEY, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_strip(NULL, VALID_DATA_KEY); // no warning
+
+  __builtin_ptrauth_strip(mismatched_type, VALID_DATA_KEY); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_strip(dp, mismatched_type); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+
+  int *dr = __builtin_ptrauth_strip(dp, VALID_DATA_KEY);
+  dr = __builtin_ptrauth_strip(dp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  int (*fr)(int) = __builtin_ptrauth_strip(fp, VALID_CODE_KEY);
+  fr = __builtin_ptrauth_strip(fp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  float *mismatch = __builtin_ptrauth_strip(dp, VALID_DATA_KEY); // expected-warning {{incompatible pointer types initializing 'float *' with an expression of type 'int *'}}
+}
+
+void test_blend_discriminator(int *dp, int (*fp)(int), int value) {
+  __builtin_ptrauth_blend_discriminator(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_blend_discriminator(dp, dp, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_blend_discriminator(dp, value); // no warning
+
+  __builtin_ptrauth_blend_discriminator(mismatched_type, value); // expected-error {{blended pointer must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_blend_discriminator(dp, mismatched_type); // expected-error {{blended integer must have integer type; type here is 'struct A'}}
+
+  float *mismatch = __builtin_ptrauth_blend_discriminator(dp, value); // expected-warning {{incompatible integer to pointer conversion initializing 'float *' with an expression o

[PATCH] D112732: [ASan] Removed AddressSanitizerPass function pass class and rolled it into the module pass for the new pass mangager only.

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added inline comments.



Comment at: llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h:92
 
-struct AddressSanitizerOptions {
-  AddressSanitizerOptions()

Why do we need to remove AddressSanitizerOptions?



Comment at: llvm/lib/Passes/PassRegistry.def:139
 "kernel;recover")
 MODULE_PASS_WITH_PARAMS("asan-module",
 "ModuleAddressSanitizerPass",

And I guess now we need to use parseASanPassOptions here? 



Comment at: llvm/lib/Passes/PassRegistry.def:396
   "no-upperbound;upperbound")
-FUNCTION_PASS_WITH_PARAMS("asan",
-  "AddressSanitizerPass",

vitalybuka wrote:
> you should also rename MODULE_PASS_WITH_PARAMS("asan-module",  to just 
> MODULE_PASS_WITH_PARAMS("asan",
I still see asan-module here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112732

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

[clang] dfa0981 - Remove an unused parameter; NFC

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2021-11-01T14:42:00-04:00
New Revision: dfa098140716cc41cfc8b83f3f083008e7219bf9

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

LOG: Remove an unused parameter; NFC

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 2109ff25fe7a..24187367f3d0 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -3182,9 +3182,8 @@ ExprResult Sema::BuildDeclarationNameExpr(const 
CXXScopeSpec &SS,
   return ULE;
 }
 
-static void
-diagnoseUncapturableValueReference(Sema &S, SourceLocation loc,
-   ValueDecl *var, DeclContext *DC);
+static void diagnoseUncapturableValueReference(Sema &S, SourceLocation loc,
+   ValueDecl *var);
 
 /// Complete semantic analysis for a reference to the given declaration.
 ExprResult Sema::BuildDeclarationNameExpr(
@@ -3348,7 +3347,7 @@ ExprResult Sema::BuildDeclarationNameExpr(
 if (BD->getDeclContext() != CurContext) {
   auto *DD = dyn_cast_or_null(BD->getDecomposedDecl());
   if (DD && DD->hasLocalStorage())
-diagnoseUncapturableValueReference(*this, Loc, BD, CurContext);
+diagnoseUncapturableValueReference(*this, Loc, BD);
 }
 break;
   }
@@ -17392,9 +17391,8 @@ void Sema::MarkCaptureUsedInEnclosingContext(VarDecl 
*Capture,
   MarkVarDeclODRUsed(Capture, Loc, *this, &CapturingScopeIndex);
 }
 
-static void
-diagnoseUncapturableValueReference(Sema &S, SourceLocation loc,
-   ValueDecl *var, DeclContext *DC) {
+static void diagnoseUncapturableValueReference(Sema &S, SourceLocation loc,
+   ValueDecl *var) {
   DeclContext *VarDC = var->getDeclContext();
 
   //  If the parameter still belongs to the translation unit, then
@@ -17473,7 +17471,7 @@ static DeclContext 
*getParentOfCapturingContextOrNull(DeclContext *DC, VarDecl *
 return getLambdaAwareParentOfDeclContext(DC);
   else if (Var->hasLocalStorage()) {
 if (Diagnose)
-   diagnoseUncapturableValueReference(S, Loc, Var, DC);
+   diagnoseUncapturableValueReference(S, Loc, Var);
   }
   return nullptr;
 }
@@ -17947,7 +17945,7 @@ bool Sema::tryCaptureVariable(
   Diag(LSI->Lambda->getBeginLoc(), diag::note_lambda_decl);
   buildLambdaCaptureFixit(*this, LSI, Var);
 } else
-  diagnoseUncapturableValueReference(*this, ExprLoc, Var, DC);
+  diagnoseUncapturableValueReference(*this, ExprLoc, Var);
   }
   return true;
 }



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

[PATCH] D112645: [OpenMP] Fix: opposite attributes could be set by -fno-inline

[Igor Kirillov via Phabricator via cfe-commits]

igor.kirillov added inline comments.



Comment at: clang/test/OpenMP/parallel_for_noinline.cpp:1
+// RUN: %clang -O0 -fopenmp -fno-inline %s -S -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-O0
+// RUN: %clang -O1 -fopenmp -fno-inline %s -S -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-O1

jhuber6 wrote:
> This can probably be merged with the other test added in D107649 since it's 
> the same problem, just add another run line and run the update script.
It was my first thought too but I don't see how to check this bug with `#pragma 
omp parallel if(0)`. If I add function with `#pragma omp parallel for` there it 
goes contrary to the test file name (parallel_**if**_codegen_PR51349). More 
than that, checks generated by `update_cc_test_checks.py` are too overwhelming 
and hide whatever we were going to test there. I can do it this way or may be 
you have any other ideas?

What if I rename my file this test file name to 
parallel_**for**_codegen_PR51349.cpp instead? They are related and thus we 
don't loose sight of them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112645

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

[PATCH] D112645: [OpenMP] Fix: opposite attributes could be set by -fno-inline

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/test/OpenMP/parallel_for_noinline.cpp:1
+// RUN: %clang -O0 -fopenmp -fno-inline %s -S -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-O0
+// RUN: %clang -O1 -fopenmp -fno-inline %s -S -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-O1

igor.kirillov wrote:
> jhuber6 wrote:
> > This can probably be merged with the other test added in D107649 since it's 
> > the same problem, just add another run line and run the update script.
> It was my first thought too but I don't see how to check this bug with 
> `#pragma omp parallel if(0)`. If I add function with `#pragma omp parallel 
> for` there it goes contrary to the test file name 
> (parallel_**if**_codegen_PR51349). More than that, checks generated by 
> `update_cc_test_checks.py` are too overwhelming and hide whatever we were 
> going to test there. I can do it this way or may be you have any other ideas?
> 
> What if I rename my file this test file name to 
> parallel_**for**_codegen_PR51349.cpp instead? They are related and thus we 
> don't loose sight of them.
Just adding this triggered the bug for me and hardly generates anything.
```
#pragma omp parallel
  ;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112645

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

[clang] d51a829 - Revert "[clang] Fortify warning for scanf calls with field width too big."

[Michael Benfield via cfe-commits]

Author: Michael Benfield
Date: 2021-11-01T19:36:45Z
New Revision: d51a8296d374122c937df708f5fa1500218baa5c

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

LOG: Revert "[clang] Fortify warning for scanf calls with field width too big."

This reverts commit 5a8c1736289f2b1df10df38e7a9e4d208a7586a6.

The warning needs to correctly handle * specifiers (which are to be
ignored).

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaChecking.cpp

Removed: 
clang/test/Sema/warn-fortify-scanf.c



diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 8a098d37ec4c3..d37c8e9266e9b 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -833,10 +833,6 @@ def warn_fortify_source_format_overflow : Warning<
   " but format string expands to at least %2">,
   InGroup;
 
-def warn_fortify_scanf_overflow : Warning<
-  "'%0' may overflow; destination buffer in argument %1 has size "
-  "%2, but the corresponding specifier may require size %3">,
-  InGroup;
 
 /// main()
 // static main() is not an error in C, just in C++.

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 8bf696a721027..bf458f914c111 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -408,61 +408,6 @@ static bool SemaBuiltinCallWithStaticChain(Sema &S, 
CallExpr *BuiltinCall) {
 
 namespace {
 
-class ScanfDiagnosticFormatHandler
-: public analyze_format_string::FormatStringHandler {
-  // Accepts the argument index (relative to the first destination index) of 
the
-  // argument whose size we want.
-  using ComputeSizeFunction =
-  llvm::function_ref(unsigned)>;
-
-  // Accepts the argument index (relative to the first destination index), the
-  // destination size, and the source size).
-  using DiagnoseFunction =
-  llvm::function_ref;
-
-  ComputeSizeFunction ComputeSizeArgument;
-  DiagnoseFunction Diagnose;
-
-public:
-  ScanfDiagnosticFormatHandler(ComputeSizeFunction ComputeSizeArgument,
-   DiagnoseFunction Diagnose)
-  : ComputeSizeArgument(ComputeSizeArgument), Diagnose(Diagnose) {}
-
-  bool HandleScanfSpecifier(const analyze_scanf::ScanfSpecifier &FS,
-const char *StartSpecifier,
-unsigned specifierLen) override {
-unsigned NulByte = 0;
-switch ((FS.getConversionSpecifier().getKind())) {
-default:
-  return true;
-case analyze_format_string::ConversionSpecifier::sArg:
-case analyze_format_string::ConversionSpecifier::ScanListArg:
-  NulByte = 1;
-  break;
-case analyze_format_string::ConversionSpecifier::cArg:
-  break;
-}
-
-auto OptionalFW = FS.getFieldWidth();
-if (OptionalFW.getHowSpecified() !=
-analyze_format_string::OptionalAmount::HowSpecified::Constant)
-  return true;
-
-unsigned SourceSize = OptionalFW.getConstantAmount() + NulByte;
-
-auto DestSizeAPS = ComputeSizeArgument(FS.getArgIndex());
-if (!DestSizeAPS)
-  return true;
-
-unsigned DestSize = DestSizeAPS->getZExtValue();
-
-if (DestSize < SourceSize)
-  Diagnose(FS.getArgIndex(), DestSize, SourceSize);
-
-return true;
-  }
-};
-
 class EstimateSizeFormatHandler
 : public analyze_format_string::FormatStringHandler {
   size_t Size;
@@ -670,12 +615,9 @@ void 
Sema::checkFortifiedBuiltinMemoryFunction(FunctionDecl *FD,
 // (potentially) more strict checking mode. Otherwise, conservatively 
assume
 // type 0.
 int BOSType = 0;
-// This check can fail for variadic functions.
-if (Index < FD->getNumParams()) {
-  if (const auto *POS =
-  FD->getParamDecl(Index)->getAttr())
-BOSType = POS->getType();
-}
+if (const auto *POS =
+FD->getParamDecl(Index)->getAttr())
+  BOSType = POS->getType();
 
 const Expr *ObjArg = TheCall->getArg(Index);
 uint64_t Result;
@@ -700,20 +642,6 @@ void 
Sema::checkFortifiedBuiltinMemoryFunction(FunctionDecl *FD,
   unsigned DiagID = 0;
   bool IsChkVariant = false;
 
-  auto GetFunctionName = [&]() {
-StringRef FunctionName = getASTContext().BuiltinInfo.getName(BuiltinID);
-// Skim off the details of whichever builtin was called to produce a better
-// diagnostic, as it's unlikely that the user wrote the __builtin
-// explicitly.
-if (IsChkVariant) {
-  FunctionName = FunctionName.drop_front(std::strlen("__builtin___"));
-  FunctionName = FunctionName.drop_back(std::strlen("_chk"));
-} else if (FunctionName.startswith("__builtin_")) {
-  FunctionName = FunctionName.drop_front(std::

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D99#3099988 , @aaron.ballman 
wrote:

> In D99#3097692 , @dblaikie 
> wrote:
>
>> In D99#3096124 , 
>> @aaron.ballman wrote:
>>
>>> In D99#3095623 , 
>>> @yonghong-song wrote:
>>>
> Ah, yeah, I see what you mean - that does seem sort of unfortunate. Is it 
> possible these attributes could only appear on typedefs and they'd be 
> more readily carried through that without needing extra typeloc tracking? 
> (sorry for not having read back through the rest of the review - which 
> may've started there and ended up here as a more general form of the 
> attribute?)

 For the question, "is it possible these attributes could only appear on 
 typedefs?" The answer is "not really possible". We are targeting existing 
 linux kernel where existing type attributes (__user, __rcu, ...) have been 
 used in places other than typedef quite extensively (e.g., function 
 argument type, function return type, field type, etc.).

 In one of my earlier prototypes, I put the tag string itself in 
 AttributedType and with this we can avoid TypeLoc, but I understand this 
 is not conventional usage and that is why we do through TypeLoc mechanism. 
 @aaron.ballman can further comment on this.
>>>
>>> FWIW, I made that request because AttributedTypeLoc stores the Attr * for 
>>> the attributed type, so we can get the attribute argument information from 
>>> that rather than having to duplicate it within a new TypeLoc object.
>>
>> So could the debug info code be done with AttributedType (I guess currently 
>> CGDebugInfo skips over those - but we could not skip over them and check if 
>> it's one of these attributes, otherwise skip) rather than passing around the 
>> extra TypeLoc?
>
> That's my hope, but I wasn't certain if there were type modifications 
> happening where we need to calculate a `TypeLoc` that's different from what 
> we would get out of the type itself. I would expect that doesn't happen 
> during CodeGen (seems awfully late to be changing types), but wasn't 100% 
> sure.

Hmm - not sure I really follow. Is there a greater risk of this than with other 
types we're emitting/lrelying entirely on types and not TypeLocs already? Any 
way we can validate whether this is an issue/is necessary to handle?

Otherwise I'd be inclined to go with the pure Type based solution, maybe leave 
a "watch out for bugs related to type changes" comment somewhere in case bugs 
do come up in the future?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

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

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Lang Hames via Phabricator via cfe-commits]

lhames added a comment.

In D107049#3096727 , @uabelho wrote:

> Hi,
>
> We're seeing a problem with this patch in our downstream (not public) 
> buildbots. With an asan-built compiler we see the following:
>
>   ...
>   10:08:55 [ RUN  ] InterpreterTest.CatchException
>   10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
>   10:08:55 libc++abi: terminating with uncaught exception of type 
> custom_exception
>   ...

I suspect that this is a Linux distro that's using libunwind as the unwinder, 
at least for this test. Linux distros typically use libgcc_s for unwinding. The 
two libraries have different behavior for their `__register_frame` functions: 
libunwind's function expects to be passed a single FDE, libgcc_s's expects to 
be passed an entire .eh_frame section. We try to guess the unwinder in the JIT 
and use the appropriate argument (see [1][2]), but when we get it wrong this is 
often the result: we try to pass an .eh-frame section to libunwind's 
`__register_frame` and it errors out on a CIE at the start of the section.

@uabelho -- In your setup I'm seeing:

  -- Looking for __unw_add_dynamic_fde
  -- Looking for __unw_add_dynamic_fde - not found

So the question is, how are we failing to find `__unw_add_dynamic_fde` during 
config, only to crash in it during the test? Is use of libunwind on your 
platform expected?

side note: Peter Housel recently posted https://reviews.llvm.org/D111863 to add 
a new registration API with consistent behavior. Hopefully in the future we can 
rely on dynamic detection of this to eliminate the issue for users of future 
libunwinds.

In D107049#3100630 , @rnk wrote:

> So, to back up a bit, do I understand correctly that this change adds tests 
> to the check-clang test suite that JIT compiles C++ code for the host and 
> throws C++ exceptions? Can we reconsider that?
>
> We have a policy of not running execution tests in the clang test suite 
> because we know they always turn out to be unreliable, flaky, and highly 
> dependent on the environment rather than the code under test. Integration 
> tests are great, everyone needs them, but they should definitely not be part 
> of the default set of tests that developers run anywhere and everywhere and 
> expect to work out of the box, regardless of the environment. +@dblaikie to 
> confirm if I am off base here about our testing strategy, and maybe Lang can 
> advise us about past JIT testing strategies.

The JIT has always used execution tests. It's difficult to test the JIT 
properly without them, since it doesn't have persistent output.

In practice the trick has always been to tighten the criteria for where these 
can run until things stabilize. We're seeing more failures on the test cases 
that Vassil is writing because he's pushing the boundaries of ORC's feature 
set, but I think the solution should still be the same: fix the JIT when we 
find bugs there, and restrict the tests to environments where they're expected 
to pass.

[1] 
https://github.com/llvm/llvm-project/commit/957334382cd12ec07b46c0ddfdcc220731f6d80f
[2] https://llvm.org/PR44074


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

https://reviews.llvm.org/D107049

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

[PATCH] D112088: [clang][deps] Keep #pragma push_macro, pop_macro and include_alias when minimizing source code.

[Sylvain Audi via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa82a844961a5: [clang][deps] Keep #pragma push_macro, 
pop_macro and include_alias when… (authored by saudi).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112088

Files:
  clang/include/clang/Lex/DependencyDirectivesSourceMinimizer.h
  clang/lib/Lex/DependencyDirectivesSourceMinimizer.cpp
  clang/test/ClangScanDeps/Inputs/preprocess_minimized_pragmas.h
  clang/test/ClangScanDeps/Inputs/preprocess_minimized_pragmas_cdb.json
  clang/test/ClangScanDeps/preprocess_minimized_pragmas.cpp
  clang/test/Lexer/minimize_source_to_dependency_directives_pragmas.c
  clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp

Index: clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
===
--- clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
+++ clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
@@ -63,6 +63,9 @@
"#import \n"
"@import A;\n"
"#pragma clang module import A\n"
+   "#pragma push_macro(A)\n"
+   "#pragma pop_macro(A)\n"
+   "#pragma include_alias(, )\n"
"export module m;\n"
"import m;\n",
Out, Tokens));
@@ -82,10 +85,13 @@
   EXPECT_EQ(pp_import, Tokens[13].K);
   EXPECT_EQ(decl_at_import, Tokens[14].K);
   EXPECT_EQ(pp_pragma_import, Tokens[15].K);
-  EXPECT_EQ(cxx_export_decl, Tokens[16].K);
-  EXPECT_EQ(cxx_module_decl, Tokens[17].K);
-  EXPECT_EQ(cxx_import_decl, Tokens[18].K);
-  EXPECT_EQ(pp_eof, Tokens[19].K);
+  EXPECT_EQ(pp_pragma_push_macro, Tokens[16].K);
+  EXPECT_EQ(pp_pragma_pop_macro, Tokens[17].K);
+  EXPECT_EQ(pp_pragma_include_alias, Tokens[18].K);
+  EXPECT_EQ(cxx_export_decl, Tokens[19].K);
+  EXPECT_EQ(cxx_module_decl, Tokens[20].K);
+  EXPECT_EQ(cxx_import_decl, Tokens[21].K);
+  EXPECT_EQ(pp_eof, Tokens[22].K);
 }
 
 TEST(MinimizeSourceToDependencyDirectivesTest, Define) {
@@ -406,6 +412,22 @@
   ASSERT_FALSE(minimizeSourceToDependencyDirectives("#pragma A\n", Out));
   EXPECT_STREQ("", Out.data());
 
+  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
+  "#pragma push_macro(\"MACRO\")\n", Out));
+  EXPECT_STREQ("#pragma push_macro(\"MACRO\")\n", Out.data());
+
+  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
+  "#pragma pop_macro(\"MACRO\")\n", Out));
+  EXPECT_STREQ("#pragma pop_macro(\"MACRO\")\n", Out.data());
+
+  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
+  "#pragma include_alias(\"A\", \"B\")\n", Out));
+  EXPECT_STREQ("#pragma include_alias(\"A\", \"B\")\n", Out.data());
+
+  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
+  "#pragma include_alias(, )\n", Out));
+  EXPECT_STREQ("#pragma include_alias(, )\n", Out.data());
+
   ASSERT_FALSE(minimizeSourceToDependencyDirectives("#pragma clang\n", Out));
   EXPECT_STREQ("", Out.data());
 
Index: clang/test/Lexer/minimize_source_to_dependency_directives_pragmas.c
===
--- /dev/null
+++ clang/test/Lexer/minimize_source_to_dependency_directives_pragmas.c
@@ -0,0 +1,21 @@
+// Test that the required #pragma directives are minimized
+// RUN: %clang_cc1 -print-dependency-directives-minimized-source %s 2>&1 | FileCheck %s
+
+#pragma once
+
+// some pragmas not needed in minimized source.
+#pragma region TestRegion
+#pragma endregion
+#pragma warning "message"
+
+// pragmas required in the minimized source.
+#pragma push_macro("MYMACRO"   )
+#pragma pop_macro("MYMACRO")
+#pragma clang module import mymodule
+#pragma include_alias(,   "mystring.h")
+
+// CHECK:  #pragma once
+// CHECK-NEXT: #pragma push_macro( "MYMACRO" )
+// CHECK-NEXT: #pragma pop_macro("MYMACRO")
+// CHECK-NEXT: #pragma clang module import mymodule
+// CHECK-NEXT: #pragma include_alias(, "mystring.h")
Index: clang/test/ClangScanDeps/preprocess_minimized_pragmas.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/preprocess_minimized_pragmas.cpp
@@ -0,0 +1,32 @@
+// RUN: rm -rf %t.dir
+// RUN: rm -rf %t.cdb
+// RUN: mkdir -p %t.dir
+// RUN: cp %s %t.dir/preprocess_minimized_pragmas_basic.cpp
+// RUN: cp %s %t.dir/preprocess_minimized_pragmas_ms.cpp
+// RUN: mkdir %t.dir/Inputs
+// RUN: cp %S/Inputs/preprocess_minimized_pragmas.h %t.dir/Inputs/preprocess_minimized_pragmas.h
+// RUN: touch %t.dir/Inputs/a.h
+// RUN: touch %t.dir/Inputs/b.h
+// RUN: touch %t.dir/Inputs/c.h
+// RUN: touch %t.dir/Inputs/c_alias.h
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inpu

[clang] a82a844 - [clang][deps] Keep #pragma push_macro, pop_macro and include_alias when minimizing source code.

[Sylvain Audi via cfe-commits]

Author: Sylvain Audi
Date: 2021-11-01T16:04:52-04:00
New Revision: a82a844961a55c8a5879453ce0e78774b33bf06a

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

LOG: [clang][deps] Keep #pragma push_macro, pop_macro and include_alias when 
minimizing source code.

The #pragma directives push_macro/pop_macro and include_alias may influence the 
#include / import directives encountered by dependency scanning tools like 
clang-scan-deps.

This patch ensures that those directives are not removed during source code 
minimization.

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

Added: 
clang/test/ClangScanDeps/Inputs/preprocess_minimized_pragmas.h
clang/test/ClangScanDeps/Inputs/preprocess_minimized_pragmas_cdb.json
clang/test/ClangScanDeps/preprocess_minimized_pragmas.cpp
clang/test/Lexer/minimize_source_to_dependency_directives_pragmas.c

Modified: 
clang/include/clang/Lex/DependencyDirectivesSourceMinimizer.h
clang/lib/Lex/DependencyDirectivesSourceMinimizer.cpp
clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp

Removed: 




diff  --git a/clang/include/clang/Lex/DependencyDirectivesSourceMinimizer.h 
b/clang/include/clang/Lex/DependencyDirectivesSourceMinimizer.h
index 9bb820156c252..121ca893e314f 100644
--- a/clang/include/clang/Lex/DependencyDirectivesSourceMinimizer.h
+++ b/clang/include/clang/Lex/DependencyDirectivesSourceMinimizer.h
@@ -39,6 +39,9 @@ enum TokenKind {
   pp_import,
   pp_pragma_import,
   pp_pragma_once,
+  pp_pragma_push_macro,
+  pp_pragma_pop_macro,
+  pp_pragma_include_alias,
   pp_include_next,
   pp_if,
   pp_ifdef,

diff  --git a/clang/lib/Lex/DependencyDirectivesSourceMinimizer.cpp 
b/clang/lib/Lex/DependencyDirectivesSourceMinimizer.cpp
index f5cbd5e51b9b9..f597c56837fb4 100644
--- a/clang/lib/Lex/DependencyDirectivesSourceMinimizer.cpp
+++ b/clang/lib/Lex/DependencyDirectivesSourceMinimizer.cpp
@@ -734,6 +734,27 @@ bool Minimizer::lexPragma(const char *&First, const char 
*const End) {
 append("#pragma once\n");
 return false;
   }
+  if (FoundId.Name == "push_macro") {
+// #pragma push_macro
+makeToken(pp_pragma_push_macro);
+append("#pragma push_macro");
+printDirectiveBody(First, End);
+return false;
+  }
+  if (FoundId.Name == "pop_macro") {
+// #pragma pop_macro
+makeToken(pp_pragma_pop_macro);
+append("#pragma pop_macro");
+printDirectiveBody(First, End);
+return false;
+  }
+  if (FoundId.Name == "include_alias") {
+// #pragma include_alias
+makeToken(pp_pragma_include_alias);
+append("#pragma include_alias");
+printDirectiveBody(First, End);
+return false;
+  }
 
   if (FoundId.Name != "clang") {
 skipLine(First, End);
@@ -835,6 +856,10 @@ bool Minimizer::lexPPLine(const char *&First, const char 
*const End) {
   // Figure out the token.
   IdInfo Id = lexIdentifier(First, End);
   First = Id.Last;
+
+  if (Id.Name == "pragma")
+return lexPragma(First, End);
+
   auto Kind = llvm::StringSwitch(Id.Name)
   .Case("include", pp_include)
   .Case("__include_macros", pp___include_macros)
@@ -850,7 +875,6 @@ bool Minimizer::lexPPLine(const char *&First, const char 
*const End) {
   .Case("elifndef", pp_elifndef)
   .Case("else", pp_else)
   .Case("endif", pp_endif)
-  .Case("pragma", pp_pragma_import)
   .Default(pp_none);
   if (Kind == pp_none) {
 skipDirective(Id.Name, First, End);
@@ -863,9 +887,6 @@ bool Minimizer::lexPPLine(const char *&First, const char 
*const End) {
   if (Kind == pp_define)
 return lexDefine(First, End);
 
-  if (Kind == pp_pragma_import)
-return lexPragma(First, End);
-
   // Everything else.
   return lexDefault(Kind, Id.Name, First, End);
 }

diff  --git a/clang/test/ClangScanDeps/Inputs/preprocess_minimized_pragmas.h 
b/clang/test/ClangScanDeps/Inputs/preprocess_minimized_pragmas.h
new file mode 100644
index 0..f0d6b090991b3
--- /dev/null
+++ b/clang/test/ClangScanDeps/Inputs/preprocess_minimized_pragmas.h
@@ -0,0 +1,27 @@
+// #pragma push_macro/pop_macro
+#define INCLUDE_A
+#pragma push_macro("INCLUDE_A")
+#undef INCLUDE_A
+#pragma pop_macro("INCLUDE_A")
+
+#ifdef INCLUDE_A
+#include "a.h"
+#endif
+
+// #pragma push_macro/pop_macro with argument macro expansion
+#define INCLUDE_B
+#define MACRO_NAME "INCLUDE_B"
+
+#pragma push_macro(MACRO_NAME)
+#undef INCLUDE_B
+#pragma pop_macro(MACRO_NAME)
+
+#ifdef INCLUDE_B
+#include "b.h"
+#endif
+
+// #pragma include_alias (MS specific)
+// When compiling without MS Extensions, the pragma is not recognized,
+// and the file c_alias.h is included instead of c.h
+#pragma include_alias("c_alias.h", "c.h")
+#include "c_alias.h"

dif

[PATCH] D95168: [clang-format] Add InsertBraces option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

In D95168#3099920 , @owenpan wrote:

> In D95168#3099739 , @MyDeveloperDay 
> wrote:
>
>> - Look further into possible Removal (I have an idea for how this might be 
>> possible, and super useful for LLVM where we don't like single if {} ), I'd 
>> like to round out on this before introducing the options rather than having 
>> to change them later
>>
>> - Should we add the possibility of removal should we change the option name 
>> to "AutomaticBraces" (thoughts?)
>
> As mentioned in D95168#3039033 , I 
> think it would be better to handle the removal separately. The LLVM Coding 
> Standards has an entire section 
> 
>  about this. Some of the listed exceptions/examples there can make things 
> more difficult.

I'm thinking more about not adding a "InsertBraces" only later to find it 
should have been `InsertRemoveBraces` or `AutomaticBraces` i.e. I want to have 
some idea as to how this might work, if it might be possible even if we land 
separately.


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

https://reviews.llvm.org/D95168

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

Re: r307232 - [modules ts] Do not emit strong function definitions from the module interface unit in every user.

[David Blaikie via cfe-commits]

Ping

On Tue, Sep 21, 2021 at 7:58 PM David Blaikie  wrote:

> Ping
>
> On Sun, Sep 5, 2021 at 11:28 AM David Blaikie  wrote:
>
>> Hey Richard - was just going back over some of the modular codegen code
>> (due to a discussion on the EWG mailing list about file extensions that
>> ended up touching on the nature of how modules are built) - and I came
>> across this code & had the same question I see I wrote up here already but
>> got lost in the *-commits mail.
>>
>> Wondering if you've got some thoughts on why this choice was implemented
>> for C++20 modules - not homing inline functions/variables, only the extern
>> linkage ones for correctness?
>>
>> On Sun, Jul 16, 2017 at 8:26 PM David Blaikie  wrote:
>>
>>> Looks good - does this support available_externally definitions of
>>> strong external linkage functions in the users of a module? (is that
>>> tested?) Should it?
>>>
>>> Also should we consider having two flags for modular codegen - one for
>>> correctness (external function definitions), one for linkage size
>>> optimization (inline functions). Given the current data on optimized builds
>>> with inline functions (that it hurts object size to emit
>>> weak+available_externally definitions rather than linkonce_odr because so
>>> many definitions are optimized away entirely, that the bytes for the weak
>>> definition are wasted/unnecessary) - or at least something to keep in
>>> mind/run numbers on in the future for more generic codebases than Google's
>>> protobuf-heavy (& only protobuf modularized) code.
>>>
>>> On Wed, Jul 5, 2017 at 5:30 PM Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: rsmith
 Date: Wed Jul  5 17:30:00 2017
 New Revision: 307232

 URL: http://llvm.org/viewvc/llvm-project?rev=307232&view=rev
 Log:
 [modules ts] Do not emit strong function definitions from the module
 interface unit in every user.

 Added:
 cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/
 cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/
 cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp
 cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cppm
 cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/user.cpp
 Modified:
 cfe/trunk/lib/Serialization/ASTWriterDecl.cpp

 Modified: cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterDecl.cpp?rev=307232&r1=307231&r2=307232&view=diff

 ==
 --- cfe/trunk/lib/Serialization/ASTWriterDecl.cpp (original)
 +++ cfe/trunk/lib/Serialization/ASTWriterDecl.cpp Wed Jul  5 17:30:00
 2017
 @@ -2233,8 +2233,18 @@ void ASTRecordWriter::AddFunctionDefinit
Writer->ClearSwitchCaseIDs();

assert(FD->doesThisDeclarationHaveABody());
 -  bool ModulesCodegen = Writer->Context->getLangOpts().ModulesCodegen
 &&
 -Writer->WritingModule &&
 !FD->isDependentContext();
 +  bool ModulesCodegen = false;
 +  if (Writer->WritingModule && !FD->isDependentContext()) {
 +// Under -fmodules-codegen, codegen is performed for all defined
 functions.
 +// When building a C++ Modules TS module interface unit, a strong
 definition
 +// in the module interface is provided by the compilation of that
 module
 +// interface unit, not by its users. (Inline functions are still
 emitted
 +// in module users.)
 +ModulesCodegen =
 +Writer->Context->getLangOpts().ModulesCodegen ||
 +(Writer->WritingModule->Kind == Module::ModuleInterfaceUnit &&
 + Writer->Context->GetGVALinkageForFunction(FD) ==
 GVA_StrongExternal);
 +  }
Record->push_back(ModulesCodegen);
if (ModulesCodegen)
  Writer->ModularCodegenDecls.push_back(Writer->GetDeclRef(FD));

 Added: cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp?rev=307232&view=auto

 ==
 --- cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp
 (added)
 +++ cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp Wed
 Jul  5 17:30:00 2017
 @@ -0,0 +1,23 @@
 +// RUN: %clang_cc1 -fmodules-ts %S/module.cppm -triple
 %itanium_abi_triple -emit-module-interface -o %t
 +// RUN: %clang_cc1 -fmodules-ts %s -triple %itanium_abi_triple
 -fmodule-file=%t -emit-llvm -o - | FileCheck %s --implicit-check-not=unused
 --implicit-check-not=global_module
 +
 +module Module;
 +
 +void use() {
 +  // CHECK: define linkonce_odr {{.*}}@_Z20used_inline_exportedv
 +  used_in

[PATCH] D112492: [HIP] Do not use kernel handle for MSVC target

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

As phrased the summary would likely be rather confusing for anyone other than 
you and me.

> Currently Visual Studio 2019 has a linker issue which causes linking error
> when a template kernel is instantiated in different compilation units.

It's not clear what exactly is the issue and what causes it.

> On the other hand, it is unnecessary to prefix kernel stub for MSVC
> target since the host and device compilation uses different mangling
> ABI.

This could use more details on why different mangling matters here. IIRC, on 
Linux where both host and device use the same mangling and HIP needed a way to 
tell apart the GPU-side kernels and their host-side stub. Different mangling 
makes it a non-issue.

> This patch let clang not emit kernel handle for MSVC target to work around 
> the linker issue.

Again, without the back-story the jump from linking error to mangling 
differences to "let's not emit a handle" does not make much sense.

I'd restructure it along the line of:

- we emit host-side handles to match GPU-side kernels
- the handles cause linking issues on windows because of X/Y/Z.
- handles are not necessary on Windows, because of the different host/device 
mangling
- no generating the handles avoids the linking issue on Windows.

This prompts the question -- should/could handle generation be improved 
instead? Having identical behavior on all platforms would arguably be better 
than a platform-specific workaround.


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

https://reviews.llvm.org/D112492

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

[PATCH] D105690: [RISCV] Rename assembler mnemonic of unordered floating-point reductions for v1.0-rc change

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.
Herald added subscribers: VincentWu, luke957.

This patch as committed, deleted 5 test files instead of renaming them. I'm 
working on restoring them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105690

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

[PATCH] D112664: [clang-format][docs] fix indentation of rst code block

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay requested changes to this revision.
MyDeveloperDay added a comment.
This revision now requires changes to proceed.

This should be Format.h, didn't we recently fix this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112664

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

[PATCH] D112399: Get Bazel building `//clang` on Windows with clang-cl.

[Geoffrey Martin-Noble via Phabricator via cfe-commits]

GMNGeoffrey accepted this revision.
GMNGeoffrey added inline comments.
This revision is now accepted and ready to land.



Comment at: utils/bazel/llvm-project-overlay/clang/BUILD.bazel:364
+# Clang-specific define on non-Windows platforms.
+"CLANG_HAVE_RLIMITS=1",
+],

Seems like this should be in clang/config.h?



Comment at: utils/bazel/llvm-project-overlay/clang/unittests/BUILD.bazel:485
+"@bazel_tools//src/conditions:windows": [
+# Need to disable the VFS tests that don't use Windows friendly 
paths.
+"--gtest_filter=-*VirtualFileOverlay*",

Probably good to note here that these are also disabled in the CMake build



Comment at: 
utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/config.h:375
+ * matches how the users of this header expect things to work with CMake.
+ * FIXME: We should consider moving other platform defines to use this 
technique
+ * as well.

Oh nice, yeah this seems like a reasonable approach. I can't believe we didn't 
think of this before... The less Bazel goop the better. We're still going to 
need some way to deal with the things that are more complicated than just 
platform and some way to handle keeping this up to date. That might push us 
back to doing it with Bazel. IDK


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

https://reviews.llvm.org/D112399

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

[PATCH] D112645: [OpenMP] Fix: opposite attributes could be set by -fno-inline

[Igor Kirillov via Phabricator via cfe-commits]

igor.kirillov updated this revision to Diff 383890.
igor.kirillov marked an inline comment as not done.
igor.kirillov added a comment.

Update test, remove redundant code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112645

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/parallel_for_noinline.cpp
  clang/test/OpenMP/parallel_if_codegen_PR51349.cpp

Index: clang/test/OpenMP/parallel_if_codegen_PR51349.cpp
===
--- clang/test/OpenMP/parallel_if_codegen_PR51349.cpp
+++ clang/test/OpenMP/parallel_if_codegen_PR51349.cpp
@@ -1,5 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --check-attributes --include-generated-funcs
 // RUN: %clang_cc1 -x c++ -O1 -fopenmp-version=45 -disable-llvm-optzns -verify -fopenmp -triple x86_64-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -x c++ -O1 -fopenmp-version=45 -disable-llvm-optzns -verify -fopenmp -triple x86_64-unknown-linux -emit-llvm -fno-inline %s -o - | FileCheck %s --check-prefix=CHECK-NOINLINE
 // expected-no-diagnostics
 
 #ifndef HEADER
@@ -8,6 +9,8 @@
 void foo() {
 #pragma omp parallel if(0)
   ;
+#pragma omp parallel
+  ;
 }
 
 #endif
@@ -23,6 +26,7 @@
 // CHECK-NEXT:store i32 0, i32* [[DOTBOUND_ZERO_ADDR]], align 4
 // CHECK-NEXT:call void @.omp_outlined.(i32* [[DOTTHREADID_TEMP_]], i32* [[DOTBOUND_ZERO_ADDR]]) #[[ATTR2:[0-9]+]]
 // CHECK-NEXT:call void @__kmpc_end_serialized_parallel(%struct.ident_t* @[[GLOB1]], i32 [[TMP0]])
+// CHECK-NEXT:call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @[[GLOB1]], i32 0, void (i32*, i32*, ...)* bitcast (void (i32*, i32*)* @.omp_outlined..1 to void (i32*, i32*, ...)*))
 // CHECK-NEXT:ret void
 //
 //
@@ -36,3 +40,52 @@
 // CHECK-NEXT:store i32* [[DOTBOUND_TID_]], i32** [[DOTBOUND_TID__ADDR]], align 8, !tbaa [[TBAA7]]
 // CHECK-NEXT:ret void
 //
+//
+// CHECK: Function Attrs: alwaysinline norecurse nounwind
+// CHECK-LABEL: define {{[^@]+}}@.omp_outlined..1
+// CHECK-SAME: (i32* noalias [[DOTGLOBAL_TID_:%.*]], i32* noalias [[DOTBOUND_TID_:%.*]]) #[[ATTR3:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DOTGLOBAL_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[DOTBOUND_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:store i32* [[DOTGLOBAL_TID_]], i32** [[DOTGLOBAL_TID__ADDR]], align 8, !tbaa [[TBAA7]]
+// CHECK-NEXT:store i32* [[DOTBOUND_TID_]], i32** [[DOTBOUND_TID__ADDR]], align 8, !tbaa [[TBAA7]]
+// CHECK-NEXT:ret void
+//
+//
+// CHECK-NOINLINE: Function Attrs: mustprogress noinline nounwind
+// CHECK-NOINLINE-LABEL: define {{[^@]+}}@_Z3foov
+// CHECK-NOINLINE-SAME: () #[[ATTR0:[0-9]+]] {
+// CHECK-NOINLINE-NEXT:  entry:
+// CHECK-NOINLINE-NEXT:[[DOTTHREADID_TEMP_:%.*]] = alloca i32, align 4
+// CHECK-NOINLINE-NEXT:[[DOTBOUND_ZERO_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NOINLINE-NEXT:[[TMP0:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @[[GLOB1:[0-9]+]])
+// CHECK-NOINLINE-NEXT:call void @__kmpc_serialized_parallel(%struct.ident_t* @[[GLOB1]], i32 [[TMP0]])
+// CHECK-NOINLINE-NEXT:store i32 [[TMP0]], i32* [[DOTTHREADID_TEMP_]], align 4, !tbaa [[TBAA3:![0-9]+]]
+// CHECK-NOINLINE-NEXT:store i32 0, i32* [[DOTBOUND_ZERO_ADDR]], align 4
+// CHECK-NOINLINE-NEXT:call void @.omp_outlined.(i32* [[DOTTHREADID_TEMP_]], i32* [[DOTBOUND_ZERO_ADDR]]) #[[ATTR2:[0-9]+]]
+// CHECK-NOINLINE-NEXT:call void @__kmpc_end_serialized_parallel(%struct.ident_t* @[[GLOB1]], i32 [[TMP0]])
+// CHECK-NOINLINE-NEXT:call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @[[GLOB1]], i32 0, void (i32*, i32*, ...)* bitcast (void (i32*, i32*)* @.omp_outlined..1 to void (i32*, i32*, ...)*))
+// CHECK-NOINLINE-NEXT:ret void
+//
+//
+// CHECK-NOINLINE: Function Attrs: noinline norecurse nounwind
+// CHECK-NOINLINE-LABEL: define {{[^@]+}}@.omp_outlined.
+// CHECK-NOINLINE-SAME: (i32* noalias [[DOTGLOBAL_TID_:%.*]], i32* noalias [[DOTBOUND_TID_:%.*]]) #[[ATTR1:[0-9]+]] {
+// CHECK-NOINLINE-NEXT:  entry:
+// CHECK-NOINLINE-NEXT:[[DOTGLOBAL_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NOINLINE-NEXT:[[DOTBOUND_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NOINLINE-NEXT:store i32* [[DOTGLOBAL_TID_]], i32** [[DOTGLOBAL_TID__ADDR]], align 8, !tbaa [[TBAA7:![0-9]+]]
+// CHECK-NOINLINE-NEXT:store i32* [[DOTBOUND_TID_]], i32** [[DOTBOUND_TID__ADDR]], align 8, !tbaa [[TBAA7]]
+// CHECK-NOINLINE-NEXT:ret void
+//
+//
+// CHECK-NOINLINE: Function Attrs: alwaysinline norecurse nounwind
+// CHECK-NOINLINE-LABEL: define {{[^@]+}}@.omp_outlined..1
+// CHECK-NOINLINE-SAME: (i32* noalias [[DOTGLOBAL_TID_:%.*]], i32* noalias [[DOTBOUND_TID_:%.*]]) #[[ATTR3:[0-9]+]] {

[clang] 670c72f - [RISCV] Restore tests for vf(w)redusum.

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2021-11-01T14:35:22-07:00
New Revision: 670c72f6f70434500d1475e1524a7088814fbc73

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

LOG: [RISCV] Restore tests for vf(w)redusum.

When D105690 changed the mnemonic from vf(w)redsum to vf(w)redusum,
several tests were deleted instead of being renamed.

This commit also consistently renames the other tests that weren't
deleted.

Added: 
clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredusum.c
clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwredusum.c
clang/test/CodeGen/RISCV/rvv-intrinsics/vfredusum.c
clang/test/CodeGen/RISCV/rvv-intrinsics/vfwredusum.c
llvm/test/CodeGen/RISCV/rvv/vfredusum-rv32.ll
llvm/test/CodeGen/RISCV/rvv/vfredusum-rv64.ll
llvm/test/CodeGen/RISCV/rvv/vfwredusum-rv32.ll
llvm/test/CodeGen/RISCV/rvv/vfwredusum-rv64.ll

Modified: 


Removed: 
clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredsum.c
clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwredsum.c
clang/test/CodeGen/RISCV/rvv-intrinsics/vfredsum.c



diff  --git a/clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredsum.c 
b/clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredusum.c
similarity index 100%
rename from clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredsum.c
rename to clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredusum.c

diff  --git a/clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwredsum.c 
b/clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwredusum.c
similarity index 100%
rename from clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwredsum.c
rename to clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwredusum.c

diff  --git a/clang/test/CodeGen/RISCV/rvv-intrinsics/vfredsum.c 
b/clang/test/CodeGen/RISCV/rvv-intrinsics/vfredusum.c
similarity index 100%
rename from clang/test/CodeGen/RISCV/rvv-intrinsics/vfredsum.c
rename to clang/test/CodeGen/RISCV/rvv-intrinsics/vfredusum.c

diff  --git a/clang/test/CodeGen/RISCV/rvv-intrinsics/vfwredusum.c 
b/clang/test/CodeGen/RISCV/rvv-intrinsics/vfwredusum.c
new file mode 100644
index 0..74a71208fddb9
--- /dev/null
+++ b/clang/test/CodeGen/RISCV/rvv-intrinsics/vfwredusum.c
@@ -0,0 +1,225 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d \
+// RUN:   -target-feature +experimental-v -target-feature +experimental-zfh \
+// RUN:   -disable-O0-optnone -emit-llvm %s -o - | opt -S -mem2reg | FileCheck 
--check-prefix=CHECK-RV64 %s
+
+#include 
+
+// CHECK-RV64-LABEL: @test_vfwredusum_vs_f32mf2_f64m1(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vfwredusum.nxv1f64.nxv1f32.i64( [[DST:%.*]], 
 [[VECTOR:%.*]],  [[SCALAR:%.*]], i64 
[[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vfloat64m1_t test_vfwredusum_vs_f32mf2_f64m1(vfloat64m1_t dst,
+vfloat32mf2_t vector,
+vfloat64m1_t scalar, size_t vl) {
+  return vfwredusum_vs_f32mf2_f64m1(dst, vector, scalar, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vfwredusum_vs_f32m1_f64m1(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vfwredusum.nxv1f64.nxv2f32.i64( [[DST:%.*]], 
 [[VECTOR:%.*]],  [[SCALAR:%.*]], i64 
[[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vfloat64m1_t test_vfwredusum_vs_f32m1_f64m1(vfloat64m1_t dst,
+   vfloat32m1_t vector,
+   vfloat64m1_t scalar, size_t vl) {
+  return vfwredusum_vs_f32m1_f64m1(dst, vector, scalar, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vfwredusum_vs_f32m2_f64m1(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vfwredusum.nxv1f64.nxv4f32.i64( [[DST:%.*]], 
 [[VECTOR:%.*]],  [[SCALAR:%.*]], i64 
[[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vfloat64m1_t test_vfwredusum_vs_f32m2_f64m1(vfloat64m1_t dst,
+   vfloat32m2_t vector,
+   vfloat64m1_t scalar, size_t vl) {
+  return vfwredusum_vs_f32m2_f64m1(dst, vector, scalar, vl);
+}
+
+// CHECK-RV64-LABEL: @test_vfwredusum_vs_f32m4_f64m1(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  
@llvm.riscv.vfwredusum.nxv1f64.nxv8f32.i64( [[DST:%.*]], 
 [[VECTOR:%.*]],  [[SCALAR:%.*]], i64 
[[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vfloat64m1_t test_vfwredusum_vs_f32m4_f64m1(vfloat64m1_t dst,
+   vfloat32m4_t vector,
+   vfloat64m1_t s

[PATCH] D112883: [bazel] Re-introduce `copts` hacks for lib/AST includes.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

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

:( LGTM


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

https://reviews.llvm.org/D112883

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

[PATCH] D112645: [OpenMP] Fix: opposite attributes could be set by -fno-inline

[Igor Kirillov via Phabricator via cfe-commits]

igor.kirillov updated this revision to Diff 383892.
igor.kirillov added a comment.

Remove my old test for the change


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112645

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/parallel_if_codegen_PR51349.cpp

Index: clang/test/OpenMP/parallel_if_codegen_PR51349.cpp
===
--- clang/test/OpenMP/parallel_if_codegen_PR51349.cpp
+++ clang/test/OpenMP/parallel_if_codegen_PR51349.cpp
@@ -1,5 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --check-attributes --include-generated-funcs
 // RUN: %clang_cc1 -x c++ -O1 -fopenmp-version=45 -disable-llvm-optzns -verify -fopenmp -triple x86_64-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -x c++ -O1 -fopenmp-version=45 -disable-llvm-optzns -verify -fopenmp -triple x86_64-unknown-linux -emit-llvm -fno-inline %s -o - | FileCheck %s --check-prefix=CHECK-NOINLINE
 // expected-no-diagnostics
 
 #ifndef HEADER
@@ -8,6 +9,8 @@
 void foo() {
 #pragma omp parallel if(0)
   ;
+#pragma omp parallel
+  ;
 }
 
 #endif
@@ -23,6 +26,7 @@
 // CHECK-NEXT:store i32 0, i32* [[DOTBOUND_ZERO_ADDR]], align 4
 // CHECK-NEXT:call void @.omp_outlined.(i32* [[DOTTHREADID_TEMP_]], i32* [[DOTBOUND_ZERO_ADDR]]) #[[ATTR2:[0-9]+]]
 // CHECK-NEXT:call void @__kmpc_end_serialized_parallel(%struct.ident_t* @[[GLOB1]], i32 [[TMP0]])
+// CHECK-NEXT:call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @[[GLOB1]], i32 0, void (i32*, i32*, ...)* bitcast (void (i32*, i32*)* @.omp_outlined..1 to void (i32*, i32*, ...)*))
 // CHECK-NEXT:ret void
 //
 //
@@ -36,3 +40,52 @@
 // CHECK-NEXT:store i32* [[DOTBOUND_TID_]], i32** [[DOTBOUND_TID__ADDR]], align 8, !tbaa [[TBAA7]]
 // CHECK-NEXT:ret void
 //
+//
+// CHECK: Function Attrs: alwaysinline norecurse nounwind
+// CHECK-LABEL: define {{[^@]+}}@.omp_outlined..1
+// CHECK-SAME: (i32* noalias [[DOTGLOBAL_TID_:%.*]], i32* noalias [[DOTBOUND_TID_:%.*]]) #[[ATTR3:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DOTGLOBAL_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[DOTBOUND_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:store i32* [[DOTGLOBAL_TID_]], i32** [[DOTGLOBAL_TID__ADDR]], align 8, !tbaa [[TBAA7]]
+// CHECK-NEXT:store i32* [[DOTBOUND_TID_]], i32** [[DOTBOUND_TID__ADDR]], align 8, !tbaa [[TBAA7]]
+// CHECK-NEXT:ret void
+//
+//
+// CHECK-NOINLINE: Function Attrs: mustprogress noinline nounwind
+// CHECK-NOINLINE-LABEL: define {{[^@]+}}@_Z3foov
+// CHECK-NOINLINE-SAME: () #[[ATTR0:[0-9]+]] {
+// CHECK-NOINLINE-NEXT:  entry:
+// CHECK-NOINLINE-NEXT:[[DOTTHREADID_TEMP_:%.*]] = alloca i32, align 4
+// CHECK-NOINLINE-NEXT:[[DOTBOUND_ZERO_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NOINLINE-NEXT:[[TMP0:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @[[GLOB1:[0-9]+]])
+// CHECK-NOINLINE-NEXT:call void @__kmpc_serialized_parallel(%struct.ident_t* @[[GLOB1]], i32 [[TMP0]])
+// CHECK-NOINLINE-NEXT:store i32 [[TMP0]], i32* [[DOTTHREADID_TEMP_]], align 4, !tbaa [[TBAA3:![0-9]+]]
+// CHECK-NOINLINE-NEXT:store i32 0, i32* [[DOTBOUND_ZERO_ADDR]], align 4
+// CHECK-NOINLINE-NEXT:call void @.omp_outlined.(i32* [[DOTTHREADID_TEMP_]], i32* [[DOTBOUND_ZERO_ADDR]]) #[[ATTR2:[0-9]+]]
+// CHECK-NOINLINE-NEXT:call void @__kmpc_end_serialized_parallel(%struct.ident_t* @[[GLOB1]], i32 [[TMP0]])
+// CHECK-NOINLINE-NEXT:call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @[[GLOB1]], i32 0, void (i32*, i32*, ...)* bitcast (void (i32*, i32*)* @.omp_outlined..1 to void (i32*, i32*, ...)*))
+// CHECK-NOINLINE-NEXT:ret void
+//
+//
+// CHECK-NOINLINE: Function Attrs: noinline norecurse nounwind
+// CHECK-NOINLINE-LABEL: define {{[^@]+}}@.omp_outlined.
+// CHECK-NOINLINE-SAME: (i32* noalias [[DOTGLOBAL_TID_:%.*]], i32* noalias [[DOTBOUND_TID_:%.*]]) #[[ATTR1:[0-9]+]] {
+// CHECK-NOINLINE-NEXT:  entry:
+// CHECK-NOINLINE-NEXT:[[DOTGLOBAL_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NOINLINE-NEXT:[[DOTBOUND_TID__ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NOINLINE-NEXT:store i32* [[DOTGLOBAL_TID_]], i32** [[DOTGLOBAL_TID__ADDR]], align 8, !tbaa [[TBAA7:![0-9]+]]
+// CHECK-NOINLINE-NEXT:store i32* [[DOTBOUND_TID_]], i32** [[DOTBOUND_TID__ADDR]], align 8, !tbaa [[TBAA7]]
+// CHECK-NOINLINE-NEXT:ret void
+//
+//
+// CHECK-NOINLINE: Function Attrs: alwaysinline norecurse nounwind
+// CHECK-NOINLINE-LABEL: define {{[^@]+}}@.omp_outlined..1
+// CHECK-NOINLINE-SAME: (i32* noalias [[DOTGLOBAL_TID_:%.*]], i32* noalias [[DOTBOUND_TID_:%.*]]) #[[ATTR3:[0-9]+]] {
+// CHECK-NOINLINE-NEXT:  entry:
+// CHECK-NOINLINE-NEXT:[[DOTGLOBAL_TID__ADDR:%.*]] = alloca 

[PATCH] D105690: [RISCV] Rename assembler mnemonic of unordered floating-point reductions for v1.0-rc change

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D105690#3101129 , @craig.topper 
wrote:

> This patch as committed, deleted 5 test files instead of renaming them. I'm 
> working on restoring them.

Deleted tests have been restored by 670c72f6f70434500d1475e1524a7088814fbc73 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105690

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

[PATCH] D112881: [clang-tidy] Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions

[Paul Altin via Phabricator via cfe-commits]

paulaltin updated this revision to Diff 383893.
paulaltin added a comment.

Fix pre-merge tests


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

https://reviews.llvm.org/D112881

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
@@ -0,0 +1,13 @@
+// RUN: %check_clang_tidy -check-suffix=DEFAULT %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: true}]}'
+
+// RUN: %check_clang_tidy -check-suffix=DISABLED %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: false}]}'
+
+void foo(unsigned long long value) {
+  double a = value;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:14: warning: narrowing conversion from 'size_t' (aka 'unsigned long') to 'double' [cppcoreguidelines-narrowing-conversions]
+  // DISABLED: No warning for integer to floating-point narrowing conversions when WarnOnIntegerToFloatingPointNarrowingConversion = false.
+}
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
@@ -15,7 +15,8 @@
 We enforce only part of the guideline, more specifically, we flag narrowing conversions from:
  - an integer to a narrower integer (e.g. ``char`` to ``unsigned char``)
if WarnOnIntegerNarrowingConversion Option is set,
- - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``),
+ - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``)
+   if WarnOnIntegerToFloatingPointNarrowingConversion Option is set,
  - a floating-point to an integer (e.g. ``double`` to ``int``),
  - a floating-point to a narrower floating-point (e.g. ``double`` to ``float``)
if WarnOnFloatingPointNarrowingConversion Option is set.
@@ -36,6 +37,11 @@
 When `true`, the check will warn on narrowing integer conversion
 (e.g. ``int`` to ``size_t``). `true` by default.
 
+.. option:: WarnOnIntegerToFloatingPointNarrowingConversion
+
+When `true`, the check will warn on narrowing integer to floating-point
+conversion (e.g. ``size_t`` to ``double``). `true` by default.
+
 .. option:: WarnOnFloatingPointNarrowingConversion
 
 When `true`, the check will warn on narrowing floating point conversion
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
@@ -37,6 +37,8 @@
 : ClangTidyCheck(Name, Context),
   WarnOnIntegerNarrowingConversion(
   Options.get("WarnOnIntegerNarrowingConversion", true)),
+  WarnOnIntegerToFloatingPointNarrowingConversion(
+  Options.get("WarnOnIntegerToFloatingPointNarrowingConversion", true)),
   WarnOnFloatingPointNarrowingConversion(
   Options.get("WarnOnFloatingPointNarrowingConversion", true)),
   WarnWithinTemplateInstantiation(
@@ -49,6 +51,8 @@
 ClangTidyOptions::OptionMap &Opts) {
   Options.store(Opts, "WarnOnIntegerNarrowingConversion",
 WarnOnIntegerNarrowingConversion);
+  Options.store(Opts, "WarnOnIntegerToFloatingPointNarrowingConversion",
+WarnOnIntegerToFloatingPointNarrowingConversion);
   Options.store(Opts, "WarnOnFloatingPointNarrowingConversion",
 WarnOnFloatingPointNarrowingConversion);
   Options.store(Opts, "WarnWithinTemplateInstantiation",
@@ -376,19 +380,21 @@
 void NarrowingConversionsCheck::handleIntegralToFloating(
 const ASTContext &Context, SourceLocation SourceLoc, const Expr &Lhs,
 const Expr &Rhs) {
-  const BuiltinType *ToType = getBuiltinType(Lhs);
-  llvm::APSInt IntegerConstant;
-  if (getIntegerConstantExprValue(Context, Rhs, IntegerConstant)) {
-if (!isWideEnoughToHold(Context, IntegerConstant, *ToType))
-  

[PATCH] D112881: [clang-tidy] Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions

[Paul Altin via Phabricator via cfe-commits]

paulaltin updated this revision to Diff 383898.
paulaltin added a comment.

Updated release notes.


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

https://reviews.llvm.org/D112881

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp

Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -119,6 +119,8 @@
 - Removed default setting `cppcoreguidelines-explicit-virtual-functions.IgnoreDestructors = "true"`,
   to match the current state of the C++ Core Guidelines.
 
+- :doc:`cppcoreguidelines-narrowing-conversions ` check now supports a WarnOnIntegerToFloatingPointNarrowingConversion option to control whether to warn on narrowing integer to floating-point conversions.
+
 
 Removed checks
 ^^
Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
@@ -0,0 +1,13 @@
+// RUN: %check_clang_tidy -check-suffix=DEFAULT %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: true}]}'
+
+// RUN: %check_clang_tidy -check-suffix=DISABLED %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: false}]}'
+
+void foo(unsigned long long value) {
+  double a = value;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:14: warning: narrowing conversion from 'size_t' (aka 'unsigned long') to 'double' [cppcoreguidelines-narrowing-conversions]
+  // DISABLED: No warning for integer to floating-point narrowing conversions when WarnOnIntegerToFloatingPointNarrowingConversion = false.
+}
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
@@ -15,7 +15,8 @@
 We enforce only part of the guideline, more specifically, we flag narrowing conversions from:
  - an integer to a narrower integer (e.g. ``char`` to ``unsigned char``)
if WarnOnIntegerNarrowingConversion Option is set,
- - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``),
+ - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``)
+   if WarnOnIntegerToFloatingPointNarrowingConversion Option is set,
  - a floating-point to an integer (e.g. ``double`` to ``int``),
  - a floating-point to a narrower floating-point (e.g. ``double`` to ``float``)
if WarnOnFloatingPointNarrowingConversion Option is set.
@@ -36,6 +37,11 @@
 When `true`, the check will warn on narrowing integer conversion
 (e.g. ``int`` to ``size_t``). `true` by default.
 
+.. option:: WarnOnIntegerToFloatingPointNarrowingConversion
+
+When `true`, the check will warn on narrowing integer to floating-point
+conversion (e.g. ``size_t`` to ``double``). `true` by default.
+
 .. option:: WarnOnFloatingPointNarrowingConversion
 
 When `true`, the check will warn on narrowing floating point conversion
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
@@ -37,6 +37,8 @@
 : ClangTidyCheck(Name, Context),
   WarnOnIntegerNarrowingConversion(
   Options.get("WarnOnIntegerNarrowingConversion", true)),
+  WarnOnIntegerToFloatingPointNarrowingConversion(
+  Options.get("WarnOnIntegerToFloatingPointNarrowingConversion", true)),
   WarnOnFloatingPointNarrowingConversion(
   Options.get("WarnOnFloatingPointNarrowingConversion", true)),
   WarnWithinTemplateInstantiation(
@@ -49,6 +51,8 @@
 ClangTidyOptions::OptionMap &Opts) {
   Options.store(Opts, "WarnOnIntegerNarrowingConversion",
 WarnOnIntegerNarrowingConversion);
+  Options.store(Opts, "WarnOnIntegerToFloatingPoint

[PATCH] D112001: [Clang] Add min/max reduction builtins.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 383900.
fhahn added a comment.

In D112001#3099965 , @aaron.ballman 
wrote:

> Precommit CI looks to be failing.
>
>   
> /var/lib/buildkite-agent/builds/llvm-project/clang/test/CodeGen/builtins-reduction-math.c:13:9:
>  error: initializing 'float' with an expression of incompatible type 'float4' 
> (vector of 4 'float' values)
>   
> float r1 = __builtin_reduce_max(vf1);

The last version of the patch did not correctly set the return type to the 
element type. That should be fixed now!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112001

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-reduction-math.c
  clang/test/Sema/builtins-reduction-math.c

Index: clang/test/Sema/builtins-reduction-math.c
===
--- /dev/null
+++ clang/test/Sema/builtins-reduction-math.c
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 %s -pedantic -verify -triple=x86_64-apple-darwin9
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+typedef int int3 __attribute__((ext_vector_type(3)));
+typedef unsigned unsigned4 __attribute__((ext_vector_type(4)));
+
+struct Foo {
+  char *p;
+};
+
+void test_builtin_reduce_max(int i, float4 v, int3 iv) {
+  struct Foo s = __builtin_reduce_max(iv);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'int'}}
+
+  i = __builtin_reduce_max(v, v);
+  // expected-error@-1 {{too many arguments to function call, expected 1, have 2}}
+
+  i = __builtin_reduce_max();
+  // expected-error@-1 {{too few arguments to function call, expected 1, have 0}}
+
+  i = __builtin_reduce_max(i);
+  // expected-error@-1 {{1st argument must be a vector type (was 'int')}}
+}
+
+void test_builtin_reduce_min(int i, float4 v, int3 iv) {
+  struct Foo s = __builtin_reduce_min(iv);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'int'}}
+
+  i = __builtin_reduce_min(v, v);
+  // expected-error@-1 {{too many arguments to function call, expected 1, have 2}}
+
+  i = __builtin_reduce_min();
+  // expected-error@-1 {{too few arguments to function call, expected 1, have 0}}
+
+  i = __builtin_reduce_min(i);
+  // expected-error@-1 {{1st argument must be a vector type (was 'int')}}
+}
Index: clang/test/CodeGen/builtins-reduction-math.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-reduction-math.c
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin %s -emit-llvm -disable-llvm-passes -o - | FileCheck %s
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+typedef short int si8 __attribute__((ext_vector_type(8)));
+typedef unsigned int u4 __attribute__((ext_vector_type(4)));
+
+__attribute__((address_space(1))) float4 vf1_as_one;
+
+void test_builtin_reduce_max(float4 vf1, si8 vi1, u4 vu1) {
+  // CHECK-LABEL: define void @test_builtin_reduce_max(
+  // CHECK:  [[VF1:%.+]] = load <4 x float>, <4 x float>* %vf1.addr, align 16
+  // CHECK-NEXT: call float @llvm.vector.reduce.fmax.v4f32(<4 x float> [[VF1]])
+  float r1 = __builtin_reduce_max(vf1);
+
+  // CHECK:  [[VI1:%.+]] = load <8 x i16>, <8 x i16>* %vi1.addr, align 16
+  // CHECK-NEXT: call i16 @llvm.vector.reduce.smax.v8i16(<8 x i16> [[VI1]])
+  short r2 = __builtin_reduce_max(vi1);
+
+  // CHECK:  [[VU1:%.+]] = load <4 x i32>, <4 x i32>* %vu1.addr, align 16
+  // CHECK-NEXT: call i32 @llvm.vector.reduce.umax.v4i32(<4 x i32> [[VU1]])
+  unsigned r3 = __builtin_reduce_max(vu1);
+
+  // CHECK:  [[VF1_AS1:%.+]] = load <4 x float>, <4 x float> addrspace(1)* @vf1_as_one, align 16
+  // CHECK-NEXT: [[RDX1:%.+]] = call float @llvm.vector.reduce.fmax.v4f32(<4 x float> [[VF1_AS1]])
+  // CHECK-NEXT: fpext float [[RDX1]] to double
+  const double r4 = __builtin_reduce_max(vf1_as_one);
+
+  // CHECK:  [[CVI1:%.+]] = load <8 x i16>, <8 x i16>* %cvi1, align 16
+  // CHECK-NEXT: [[RDX2:%.+]] = call i16 @llvm.vector.reduce.smax.v8i16(<8 x i16> [[CVI1]])
+  // CHECK-NEXT: sext i16 [[RDX2]] to i64
+  const si8 cvi1 = vi1;
+  unsigned long long r5 = __builtin_reduce_max(cvi1);
+}
+
+void test_builtin_reduce_min(float4 vf1, si8 vi1, u4 vu1) {
+  // CHECK-LABEL: define void @test_builtin_reduce_min(
+  // CHECK:  [[VF1:%.+]] = load <4 x float>, <4 x float>* %vf1.addr, align 16
+  // CHECK-NEXT: call float @llvm.vector.reduce.fmin.v4f32(<4 x float> [[VF1]])
+  float r1 = __builtin_reduce_min(vf1);
+
+  // CHECK:  [[VI1:%.+]] = load <8 x i16>, <8 x i16>* %vi1.addr, align 16
+  // CHECK-NEXT: call i16 @llvm.vector.reduce.smin.v8i16(<8 x i16> [[VI1]])
+  short r2 = __builtin_reduce_min(vi1);
+
+  // CH

[PATCH] D112881: [clang-tidy] Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions

[Paul Altin via Phabricator via cfe-commits]

paulaltin updated this revision to Diff 383901.
paulaltin added a comment.

Fix pre-merge tests.


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

https://reviews.llvm.org/D112881

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
@@ -0,0 +1,13 @@
+// RUN: %check_clang_tidy -check-suffix=DEFAULT %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: true}]}'
+
+// RUN: %check_clang_tidy -check-suffix=DISABLED %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: false}]}'
+
+void foo(unsigned long long value) {
+  double a = value;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:14: warning: narrowing conversion from 'unsigned long long' to 'double' [cppcoreguidelines-narrowing-conversions]
+  // DISABLED: No warning for integer to floating-point narrowing conversions when WarnOnIntegerToFloatingPointNarrowingConversion = false.
+}
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
@@ -15,7 +15,8 @@
 We enforce only part of the guideline, more specifically, we flag narrowing conversions from:
  - an integer to a narrower integer (e.g. ``char`` to ``unsigned char``)
if WarnOnIntegerNarrowingConversion Option is set,
- - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``),
+ - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``)
+   if WarnOnIntegerToFloatingPointNarrowingConversion Option is set,
  - a floating-point to an integer (e.g. ``double`` to ``int``),
  - a floating-point to a narrower floating-point (e.g. ``double`` to ``float``)
if WarnOnFloatingPointNarrowingConversion Option is set.
@@ -36,6 +37,11 @@
 When `true`, the check will warn on narrowing integer conversion
 (e.g. ``int`` to ``size_t``). `true` by default.
 
+.. option:: WarnOnIntegerToFloatingPointNarrowingConversion
+
+When `true`, the check will warn on narrowing integer to floating-point
+conversion (e.g. ``size_t`` to ``double``). `true` by default.
+
 .. option:: WarnOnFloatingPointNarrowingConversion
 
 When `true`, the check will warn on narrowing floating point conversion
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -119,6 +119,8 @@
 - Removed default setting `cppcoreguidelines-explicit-virtual-functions.IgnoreDestructors = "true"`,
   to match the current state of the C++ Core Guidelines.
 
+- :doc:`cppcoreguidelines-narrowing-conversions ` check now supports a WarnOnIntegerToFloatingPointNarrowingConversion option to control whether to warn on narrowing integer to floating-point conversions.
+
 
 Removed checks
 ^^
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
@@ -37,6 +37,8 @@
 : ClangTidyCheck(Name, Context),
   WarnOnIntegerNarrowingConversion(
   Options.get("WarnOnIntegerNarrowingConversion", true)),
+  WarnOnIntegerToFloatingPointNarrowingConversion(
+  Options.get("WarnOnIntegerToFloatingPointNarrowingConversion", true)),
   WarnOnFloatingPointNarrowingConversion(
   Options.get("WarnOnFloatingPointNarrowingConversion", true)),
   WarnWithinTemplateInstantiation(
@@ -49,6 +51,8 @@
 ClangTidyOptions::OptionMap &Opts) {
   Options.store(Opts, "WarnOnIntegerNarrowingConversion",
 WarnOnIntegerNarrowingConversion);
+  Options.store(Opts, "WarnOnIntegerToFloatingPointNarrowingCon

[PATCH] D112881: [clang-tidy] Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions

[Paul Altin via Phabricator via cfe-commits]

paulaltin updated this revision to Diff 383904.
paulaltin added a comment.

Attempting to fix failed patch.


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

https://reviews.llvm.org/D112881

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
@@ -0,0 +1,13 @@
+// RUN: %check_clang_tidy -check-suffix=DEFAULT %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: true}]}'
+
+// RUN: %check_clang_tidy -check-suffix=DISABLED %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: false}]}'
+
+void foo(unsigned long long value) {
+  double a = value;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:14: warning: narrowing conversion from 'unsigned long long' to 'double' [cppcoreguidelines-narrowing-conversions]
+  // DISABLED: No warning for integer to floating-point narrowing conversions when WarnOnIntegerToFloatingPointNarrowingConversion = false.
+}
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
@@ -15,7 +15,8 @@
 We enforce only part of the guideline, more specifically, we flag narrowing conversions from:
  - an integer to a narrower integer (e.g. ``char`` to ``unsigned char``)
if WarnOnIntegerNarrowingConversion Option is set,
- - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``),
+ - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``)
+   if WarnOnIntegerToFloatingPointNarrowingConversion Option is set,
  - a floating-point to an integer (e.g. ``double`` to ``int``),
  - a floating-point to a narrower floating-point (e.g. ``double`` to ``float``)
if WarnOnFloatingPointNarrowingConversion Option is set.
@@ -36,6 +37,11 @@
 When `true`, the check will warn on narrowing integer conversion
 (e.g. ``int`` to ``size_t``). `true` by default.
 
+.. option:: WarnOnIntegerToFloatingPointNarrowingConversion
+
+When `true`, the check will warn on narrowing integer to floating-point
+conversion (e.g. ``size_t`` to ``double``). `true` by default.
+
 .. option:: WarnOnFloatingPointNarrowingConversion
 
 When `true`, the check will warn on narrowing floating point conversion
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -119,6 +119,8 @@
 - Removed default setting `cppcoreguidelines-explicit-virtual-functions.IgnoreDestructors = "true"`,
   to match the current state of the C++ Core Guidelines.
 
+- :doc:`cppcoreguidelines-narrowing-conversions ` check now supports a WarnOnIntegerToFloatingPointNarrowingConversion option to control whether to warn on narrowing integer to floating-point conversions.
+
 
 Removed checks
 ^^
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
@@ -37,6 +37,8 @@
 : ClangTidyCheck(Name, Context),
   WarnOnIntegerNarrowingConversion(
   Options.get("WarnOnIntegerNarrowingConversion", true)),
+  WarnOnIntegerToFloatingPointNarrowingConversion(
+  Options.get("WarnOnIntegerToFloatingPointNarrowingConversion", true)),
   WarnOnFloatingPointNarrowingConversion(
   Options.get("WarnOnFloatingPointNarrowingConversion", true)),
   WarnWithinTemplateInstantiation(
@@ -49,6 +51,8 @@
 ClangTidyOptions::OptionMap &Opts) {
   Options.store(Opts, "WarnOnIntegerNarrowingCo

[PATCH] D112881: [clang-tidy] Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions

[Paul Altin via Phabricator via cfe-commits]

paulaltin updated this revision to Diff 383905.
paulaltin added a comment.

Attempting to fix failed patch.


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

https://reviews.llvm.org/D112881

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-narrowingintegertofloatingpoint-option.cpp
@@ -0,0 +1,13 @@
+// RUN: %check_clang_tidy -check-suffix=DEFAULT %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: true}]}'
+
+// RUN: %check_clang_tidy -check-suffix=DISABLED %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [{key: cppcoreguidelines-narrowing-conversions.WarnOnIntegerToFloatingPointNarrowingConversion, value: false}]}'
+
+void foo(unsigned long long value) {
+  double a = value;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:14: warning: narrowing conversion from 'unsigned long long' to 'double' [cppcoreguidelines-narrowing-conversions]
+  // DISABLED: No warning for integer to floating-point narrowing conversions when WarnOnIntegerToFloatingPointNarrowingConversion = false.
+}
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
@@ -15,7 +15,8 @@
 We enforce only part of the guideline, more specifically, we flag narrowing conversions from:
  - an integer to a narrower integer (e.g. ``char`` to ``unsigned char``)
if WarnOnIntegerNarrowingConversion Option is set,
- - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``),
+ - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``)
+   if WarnOnIntegerToFloatingPointNarrowingConversion Option is set,
  - a floating-point to an integer (e.g. ``double`` to ``int``),
  - a floating-point to a narrower floating-point (e.g. ``double`` to ``float``)
if WarnOnFloatingPointNarrowingConversion Option is set.
@@ -36,6 +37,11 @@
 When `true`, the check will warn on narrowing integer conversion
 (e.g. ``int`` to ``size_t``). `true` by default.
 
+.. option:: WarnOnIntegerToFloatingPointNarrowingConversion
+
+When `true`, the check will warn on narrowing integer to floating-point
+conversion (e.g. ``size_t`` to ``double``). `true` by default.
+
 .. option:: WarnOnFloatingPointNarrowingConversion
 
 When `true`, the check will warn on narrowing floating point conversion
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -119,6 +119,8 @@
 - Removed default setting `cppcoreguidelines-explicit-virtual-functions.IgnoreDestructors = "true"`,
   to match the current state of the C++ Core Guidelines.
 
+- :doc:`cppcoreguidelines-narrowing-conversions ` check now supports a WarnOnIntegerToFloatingPointNarrowingConversion option to control whether to warn on narrowing integer to floating-point conversions.
+
 
 Removed checks
 ^^
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
@@ -37,6 +37,8 @@
 : ClangTidyCheck(Name, Context),
   WarnOnIntegerNarrowingConversion(
   Options.get("WarnOnIntegerNarrowingConversion", true)),
+  WarnOnIntegerToFloatingPointNarrowingConversion(
+  Options.get("WarnOnIntegerToFloatingPointNarrowingConversion", true)),
   WarnOnFloatingPointNarrowingConversion(
   Options.get("WarnOnFloatingPointNarrowingConversion", true)),
   WarnWithinTemplateInstantiation(
@@ -49,6 +51,8 @@
 ClangTidyOptions::OptionMap &Opts) {
   Options.store(Opts, "WarnOnIntegerNarrowingConversion",
 WarnOnIntegerNarrowingConversion);
+  Options.store(Opts, "WarnOnIntegerToFloatingPointN

[PATCH] D112916: Confusable identifiers detection

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang-tools-extra/clang-tidy/misc/CMakeLists.txt:9
+add_custom_command(
+OUTPUT confusables.h
+COMMAND make_confusable_table 
${CMAKE_CURRENT_SOURCE_DIR}/ConfusableTable/confusables.txt 
${CMAKE_CURRENT_BINARY_DIR}/confusables.h

Please generate a filename that follows our normal conventions 
(`Confusables.inc`).



Comment at: clang-tools-extra/clang-tidy/misc/ConfusableTable/confusables.txt:5
+# Unicode and the Unicode Logo are registered trademarks of Unicode, Inc. in 
the U.S. and other countries.
+# For terms of use, see http://www.unicode.org/terms_of_use.html
+#

From the terms of use we find this: https://www.unicode.org/license.html and in 
particular:

> [...] provided that either
> (a) this copyright and permission notice appear with all copies
> of the Data Files or Software, or
> (b) this copyright and permission notice appear in associated
> Documentation.

... so it looks like we might need to include a copy of at least the Unicode 
license. I'd like someone from the LLVM foundation to check for licensing 
concerns here before this lands.



Comment at: clang-tools-extra/clang-tidy/misc/Homoglyph.cpp:1-2
+//===--- MisleadingBidirectional.cpp - clang-tidy
+//===//
+//

Nit: fix the formatting here.



Comment at: clang-tools-extra/clang-tidy/misc/Homoglyph.cpp:89-90
+for (auto *OND : Mapped) {
+  if (!NDDecl->isDeclInLexicalTraversal(OND))
+continue;
+  if (OND->getName() != NDName) {

I think we also need to check for the reverse case 
(`OND->getDeclContext()->isDeclInLexicalTraversal(ND)`) here (assuming `a` and 
`A ` are homoglyphs etc):

```
int a;
namespace N {
  int A; // new is in context of old but not vice versa
  int b;
}
int B; // old is in context of new but not vice versa
namespace N {
  int c = a + B; // finds  ::a and ::B
}
```



Comment at: clang-tools-extra/clang-tidy/misc/Homoglyph.h:1
+//===--- Homoglyph.h - clang-tidy *- C++ -*-===//
+//

Nit: add more `-`s to pad to 80 characters.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112916

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