[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D93747#2481383 , @hoy wrote:

> In D93747#2481304 , @tmsriram wrote:
>
>> In D93747#2481223 , @tmsriram wrote:
>>
>>> In D93747#2481163 , @dblaikie 
>>> wrote:
>>>
 In D93747#2481095 , @hoy wrote:

> In D93747#2481073 , @dblaikie 
> wrote:
>
>> Suggesting that gdb isn't using the DW_AT_name at all for "break 
>> " but instead demangling and stripping off the extras 
>> from the linkage name, and since it can't demangle this uniquified name 
>> (unlike the mangled name used when using the overloadable attribute) 
>> that degrades the debugger user experience? I'd have to test that in 
>> more detail/with some hand-hacked DWARF.
>
> Yes, I think in your case the linage name can be demangled by the 
> debugger. In my previous experiment, the uniquefied names could not be 
> demangled therefore I was not able to breakpoint.

 Ah, did some more testing. Seems it's because it isn't a classically 
 mangled name.
>>
>> The simplest fix I can think of is to emit the base 10 number of the 
>> md5hash.  That would preserve all the existing uniqueness and be demangler 
>> friendly.  @hoy @dblaikie  WDYT?
>
> I think using the base 10 form of md5hash is a smart workaround. Thanks for 
> the suggestion.

Sure - wouldn't mind having some wording from the Itanium ABI/mangling rules 
that explain/corroborate what we've seen from testing to ensure we are using it 
correctly and there aren't any other ways that might be more suitable, or 
lurking gotchas we haven't tested.

 It might be possible for this uniquifying step to check if the name is 
 mangled (does it start with "_Z") and if it isn't mangled, it could mangle 
 it (check the length of the name, then "_Zv") and add the 
 unique suffix. That looks to me like it preserves the original debugging 
 behavior?

 (has the problem that we don't actually know the mangling scheme at this 
 point - we do know it up in clang (where it might be Itanium mangling or 
 Microsoft mangling), might point again to the possibility this feature is 
 more suitable to implement in the frontend rather than a middle end pass. 
 And also the 'v' in the mangling is 'void return type', which is a lie - 
 not sure if we could do something better there)
>
> Doing name unification in the frontend sounds like the ultimate solution and 
> since the frontend has all the knowledge about the name mangler. I think for 
> now we can go with the solution @tmsriram suggested, i.e., using the base 10 
> form of md5 hash.

Any general idea of how long "for now" would be? It doesn't seem like putting 
this off is going to make things especially better & seems like more bug 
fixes/changes/etc are being built around the solution as it is at the moment. 
So I'd be hesitant to put off this kind of restructuring too long.

 I think it's pretty important that we don't break tradeoff debuggability 
 for profile accuracy. It'll make for a difficult tradeoff for our/any 
 users.
>>>
>>> Agreed, I didn't expect this.
>>>
 (side note: using the original source file name seems problematic - I know 
 in google at least, the same source file is sometimes built into more than 
 one library/form with different preprocessor defines, so this may not 
 produce as unique a name as you are expecting?)
>>>
>>> It was a best effort and I think the hashing can be improved by using more 
>>> signals other than just the module name if needed.  For hard data though, 
>>> this does significantly improve performance which clearly comes from better 
>>> profile attribution so it does something.

I'm OK with the idea that this helped the situation - but it doesn't seem very 
principled/rigorous. Rather than a sliding scale of "better" I think it'd be 
worth considering in more detail what would be required to make this correct.

Using the object file name may be more robust - also not perfect for all build 
systems (one could imagine a distributed build system that /might/ be able to 
get away with having the distributed builders always build a file named x.o - 
only to have the distribution system rename the file to its canonical name on 
the main machine before linking occurs - but I think that's not how most 
distributed build systems work, and most build systems provide a unique object 
file name across a build?) but maybe moreso than using the input file name? (at 
least I think for google/blaze the object filename is genuinely unique)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

_

[PATCH] D92634: [Analyzer] Diagnose signed integer overflow

[Daniel Marjamäki via Phabricator via cfe-commits]

danielmarjamaki added a comment.

> I also agree with @NoQ's D92634#2478703 
>  comment.

well.. maybe it's better that I stop programming then and take this code I had 
and test it out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92634

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

[PATCH] D93796: [clangd][fuzzyFind] Do not show stale symbols in the result.

[Aleksandr Platonov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG979228f120f4: [clangd][fuzzyFind] Do not show stale symbols 
in the result. (authored by ArcsinX).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93796

Files:
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/index/Merge.h
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
  clang-tools-extra/clangd/unittests/IndexTests.cpp

Index: clang-tools-extra/clangd/unittests/IndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -335,6 +335,39 @@
   UnorderedElementsAre("ns::A", "ns::B", "ns::C"));
 }
 
+TEST(MergeIndexTest, FuzzyFindRemovedSymbol) {
+  FileIndex DynamicIndex, StaticIndex;
+  MergedIndex Merge(&DynamicIndex, &StaticIndex);
+
+  const char *HeaderCode = "class Foo;";
+  auto HeaderSymbols = TestTU::withHeaderCode(HeaderCode).headerSymbols();
+  auto Foo = findSymbol(HeaderSymbols, "Foo");
+
+  // Build static index for test.cc with Foo symbol
+  TestTU Test;
+  Test.HeaderCode = HeaderCode;
+  Test.Code = "class Foo {};";
+  Test.Filename = "test.cc";
+  auto AST = Test.build();
+  StaticIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Remove Foo symbol, i.e. build dynamic index for test.cc, which is empty.
+  Test.HeaderCode = "";
+  Test.Code = "";
+  AST = Test.build();
+  DynamicIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Merged index should not return removed symbol.
+  FuzzyFindRequest Req;
+  Req.AnyScope = true;
+  Req.Query = "Foo";
+  unsigned SymbolCounter = 0;
+  bool IsIncomplete =
+  Merge.fuzzyFind(Req, [&](const Symbol &) { ++SymbolCounter; });
+  EXPECT_FALSE(IsIncomplete);
+  EXPECT_EQ(SymbolCounter, 0u);
+}
+
 TEST(MergeTest, Merge) {
   Symbol L, R;
   L.ID = R.ID = SymbolID("hello");
Index: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -52,7 +52,17 @@
   return *SymbolInfos;
 }
 
-TEST(WorkspaceSymbols, Macros) {
+// FIXME: We update two indexes during main file processing:
+//- preamble index (static)
+//- main-file index (dynamic)
+//The macro in this test appears to be in the preamble index and not
+//in the main-file index. According to our logic of indexes merging, we
+//do not take this macro from the static (preamble) index, because it
+//location within the file from the dynamic (main-file) index.
+//
+//Possible solution is to exclude main-file symbols from the preamble
+//index, after that we can enable this test again.
+TEST(WorkspaceSymbols, DISABLED_Macros) {
   TestTU TU;
   TU.Code = R"cpp(
#define MACRO X
Index: clang-tools-extra/clangd/index/Merge.h
===
--- clang-tools-extra/clangd/index/Merge.h
+++ clang-tools-extra/clangd/index/Merge.h
@@ -23,10 +23,6 @@
 //  - the Dynamic index covers few files, but is relatively up-to-date.
 //  - the Static index covers a bigger set of files, but is relatively stale.
 // The returned index attempts to combine results, and avoid duplicates.
-//
-// FIXME: We don't have a mechanism in Index to track deleted symbols and
-// refs in dirty files, so the merged index may return stale symbols
-// and refs from Static index.
 class MergedIndex : public SymbolIndex {
   const SymbolIndex *Dynamic, *Static;
 
Index: clang-tools-extra/clangd/index/Merge.cpp
===
--- clang-tools-extra/clangd/index/Merge.cpp
+++ clang-tools-extra/clangd/index/Merge.cpp
@@ -22,11 +22,6 @@
 namespace clang {
 namespace clangd {
 
-// FIXME: Deleted symbols in dirty files are still returned (from Static).
-//To identify these eliminate these, we should:
-//  - find the generating file from each Symbol which is Static-only
-//  - ask Dynamic if it has that file (needs new SymbolIndex method)
-//  - if so, drop the Symbol.
 bool MergedIndex::fuzzyFind(
 const FuzzyFindRequest &Req,
 llvm::function_ref Callback) const {
@@ -49,7 +44,13 @@
   SymbolSlab Dyn = std::move(DynB).build();
 
   llvm::DenseSet SeenDynamicSymbols;
+  auto DynamicContainsFile = Dynamic->indexedFiles();
   More |= Static->fuzzyFind(Req, [&](const Symbol &S) {
+// We expect the definition to see the canonical declaration, so it seems
+// to be enough to check only the definition if it exists.
+if (DynamicContainsFile(S.Definition ? S.Definition.FileURI
+ : S.CanonicalDeclaration.FileURI))
+  return;
 auto DynS = Dyn.find(S.I

[clang-tools-extra] 979228f - [clangd][fuzzyFind] Do not show stale symbols in the result.

[Aleksandr Platonov via cfe-commits]

Author: Aleksandr Platonov
Date: 2021-01-06T11:17:12+03:00
New Revision: 979228f120f4aa1265648b1c06f65a84bcca1ed6

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

LOG: [clangd][fuzzyFind] Do not show stale symbols in the result.

This is follow up to D93393.
Without this patch `MergedIndex::fuzzyFind()` returns stale symbols from the 
static index even if these symbols were removed.

Reviewed By: sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/index/Merge.cpp
clang-tools-extra/clangd/index/Merge.h
clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
clang-tools-extra/clangd/unittests/IndexTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/Merge.cpp 
b/clang-tools-extra/clangd/index/Merge.cpp
index f66f47499624..29174ff0d354 100644
--- a/clang-tools-extra/clangd/index/Merge.cpp
+++ b/clang-tools-extra/clangd/index/Merge.cpp
@@ -22,11 +22,6 @@
 namespace clang {
 namespace clangd {
 
-// FIXME: Deleted symbols in dirty files are still returned (from Static).
-//To identify these eliminate these, we should:
-//  - find the generating file from each Symbol which is Static-only
-//  - ask Dynamic if it has that file (needs new SymbolIndex method)
-//  - if so, drop the Symbol.
 bool MergedIndex::fuzzyFind(
 const FuzzyFindRequest &Req,
 llvm::function_ref Callback) const {
@@ -49,7 +44,13 @@ bool MergedIndex::fuzzyFind(
   SymbolSlab Dyn = std::move(DynB).build();
 
   llvm::DenseSet SeenDynamicSymbols;
+  auto DynamicContainsFile = Dynamic->indexedFiles();
   More |= Static->fuzzyFind(Req, [&](const Symbol &S) {
+// We expect the definition to see the canonical declaration, so it seems
+// to be enough to check only the definition if it exists.
+if (DynamicContainsFile(S.Definition ? S.Definition.FileURI
+ : S.CanonicalDeclaration.FileURI))
+  return;
 auto DynS = Dyn.find(S.ID);
 ++StaticCount;
 if (DynS == Dyn.end())

diff  --git a/clang-tools-extra/clangd/index/Merge.h 
b/clang-tools-extra/clangd/index/Merge.h
index 0cdff38f0678..f8696b460c90 100644
--- a/clang-tools-extra/clangd/index/Merge.h
+++ b/clang-tools-extra/clangd/index/Merge.h
@@ -23,10 +23,6 @@ Symbol mergeSymbol(const Symbol &L, const Symbol &R);
 //  - the Dynamic index covers few files, but is relatively up-to-date.
 //  - the Static index covers a bigger set of files, but is relatively stale.
 // The returned index attempts to combine results, and avoid duplicates.
-//
-// FIXME: We don't have a mechanism in Index to track deleted symbols and
-// refs in dirty files, so the merged index may return stale symbols
-// and refs from Static index.
 class MergedIndex : public SymbolIndex {
   const SymbolIndex *Dynamic, *Static;
 

diff  --git a/clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp 
b/clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
index 43658284937e..bdd3ddca1a61 100644
--- a/clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ b/clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -52,7 +52,17 @@ std::vector getSymbols(TestTU &TU, 
llvm::StringRef Query,
   return *SymbolInfos;
 }
 
-TEST(WorkspaceSymbols, Macros) {
+// FIXME: We update two indexes during main file processing:
+//- preamble index (static)
+//- main-file index (dynamic)
+//The macro in this test appears to be in the preamble index and not
+//in the main-file index. According to our logic of indexes merging, we
+//do not take this macro from the static (preamble) index, because it
+//location within the file from the dynamic (main-file) index.
+//
+//Possible solution is to exclude main-file symbols from the preamble
+//index, after that we can enable this test again.
+TEST(WorkspaceSymbols, DISABLED_Macros) {
   TestTU TU;
   TU.Code = R"cpp(
#define MACRO X

diff  --git a/clang-tools-extra/clangd/unittests/IndexTests.cpp 
b/clang-tools-extra/clangd/unittests/IndexTests.cpp
index ce4845e3e144..33b0414275ca 100644
--- a/clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ b/clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -335,6 +335,39 @@ TEST(MergeIndexTest, FuzzyFind) {
   UnorderedElementsAre("ns::A", "ns::B", "ns::C"));
 }
 
+TEST(MergeIndexTest, FuzzyFindRemovedSymbol) {
+  FileIndex DynamicIndex, StaticIndex;
+  MergedIndex Merge(&DynamicIndex, &StaticIndex);
+
+  const char *HeaderCode = "class Foo;";
+  auto HeaderSymbols = TestTU::withHeaderCode(HeaderCode).headerSymbols();
+  auto Foo = findSymbol(HeaderSymbols, "Foo");
+
+  // Build static index for test.cc with Foo symbol
+  TestTU Test;
+  Test.HeaderCode = 

[PATCH] D94021: [OpenCL] Add clang extension for function pointers

[Marco Antognini via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D94021

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

[PATCH] D94027: [OpenCL] Add clang extension for variadic functions

[Marco Antognini via Phabricator via cfe-commits]

mantognini added a comment.

LGTM, just one question: I see in the other review you updated 
clang/test/SemaOpenCL/extension-version.cl. Do you need to do the same here?


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

https://reviews.llvm.org/D94027

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

[PATCH] D92812: [X86] AMD Znver3 (Family 19H) Enablement

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon accepted this revision.
RKSimon added a comment.

LGTM - cheers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92812

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

[PATCH] D92812: [X86] AMD Znver3 (Family 19H) Enablement

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

xbolva00 added a comment.

Patch title should be adjusted I think


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92812

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

[PATCH] D93942: [OpenCL] Improve online documentation.

[Marco Antognini via Phabricator via cfe-commits]

mantognini added a comment.

LGTM, except for a minor typo. Otherwise my comments have been addressed. 
Thanks.




Comment at: clang/docs/OpenCLSupport.rst:69
++==+==+==+===+
+| Command line interface   | New value for `-cl-std` flag  
   | :good:`done` | https://reviews.llvm.org/D88300 
  |
++--+--+--+---+

Anastasia wrote:
> mantognini wrote:
> > Double backticks?
> Just to make sure I understand you, do you suggest it for ``-cl-std``?
Yes, as you rightly updated. :)



Comment at: clang/docs/UsersManual.rst:3242
 
-Since C++ features are to be used on top of OpenCL C functionality, all 
existing
-restrictions from OpenCL C v2.0 will inherently apply. All OpenCL C builtin 
types
-and function libraries are supported and can be used in this mode.
+Clang currently support C++ for OpenCL v1.0.
+For detailed information about this language refer to the C++ for OpenCL




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

https://reviews.llvm.org/D93942

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

[PATCH] D94162: [PowerPC] Add variants of 64-bit vector types for vec_sel.

[EsmeYi via Phabricator via cfe-commits]

Esme created this revision.
Esme added reviewers: steven.zhang, nemanjai, qiucf, shchenz, PowerPC.
Herald added a subscriber: kbarton.
Esme requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch added the following variants of vec_sel.

  vector bool long long
  vec_sel(vector bool long long
  vector bool long long,
  vector bool long long);
  
  vector bool long long
  vec_sel(vector bool long long
  vector bool long long,
  vector unsigned long long);
  
  vector signed long long
  vec_sel(vector signed long long
  vector signed long long,
  vector bool long long);
  
  vector signed long long
  vec_sel(vector signed long long
  vector signed long long,
  vector unsigned long long);
  
  vector unsigned long long
  vec_sel(vector unsigned long long
  vector unsigned long long,
  vector bool long long);
  
  vector unsigned long long
  vec_sel(vector unsigned long long
  vector unsigned long long,
  vector unsigned long long);


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94162

Files:
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-vsx.c

Index: clang/test/CodeGen/builtins-ppc-vsx.c
===
--- clang/test/CodeGen/builtins-ppc-vsx.c
+++ clang/test/CodeGen/builtins-ppc-vsx.c
@@ -928,6 +928,66 @@
 // CHECK-LE: or <2 x i64>
 // CHECK-LE: bitcast <2 x i64> %{{[0-9]+}} to <2 x double>
 
+  res_vbll = vec_sel(vbll, vbll, vbll);
+// CHECK: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK: and <2 x i64> %{{[0-9]+}},
+// CHECK: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK: or <2 x i64>
+// CHECK-LE: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK-LE: and <2 x i64> %{{[0-9]+}},
+// CHECK-LE: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK-LE: or <2 x i64>
+
+  res_vbll = vec_sel(vbll, vbll, vull);
+// CHECK: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK: and <2 x i64> %{{[0-9]+}},
+// CHECK: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK: or <2 x i64>
+// CHECK-LE: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK-LE: and <2 x i64> %{{[0-9]+}},
+// CHECK-LE: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK-LE: or <2 x i64>
+
+  res_vsll = vec_sel(vsll, vsll, vbll);
+// CHECK: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK: and <2 x i64> %{{[0-9]+}},
+// CHECK: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK: or <2 x i64>
+// CHECK-LE: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK-LE: and <2 x i64> %{{[0-9]+}},
+// CHECK-LE: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK-LE: or <2 x i64>
+
+  res_vsll = vec_sel(vsll, vsll, vull);
+// CHECK: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK: and <2 x i64> %{{[0-9]+}},
+// CHECK: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK: or <2 x i64>
+// CHECK-LE: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK-LE: and <2 x i64> %{{[0-9]+}},
+// CHECK-LE: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK-LE: or <2 x i64>
+
+  res_vull = vec_sel(vull, vull, vbll);
+// CHECK: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK: and <2 x i64> %{{[0-9]+}},
+// CHECK: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK: or <2 x i64>
+// CHECK-LE: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK-LE: and <2 x i64> %{{[0-9]+}},
+// CHECK-LE: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK-LE: or <2 x i64>
+
+  res_vull = vec_sel(vull, vull, vull);
+// CHECK: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK: and <2 x i64> %{{[0-9]+}},
+// CHECK: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK: or <2 x i64>
+// CHECK-LE: xor <2 x i64> %{{[0-9]+}}, 
+// CHECK-LE: and <2 x i64> %{{[0-9]+}},
+// CHECK-LE: and <2 x i64> %{{[0-9]+}}, %{{[0-9]+}}
+// CHECK-LE: or <2 x i64>
+
   res_vf = vec_sqrt(vf);
 // CHECK: call <4 x float> @llvm.sqrt.v4f32(<4 x float> %{{[0-9]+}})
 // CHECK-LE: call <4 x float> @llvm.sqrt.v4f32(<4 x float> %{{[0-9]+}})
Index: clang/lib/Headers/altivec.h
===
--- clang/lib/Headers/altivec.h
+++ clang/lib/Headers/altivec.h
@@ -8281,6 +8281,46 @@
((vector long long)__b & (vector long long)__c);
   return (vector double)__res;
 }
+
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_sel(vector bool long long __a, vector bool long long __b,
+vector bool long long __c) {
+  return (__a & ~__c) | (__b & __c);
+}
+
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_sel(vector bool long long __a, vector bool long long __b,
+vector unsigned long long __c) {
+  return (__a & ~(vector bool long long)__c) |
+ (__b & (vector bool long long)__c);
+}
+
+static __inline__ vector signed long long __ATTRS_o_ai
+vec_sel(vector signed long long __a, vector signed long long __b,
+vector bool long long __c) {
+  return (__a & ~(vector signed long long)__c) |
+ (__b & (vector signed long long)__c);
+}
+
+static __inline__ vector signed long long __ATTRS_o_ai
+vec_sel(vector signed long long __a, vector sig

[PATCH] D93453: [flang][driver] Add support for `-I`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

Flang supports include files and module files.  The search path is used to look 
for both include files and module files.  The help text doesn't include info 
about module files.

The help text refers to the -isystem option.  Is that implemented for flang, 
and if so, ought tests be added to make sure -I and -isystem co-exist as 
documented for flang?

Not that there's also a special include directory for intrinsic modules.  
Intrinsic modules are treated specially, and right now, they are special by 
virtue of being in a special directory.  In the throwaway driver, the option is 
-intrinsic-module-directory.

There's also the -module option to specify the directory into which newly 
created module files are written.   I don't recall if flang or other compilers 
generally add that directory to the search path as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93453

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

[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 314846.
NoQ added a comment.

Handle conflicts across redeclarations! Fix typos and documentation formatting.


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

https://reviews.llvm.org/D91898

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-enforce-tcb-errors.cpp
  clang/test/Sema/attr-enforce-tcb.c
  clang/test/Sema/attr-enforce-tcb.cpp

Index: clang/test/Sema/attr-enforce-tcb.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-enforce-tcb.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#define PLACE_IN_TCB(NAME) [[clang::enforce_tcb(NAME)]]
+#define PLACE_IN_TCB_LEAF(NAME) [[clang::enforce_tcb_leaf(NAME)]]
+
+PLACE_IN_TCB("foo") void in_tcb_foo();
+void not_in_tcb();
+
+// Test behavior on classes and methods.
+class C {
+  void bar();
+
+  PLACE_IN_TCB("foo")
+  void foo() {
+// TODO: Figure out if we want to support methods at all.
+// Does it even make sense to isolate individual methods into a TCB?
+// Maybe a per-class attribute would make more sense?
+bar(); // expected-warning{{calling 'bar' is a violation of trusted computing base 'foo'}}
+  }
+};
+
+// Test behavior on templates.
+template 
+PLACE_IN_TCB("foo")
+void foo_never_instantiated() {
+  not_in_tcb(); // expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+template 
+PLACE_IN_TCB("foo")
+void foo_specialized();
+
+template<>
+void foo_specialized() {
+  not_in_tcb(); // expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+PLACE_IN_TCB("foo")
+void call_template_good() {
+  foo_specialized(); // no-warning
+}
+PLACE_IN_TCB("bar")
+void call_template_bad() {
+  foo_specialized(); // expected-warning{{calling 'foo_specialized' is a violation of trusted computing base 'bar'}}
+}
+
+template
+void foo_specialization_in_tcb();
+
+template<>
+PLACE_IN_TCB("foo")
+void foo_specialization_in_tcb() {
+  not_in_tcb(); //expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+template<>
+void foo_specialization_in_tcb() {
+  not_in_tcb(); // no-warning
+  in_tcb_foo(); // no-warning
+}
+
+PLACE_IN_TCB("foo")
+void call_specialization_in_tcb() {
+  foo_specialization_in_tcb(); // no-warning
+  foo_specialization_in_tcb(); // expected-warning{{calling 'foo_specialization_in_tcb' is a violation of trusted computing base 'foo'}}
+  foo_specialization_in_tcb(); // expected-warning{{'foo_specialization_in_tcb' is a violation of trusted computing base 'foo'}}
+}
Index: clang/test/Sema/attr-enforce-tcb.c
===
--- /dev/null
+++ clang/test/Sema/attr-enforce-tcb.c
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#define PLACE_IN_TCB(NAME) __attribute__ ((enforce_tcb(NAME)))
+#define PLACE_IN_TCB_LEAF(NAME) __attribute__ ((enforce_tcb_leaf(NAME)))
+
+void foo1 (void) PLACE_IN_TCB("bar");
+void foo2 (void) PLACE_IN_TCB("bar");
+void foo3 (void); // not in any TCB
+void foo4 (void) PLACE_IN_TCB("bar2");
+void foo5 (void) PLACE_IN_TCB_LEAF("bar");
+void foo6 (void) PLACE_IN_TCB("bar2") PLACE_IN_TCB("bar");
+void foo7 (void) PLACE_IN_TCB("bar3");
+void foo8 (void) PLACE_IN_TCB("bar") PLACE_IN_TCB("bar2");
+void foo9 (void);
+
+void foo1() {
+foo2(); // OK - function in same TCB
+foo3(); // expected-warning {{calling 'foo3' is a violation of trusted computing base 'bar'}}
+foo4(); // expected-warning {{calling 'foo4' is a violation of trusted computing base 'bar'}}
+foo5(); // OK - in leaf node
+foo6(); // OK - in multiple TCBs, one of which is the same
+foo7(); // expected-warning {{calling 'foo7' is a violation of trusted computing base 'bar'}}
+(void) __builtin_clz(5); // OK - builtins are excluded
+}
+
+// Normal use without any attributes works
+void foo3() {
+foo9(); // no-warning
+}
+
+void foo5() {
+// all calls should be okay, function in TCB leaf
+foo2(); // no-warning
+foo3(); // no-warning
+foo4(); // no-warning
+}
+
+void foo6() {
+foo1(); // expected-warning {{calling 'foo1' is a violation of trusted computing base 'bar2'}}
+foo4(); // expected-warning {{calling 'foo4' is a violation of trusted computing base 'bar'}}
+foo8(); // no-warning
+foo7(); // #1
+// expected-warning@#1 {{calling 'foo7' is a violation of trusted computing base 'bar2'}}
+// expected-warning@#1 {{calling 'foo7' is a violation of trusted computing base 'bar'}}
+}
+
+// Ensure that attribute merging works as expected across redeclarations.
+v

[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11087
+// TCB warnings
+def err_tcb_conflicting_attributes : Error<
+  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;

aaron.ballman wrote:
> NoQ wrote:
> > Do i understand correctly that while "unknown attribute" is a warning 
> > ("must be an attribute for some other compiler, let's ignore"), misuse of a 
> > known attribute is typically an error ("ok, whatever you meant here, i have 
> > an opinion about what this really means and i don't like it")?
> It depends strongly on the attribute and the problem at hand. My usual rule 
> of thumb is: if the attribute is being ignored because the code makes no 
> sense, it's an error, but if the attribute can still be useful (perhaps after 
> some adjustment), then warn. e.g., putting a calling convention attribute on 
> a variable of type `int` makes no sense -- that should probably err rather 
> than warn and ignore because the user did something baffling.
> 
> I could go either way on this one. Giving an error and forcing the user to 
> say what they mean is appealing, but it would also be defensible to warn 
> about the conflicting attribute and ignore just that one (retaining the 
> original attribute). I would say leave it as an error and we can downgrade to 
> a warning later if there's feedback from compelling real world use cases.
> retaining the original attribute

There's an interesting aspect of error recovery here (which i didn't address 
yet but added FIXMEs). We probably shouldn't emit additional warnings based on 
the attributes about which we've already reported a conflict error; that's just 
unnecessary clutter. That'd mean that we should always discard the non-leaf 
attribute and keep the leaf attribute (if we can at all discard attributes). Or 
keep both and repeat the conflict check during checking in order to suppress 
the warning.



Comment at: clang/test/Sema/attr-enforce-tcb-errors.cpp:23
+void both_tcb_and_tcb_leaf_on_separate_redeclarations();
+__attribute__((enforce_tcb_leaf("x"))) // FIXME: This should be an error.
+void both_tcb_and_tcb_leaf_on_separate_redeclarations() {}

aaron.ballman wrote:
> NoQ wrote:
> > Unfortunately the new facility doesn't catch this case because in 
> > `handleEnforceTCBAttr()` the function doesn't yet know that it's a 
> > redeclaration. I think this case is more important to catch than the 
> > straightforward case (because it's very easy to make this mistake), so i'll 
> > try to find a better place to emit the error. Is it ok if this goes into a 
> > follow-up patch?
> I was about to comment on the code in SemaDeclAttr.cpp but skipped down here 
> to see if you had a redeclaration test first, and found this comment instead. 
> :-D I think you need to follow the `mergeFooAttr` pattern to enforce this 
> properly (and I think it probably should be done in the initial patch, but it 
> shouldn't be too painful hopefully). The basic idea is that you change 
> `mergeDeclAttribute()` in SemaDecl.cpp to call `S.mergeEnforceTCBAttr()` that 
> checks whether there are conflicting attributes or not. Then in 
> `handleEnforceTCBAttr()` in SemaDeclAttr.cpp, you can call 
> `mergeEnforceTCBAttr()` to handle the straightforward case.
Found it, thanks!!


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

https://reviews.llvm.org/D91898

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

[PATCH] D94131: [clang-tidy] Use new mapAnyOf matcher

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Theres a few compile errors here in the pre merge. Is this patch based against 
trunk or some local branch?




Comment at: clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp:313
// may be instantiated to use std::move() on built-in types.
-   binaryOperator(hasOperatorName("="), hasLHS(DeclRefMatcher)),
-   cxxOperatorCallExpr(hasOverloadedOperatorName("="),
-   hasArgument(0, DeclRefMatcher)),
+   binaryOperation(hasOperatorName("="), hasLHS(DeclRefMatcher)),
// Declaration. We treat this as a type of reinitialization too,

This doesn't compile and it appears unrelated. Same beloe



Comment at: clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidGotoCheck.cpp:32
   // out of a nested loop.
-  auto Loop = stmt(anyOf(forStmt(), cxxForRangeStmt(), whileStmt(), doStmt()));
-  auto NestedLoop =
-  stmt(anyOf(forStmt(hasAncestor(Loop)), 
cxxForRangeStmt(hasAncestor(Loop)),
- whileStmt(hasAncestor(Loop)), doStmt(hasAncestor(Loop;
+  auto Loop = mapAnyOf(forStmt, cxxForRangeStmt, whileStmt, doStmt);
+  auto NestedLoop = Loop.with(hasAncestor(Loop.with(anything(;

Any reason for clang not finding this? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94131

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

[PATCH] D38968: [OpenMP] Implement omp_is_initial_device() as builtin

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added subscribers: jdoerfert, JonChesterfield.
JonChesterfield added a comment.
Herald added subscribers: sstefan1, guansong, yaxunl.
Herald added a reviewer: jdoerfert.

@jdoerfert suggested replacing this with a context selector. One less special 
case in clang.

Related, if this is a builtin (or in header), I think we can and should delete 
it from the devicertl. It's probably used as a branch condition so replacing 
with a 0/1 asap is winning for compilation time.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D38968

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

[PATCH] D93942: [OpenCL] Improve online documentation.

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 314856.
Anastasia added a comment.

Another fix from Marco.


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

https://reviews.llvm.org/D93942

Files:
  clang/docs/OpenCLSupport.rst
  clang/docs/UsersManual.rst

Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -41,7 +41,8 @@
variants depending on base language.
 -  :ref:`C++ Language `
 -  :ref:`Objective C++ Language `
--  :ref:`OpenCL C Language `: v1.0, v1.1, v1.2, v2.0.
+-  :ref:`OpenCL Kernel Language `: OpenCL C v1.0, v1.1, v1.2, v2.0,
+   plus C++ for OpenCL.
 
 In addition to these base languages and their dialects, Clang supports a
 broad variety of language extensions, which are documented in the
@@ -2796,8 +2797,8 @@
 ===
 
 Clang can be used to compile OpenCL kernels for execution on a device
-(e.g. GPU). It is possible to compile the kernel into a binary (e.g. for AMD or
-Nvidia targets) that can be uploaded to run directly on a device (e.g. using
+(e.g. GPU). It is possible to compile the kernel into a binary (e.g. for AMDGPU)
+that can be uploaded to run directly on a device (e.g. using
 `clCreateProgramWithBinary
 `_) or
 into generic bitcode files loadable into other toolchains.
@@ -2824,13 +2825,26 @@
 
  $ clang -c -emit-llvm test.cl
 
-This will produce a generic test.bc file that can be used in vendor toolchains
+This will produce a file `test.bc` that can be used in vendor toolchains
 to perform machine code generation.
 
-Clang currently supports OpenCL C language standards up to v2.0. Starting from
-clang 9 a C++ mode is available for OpenCL (see
+Note that if compiled to bitcode for generic targets such as SPIR,
+portable IR is produced that it can be used with various vendor
+tools as well as open source tools such as `SPIRV-LLVM Translator
+`_
+to produce SPIR-V binary.
+
+
+Clang currently supports OpenCL C language standards up to v2.0. Clang mainly
+supports full profile. There is only very limited support of the embedded
+profile. 
+Starting from clang 9 a C++ mode is available for OpenCL (see
 :ref:`C++ for OpenCL `).
 
+There is ongoing support for OpenCL v3.0 that is documented along with other
+experimental functionality and features in development on :doc:`OpenCLSupport`
+page.
+
 OpenCL Specific Options
 ---
 
@@ -2847,24 +2861,31 @@
 
 .. option:: -finclude-default-header
 
-Loads standard includes during compilations. By default OpenCL headers are not
-loaded and therefore standard library includes are not available. To load them
-automatically a flag has been added to the frontend (see also :ref:`the section
-on the OpenCL Header `):
+Adds most of builtin types and function declarations during compilations. By
+default the OpenCL headers are not loaded and therefore certain builtin
+types and most of builtin functions are not declared. To load them
+automatically this flag can be passed to the frontend (see also :ref:`the
+section on the OpenCL Header `):
 
.. code-block:: console
 
  $ clang -Xclang -finclude-default-header test.cl
 
-Alternatively ``-include`` or ``-I`` followed by the path to the header location
-can be given manually.
+Note that this is a frontend-only flag and therefore it requires the use of
+flags that forward options to the frontend, e.g. ``-cc1`` or ``-Xclang``.
+
+Alternatively the internal header `opencl-c.h` containing the declarations
+can be included manually using ``-include`` or ``-I`` followed by the path
+to the header location. The header can be found in the clang source tree or
+installation directory.
 
.. code-block:: console
 
- $ clang -I/lib/Headers/opencl-c.h test.cl
+ $ clang -I/lib/Headers/opencl-c.h test.cl
+ $ clang -I/lib/clang//include/opencl-c.h/opencl-c.h test.cl
 
-In this case the kernel code should contain ``#include `` just as a
-regular C include.
+In this example it is assumed that the kernel code contains
+``#include `` just as a regular C include.
 
 .. _opencl_cl_ext:
 
@@ -2874,10 +2895,14 @@
 of extensions that they support. Clang allows to amend this using the ``-cl-ext``
 flag with a comma-separated list of extensions prefixed with ``'+'`` or ``'-'``.
 The syntax: ``-cl-ext=<(['-'|'+'][,])+>``,  where extensions
-can be either one of `the OpenCL specification extensions
-`_
-or any known vendor extension. Alternatively, ``'all'`` can be used to enable
+can be either one of `the OpenCL published extensions
+`_
+or any vendor extension. Alternatively, ``'all'`` can be used to enable
 or disable all known extensions.
+
+Note that this is a frontend-only flag and therefore it requires the us

[PATCH] D94092: [Clang] Remove unnecessary Attr.isArgIdent checks.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D94092#2481276 , @rjmccall wrote:

> Without bothering to look it up, I would guess that the attribute-parsing 
> code used to generically handle the ambiguity between identifier expressions 
> and identifier attribute arguments by just always parsing simple identifiers 
> as identifier arguments, making it Sema's responsibility to turn that back 
> into an expression.  At some point, the parser was made sensitive to the 
> actual attribute being parsed, but we never bothered to simplify Sema.  At 
> any rate, the parser does now know exactly which argument of which attribute 
> it's parsing, so there's zero reason for it to force this complexity on Sema 
> anymore; if we find a case that parses identifier arguments, we should fix it 
> in the parser to parse an expression instead.

I don't think it will be quite that trivial (switching all identifiers to be 
parsed as expressions instead). For instance, attributes that take enumeration 
arguments can parse those arguments as identifiers, but those identifiers will 
never be found by usual expression lookup because they don't really exist. That 
said, any attribute that currently accepts an identifier because it really 
wants to use that identifier in an expression in Sema should update the 
attribute argument clauses in Attr.td and make the corresponding changes in 
SemaDeclAttr.cpp/SemaStmt.cpp/SemaType.cpp as appropriate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94092

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

[PATCH] D83892: [clang][cli] Port CodeGen option flags to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added a comment.

@thakis Thanks for the heads-up and sorry for the inconvenience.

@rnk You're right. This patch accidentally changed `Group` to 
`Group` for  `-g[no-]column-info`. In the linked build, this caused 
expansion of the driver flag `-gcolumn-info` to cc1 flag 
`-debug-info-kind=limited` instead of the correct 
`-debug-info-kind=tables-only`.

I've fixed the `Group` for `-g[no-]column-info` and for other two flags that 
were affected in a similar way in. 
https://reviews.llvm.org/rGce8c59e6af487f0b8786ae921aa926341f0ae04f

Let me know if there are any outstanding issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83892

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

[PATCH] D93222: [RFC][analyzer] Introduce MacroExpansionContext to libAnalysis

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

steakhal updated this revision to Diff 314857.
steakhal marked 11 inline comments as done.
steakhal added a comment.

- move `MacroExpansionRangeRecorder` to `clang::detail` and mark it as a friend 
class
- fix comment typo in `getExpandedMacroForLocation`
- rename `getExpandedMacroForLocation` -> `getExpandedText`
- rename `getSubstitutedTextForLocation` -> `getOriginalText`
- introduce `llvm_unreachable` where applicable.

No tests were changed.


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

https://reviews.llvm.org/D93222

Files:
  clang/include/clang/Analysis/MacroExpansionContext.h
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/MacroExpansionContext.cpp
  clang/unittests/Analysis/CMakeLists.txt
  clang/unittests/Analysis/MacroExpansionContextTest.cpp

Index: clang/unittests/Analysis/MacroExpansionContextTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/MacroExpansionContextTest.cpp
@@ -0,0 +1,338 @@
+//===- unittests/Analysis/MacroExpansionContextTest.cpp - -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Analysis/MacroExpansionContext.h"
+#include "clang/AST/ASTConsumer.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetInfo.h"
+#include "clang/Basic/TargetOptions.h"
+#include "clang/Lex/HeaderSearch.h"
+#include "clang/Lex/HeaderSearchOptions.h"
+#include "clang/Lex/Preprocessor.h"
+#include "clang/Lex/PreprocessorOptions.h"
+#include "clang/Parse/Parser.h"
+#include "llvm/ADT/SmallString.h"
+#include "gtest/gtest.h"
+
+// static bool HACK_EnableDebugInUnitTest = (::llvm::DebugFlag = true);
+
+namespace clang {
+namespace analysis {
+namespace {
+
+class MacroExpansionContextTest : public ::testing::Test {
+protected:
+  MacroExpansionContextTest()
+  : InMemoryFileSystem(new llvm::vfs::InMemoryFileSystem),
+FileMgr(FileSystemOptions(), InMemoryFileSystem),
+DiagID(new DiagnosticIDs()), DiagOpts(new DiagnosticOptions()),
+Diags(DiagID, DiagOpts.get(), new IgnoringDiagConsumer()),
+SourceMgr(Diags, FileMgr), TargetOpts(new TargetOptions()) {
+TargetOpts->Triple = "x86_64-pc-linux-unknown";
+Target = TargetInfo::CreateTargetInfo(Diags, TargetOpts);
+LangOpts.CPlusPlus20 = 1; // For __VA_OPT__
+  }
+
+  IntrusiveRefCntPtr InMemoryFileSystem;
+  FileManager FileMgr;
+  IntrusiveRefCntPtr DiagID;
+  IntrusiveRefCntPtr DiagOpts;
+  DiagnosticsEngine Diags;
+  SourceManager SourceMgr;
+  LangOptions LangOpts;
+  std::shared_ptr TargetOpts;
+  IntrusiveRefCntPtr Target;
+
+  std::unique_ptr
+  getMacroExpansionContextFor(StringRef SourceText) {
+std::unique_ptr Buf =
+llvm::MemoryBuffer::getMemBuffer(SourceText);
+SourceMgr.setMainFileID(SourceMgr.createFileID(std::move(Buf)));
+TrivialModuleLoader ModLoader;
+HeaderSearch HeaderInfo(std::make_shared(), SourceMgr,
+Diags, LangOpts, Target.get());
+Preprocessor PP(std::make_shared(), Diags, LangOpts,
+SourceMgr, HeaderInfo, ModLoader,
+/*IILookup =*/nullptr,
+/*OwnsHeaderSearch =*/false);
+
+PP.Initialize(*Target);
+auto Ctx = std::make_unique(PP, LangOpts);
+
+// Lex source text.
+PP.EnterMainSourceFile();
+
+while (true) {
+  Token Tok;
+  PP.Lex(Tok);
+  if (Tok.is(tok::eof))
+break;
+}
+
+// Callbacks have been executed at this point.
+return Ctx;
+  }
+
+  /// Returns the expansion location to main file at the given row and column.
+  SourceLocation at(unsigned row, unsigned col) const {
+SourceLocation Loc =
+SourceMgr.translateLineCol(SourceMgr.getMainFileID(), row, col);
+return SourceMgr.getExpansionLoc(Loc);
+  }
+};
+
+TEST_F(MacroExpansionContextTest, EmptyExpansions) {
+  const auto Ctx = getMacroExpansionContextFor(R"code(
+  #define EMPTY
+  A b cd EMPTY ef EMPTY gh
+EMPTY zz
+  )code");
+  // After preprocessing:
+  //  A b cd ef gh
+  //  zz
+
+  EXPECT_EQ("", Ctx->getExpandedText(at(3, 10)));
+  EXPECT_EQ("EMPTY", Ctx->getOriginalText(at(3, 10)));
+
+  EXPECT_EQ("", Ctx->getExpandedText(at(3, 19)));
+  EXPECT_EQ("EMPTY", Ctx->getOriginalText(at(3, 19)));
+
+  EXPECT_EQ("", Ctx->getExpandedText(at(4, 1)));
+  EXPECT_EQ("EMPTY", Ctx->getOriginalText(at(4, 1)));
+}
+
+TEST_F(MacroExpansionContextTest, TransitiveExpansions) {
+  const auto Ctx = getMacroExpansionContextFor(R"code(
+  #define EMPTY
+  #define WOOF EMPTY 

[PATCH] D77598: Integral template argument suffix and cast printing

[Pratyush Das via Phabricator via cfe-commits]

reikdas updated this revision to Diff 314858.
reikdas marked an inline comment as done.
reikdas added a comment.

Address @rsmith review


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

https://reviews.llvm.org/D77598

Files:
  clang/include/clang/AST/DeclTemplate.h
  clang/include/clang/AST/StmtDataCollectors.td
  clang/include/clang/AST/TemplateBase.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/DeclTemplate.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Analysis/PathDiagnostic.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/Analysis/eval-predefined-exprs.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p12.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p13.cpp
  clang/test/SemaCXX/builtin-align-cxx.cpp
  clang/test/SemaCXX/cxx11-ast-print.cpp
  clang/test/SemaCXX/cxx1z-ast-print.cpp
  clang/test/SemaCXX/matrix-type-builtins.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  clang/test/SemaTemplate/delegating-constructors.cpp
  clang/test/SemaTemplate/matrix-type.cpp
  clang/test/SemaTemplate/temp_arg_nontype.cpp
  clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
  clang/tools/libclang/CIndex.cpp
  
clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp

Index: clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
===
--- clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
+++ clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
@@ -20,7 +20,7 @@
 llvm::raw_string_ostream Stream(ArgStr);
 const TemplateArgument &Arg = ArgLoc.getArgument();
 
-Arg.print(Context->getPrintingPolicy(), Stream);
+Arg.print(Context->getPrintingPolicy(), Stream, /*IncludeType*/ true);
 Match(Stream.str(), ArgLoc.getLocation());
 return ExpectedLocationVisitor::
   TraverseTemplateArgumentLoc(ArgLoc);
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5145,8 +5145,9 @@
 SmallString<128> Str;
 llvm::raw_svector_ostream OS(Str);
 OS << *ClassSpec;
-printTemplateArgumentList(OS, ClassSpec->getTemplateArgs().asArray(),
-  Policy);
+printTemplateArgumentList(
+OS, ClassSpec->getTemplateArgs().asArray(), Policy,
+ClassSpec->getSpecializedTemplate()->getTemplateParameters());
 return cxstring::createDup(OS.str());
   }
 
Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -503,3 +503,43 @@
   template<> struct Q<&R::n> { static constexpr int X = 1; };
   static_assert(R().f() == 1);
 }
+
+namespace dependent_reference {
+  template struct S { int *q = &r; };
+  template auto f() { static int n; return S(); }
+  auto v = f<0>();
+  auto w = f<1>();
+  static_assert(!is_same);
+  // Ensure that we can instantiate the definition of S<...>.
+  int n = *v.q + *w.q;
+}
+
+namespace TypeSuffix {
+  template  struct A {};
+  template <> struct A<1> { using type = int; }; // expected-note {{'A<1>::type' declared here}}
+  A<1L>::type a; // expected-error {{no type named 'type' in 'TypeSuffix::A<1L>'; did you mean 'A<1>::type'?}}
+
+  template  struct B {};
+  template <> struct B<1> { using type = int; }; // expected-note {{'B<1>::type' declared here}}
+  B<2>::type b;  // expected-error {{no type named 'type' in 'TypeSuffix::B<2>'; did you mean 'B<1>::type'?}}
+
+  template  struct C {};
+  template <> struct C<'a'> { using type = signed char; }; // expected-note {{'C<'a'>::type' declared here}}
+  C<(signed char)'a'>::type c; // expected-error {{no type named 'type' in 'TypeSuffix::C<(signed char)'a'>'; did you mean 'C<'a'>::type'?}}
+
+  template  struct D {};
+  template <> struct D<'a'> { using type = signed char; }; // expected-note {{'D<'a'>::type' declared here}}
+  D<'b'>::type d;  // expected-error {{no type named 'type' in 'TypeSuffix::D<'b'>'; did you mean 'D<'a'>::type'?}}
+
+  template  struct E {};
+  template <> struct E<'a'> { using type = unsigned char; }; // expected-note {{'E<'a'>::type' declared here}}
+  E<(unsigned char)'a'>::type e; // 

[PATCH] D94083: [AArch64] Add +pauth archictecture option, allowing the v8.3a pointer authentication extension.

[Momchil Velikov via Phabricator via cfe-commits]

chill accepted this revision.
chill 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/D94083/new/

https://reviews.llvm.org/D94083

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

[PATCH] D77598: Integral template argument suffix and cast printing

[Pratyush Das via Phabricator via cfe-commits]

reikdas updated this revision to Diff 314859.
reikdas marked 2 inline comments as done.

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

https://reviews.llvm.org/D77598

Files:
  clang/include/clang/AST/DeclTemplate.h
  clang/include/clang/AST/StmtDataCollectors.td
  clang/include/clang/AST/TemplateBase.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/DeclTemplate.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Analysis/PathDiagnostic.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/Analysis/eval-predefined-exprs.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p12.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p13.cpp
  clang/test/SemaCXX/builtin-align-cxx.cpp
  clang/test/SemaCXX/cxx11-ast-print.cpp
  clang/test/SemaCXX/cxx1z-ast-print.cpp
  clang/test/SemaCXX/matrix-type-builtins.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  clang/test/SemaTemplate/delegating-constructors.cpp
  clang/test/SemaTemplate/matrix-type.cpp
  clang/test/SemaTemplate/temp_arg_nontype.cpp
  clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
  clang/tools/libclang/CIndex.cpp
  
clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp

Index: clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
===
--- clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
+++ clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
@@ -20,7 +20,7 @@
 llvm::raw_string_ostream Stream(ArgStr);
 const TemplateArgument &Arg = ArgLoc.getArgument();
 
-Arg.print(Context->getPrintingPolicy(), Stream);
+Arg.print(Context->getPrintingPolicy(), Stream, /*IncludeType*/ true);
 Match(Stream.str(), ArgLoc.getLocation());
 return ExpectedLocationVisitor::
   TraverseTemplateArgumentLoc(ArgLoc);
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5145,8 +5145,9 @@
 SmallString<128> Str;
 llvm::raw_svector_ostream OS(Str);
 OS << *ClassSpec;
-printTemplateArgumentList(OS, ClassSpec->getTemplateArgs().asArray(),
-  Policy);
+printTemplateArgumentList(
+OS, ClassSpec->getTemplateArgs().asArray(), Policy,
+ClassSpec->getSpecializedTemplate()->getTemplateParameters());
 return cxstring::createDup(OS.str());
   }
 
Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -503,3 +503,33 @@
   template<> struct Q<&R::n> { static constexpr int X = 1; };
   static_assert(R().f() == 1);
 }
+
+namespace TypeSuffix {
+  template  struct A {};
+  template <> struct A<1> { using type = int; }; // expected-note {{'A<1>::type' declared here}}
+  A<1L>::type a; // expected-error {{no type named 'type' in 'TypeSuffix::A<1L>'; did you mean 'A<1>::type'?}}
+
+  template  struct B {};
+  template <> struct B<1> { using type = int; }; // expected-note {{'B<1>::type' declared here}}
+  B<2>::type b;  // expected-error {{no type named 'type' in 'TypeSuffix::B<2>'; did you mean 'B<1>::type'?}}
+
+  template  struct C {};
+  template <> struct C<'a'> { using type = signed char; }; // expected-note {{'C<'a'>::type' declared here}}
+  C<(signed char)'a'>::type c; // expected-error {{no type named 'type' in 'TypeSuffix::C<(signed char)'a'>'; did you mean 'C<'a'>::type'?}}
+
+  template  struct D {};
+  template <> struct D<'a'> { using type = signed char; }; // expected-note {{'D<'a'>::type' declared here}}
+  D<'b'>::type d;  // expected-error {{no type named 'type' in 'TypeSuffix::D<'b'>'; did you mean 'D<'a'>::type'?}}
+
+  template  struct E {};
+  template <> struct E<'a'> { using type = unsigned char; }; // expected-note {{'E<'a'>::type' declared here}}
+  E<(unsigned char)'a'>::type e; // expected-error {{no type named 'type' in 'TypeSuffix::E<(unsigned char)'a'>'; did you mean 'E<'a'>::type'?}}
+
+  template  struct F {};
+  template <> struct F<'a'> { using type = unsigned char; }; // expected-note {{'F<'a'>::type' declared here}}
+  F<'b'>::type f;// expected-error {{no

[PATCH] D92892: [clang] Change builtin object size to be compatible with GCC when sub-object is invalid

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added subscribers: cfe-commits, aaron.ballman.
aaron.ballman added reviewers: rsmith, jyknight.
aaron.ballman added a comment.

Adding some reviewers and subscribing the mailing lists. FWIW, the changes seem 
reasonable to me.


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

https://reviews.llvm.org/D92892

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

[PATCH] D94169: [clang][driver] Restore the original help text for `-I`

[Andrzej Warzynski via Phabricator via cfe-commits]

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

The help text for `-I` was recently expanded in this commit:

- 8dd4e3ceb804a58bcf25e6856fc6fde5e1995a66 


The updated version:

- describes the internal implementation in Clang, and
- is inconsistently long when compared to other options printed with `clang 
-help`.

We are now in the process of adding support for `-I` in Flang and this
expanded description is invalid as far as Flang is concerned (i.e. it
does not reflect Flang's internal implementation). See this review:

- https://reviews.llvm.org/D93453

This patch reverts the original change in Options.td. This way the
description of `-I` remains generic and valid for both Clang and Flang.

Clang's internal documentation for `-I` is available in
ClangCommandLineReference.rst (it's identical to what's being removed
here, so no information is lost).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94169

Files:
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -649,12 +649,7 @@
  "remove current directory from include path">;
 def I : JoinedOrSeparate<["-"], "I">, Group,
 Flags<[CC1Option,CC1AsOption]>, MetaVarName<"">,
-HelpText<"Add directory to include search path. If there are multiple -I "
- "options, these directories are searched in the order they are "
- "given before the standard system directories are searched. "
- "If the same directory is in the SYSTEM include search paths, for 
"
- "example if also specified with -isystem, the -I option will be "
- "ignored">;
+HelpText<"Add directory to include search path">;
 def L : JoinedOrSeparate<["-"], "L">, Flags<[RenderJoined]>, Group,
 MetaVarName<"">, HelpText<"Add directory to library search path">;
 def MD : Flag<["-"], "MD">, Group,


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -649,12 +649,7 @@
  "remove current directory from include path">;
 def I : JoinedOrSeparate<["-"], "I">, Group,
 Flags<[CC1Option,CC1AsOption]>, MetaVarName<"">,
-HelpText<"Add directory to include search path. If there are multiple -I "
- "options, these directories are searched in the order they are "
- "given before the standard system directories are searched. "
- "If the same directory is in the SYSTEM include search paths, for "
- "example if also specified with -isystem, the -I option will be "
- "ignored">;
+HelpText<"Add directory to include search path">;
 def L : JoinedOrSeparate<["-"], "L">, Flags<[RenderJoined]>, Group,
 MetaVarName<"">, HelpText<"Add directory to library search path">;
 def MD : Flag<["-"], "MD">, Group,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93453: [flang][driver] Add support for `-I`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

In D93453#2481720 , @sscalpone wrote:

> Flang supports include files and module files.  The search path is used to 
> look for both include files and module files.  The help text doesn't include 
> info about module files.

Good point - the help message is inaccurate.  It comes from Options.td, which 
currently is shared with Clang: 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Driver/Options.td#L650-L657.
 It documents Clang's internal implementation. IMO `Options.td` should not 
reveal internal implementation. In fact, that information is duplicated here: 
https://clang.llvm.org/docs/ClangCommandLineReference.html#include-path-management.
 I suggested a fix here: https://reviews.llvm.org/D94169.

> The help text refers to the -isystem option.  Is that implemented for flang, 
> and if so, ought tests be added to make sure -I and -isystem co-exist as 
> documented for flang?

`-isystem` is neither implemented nor planned in the near future for the new 
Flang driver [2]. Also, the updated `help` message won't contain any references 
to `-isystem`.

> Not that there's also a special include directory for intrinsic modules.  
> Intrinsic modules are treated specially, and right now, they are special by 
> virtue of being in a special directory.  In the throwaway driver, the option 
> is -intrinsic-module-directory.
>
> There's also the -module option to specify the directory into which newly 
> created module files are written.   I don't recall if flang or other 
> compilers generally add that directory to the search path as well.

Yea, we are aware of that. As proposed in [1] and [2]:

- `-intrinsic-module-directory` will be replaced with `-fintrinsic-modules-path`
- `-module` will be replaced with `-J/-module-dir`

There will be separate patches for these options.

[1] [flang-dev] RFC: new Flang driver options: 
https://lists.llvm.org/pipermail/flang-dev/2020-November/000588.html
[2] LLVM/flang new driver options: 
https://docs.google.com/spreadsheets/d/1JRe39lP_KhtkYxFEIvwrCFlE5v1Ofa_krOHI-XXXWPY/edit#gid=0


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93453

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

[PATCH] D86844: [LoopDeletion] Allows deletion of possibly infinite side-effect free loops

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

xbolva00 added a comment.

  int a, b;
  
  int f(void) {
  while (1) {
  if (a != b) return 1;
  }
  return 0;
  }
  
  int g(int a, int b) {
  while (1) {
  if (a != b) return 1;
  }
  return 0;
  }

LLVM does not catch these cases; gcc does.

https://godbolt.org/z/jW7son


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86844

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

[PATCH] D93701: [clang][cli] NFC: Make Diags optional in normalizer

[Jan Svoboda via Phabricator via cfe-commits]

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

Instead of making Diags optional everywhere, pass an ignoring Diags into 
ParseDiagnosticArgs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93701

Files:
  clang/include/clang/Frontend/CompilerInvocation.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/tools/driver/driver.cpp

Index: clang/tools/driver/driver.cpp
===
--- clang/tools/driver/driver.cpp
+++ clang/tools/driver/driver.cpp
@@ -281,7 +281,9 @@
   // We ignore MissingArgCount and the return value of ParseDiagnosticArgs.
   // Any errors that would be diagnosed here will also be diagnosed later,
   // when the DiagnosticsEngine actually exists.
-  (void)ParseDiagnosticArgs(*DiagOpts, Args);
+  DiagnosticsEngine DummyDiags(new DiagnosticIDs(), new DiagnosticOptions(),
+   new IgnoringDiagConsumer());
+  (void)ParseDiagnosticArgs(*DiagOpts, Args, DummyDiags);
 
   UseNewCC1Process =
   Args.hasFlag(clang::driver::options::OPT_fno_integrated_cc1,
Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -328,7 +328,9 @@
   unsigned MissingArgIndex, MissingArgCount;
   llvm::opt::InputArgList ParsedArgs = driver::getDriverOptTable().ParseArgs(
   ArrayRef(Argv).slice(1), MissingArgIndex, MissingArgCount);
-  ParseDiagnosticArgs(*DiagOpts, ParsedArgs);
+  DiagnosticsEngine DummyDiags(new DiagnosticIDs(), new DiagnosticOptions(),
+   new IgnoringDiagConsumer());
+  ParseDiagnosticArgs(*DiagOpts, ParsedArgs, DummyDiags);
   TextDiagnosticPrinter DiagnosticPrinter(
   llvm::errs(), &*DiagOpts);
   DiagnosticsEngine Diagnostics(
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -828,7 +828,7 @@
 
 static bool parseDiagnosticLevelMask(StringRef FlagName,
  const std::vector &Levels,
- DiagnosticsEngine *Diags,
+ DiagnosticsEngine &Diags,
  DiagnosticLevelMask &M) {
   bool Success = true;
   for (const auto &Level : Levels) {
@@ -841,8 +841,7 @@
 .Default(DiagnosticLevelMask::None);
 if (PM == DiagnosticLevelMask::None) {
   Success = false;
-  if (Diags)
-Diags->Report(diag::err_drv_invalid_value) << FlagName << Level;
+  Diags.Report(diag::err_drv_invalid_value) << FlagName << Level;
 }
 M = M | PM;
   }
@@ -1381,7 +1380,7 @@
 }
 
 static bool checkVerifyPrefixes(const std::vector &VerifyPrefixes,
-DiagnosticsEngine *Diags) {
+DiagnosticsEngine &Diags) {
   bool Success = true;
   for (const auto &Prefix : VerifyPrefixes) {
 // Every prefix must start with a letter and contain only alphanumeric
@@ -1391,17 +1390,15 @@
 });
 if (BadChar != Prefix.end() || !isLetter(Prefix[0])) {
   Success = false;
-  if (Diags) {
-Diags->Report(diag::err_drv_invalid_value) << "-verify=" << Prefix;
-Diags->Report(diag::note_drv_verify_prefix_spelling);
-  }
+  Diags.Report(diag::err_drv_invalid_value) << "-verify=" << Prefix;
+  Diags.Report(diag::note_drv_verify_prefix_spelling);
 }
   }
   return Success;
 }
 
 bool clang::ParseDiagnosticArgs(DiagnosticOptions &Opts, ArgList &Args,
-DiagnosticsEngine *Diags,
+DiagnosticsEngine &Diags,
 bool DefaultDiagColor) {
   bool Success = true;
 
@@ -1437,10 +1434,9 @@
 Opts.setShowOverloads(Ovl_All);
   else {
 Success = false;
-if (Diags)
-  Diags->Report(diag::err_drv_invalid_value)
-  << Args.getLastArg(OPT_fshow_overloads_EQ)->getAsString(Args)
-  << ShowOverloads;
+Diags.Report(diag::err_drv_invalid_value)
+<< Args.getLastArg(OPT_fshow_overloads_EQ)->getAsString(Args)
+<< ShowOverloads;
   }
 
   StringRef ShowCategory =
@@ -1453,10 +1449,9 @@
 Opts.ShowCategories = 2;
   else {
 Success = false;
-if (Diags)
-  Diags->Report(diag::err_drv_invalid_value)
-  << Args.getLastArg(OPT_fdiagnostics_show_category)->getAsString(Args)
-  << ShowCategory;
+Diags.Report(diag::err_drv_invalid_value)
+<< Args.getLastArg(OPT_fdiagnostics_show_category)->getAsString(Args)
+<< ShowCategory;
   }
 
   StringRef Format =
@@ -1472,10 +1467,9 @@
 Opts.setFormat(DiagnosticOptions::Vi);
   else {
 Success = false;
-if (Diags)
-  Diags->Report(diag::err

[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

In D93377#2481312 , @rjmccall wrote:

> Are you committed to the name `__ibm128`?

Insofar as that's what GCC on Power (for example, `gcc (Ubuntu 
7.5.0-3ubuntu1~18.04) 7.5.0` from 2017) has shipped with for several years, yes.


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

https://reviews.llvm.org/D93377

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

[PATCH] D94027: [OpenCL] Add clang extension for variadic functions

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 314869.
Anastasia added a comment.

Added missing testing in extension-version.cl


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

https://reviews.llvm.org/D94027

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Sema/SemaType.cpp
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
  clang/test/Misc/nvptx.languageOptsOpenCL.cl
  clang/test/Misc/r600.languageOptsOpenCL.cl
  clang/test/SemaOpenCL/extension-version.cl
  clang/test/SemaOpenCL/func.cl

Index: clang/test/SemaOpenCL/func.cl
===
--- clang/test/SemaOpenCL/func.cl
+++ clang/test/SemaOpenCL/func.cl
@@ -1,18 +1,31 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DFUNCPTREXT
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DVARARG
 
 #ifdef FUNCPTREXT
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 #endif
+#ifdef VARARGEXT
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+#endif
 
 // Variadic functions
-void vararg_f(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+void vararg_f(int, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+#endif
 void __vararg_f(int, ...);
-typedef void (*vararg_fptr_t)(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+typedef void (*vararg_fptr_t)(int, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+#endif
 #ifndef FUNCPTREXT
-// expected-error@-2 {{pointers to functions are not allowed}}
+// expected-error@-5 {{pointers to functions are not allowed}}
+#endif
+int printf(__constant const char *st, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 #endif
-int printf(__constant const char *st, ...); // expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 
 // Struct type with function pointer field
 typedef struct s
Index: clang/test/SemaOpenCL/extension-version.cl
===
--- clang/test/SemaOpenCL/extension-version.cl
+++ clang/test/SemaOpenCL/extension-version.cl
@@ -24,6 +24,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifndef cl_khr_fp16
 #error "Missing cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/r600.languageOptsOpenCL.cl
===
--- clang/test/Misc/r600.languageOptsOpenCL.cl
+++ clang/test/Misc/r600.languageOptsOpenCL.cl
@@ -35,6 +35,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifdef cl_khr_fp16
 #error "Incorrect cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/nvptx.languageOptsOpenCL.cl
===
--- clang/test/Misc/nvptx.languageOptsOpenCL.cl
+++ clang/test/Misc/nvptx.languageOptsOpenCL.cl
@@ -27,6 +27,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifdef cl_khr_fp16
 #error "Incorrect cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/amdgcn.languageOptsOpenCL.cl
===
--- clang/test/Misc/amdgcn.languageOptsOpenCL.cl
+++ clang/test/Misc/amdgcn.languageOptsOpenCL.cl
@@ -19,6 +19,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifndef cl_khr_fp16
 #error "Missing cl_khr_fp16 define"
 #endif
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -5019,6 +5019,7 @@
 // (s6.9.e and s6.12.5 OpenCL v2.0) except for printf.
 // We also allow here any toolchain reserved identifiers.
 if (FTI.isVariadic &&
+!S.getOpenCLOptions().isEnabled("__cl_clang_variadic_fu

[PATCH] D94027: [OpenCL] Add clang extension for variadic functions

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D94027#2481597 , @mantognini wrote:

> LGTM, just one question: I see in the other review you updated 
> clang/test/SemaOpenCL/extension-version.cl. Do you need to do the same here?

Good spot! Thanks!


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

https://reviews.llvm.org/D94027

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

[PATCH] D91806: [InstCombine] Update valueCoversEntireFragment to use TypeSize

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen accepted this revision.
sdesmalen 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/D91806/new/

https://reviews.llvm.org/D91806

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

[PATCH] D94172: [clang][cli] NFC: Move marshalling macros closer together

[Jan Svoboda via Phabricator via cfe-commits]

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

This patch moves marshalling macros closer together. In a future patch that 
starts reusing them, this help to reduce to limit the scope of the macros.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94172

Files:
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -382,6 +382,55 @@
   return KeyPath & Value;
 }
 
+bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
+ DiagnosticsEngine &Diags) {
+  bool Success = true;
+
+#define OPTION_WITH_MARSHALLING(   \
+PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
+HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
+TABLE_INDEX)   \
+  if ((FLAGS)&options::CC1Option) {\
+this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
+if (IMPLIED_CHECK) \
+  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
+if (auto MaybeValue =  \
+NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   \
+  this->KEYPATH = MERGER(  \
+  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   \
+  }
+
+#include "clang/Driver/Options.inc"
+#undef OPTION_WITH_MARSHALLING
+
+  return Success;
+}
+
+void CompilerInvocation::generateCC1CommandLine(
+SmallVectorImpl &Args, StringAllocator SA) const {
+  // Capture the extracted value as a lambda argument to avoid potential issues
+  // with lifetime extension of the reference.
+#define OPTION_WITH_MARSHALLING(   \
+PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
+HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
+TABLE_INDEX)   \
+  if ((FLAGS)&options::CC1Option) {\
+[&](const auto &Extracted) {   \
+  if (ALWAYS_EMIT ||   \
+  (Extracted !=\
+   static_castKEYPATH)>(   \
+   (IMPLIED_CHECK) ? (IMPLIED_VALUE) : (DEFAULT_VALUE  \
+DENORMALIZER(Args, SPELLING, SA, Option::KIND##Class, TABLE_INDEX, \
+ Extracted);   \
+}(EXTRACTOR(this->KEYPATH));   \
+  }
+
+#include "clang/Driver/Options.inc"
+#undef OPTION_WITH_MARSHALLING
+}
+
 static void FixupInvocation(CompilerInvocation &Invocation,
 DiagnosticsEngine &Diags,
 const InputArgList &Args) {
@@ -2982,31 +3031,6 @@
   }
 }
 
-bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
- DiagnosticsEngine &Diags) {
-  bool Success = true;
-
-#define OPTION_WITH_MARSHALLING(   \
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
-TABLE_INDEX)   \
-  if ((FLAGS)&options::CC1Option) {\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
-if (IMPLIED_CHECK) \
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
-if (auto MaybeValue =  \
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   \
-  this->KEYPATH = MERGER(  \
-  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   \
-  }
-
-#include "clang/Driver/Options.inc"
-#undef OPTION_WITH_MARSHALLING
-
-  retur

[PATCH] D94027: [OpenCL] Add clang extension for variadic functions

[Marco Antognini via Phabricator via cfe-commits]

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

Thanks for the update.


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

https://reviews.llvm.org/D94027

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

[PATCH] D93702: [clang][cli] NFC: Make marshalling macros reusable

[Jan Svoboda via Phabricator via cfe-commits]

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

Pass local variables to macros explicitly, rebase on top of prep patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93702

Files:
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -382,39 +382,44 @@
   return KeyPath & Value;
 }
 
-bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
- DiagnosticsEngine &Diags) {
-  bool Success = true;
-
-#define OPTION_WITH_MARSHALLING(   
\
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
-TABLE_INDEX)   
\
+#define PARSE_OPTION_WITH_MARSHALLING( 
\
+ARGS, DIAGS, SUCCESS, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,
\
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX) 
\
   if ((FLAGS)&options::CC1Option) {
\
 this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  
\
 if (IMPLIED_CHECK) 
\
   this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);
\
 if (auto MaybeValue =  
\
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   
\
+NORMALIZER(OPT_##ID, TABLE_INDEX, ARGS, DIAGS, SUCCESS))   
\
   this->KEYPATH = MERGER(  
\
   this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   
\
   }
 
+bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
+ DiagnosticsEngine &Diags) {
+  bool Success = true;
+
+#define OPTION_WITH_MARSHALLING(   
\
+PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
+HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
+TABLE_INDEX)   
\
+  PARSE_OPTION_WITH_MARSHALLING(   
\
+  Args, Diags, Success, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,  
\
+  IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX)
 #include "clang/Driver/Options.inc"
 #undef OPTION_WITH_MARSHALLING
 
   return Success;
 }
 
-void CompilerInvocation::generateCC1CommandLine(
-SmallVectorImpl &Args, StringAllocator SA) const {
-  // Capture the extracted value as a lambda argument to avoid potential issues
-  // with lifetime extension of the reference.
-#define OPTION_WITH_MARSHALLING(   
\
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
+#undef PARSE_OPTION_WITH_MARSHALLING
+
+// Capture the extracted value as a lambda argument to avoid potential issues
+// with lifetime extension of the reference.
+#define GENERATE_OPTION_WITH_MARSHALLING(  
\
+ARGS, STRING_ALLOCATOR, KIND, FLAGS, SPELLING, ALWAYS_EMIT, KEYPATH,   
\
+DEFAULT_VALUE, IMPLIED_CHECK, IMPLIED_VALUE, DENORMALIZER, EXTRACTOR,  
\
 TABLE_INDEX)   
\
   if ((FLAGS)&options::CC1Option) {
\
 [&](const auto &Extracted) {   
\
@@ -422,15 +427,27 @@
   (Extracted !=
\
static_castKEYPATH)>(   
\
(IMPLIED_CHECK) ? (IMPLIED_VALUE) : (DEFAULT_VALUE  
\
-DENORMALIZER(Args, SPELLING, SA, Option::KIND##Class, TABLE_INDEX, 
\
- Extracted);   
\
+DENORMALIZER(ARGS, SPELLING, STRING_ALLOCATOR, Option::KIND##Class,
\
+ TABLE_INDEX, Extracted);  
\
 }(EXTRACTOR(this->KEYPATH));   
\
   }
 
+void CompilerIn

[PATCH] D94172: [clang][cli] NFC: Move marshalling macros closer together

[Jan Svoboda via Phabricator via cfe-commits]

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

Only more parseSimpleArgs closer to ParseDiagnosticArgs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94172

Files:
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1397,6 +1397,31 @@
   return Success;
 }
 
+bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
+ DiagnosticsEngine &Diags) {
+  bool Success = true;
+
+#define OPTION_WITH_MARSHALLING(   
\
+PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
+HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
+TABLE_INDEX)   
\
+  if ((FLAGS)&options::CC1Option) {
\
+this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  
\
+if (IMPLIED_CHECK) 
\
+  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);
\
+if (auto MaybeValue =  
\
+NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   
\
+  this->KEYPATH = MERGER(  
\
+  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   
\
+  }
+
+#include "clang/Driver/Options.inc"
+#undef OPTION_WITH_MARSHALLING
+
+  return Success;
+}
+
 bool clang::ParseDiagnosticArgs(DiagnosticOptions &Opts, ArgList &Args,
 DiagnosticsEngine &Diags,
 bool DefaultDiagColor) {
@@ -2982,31 +3007,6 @@
   }
 }
 
-bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
- DiagnosticsEngine &Diags) {
-  bool Success = true;
-
-#define OPTION_WITH_MARSHALLING(   
\
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
-TABLE_INDEX)   
\
-  if ((FLAGS)&options::CC1Option) {
\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  
\
-if (IMPLIED_CHECK) 
\
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);
\
-if (auto MaybeValue =  
\
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   
\
-  this->KEYPATH = MERGER(  
\
-  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   
\
-  }
-
-#include "clang/Driver/Options.inc"
-#undef OPTION_WITH_MARSHALLING
-
-  return Success;
-}
-
 bool CompilerInvocation::CreateFromArgs(CompilerInvocation &Res,
 ArrayRef CommandLineArgs,
 DiagnosticsEngine &Diags,


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1397,6 +1397,31 @@
   return Success;
 }
 
+bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
+ DiagnosticsEngine &Diags) {
+  bool Success = true;
+
+#define OPTION_WITH_MARSHALLING(   \
+PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
+HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
+TABLE_INDEX)   \
+  if ((FLAGS)&options::CC1Option) {\
+this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
+if (IMPLIED_CHECK) \
+  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
+if (auto MaybeValue =  \
+NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   \
+  this->KEYPATH =

[PATCH] D94092: [Clang] Remove unnecessary Attr.isArgIdent checks.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D94092#2481857 , @aaron.ballman 
wrote:

> In D94092#2481276 , @rjmccall wrote:
>
>> Without bothering to look it up, I would guess that the attribute-parsing 
>> code used to generically handle the ambiguity between identifier expressions 
>> and identifier attribute arguments by just always parsing simple identifiers 
>> as identifier arguments, making it Sema's responsibility to turn that back 
>> into an expression.  At some point, the parser was made sensitive to the 
>> actual attribute being parsed, but we never bothered to simplify Sema.  At 
>> any rate, the parser does now know exactly which argument of which attribute 
>> it's parsing, so there's zero reason for it to force this complexity on Sema 
>> anymore; if we find a case that parses identifier arguments, we should fix 
>> it in the parser to parse an expression instead.
>
> I don't think it will be quite that trivial (switching all identifiers to be 
> parsed as expressions instead). For instance, attributes that take 
> enumeration arguments can parse those arguments as identifiers, but those 
> identifiers will never be found by usual expression lookup because they don't 
> really exist. That said, any attribute that currently accepts an identifier 
> because it really wants to use that identifier in an expression in Sema 
> should update the attribute argument clauses in Attr.td and make the 
> corresponding changes in SemaDeclAttr.cpp/SemaStmt.cpp/SemaType.cpp as 
> appropriate.

Right, there is an Identifier type (and collection type) in Attr.td that at 
least a handful of attributes are using intentionally.  It is typically a case 
where GCC accepted an identifier, and it isn't always something that is 
look-up-able via normal C++ mechanisms (such as in the case of `cpu_dispatch`, 
where the identifiers are CPU names).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94092

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

[clang] 29d375f - [OpenCL][NFC] Improve OpenCL test file naming

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2021-01-06T14:16:44Z
New Revision: 29d375f5ff27dc49c2c88c2ec1093cfcd826d449

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

LOG: [OpenCL][NFC] Improve OpenCL test file naming

Change "negative" into "invalid" and put "invalid" at the beginning of
the file name, following the bulk of the invalid tests in the
SemaOpenCL directory.

Use the "invalid-" prefix only for tests that contain only invalid
constructs.

Drop the "valid" suffix for CodeGen tests, as inputs in this directory
are supposed to be valid anyway.

Added: 
clang/test/CodeGenOpenCL/vector_literals.cl
clang/test/CodeGenOpenCL/vector_shufflevector.cl
clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
clang/test/SemaOpenCL/invalid-vector-literals.cl
clang/test/SemaOpenCL/vector-conv.cl
clang/test/SemaOpenCLCXX/invalid-kernel.cl

Modified: 


Removed: 
clang/test/CodeGenOpenCL/vector_literals_valid.cl
clang/test/CodeGenOpenCL/vector_shufflevector_valid.cl
clang/test/SemaOpenCL/pipes-1.2-negative.cl
clang/test/SemaOpenCL/vector_conv_invalid.cl
clang/test/SemaOpenCL/vector_literals_invalid.cl
clang/test/SemaOpenCLCXX/kernel_invalid.cl



diff  --git a/clang/test/CodeGenOpenCL/vector_literals_valid.cl 
b/clang/test/CodeGenOpenCL/vector_literals.cl
similarity index 100%
rename from clang/test/CodeGenOpenCL/vector_literals_valid.cl
rename to clang/test/CodeGenOpenCL/vector_literals.cl

diff  --git a/clang/test/CodeGenOpenCL/vector_shufflevector_valid.cl 
b/clang/test/CodeGenOpenCL/vector_shufflevector.cl
similarity index 100%
rename from clang/test/CodeGenOpenCL/vector_shufflevector_valid.cl
rename to clang/test/CodeGenOpenCL/vector_shufflevector.cl

diff  --git a/clang/test/SemaOpenCL/pipes-1.2-negative.cl 
b/clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
similarity index 100%
rename from clang/test/SemaOpenCL/pipes-1.2-negative.cl
rename to clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl

diff  --git a/clang/test/SemaOpenCL/vector_literals_invalid.cl 
b/clang/test/SemaOpenCL/invalid-vector-literals.cl
similarity index 100%
rename from clang/test/SemaOpenCL/vector_literals_invalid.cl
rename to clang/test/SemaOpenCL/invalid-vector-literals.cl

diff  --git a/clang/test/SemaOpenCL/vector_conv_invalid.cl 
b/clang/test/SemaOpenCL/vector-conv.cl
similarity index 100%
rename from clang/test/SemaOpenCL/vector_conv_invalid.cl
rename to clang/test/SemaOpenCL/vector-conv.cl

diff  --git a/clang/test/SemaOpenCLCXX/kernel_invalid.cl 
b/clang/test/SemaOpenCLCXX/invalid-kernel.cl
similarity index 100%
rename from clang/test/SemaOpenCLCXX/kernel_invalid.cl
rename to clang/test/SemaOpenCLCXX/invalid-kernel.cl



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

[PATCH] D93702: [clang][cli] NFC: Make marshalling macros reusable

[Jan Svoboda via Phabricator via cfe-commits]

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

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93702

Files:
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1397,31 +1397,39 @@
   return Success;
 }
 
-bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
- DiagnosticsEngine &Diags) {
-  bool Success = true;
-
-#define OPTION_WITH_MARSHALLING(   
\
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
-TABLE_INDEX)   
\
+#define PARSE_OPTION_WITH_MARSHALLING( 
\
+ARGS, DIAGS, SUCCESS, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,
\
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX) 
\
   if ((FLAGS)&options::CC1Option) {
\
 this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  
\
 if (IMPLIED_CHECK) 
\
   this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);
\
 if (auto MaybeValue =  
\
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   
\
+NORMALIZER(OPT_##ID, TABLE_INDEX, ARGS, DIAGS, SUCCESS))   
\
   this->KEYPATH = MERGER(  
\
   this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   
\
   }
 
+bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
+ DiagnosticsEngine &Diags) {
+  bool Success = true;
+
+#define OPTION_WITH_MARSHALLING(   
\
+PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
+HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
+TABLE_INDEX)   
\
+  PARSE_OPTION_WITH_MARSHALLING(   
\
+  Args, Diags, Success, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,  
\
+  IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX)
 #include "clang/Driver/Options.inc"
 #undef OPTION_WITH_MARSHALLING
 
   return Success;
 }
 
+#undef PARSE_OPTION_WITH_MARSHALLING
+
 bool clang::ParseDiagnosticArgs(DiagnosticOptions &Opts, ArgList &Args,
 DiagnosticsEngine &Diags,
 bool DefaultDiagColor) {


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1397,31 +1397,39 @@
   return Success;
 }
 
-bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
- DiagnosticsEngine &Diags) {
-  bool Success = true;
-
-#define OPTION_WITH_MARSHALLING(   \
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
-TABLE_INDEX)   \
+#define PARSE_OPTION_WITH_MARSHALLING( \
+ARGS, DIAGS, SUCCESS, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,\
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX) \
   if ((FLAGS)&options::CC1Option) {\
 this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
 if (IMPLIED_CHECK) \
   this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
 if (auto MaybeValue =  \
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   \
+NORMALIZER(OPT_##ID, TABLE_INDEX, ARGS, DIAGS, SUCCESS))   \
   this->KEYPATH = MERGER(  \
   this->KEYPATH, static_c

[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

[Shao-Ce Sun via Phabricator via cfe-commits]

achieveartificialintelligence updated this revision to Diff 314879.
achieveartificialintelligence marked 5 inline comments as done.
achieveartificialintelligence added a comment.

Thanks for suggestions. We updated the code again.


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

https://reviews.llvm.org/D93298

Files:
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfo.td
  llvm/lib/Target/RISCV/RISCVInstrInfoZfdinx.td
  llvm/lib/Target/RISCV/RISCVInstrInfoZfhinx.td
  llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td
  llvm/lib/Target/RISCV/RISCVRegisterInfo.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/MC/RISCV/rv32i-invalid.s
  llvm/test/MC/RISCV/rv32zfdinx-invalid.s
  llvm/test/MC/RISCV/rv32zfdinx-valid.s
  llvm/test/MC/RISCV/rv32zfhinx-invalid.s
  llvm/test/MC/RISCV/rv32zfhinx-valid.s
  llvm/test/MC/RISCV/rv32zfinx-invalid.s
  llvm/test/MC/RISCV/rv32zfinx-valid.s
  llvm/test/MC/RISCV/rv64zfdinx-invalid.s
  llvm/test/MC/RISCV/rv64zfdinx-valid.s
  llvm/test/MC/RISCV/rv64zfhinx-invalid.s
  llvm/test/MC/RISCV/rv64zfhinx-valid.s
  llvm/test/MC/RISCV/rv64zfinx-invalid.s
  llvm/test/MC/RISCV/rv64zfinx-valid.s
  llvm/test/MC/RISCV/rvzfdinx-aliases-valid.s
  llvm/test/MC/RISCV/rvzfhinx-aliases-valid.s
  llvm/test/MC/RISCV/rvzfinx-aliases-valid.s

Index: llvm/test/MC/RISCV/rvzfinx-aliases-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rvzfinx-aliases-valid.s
@@ -0,0 +1,82 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zfinx -riscv-no-aliases \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zfinx \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zfinx -riscv-no-aliases \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zfinx \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx -M no-aliases - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx - \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx -M no-aliases - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx - \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+
+##===--===##
+## Assembler Pseudo Instructions (User-Level ISA, Version 2.2, Chapter 20)
+##===--===##
+
+# CHECK-INST: fsgnjx.s s1, s2, s2
+# CHECK-ALIAS: fabs.s s1, s2
+fabs.s s1, s2
+# CHECK-INST: fsgnjn.s s2, s3, s3
+# CHECK-ALIAS: fneg.s s2, s3
+fneg.s s2, s3
+
+# CHECK-INST: flt.s tp, s6, s5
+# CHECK-ALIAS: flt.s tp, s6, s5
+fgt.s x4, s5, s6
+# CHECK-INST: fle.s t2, s1, s0
+# CHECK-ALIAS: fle.s t2, s1, s0
+fge.s x7, x8, x9
+
+##===--===##
+## Aliases which omit the rounding mode.
+##===--===##
+
+# CHECK-INST: fmadd.s a0, a1, a2, a3, dyn
+# CHECK-ALIAS: fmadd.s a0, a1, a2, a3{{[[:space:]]}}
+fmadd.s x10, x11, x12, x13
+# CHECK-INST: fmsub.s a4, a5, a6, a7, dyn
+# CHECK-ALIAS: fmsub.s a4, a5, a6, a7{{[[:space:]]}}
+fmsub.s x14, x15, x16, x17
+# CHECK-INST: fnmsub.s s2, s3, s4, s5, dyn
+# CHECK-ALIAS: fnmsub.s s2, s3, s4, s5{{[[:space:]]}}
+fnmsub.s x18, x19, x20, x21
+# CHECK-INST: fnmadd.s s6, s7, s8, s9, dyn
+# CHECK-ALIAS: fnmadd.s s6, s7, s8, s9{{[[:space:]]}}
+fnmadd.s x22, x23, x24, x25
+# CHECK-INST: fadd.s s10, s11, t3, dyn
+# CHECK-ALIAS: fadd.s s10, s11, t3{{[[:space:]]}}
+fadd.s x26, x27, x28
+# CHECK-INST: fsub.s t4, t5, t6, dyn
+# CHECK-ALIAS: fsub.s t4, t5, t6{{[[:space:]]}}
+fsub.s x29, x30, x31
+# CHECK-INST: fmul.s s0, s1, s2, dyn
+# CHECK-ALIAS: fmul.s s0, s1, s2{{[[:space:]]}}
+fmul.s s0, s1, s2
+# CHECK-INST: fdiv.s s3, s4, s5, dyn
+# CHECK-ALIAS: fdiv.s s3, s4, s5{{[[:space:]]}}
+fdiv.s s3, s4, s5
+# CHECK-INST: sqrt.s s6, s7, dyn
+# CHECK-ALIAS: sqrt.s s6, s7{{[[:space:]]}}
+fsqrt.s s6, s7
+# CHECK-INST: fcvt.w.s a0, s5, dyn
+# CHECK-ALIAS: fcvt.w.s a0, s5{{[[:space:]]}}
+fcvt.w.s a0, s5
+# CHECK-INST: fcvt.wu.s a1, s6, dyn
+# CHECK-ALIAS: fcvt.wu.s a1, s6{{[[:space:]]}}
+fcvt.wu.s a1, s6
+# CHECK-INST: fcvt.s.w t6, a4, dyn
+# CHECK-ALIAS: fcvt.

[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11087
+// TCB warnings
+def err_tcb_conflicting_attributes : Error<
+  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;

NoQ wrote:
> aaron.ballman wrote:
> > NoQ wrote:
> > > Do i understand correctly that while "unknown attribute" is a warning 
> > > ("must be an attribute for some other compiler, let's ignore"), misuse of 
> > > a known attribute is typically an error ("ok, whatever you meant here, i 
> > > have an opinion about what this really means and i don't like it")?
> > It depends strongly on the attribute and the problem at hand. My usual rule 
> > of thumb is: if the attribute is being ignored because the code makes no 
> > sense, it's an error, but if the attribute can still be useful (perhaps 
> > after some adjustment), then warn. e.g., putting a calling convention 
> > attribute on a variable of type `int` makes no sense -- that should 
> > probably err rather than warn and ignore because the user did something 
> > baffling.
> > 
> > I could go either way on this one. Giving an error and forcing the user to 
> > say what they mean is appealing, but it would also be defensible to warn 
> > about the conflicting attribute and ignore just that one (retaining the 
> > original attribute). I would say leave it as an error and we can downgrade 
> > to a warning later if there's feedback from compelling real world use cases.
> > retaining the original attribute
> 
> There's an interesting aspect of error recovery here (which i didn't address 
> yet but added FIXMEs). We probably shouldn't emit additional warnings based 
> on the attributes about which we've already reported a conflict error; that's 
> just unnecessary clutter. That'd mean that we should always discard the 
> non-leaf attribute and keep the leaf attribute (if we can at all discard 
> attributes). Or keep both and repeat the conflict check during checking in 
> order to suppress the warning.
> That'd mean that we should always discard the non-leaf attribute and keep the 
> leaf attribute (if we can at all discard attributes). Or keep both and repeat 
> the conflict check during checking in order to suppress the warning.

You can do `TheDecl->dropAttr();` to drop the non-leaf attributes 
(or, if easy, it's better to not add the problematic attribute in the first 
place). Would you like to do that work in this patch or as a follow-up? (I'm 
fine either way.)



Comment at: clang/lib/Sema/SemaChecking.cpp:16088
+  // is in a TCB that the Callee is not.
+  for (const auto *Attr : Caller->specific_attrs()) {
+StringRef CallerTCB = Attr->getTCBName();

Can you rename this to be something other than a type name?


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

https://reviews.llvm.org/D91898

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

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

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

Rebase on top of prep patches


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

Files:
  clang/include/clang/Basic/DiagnosticOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -99,6 +99,13 @@
 
   MarshallingInfo(const Record &R) : R(R) {}
 
+  std::string getMacroName() const {
+if (KeyPath.startswith("DiagnosticOpts."))
+  return (Twine("DIAG_") + MarshallingInfo::MacroName).str();
+
+return MarshallingInfo::MacroName;
+  }
+
   void emit(raw_ostream &OS) const {
 write_cstring(OS, StringRef(getOptionSpelling(R)));
 OS << ", ";
@@ -420,13 +427,13 @@
 MarshallingInfos.push_back(createMarshallingInfo(*R));
 
   for (const auto &MI : MarshallingInfos) {
-OS << "#ifdef " << MarshallingInfo::MacroName << "\n";
-OS << MarshallingInfo::MacroName << "(";
+OS << "#ifdef " << MI.getMacroName() << "\n";
+OS << MI.getMacroName() << "(";
 WriteOptRecordFields(OS, MI.R);
 OS << ", ";
 MI.emit(OS);
 OS << ")\n";
-OS << "#endif // " << MarshallingInfo::MacroName << "\n";
+OS << "#endif // " << MI.getMacroName() << "\n";
   }
 
   OS << "\n";
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -386,7 +386,6 @@
 DiagnosticsEngine &Diags,
 const InputArgList &Args) {
   LangOptions &LangOpts = *Invocation.getLangOpts();
-  DiagnosticOptions &DiagOpts = Invocation.getDiagnosticOpts();
   CodeGenOptions &CodeGenOpts = Invocation.getCodeGenOpts();
   TargetOptions &TargetOpts = Invocation.getTargetOpts();
   FrontendOptions &FrontendOpts = Invocation.getFrontendOpts();
@@ -400,8 +399,6 @@
   LangOpts.SpeculativeLoadHardening = CodeGenOpts.SpeculativeLoadHardening;
   LangOpts.CurrentModule = LangOpts.ModuleName;
 
-  llvm::sys::Process::UseANSIEscapeCodes(DiagOpts.UseANSIEscapeCodes);
-
   llvm::Triple T(TargetOpts.Triple);
   llvm::Triple::ArchType Arch = T.getArch();
 
@@ -1401,13 +1398,12 @@
 ARGS, DIAGS, SUCCESS, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,\
 IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX) \
   if ((FLAGS)&options::CC1Option) {\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
+KEYPATH = MERGER(KEYPATH, DEFAULT_VALUE);  \
 if (IMPLIED_CHECK) \
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
+  KEYPATH = MERGER(KEYPATH, IMPLIED_VALUE);\
 if (auto MaybeValue =  \
 NORMALIZER(OPT_##ID, TABLE_INDEX, ARGS, DIAGS, SUCCESS))   \
-  this->KEYPATH = MERGER(  \
-  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   \
+  KEYPATH = MERGER(KEYPATH, static_cast(*MaybeValue));  \
   }
 
 bool CompilerInvocation::parseSimpleArgs(const ArgList &Args,
@@ -1428,86 +1424,34 @@
   return Success;
 }
 
-#undef PARSE_OPTION_WITH_MARSHALLING
-
 bool clang::ParseDiagnosticArgs(DiagnosticOptions &Opts, ArgList &Args,
 DiagnosticsEngine &Diags,
 bool DefaultDiagColor) {
   bool Success = true;
 
-  Opts.DiagnosticLogFile =
-  std::string(Args.getLastArgValue(OPT_diagnostic_log_file));
+  DiagnosticOptions &DiagnosticOpts = Opts;
+
+#define DIAG_OPTION_WITH_MARSHALLING(  \
+PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
+HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
+IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
+TABLE_INDEX)   \
+  PARSE_OPTION_WITH_MARSHALLING(   \
+  Args, Diags, Success, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,  \
+  IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX)
+#include "clang/Driver/Options.inc"
+#undef DIAG_OPTION_WITH_MARSHALLING
+
+  llvm::sys::Process::UseANSIEscapeCodes(Opts.UseANSIEscapeCodes);
+
   if (Arg *A =
   Args.getLastArg(OPT_diagnostic_serialized_file, OPT__serialize_diags))
 Opts.

[clang] 0c41b1c - [Driver][MachineOutliner] Support outlining option with LTO

[Yvan Roux via cfe-commits]

Author: Yvan Roux
Date: 2021-01-06T16:01:38+01:00
New Revision: 0c41b1c9f93c09966b87126820d3cf41d8eebbf9

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

LOG: [Driver][MachineOutliner] Support outlining option with LTO

This patch propagates the -moutline flag when LTO is enabled and avoids
passing it explicitly to the linker plugin.

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

Added: 
clang/test/Driver/arm-machine-outliner.c

Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/CommonArgs.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index f8b9bf25373e..917601836c0a 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -6396,26 +6396,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 options::OPT_fno_cxx_static_destructors, true))
 CmdArgs.push_back("-fno-c++-static-destructors");
 
-  if (Arg *A = Args.getLastArg(options::OPT_moutline,
-   options::OPT_mno_outline)) {
-if (A->getOption().matches(options::OPT_moutline)) {
-  // We only support -moutline in AArch64 and ARM targets right now. If
-  // we're not compiling for these, emit a warning and ignore the flag.
-  // Otherwise, add the proper mllvm flags.
-  if (!(Triple.isARM() || Triple.isThumb() ||
-Triple.getArch() == llvm::Triple::aarch64 ||
-Triple.getArch() == llvm::Triple::aarch64_32)) {
-D.Diag(diag::warn_drv_moutline_unsupported_opt) << 
Triple.getArchName();
-  } else {
-CmdArgs.push_back("-mllvm");
-CmdArgs.push_back("-enable-machine-outliner");
-  }
-} else {
-  // Disable all outlining behaviour.
-  CmdArgs.push_back("-mllvm");
-  CmdArgs.push_back("-enable-machine-outliner=never");
-}
-  }
+  addMachineOutlinerArgs(D, Args, CmdArgs, Triple, /*IsLTO=*/false);
 
   if (Arg *A = Args.getLastArg(options::OPT_moutline_atomics,
options::OPT_mno_outline_atomics)) {

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index fe5e7536d380..6a95aa5ec628 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -624,6 +624,9 @@ void tools::addLTOOptions(const ToolChain &ToolChain, const 
ArgList &Args,
 
   // Handle remarks hotness/threshold related options.
   renderRemarksHotnessOptions(Args, CmdArgs);
+
+  addMachineOutlinerArgs(D, Args, CmdArgs, ToolChain.getEffectiveTriple(),
+ /*IsLTO=*/true);
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,
@@ -1586,3 +1589,36 @@ unsigned tools::getOrCheckAMDGPUCodeObjectVersion(
   }
   return CodeObjVer;
 }
+
+void tools::addMachineOutlinerArgs(const Driver &D,
+   const llvm::opt::ArgList &Args,
+   llvm::opt::ArgStringList &CmdArgs,
+   const llvm::Triple &Triple, bool IsLTO) {
+  auto addArg = [&, IsLTO](const Twine &Arg) {
+if (IsLTO) {
+  CmdArgs.push_back(Args.MakeArgString("-plugin-opt=" + Arg));
+} else {
+  CmdArgs.push_back("-mllvm");
+  CmdArgs.push_back(Args.MakeArgString(Arg));
+}
+  };
+
+  if (Arg *A = Args.getLastArg(options::OPT_moutline,
+   options::OPT_mno_outline)) {
+if (A->getOption().matches(options::OPT_moutline)) {
+  // We only support -moutline in AArch64 and ARM targets right now. If
+  // we're not compiling for these, emit a warning and ignore the flag.
+  // Otherwise, add the proper mllvm flags.
+  if (!(Triple.isARM() || Triple.isThumb() ||
+Triple.getArch() == llvm::Triple::aarch64 ||
+Triple.getArch() == llvm::Triple::aarch64_32)) {
+D.Diag(diag::warn_drv_moutline_unsupported_opt) << 
Triple.getArchName();
+  } else {
+addArg(Twine("-enable-machine-outliner"));
+  }
+} else {
+  // Disable all outlining behaviour.
+  addArg(Twine("-enable-machine-outliner=never"));
+}
+  }
+}

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.h 
b/clang/lib/Driver/ToolChains/CommonArgs.h
index 9a365f376022..187c340d1c3c 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.h
+++ b/clang/lib/Driver/ToolChains/CommonArgs.h
@@ -141,6 +141,10 @@ void addX86AlignBranchArgs(const Driver &D, const 
llvm::opt::ArgList &Args,
 unsigned getOrCheckAMDGPUCodeObjectVersion(const Driver &D,
const llvm::opt::ArgList &Args,
  

[PATCH] D93385: [Driver][MachineOutliner] Support outlining option with LTO

[Yvan Roux 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 rG0c41b1c9f93c: [Driver][MachineOutliner] Support outlining 
option with LTO (authored by yroux).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93385

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/test/Driver/arm-machine-outliner.c

Index: clang/test/Driver/arm-machine-outliner.c
===
--- /dev/null
+++ clang/test/Driver/arm-machine-outliner.c
@@ -0,0 +1,9 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang -target armv7-linux-gnueabihf -moutline -c %s -### 2>&1 | FileCheck %s -check-prefix=ON
+// ON: "-mllvm" "-enable-machine-outliner"
+// RUN: %clang -target armv7-linux-gnueabihf -flto -moutline %s -### 2>&1 | FileCheck %s -check-prefix=ON-LTO
+// ON-LTO: "-plugin-opt=-enable-machine-outliner"
+// RUN: %clang -target armv7-linux-gnueabihf -moutline -mno-outline -c %s -### 2>&1 | FileCheck %s -check-prefix=OFF
+// OFF: "-mllvm" "-enable-machine-outliner=never"
+// RUN: %clang -target armv7-linux-gnueabihf -flto -moutline -mno-outline %s -### 2>&1 | FileCheck %s -check-prefix=OFF-LTO
+// OFF-LTO: "-plugin-opt=-enable-machine-outliner=never"
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -141,6 +141,10 @@
 unsigned getOrCheckAMDGPUCodeObjectVersion(const Driver &D,
const llvm::opt::ArgList &Args,
bool Diagnose = false);
+
+void addMachineOutlinerArgs(const Driver &D, const llvm::opt::ArgList &Args,
+llvm::opt::ArgStringList &CmdArgs,
+const llvm::Triple &Triple, bool IsLTO);
 } // end namespace tools
 } // end namespace driver
 } // end namespace clang
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -624,6 +624,9 @@
 
   // Handle remarks hotness/threshold related options.
   renderRemarksHotnessOptions(Args, CmdArgs);
+
+  addMachineOutlinerArgs(D, Args, CmdArgs, ToolChain.getEffectiveTriple(),
+ /*IsLTO=*/true);
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,
@@ -1586,3 +1589,36 @@
   }
   return CodeObjVer;
 }
+
+void tools::addMachineOutlinerArgs(const Driver &D,
+   const llvm::opt::ArgList &Args,
+   llvm::opt::ArgStringList &CmdArgs,
+   const llvm::Triple &Triple, bool IsLTO) {
+  auto addArg = [&, IsLTO](const Twine &Arg) {
+if (IsLTO) {
+  CmdArgs.push_back(Args.MakeArgString("-plugin-opt=" + Arg));
+} else {
+  CmdArgs.push_back("-mllvm");
+  CmdArgs.push_back(Args.MakeArgString(Arg));
+}
+  };
+
+  if (Arg *A = Args.getLastArg(options::OPT_moutline,
+   options::OPT_mno_outline)) {
+if (A->getOption().matches(options::OPT_moutline)) {
+  // We only support -moutline in AArch64 and ARM targets right now. If
+  // we're not compiling for these, emit a warning and ignore the flag.
+  // Otherwise, add the proper mllvm flags.
+  if (!(Triple.isARM() || Triple.isThumb() ||
+Triple.getArch() == llvm::Triple::aarch64 ||
+Triple.getArch() == llvm::Triple::aarch64_32)) {
+D.Diag(diag::warn_drv_moutline_unsupported_opt) << Triple.getArchName();
+  } else {
+addArg(Twine("-enable-machine-outliner"));
+  }
+} else {
+  // Disable all outlining behaviour.
+  addArg(Twine("-enable-machine-outliner=never"));
+}
+  }
+}
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6396,26 +6396,7 @@
 options::OPT_fno_cxx_static_destructors, true))
 CmdArgs.push_back("-fno-c++-static-destructors");
 
-  if (Arg *A = Args.getLastArg(options::OPT_moutline,
-   options::OPT_mno_outline)) {
-if (A->getOption().matches(options::OPT_moutline)) {
-  // We only support -moutline in AArch64 and ARM targets right now. If
-  // we're not compiling for these, emit a warning and ignore the flag.
-  // Otherwise, add the proper mllvm flags.
-  if (!(Triple.isARM() || Triple.isThumb() ||
-Triple.getArch() == llvm::Triple::aarch64 ||
-Triple.getArch() == llvm::Tr

[PATCH] D94177: [analyze] Add better support for leaks (and similar diagnostics)

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko created this revision.
vsavchenko added reviewers: NoQ, xazax.hun, jkorous, aaron.ballman, martong, 
Szelethus, steakhal.
Herald added subscribers: Charusso, rnkovacs.
vsavchenko requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In addition to the actual bug location, we can check if the uniqueing
location has user-provided suppressions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94177

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugSuppression.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/BugSuppression.cpp
  clang/test/Analysis/suppression-attr.m

Index: clang/test/Analysis/suppression-attr.m
===
--- clang/test/Analysis/suppression-attr.m
+++ clang/test/Analysis/suppression-attr.m
@@ -4,6 +4,7 @@
 // RUN:   -analyzer-checker=osx.cocoa.NSError \
 // RUN:   -analyzer-checker=osx.ObjCProperty \
 // RUN:   -analyzer-checker=osx.cocoa.RetainCount \
+// RUN:   -analyzer-checker=unix.Malloc \
 // RUN:   -analyzer-checker=alpha.core.CastToStruct \
 // RUN:   -Wno-unused-value -Wno-objc-root-class -verify %s
 
@@ -37,6 +38,10 @@
 @interface NSMutableString : NSObject
 @end
 
+typedef unsigned long size_t;
+void *malloc(size_t);
+void free(void *);
+
 void dereference_1() {
   int *x = 0;
   *x; // expected-warning{{Dereference of null pointer (loaded from variable 'x')}}
@@ -83,6 +88,50 @@
   SUPPRESS int y = *x; // no-warning
 }
 
+int malloc_leak_1() {
+  int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+  return *x; // expected-warning{{Potential leak of memory pointed to by 'x'}}
+}
+
+int malloc_leak_suppression_1_1() {
+  SUPPRESS int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+  return *x;
+}
+
+int malloc_leak_suppression_1_2() {
+  int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+  SUPPRESS return *x;
+}
+
+void malloc_leak_2() {
+  int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+} // expected-warning{{Potential leak of memory pointed to by 'x'}}
+
+void malloc_leak_suppression_2_1() {
+  SUPPRESS int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+}
+
+void malloc_leak_suppression_2_2() SUPPRESS {
+  int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+}
+
+SUPPRESS void malloc_leak_suppression_2_3() {
+  int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+}
+
+void malloc_leak_suppression_2_4(int cond) {
+  int *x = (int *)malloc(sizeof(int));
+  *x = 42;
+  SUPPRESS;
+}
+
 void retain_release_leak_1() {
   [[NSMutableString alloc] init]; // expected-warning{{Potential leak of an object of type 'NSMutableString *'}}
 }
Index: clang/lib/StaticAnalyzer/Core/BugSuppression.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugSuppression.cpp
+++ clang/lib/StaticAnalyzer/Core/BugSuppression.cpp
@@ -132,8 +132,15 @@
 //   (i.e. removing the whole function from the analysis).
 bool BugSuppression::isSuppressed(const BugReport &R) {
   PathDiagnosticLocation Location = R.getLocation();
+  PathDiagnosticLocation UniqueingLocation = R.getUniqueingLocation();
   const Decl *DeclWithIssue = R.getDeclWithIssue();
 
+  return isSuppressed(Location, DeclWithIssue) ||
+ isSuppressed(UniqueingLocation, DeclWithIssue);
+}
+
+bool BugSuppression::isSuppressed(const PathDiagnosticLocation &Location,
+  const Decl *DeclWithIssue) {
   if (!Location.isValid() || DeclWithIssue == nullptr)
 return false;
 
Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -2386,11 +2386,10 @@
   return Ranges;
 }
 
-PathDiagnosticLocation
-PathSensitiveBugReport::getLocation() const {
+PathDiagnosticLocation PathSensitiveBugReport::getLocation() const {
   assert(ErrorNode && "Cannot create a location with a null node.");
   const Stmt *S = ErrorNode->getStmtForDiagnostics();
-ProgramPoint P = ErrorNode->getLocation();
+  ProgramPoint P = ErrorNode->getLocation();
   const LocationContext *LC = P.getLocationContext();
   SourceManager &SM =
   ErrorNode->getState()->getStateManager().getContext().getSourceManager();
@@ -2407,6 +2406,12 @@
   }
 
   if (S) {
+// Attributed statements usually have corrupted begin locations,
+// it's OK to ignore attributes for our purposes and deal with
+// the actual annotated statement.
+if (const auto *AS = dyn_cast(S))
+  S = AS->getSubStmt();
+
 // For member expressions, return the location of the '.' or '->'.
 if (const auto *ME = dyn_cast(S))
   return PathDiagnosticLocation::createMemberLoc(ME, SM);
Index: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugSuppression.h
===
--- clang/include/clang/StaticAnalyzer/Core/Bug

[clang] 3fa6ced - Fix MaterializeTemporaryExpr's type when its an incomplete array.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2021-01-06T07:17:12-08:00
New Revision: 3fa6cedb6be809092f8a8b27e63bd4f6dc526a08

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

LOG: Fix MaterializeTemporaryExpr's type when its an incomplete array.

Like the VarDecl that gets its type updated based on an init-list, this
patch corrects the MaterializeTemporaryExpr's type to make sure it isn't
creating an incomplete type, which leads to a handful of CodeGen crashes
(see PR 47636).

Based on @rsmith 's comments on D88236

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

Added: 
clang/test/AST/pr47636.cpp

Modified: 
clang/lib/Sema/SemaInit.cpp
clang/test/CodeGenCXX/pr47636.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index b5f31bf403d4..38f6a5975ea3 100644
--- a/clang/lib/Sema/SemaInit.cpp
+++ b/clang/lib/Sema/SemaInit.cpp
@@ -8200,9 +8200,21 @@ ExprResult InitializationSequence::Perform(Sema &S,
   if (S.CheckExceptionSpecCompatibility(CurInit.get(), DestType))
 return ExprError();
 
+  QualType MTETy = Step->Type;
+
+  // When this is an incomplete array type (such as when this is
+  // initializing an array of unknown bounds from an init list), use THAT
+  // type instead so that we propogate the array bounds.
+  if (MTETy->isIncompleteArrayType() &&
+  !CurInit.get()->getType()->isIncompleteArrayType() &&
+  S.Context.hasSameType(
+  MTETy->getPointeeOrArrayElementType(),
+  CurInit.get()->getType()->getPointeeOrArrayElementType()))
+MTETy = CurInit.get()->getType();
+
   // Materialize the temporary into memory.
   MaterializeTemporaryExpr *MTE = S.CreateMaterializeTemporaryExpr(
-  Step->Type, CurInit.get(), 
Entity.getType()->isLValueReferenceType());
+  MTETy, CurInit.get(), Entity.getType()->isLValueReferenceType());
   CurInit = MTE;
 
   // If we're extending this temporary to automatic storage duration -- we

diff  --git a/clang/test/AST/pr47636.cpp b/clang/test/AST/pr47636.cpp
new file mode 100644
index ..29d2a0a06e79
--- /dev/null
+++ b/clang/test/AST/pr47636.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsyntax-only %s -ast-dump | FileCheck %s
+
+int(&&intu_rvref)[] {1,2,3,4};
+// CHECK: VarDecl 0x[[GLOB_ADDR:[0-9a-f]+]] {{.*}} intu_rvref 'int (&&)[4]' 
listinit
+// CHECK-NEXT: ExprWithCleanups {{.*}} 'int [4]' xvalue
+// CHECK-NEXT: MaterializeTemporaryExpr {{.*}} 'int [4]' xvalue extended by 
Var 0x[[GLOB_ADDR]] 'intu_rvref' 'int (&&)[4]'
+// CHECK-NEXT: InitListExpr {{.*}} 'int [4]'
+
+// CHECK: FunctionDecl {{.*}} static_const
+void static_const() {
+  static const int(&&intu_rvref)[] {1,2,3,4};
+  // CHECK: VarDecl 0x[[STATIC_ADDR:[0-9a-f]+]] {{.*}} intu_rvref 'const int 
(&&)[4]' static listinit
+  // CHECK-NEXT: ExprWithCleanups {{.*}} 'const int [4]' xvalue
+  // CHECK-NEXT: MaterializeTemporaryExpr {{.*}} 'const int [4]' xvalue 
extended by Var 0x[[STATIC_ADDR]] 'intu_rvref' 'const int (&&)[4]'
+  // CHECK-NEXT: InitListExpr {{.*}} 'const int [4]'
+}
+
+// CHECK: FunctionDecl {{.*}} const_expr
+constexpr int const_expr() {
+  int(&&intu_rvref)[]{1, 2, 3, 4};
+  // CHECK: VarDecl 0x[[CE_ADDR:[0-9a-f]+]] {{.*}} intu_rvref 'int (&&)[4]' 
listinit
+  // CHECK-NEXT: ExprWithCleanups {{.*}} 'int [4]' xvalue
+  // CHECK-NEXT: MaterializeTemporaryExpr {{.*}} 'int [4]' xvalue extended by 
Var 0x[[CE_ADDR]] 'intu_rvref' 'int (&&)[4]'
+  // CHECK-NEXT: InitListExpr {{.*}} 'int [4]'
+  return intu_rvref[0];
+}

diff  --git a/clang/test/CodeGenCXX/pr47636.cpp 
b/clang/test/CodeGenCXX/pr47636.cpp
index 64fb44114bd2..b6b31d623761 100644
--- a/clang/test/CodeGenCXX/pr47636.cpp
+++ b/clang/test/CodeGenCXX/pr47636.cpp
@@ -8,3 +8,15 @@ void foo() {
   // CHECK: @_ZZ3foovE10intu_rvref = internal constant [4 x i32]* 
@_ZGRZ3foovE10intu_rvref_
   // CHECK: @_ZGRZ3foovE10intu_rvref_ = internal constant [4 x i32] [i32 1, 
i32 2, i32 3, i32 4]
 }
+
+// Example given on review, ensure this doesn't crash as well.
+constexpr int f() {
+  // CHECK: i32 @_Z1fv()
+  int(&&intu_rvref)[]{1, 2, 3, 4};
+  // CHECK: %{{.*}} = alloca [4 x i32]*
+  return intu_rvref[2];
+}
+
+void use_f() {
+  int i = f();
+}



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

[PATCH] D88298: Fix MaterializeTemporaryExpr's type when its an incomplete array.

[Erich Keane via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3fa6cedb6be8: Fix MaterializeTemporaryExpr's type when 
its an incomplete array. (authored by erichkeane).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88298

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/AST/pr47636.cpp
  clang/test/CodeGenCXX/pr47636.cpp


Index: clang/test/CodeGenCXX/pr47636.cpp
===
--- clang/test/CodeGenCXX/pr47636.cpp
+++ clang/test/CodeGenCXX/pr47636.cpp
@@ -8,3 +8,15 @@
   // CHECK: @_ZZ3foovE10intu_rvref = internal constant [4 x i32]* 
@_ZGRZ3foovE10intu_rvref_
   // CHECK: @_ZGRZ3foovE10intu_rvref_ = internal constant [4 x i32] [i32 1, 
i32 2, i32 3, i32 4]
 }
+
+// Example given on review, ensure this doesn't crash as well.
+constexpr int f() {
+  // CHECK: i32 @_Z1fv()
+  int(&&intu_rvref)[]{1, 2, 3, 4};
+  // CHECK: %{{.*}} = alloca [4 x i32]*
+  return intu_rvref[2];
+}
+
+void use_f() {
+  int i = f();
+}
Index: clang/test/AST/pr47636.cpp
===
--- /dev/null
+++ clang/test/AST/pr47636.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsyntax-only %s -ast-dump | FileCheck %s
+
+int(&&intu_rvref)[] {1,2,3,4};
+// CHECK: VarDecl 0x[[GLOB_ADDR:[0-9a-f]+]] {{.*}} intu_rvref 'int (&&)[4]' 
listinit
+// CHECK-NEXT: ExprWithCleanups {{.*}} 'int [4]' xvalue
+// CHECK-NEXT: MaterializeTemporaryExpr {{.*}} 'int [4]' xvalue extended by 
Var 0x[[GLOB_ADDR]] 'intu_rvref' 'int (&&)[4]'
+// CHECK-NEXT: InitListExpr {{.*}} 'int [4]'
+
+// CHECK: FunctionDecl {{.*}} static_const
+void static_const() {
+  static const int(&&intu_rvref)[] {1,2,3,4};
+  // CHECK: VarDecl 0x[[STATIC_ADDR:[0-9a-f]+]] {{.*}} intu_rvref 'const int 
(&&)[4]' static listinit
+  // CHECK-NEXT: ExprWithCleanups {{.*}} 'const int [4]' xvalue
+  // CHECK-NEXT: MaterializeTemporaryExpr {{.*}} 'const int [4]' xvalue 
extended by Var 0x[[STATIC_ADDR]] 'intu_rvref' 'const int (&&)[4]'
+  // CHECK-NEXT: InitListExpr {{.*}} 'const int [4]'
+}
+
+// CHECK: FunctionDecl {{.*}} const_expr
+constexpr int const_expr() {
+  int(&&intu_rvref)[]{1, 2, 3, 4};
+  // CHECK: VarDecl 0x[[CE_ADDR:[0-9a-f]+]] {{.*}} intu_rvref 'int (&&)[4]' 
listinit
+  // CHECK-NEXT: ExprWithCleanups {{.*}} 'int [4]' xvalue
+  // CHECK-NEXT: MaterializeTemporaryExpr {{.*}} 'int [4]' xvalue extended by 
Var 0x[[CE_ADDR]] 'intu_rvref' 'int (&&)[4]'
+  // CHECK-NEXT: InitListExpr {{.*}} 'int [4]'
+  return intu_rvref[0];
+}
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -8200,9 +8200,21 @@
   if (S.CheckExceptionSpecCompatibility(CurInit.get(), DestType))
 return ExprError();
 
+  QualType MTETy = Step->Type;
+
+  // When this is an incomplete array type (such as when this is
+  // initializing an array of unknown bounds from an init list), use THAT
+  // type instead so that we propogate the array bounds.
+  if (MTETy->isIncompleteArrayType() &&
+  !CurInit.get()->getType()->isIncompleteArrayType() &&
+  S.Context.hasSameType(
+  MTETy->getPointeeOrArrayElementType(),
+  CurInit.get()->getType()->getPointeeOrArrayElementType()))
+MTETy = CurInit.get()->getType();
+
   // Materialize the temporary into memory.
   MaterializeTemporaryExpr *MTE = S.CreateMaterializeTemporaryExpr(
-  Step->Type, CurInit.get(), 
Entity.getType()->isLValueReferenceType());
+  MTETy, CurInit.get(), Entity.getType()->isLValueReferenceType());
   CurInit = MTE;
 
   // If we're extending this temporary to automatic storage duration -- we


Index: clang/test/CodeGenCXX/pr47636.cpp
===
--- clang/test/CodeGenCXX/pr47636.cpp
+++ clang/test/CodeGenCXX/pr47636.cpp
@@ -8,3 +8,15 @@
   // CHECK: @_ZZ3foovE10intu_rvref = internal constant [4 x i32]* @_ZGRZ3foovE10intu_rvref_
   // CHECK: @_ZGRZ3foovE10intu_rvref_ = internal constant [4 x i32] [i32 1, i32 2, i32 3, i32 4]
 }
+
+// Example given on review, ensure this doesn't crash as well.
+constexpr int f() {
+  // CHECK: i32 @_Z1fv()
+  int(&&intu_rvref)[]{1, 2, 3, 4};
+  // CHECK: %{{.*}} = alloca [4 x i32]*
+  return intu_rvref[2];
+}
+
+void use_f() {
+  int i = f();
+}
Index: clang/test/AST/pr47636.cpp
===
--- /dev/null
+++ clang/test/AST/pr47636.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsyntax-only %s -ast-dump | FileCheck %s
+
+int(&&intu_rvref)[] {1,2,3,4};
+// CHECK: VarDecl 0x[[GLOB_ADDR:[0-9a-f]+]] {{.*}} intu_rvref 'int (&&)[4]' listinit
+// CHECK-NEXT: ExprWithCleanups {{.*}} 'int [4]' xvalue
+// CHECK-NEXT: MaterializeTemporaryExpr {{.*}} 'int [4]'

[PATCH] D93587: [hip] Fix HIP version parsing.

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

Pls address Artem's comments. LGTM otherwise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

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

[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 314898.
NoQ marked 2 inline comments as done.
NoQ added a comment.

Drop broken attributes. Fix naming.


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

https://reviews.llvm.org/D91898

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-enforce-tcb-errors.cpp
  clang/test/Sema/attr-enforce-tcb.c
  clang/test/Sema/attr-enforce-tcb.cpp

Index: clang/test/Sema/attr-enforce-tcb.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-enforce-tcb.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#define PLACE_IN_TCB(NAME) [[clang::enforce_tcb(NAME)]]
+#define PLACE_IN_TCB_LEAF(NAME) [[clang::enforce_tcb_leaf(NAME)]]
+
+PLACE_IN_TCB("foo") void in_tcb_foo();
+void not_in_tcb();
+
+// Test behavior on classes and methods.
+class C {
+  void bar();
+
+  PLACE_IN_TCB("foo")
+  void foo() {
+// TODO: Figure out if we want to support methods at all.
+// Does it even make sense to isolate individual methods into a TCB?
+// Maybe a per-class attribute would make more sense?
+bar(); // expected-warning{{calling 'bar' is a violation of trusted computing base 'foo'}}
+  }
+};
+
+// Test behavior on templates.
+template 
+PLACE_IN_TCB("foo")
+void foo_never_instantiated() {
+  not_in_tcb(); // expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+template 
+PLACE_IN_TCB("foo")
+void foo_specialized();
+
+template<>
+void foo_specialized() {
+  not_in_tcb(); // expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+PLACE_IN_TCB("foo")
+void call_template_good() {
+  foo_specialized(); // no-warning
+}
+PLACE_IN_TCB("bar")
+void call_template_bad() {
+  foo_specialized(); // expected-warning{{calling 'foo_specialized' is a violation of trusted computing base 'bar'}}
+}
+
+template
+void foo_specialization_in_tcb();
+
+template<>
+PLACE_IN_TCB("foo")
+void foo_specialization_in_tcb() {
+  not_in_tcb(); //expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+template<>
+void foo_specialization_in_tcb() {
+  not_in_tcb(); // no-warning
+  in_tcb_foo(); // no-warning
+}
+
+PLACE_IN_TCB("foo")
+void call_specialization_in_tcb() {
+  foo_specialization_in_tcb(); // no-warning
+  foo_specialization_in_tcb(); // expected-warning{{calling 'foo_specialization_in_tcb' is a violation of trusted computing base 'foo'}}
+  foo_specialization_in_tcb(); // expected-warning{{'foo_specialization_in_tcb' is a violation of trusted computing base 'foo'}}
+}
Index: clang/test/Sema/attr-enforce-tcb.c
===
--- /dev/null
+++ clang/test/Sema/attr-enforce-tcb.c
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#define PLACE_IN_TCB(NAME) __attribute__ ((enforce_tcb(NAME)))
+#define PLACE_IN_TCB_LEAF(NAME) __attribute__ ((enforce_tcb_leaf(NAME)))
+
+void foo1 (void) PLACE_IN_TCB("bar");
+void foo2 (void) PLACE_IN_TCB("bar");
+void foo3 (void); // not in any TCB
+void foo4 (void) PLACE_IN_TCB("bar2");
+void foo5 (void) PLACE_IN_TCB_LEAF("bar");
+void foo6 (void) PLACE_IN_TCB("bar2") PLACE_IN_TCB("bar");
+void foo7 (void) PLACE_IN_TCB("bar3");
+void foo8 (void) PLACE_IN_TCB("bar") PLACE_IN_TCB("bar2");
+void foo9 (void);
+
+void foo1() {
+foo2(); // OK - function in same TCB
+foo3(); // expected-warning {{calling 'foo3' is a violation of trusted computing base 'bar'}}
+foo4(); // expected-warning {{calling 'foo4' is a violation of trusted computing base 'bar'}}
+foo5(); // OK - in leaf node
+foo6(); // OK - in multiple TCBs, one of which is the same
+foo7(); // expected-warning {{calling 'foo7' is a violation of trusted computing base 'bar'}}
+(void) __builtin_clz(5); // OK - builtins are excluded
+}
+
+// Normal use without any attributes works
+void foo3() {
+foo9(); // no-warning
+}
+
+void foo5() {
+// all calls should be okay, function in TCB leaf
+foo2(); // no-warning
+foo3(); // no-warning
+foo4(); // no-warning
+}
+
+void foo6() {
+foo1(); // expected-warning {{calling 'foo1' is a violation of trusted computing base 'bar2'}}
+foo4(); // expected-warning {{calling 'foo4' is a violation of trusted computing base 'bar'}}
+foo8(); // no-warning
+foo7(); // #1
+// expected-warning@#1 {{calling 'foo7' is a violation of trusted computing base 'bar2'}}
+// expected-warning@#1 {{calling 'foo7' is a violation of trusted computing base 'bar'}}
+}
+
+// Ensure that attribute merging works as expected across redeclarations.
+void fo

[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11087
+// TCB warnings
+def err_tcb_conflicting_attributes : Error<
+  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;

aaron.ballman wrote:
> NoQ wrote:
> > aaron.ballman wrote:
> > > NoQ wrote:
> > > > Do i understand correctly that while "unknown attribute" is a warning 
> > > > ("must be an attribute for some other compiler, let's ignore"), misuse 
> > > > of a known attribute is typically an error ("ok, whatever you meant 
> > > > here, i have an opinion about what this really means and i don't like 
> > > > it")?
> > > It depends strongly on the attribute and the problem at hand. My usual 
> > > rule of thumb is: if the attribute is being ignored because the code 
> > > makes no sense, it's an error, but if the attribute can still be useful 
> > > (perhaps after some adjustment), then warn. e.g., putting a calling 
> > > convention attribute on a variable of type `int` makes no sense -- that 
> > > should probably err rather than warn and ignore because the user did 
> > > something baffling.
> > > 
> > > I could go either way on this one. Giving an error and forcing the user 
> > > to say what they mean is appealing, but it would also be defensible to 
> > > warn about the conflicting attribute and ignore just that one (retaining 
> > > the original attribute). I would say leave it as an error and we can 
> > > downgrade to a warning later if there's feedback from compelling real 
> > > world use cases.
> > > retaining the original attribute
> > 
> > There's an interesting aspect of error recovery here (which i didn't 
> > address yet but added FIXMEs). We probably shouldn't emit additional 
> > warnings based on the attributes about which we've already reported a 
> > conflict error; that's just unnecessary clutter. That'd mean that we should 
> > always discard the non-leaf attribute and keep the leaf attribute (if we 
> > can at all discard attributes). Or keep both and repeat the conflict check 
> > during checking in order to suppress the warning.
> > That'd mean that we should always discard the non-leaf attribute and keep 
> > the leaf attribute (if we can at all discard attributes). Or keep both and 
> > repeat the conflict check during checking in order to suppress the warning.
> 
> You can do `TheDecl->dropAttr();` to drop the non-leaf attributes 
> (or, if easy, it's better to not add the problematic attribute in the first 
> place). Would you like to do that work in this patch or as a follow-up? (I'm 
> fine either way.)
Hmm, that's indeed an easy and reasonable solution. Ideally i should only drop 
attributes with the same argument but that's too far into the area of 
diminishing returns for me :)


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

https://reviews.llvm.org/D91898

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

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

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

Introduce `IsDiag` mixin, add test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

Files:
  clang/include/clang/Basic/DiagnosticOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp
  llvm/include/llvm/Option/OptParser.td
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -66,6 +66,7 @@
   static constexpr const char *MacroName = "OPTION_WITH_MARSHALLING";
   const Record &R;
   bool ShouldAlwaysEmit;
+  StringRef MacroPrefix;
   StringRef KeyPath;
   StringRef DefaultValue;
   StringRef NormalizedValuesScope;
@@ -99,6 +100,10 @@
 
   MarshallingInfo(const Record &R) : R(R) {}
 
+  std::string getMacroName() const {
+return (MacroPrefix + MarshallingInfo::MacroName).str();
+  }
+
   void emit(raw_ostream &OS) const {
 write_cstring(OS, StringRef(getOptionSpelling(R)));
 OS << ", ";
@@ -160,6 +165,7 @@
   MarshallingInfo Ret(R);
 
   Ret.ShouldAlwaysEmit = R.getValueAsBit("ShouldAlwaysEmit");
+  Ret.MacroPrefix = R.getValueAsString("MacroPrefix");
   Ret.KeyPath = R.getValueAsString("KeyPath");
   Ret.DefaultValue = R.getValueAsString("DefaultValue");
   Ret.NormalizedValuesScope = R.getValueAsString("NormalizedValuesScope");
@@ -420,13 +426,13 @@
 MarshallingInfos.push_back(createMarshallingInfo(*R));
 
   for (const auto &MI : MarshallingInfos) {
-OS << "#ifdef " << MarshallingInfo::MacroName << "\n";
-OS << MarshallingInfo::MacroName << "(";
+OS << "#ifdef " << MI.getMacroName() << "\n";
+OS << MI.getMacroName() << "(";
 WriteOptRecordFields(OS, MI.R);
 OS << ", ";
 MI.emit(OS);
 OS << ")\n";
-OS << "#endif // " << MarshallingInfo::MacroName << "\n";
+OS << "#endif // " << MI.getMacroName() << "\n";
   }
 
   OS << "\n";
Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -97,6 +97,7 @@
   OptionGroup Group = ?;
   Option Alias = ?;
   list AliasArgs = [];
+  code MacroPrefix = "";
   code KeyPath = ?;
   code DefaultValue = ?;
   code ImpliedValue = ?;
Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -606,4 +606,19 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
 }
+
+// Diagnostic option.
+
+TEST_F(CommandLineTest, DiagnosticOptionPresent) {
+  const char *Args[] = {"-verify=xyz"};
+
+  ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
+
+  ASSERT_EQ(Invocation.getDiagnosticOpts().VerifyPrefixes,
+std::vector({"xyz"}));
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, ContainsN(StrEq("-verify=xyz"), 1));
+}
 } // anonymous namespace
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -386,7 +386,6 @@
 DiagnosticsEngine &Diags,
 const InputArgList &Args) {
   LangOptions &LangOpts = *Invocation.getLangOpts();
-  DiagnosticOptions &DiagOpts = Invocation.getDiagnosticOpts();
   CodeGenOptions &CodeGenOpts = Invocation.getCodeGenOpts();
   TargetOptions &TargetOpts = Invocation.getTargetOpts();
   FrontendOptions &FrontendOpts = Invocation.getFrontendOpts();
@@ -400,8 +399,6 @@
   LangOpts.SpeculativeLoadHardening = CodeGenOpts.SpeculativeLoadHardening;
   LangOpts.CurrentModule = LangOpts.ModuleName;
 
-  llvm::sys::Process::UseANSIEscapeCodes(DiagOpts.UseANSIEscapeCodes);
-
   llvm::Triple T(TargetOpts.Triple);
   llvm::Triple::ArchType Arch = T.getArch();
 
@@ -1401,13 +1398,12 @@
 ARGS, DIAGS, SUCCESS, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,\
 IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX) \
   if ((FLAGS)&options::CC1Option) {\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
+KEYPATH = MERGER(KEYPATH, DEFAULT_VALUE);  \
 if (IMPLIED_CHECK) \
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
+  KEYPATH = MERGER

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 314899.
jhuber6 retitled this revision from "[NVPTX] Strip debugging symbols for 
optimized NVPTX targets." to "[NVPTX] Fix debugging information being added to 
NVPTX target if remarks are enabled".
jhuber6 edited the summary of this revision.
jhuber6 added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changing the solution. The problem seems to be that after adjusting the debug 
info, the driver would change the debug kind if remarks were enabled. Now it 
adjusts the debug information after performing that change. This means that 
some diagnostics won't work with optimizations but it's necessary to compile 
correctly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94092: [Clang] Remove unnecessary Attr.isArgIdent checks.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D94092#2482035 , @erichkeane wrote:

> In D94092#2481857 , @aaron.ballman 
> wrote:
>
>> In D94092#2481276 , @rjmccall wrote:
>>
>>> Without bothering to look it up, I would guess that the attribute-parsing 
>>> code used to generically handle the ambiguity between identifier 
>>> expressions and identifier attribute arguments by just always parsing 
>>> simple identifiers as identifier arguments, making it Sema's responsibility 
>>> to turn that back into an expression.  At some point, the parser was made 
>>> sensitive to the actual attribute being parsed, but we never bothered to 
>>> simplify Sema.  At any rate, the parser does now know exactly which 
>>> argument of which attribute it's parsing, so there's zero reason for it to 
>>> force this complexity on Sema anymore; if we find a case that parses 
>>> identifier arguments, we should fix it in the parser to parse an expression 
>>> instead.
>>
>> I don't think it will be quite that trivial (switching all identifiers to be 
>> parsed as expressions instead). For instance, attributes that take 
>> enumeration arguments can parse those arguments as identifiers, but those 
>> identifiers will never be found by usual expression lookup because they 
>> don't really exist. That said, any attribute that currently accepts an 
>> identifier because it really wants to use that identifier in an expression 
>> in Sema should update the attribute argument clauses in Attr.td and make the 
>> corresponding changes in SemaDeclAttr.cpp/SemaStmt.cpp/SemaType.cpp as 
>> appropriate.
>
> Right, there is an Identifier type (and collection type) in Attr.td that at 
> least a handful of attributes are using intentionally.  It is typically a 
> case where GCC accepted an identifier, and it isn't always something that is 
> look-up-able via normal C++ mechanisms (such as in the case of 
> `cpu_dispatch`, where the identifiers are CPU names).
>
> EDIT:
> That said, I believe @rjmccall is correct, I think based on my run through 
> history (and knowing a bit about it from past digging) that the `vector_size` 
> attribute was added before attribute parsing did nearly as much as it did (I 
> think it even predates Attr.td).
>
> I suspect the rest of the attributes (Particularly Matrix and Address Space!) 
> simply copy/pasted that section and edited it to work, despite not having a 
> reproducer that hit it.

For the matrix_type attribute, I originally just copied & adjusted the 
ext_vector_type version.

Thanks for all the comments, I'll go ahead and land this now. We should know 
soon enough if there's anything out in the wild that can pass an `ArgIdent`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94092

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

[PATCH] D93453: [flang][driver] Add support for `-I`

[Faris via Phabricator via cfe-commits]

FarisRehman updated this revision to Diff 314905.
FarisRehman added a comment.

Address minor changes in review comments

Summary of changes

- Add a TODO for future search-path related options
- Change the text which the driver-help tests look for, which matches the help 
message in #D94169
- Rename the test header


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93453

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Flang-Driver/Inputs/basic_test_header.h
  flang/test/Flang-Driver/driver-help-hidden.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Flang-Driver/include_header.f90

Index: flang/test/Flang-Driver/include_header.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/include_header.f90
@@ -0,0 +1,39 @@
+! Ensure argument -I works as expected.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: %flang-new -E %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+! RUN: %flang-new -E -I %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=INCLUDED
+! RUN: %flang-new -E -I %S/InvalidFolder %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+! RUN: %flang-new -fc1 -E -I %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=INCLUDED
+! RUN: %flang-new -fc1 -E -I %S/InvalidFolder %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+
+!
+! EXPECTED OUTPUT FOR MISSING INCLUDED FILE
+!
+! UNINCLUDED:program b
+! UNINCLUDED-NOT:program a
+! UNINCLUDED-NEXT:end
+
+!--
+! EXPECTED OUTPUT FOR INCLUDE
+!--
+! INCLUDED:program a
+! INCLUDED-NOT:program b
+! INCLUDED-NEXT:end
+
+#include 
+#ifdef X
+program A
+#else
+program B
+#endif
+end
\ No newline at end of file
Index: flang/test/Flang-Driver/driver-help.f90
===
--- flang/test/Flang-Driver/driver-help.f90
+++ flang/test/Flang-Driver/driver-help.f90
@@ -24,6 +24,7 @@
 ! HELP-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! HELP-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! HELP-NEXT: -help  Display available options
+! HELP-NEXT: -IAdd directory to include search path
 ! HELP-NEXT: -o   Write output to 
 ! HELP-NEXT: -U  Undefine macro 
 ! HELP-NEXT: --version  Print version information
@@ -37,6 +38,7 @@
 ! HELP-FC1-NEXT: -D = Define  to  (or 1 if  omitted)
 ! HELP-FC1-NEXT: -E Only run the preprocessor
 ! HELP-FC1-NEXT: -help  Display available options
+! HELP-FC1-NEXT: -IAdd directory to include search path
 ! HELP-FC1-NEXT: -o   Write output to 
 ! HELP-FC1-NEXT: -U  Undefine macro 
 ! HELP-FC1-NEXT: --version  Print version information
Index: flang/test/Flang-Driver/driver-help-hidden.f90
===
--- flang/test/Flang-Driver/driver-help-hidden.f90
+++ flang/test/Flang-Driver/driver-help-hidden.f90
@@ -24,6 +24,7 @@
 ! CHECK-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! CHECK-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! CHECK-NEXT: -help Display available options
+! CHECK-NEXT: -IAdd directory to include search path
 ! CHECK-NEXT: -o  Write output to 
 ! CHECK-NEXT: -test-io  Run the InputOuputTest action. Use for development and testing only.
 ! CHECK-NEXT: -U  Undefine macro 
Index: flang/test/Flang-Driver/Inputs/basic_test_header.h
===
--- /dev/null
+++ flang/test/Flang-Driver/Inputs/basic_test_header.h
@@ -0,0 +1 @@
+#define X
\ No newline at end of file
Index: flang/lib/Frontend/CompilerInvocation.cpp
===
--- flang/lib/Frontend/CompilerInvocation.cpp
+++ flang/lib/Frontend/CompilerInvocation.cpp
@@ -171,6 +171,10 @@
   opts.addMacroUndef(currentArg->getValue());
 }
   }
+
+  // Add the ordered list of -I's.
+  for (const auto *currentArg : args.filtered(clang::driver::options::OPT_I))
+opts.searchDirectoriesFromDashI.emplace_back(currentArg->getValue());
 }
 
 bool CompilerInvocation::CreateFromArgs(CompilerInvocation &res,
@@ -256,4 +260,9 @@
   const auto &preprocessorOptions = preprocessorOpts();
 
   collectMacroDefinitions(preprocessor

[clang] 7809fa2 - [flang][driver] Add support for `-D`, `-U`

[Andrzej Warzynski via cfe-commits]

Author: Faris Rehman
Date: 2021-01-06T16:17:13Z
New Revision: 7809fa2040fd40b4a4b56696c7fbcd0f0fa9

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

LOG: [flang][driver] Add support for `-D`, `-U`

Add support for options -D and -U in the new Flang driver.

Summary of changes:
  - Create PreprocessorOptions, to be used by the driver then translated
into Fortran::parser::Options
  - Create CompilerInvocation::setFortranOpts to pass preprocessor
options into the parser options
  - Add a dedicated method, Flang::AddPreprocessingOptions, to extract
preprocessing options from the driver arguments into the preprocessor
command arguments

Macros specified like -DName will default to definition 1.

When defining macros, the new driver will drop anything after an
end-of-line character. This is consistent with gfortran and clang, but
different to what currently f18 does. However, flang (which is a bash
wrapper for f18), also drops everything after an end-of-line character.
So gfortran-like behaviour felt like the natural choice. Test is added
to demonstrate this behaviour.

Reviewed By: awarzynski

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

Added: 
flang/include/flang/Frontend/PreprocessorOptions.h
flang/test/Flang-Driver/macro_def_undef.f90
flang/test/Flang-Driver/macro_multiline.f90

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Flang.cpp
clang/lib/Driver/ToolChains/Flang.h
flang/include/flang/Frontend/CompilerInstance.h
flang/include/flang/Frontend/CompilerInvocation.h
flang/lib/Frontend/CompilerInstance.cpp
flang/lib/Frontend/CompilerInvocation.cpp
flang/test/Flang-Driver/driver-help-hidden.f90
flang/test/Flang-Driver/driver-help.f90

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 3c2a9f307c65..428c14a7d9bb 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -631,7 +631,7 @@ def C : Flag<["-"], "C">, Flags<[CC1Option]>, 
Group,
 HelpText<"Include comments in preprocessed output">,
 MarshallingInfoFlag<"PreprocessorOutputOpts.ShowComments">;
 def D : JoinedOrSeparate<["-"], "D">, Group,
-Flags<[CC1Option]>, MetaVarName<"=">,
+Flags<[CC1Option, FlangOption, FC1Option]>, MetaVarName<"=">,
 HelpText<"Define  to  (or 1 if  omitted)">;
 def E : Flag<["-"], "E">, Flags<[NoXarchOption,CC1Option, FlangOption, 
FC1Option]>, Group,
 HelpText<"Only run the preprocessor">;
@@ -730,7 +730,7 @@ def Ttext : JoinedOrSeparate<["-"], "Ttext">, 
Group,
 def T : JoinedOrSeparate<["-"], "T">, Group,
   MetaVarName<"

[PATCH] D93401: [flang][driver] Add support for `-D`, `-U`

[Andrzej Warzynski 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 rG7809fa204000: [flang][driver] Add support for `-D`, `-U` 
(authored by FarisRehman, committed by awarzynski).

Changed prior to commit:
  https://reviews.llvm.org/D93401?vs=313532&id=314906#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93401

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  flang/include/flang/Frontend/CompilerInstance.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Flang-Driver/driver-help-hidden.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Flang-Driver/macro_def_undef.f90
  flang/test/Flang-Driver/macro_multiline.f90

Index: flang/test/Flang-Driver/macro_multiline.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/macro_multiline.f90
@@ -0,0 +1,22 @@
+! Ensure the end-of-line character and anything that follows after in a macro definition (-D) is ignored.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -fc1 -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
+
+!---
+! EXPECTED OUTPUT FOR MACRO 'X'
+!---
+! CHECK:start a end
+! CHECK-NOT:THIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT
+! CHECK-NOT:this_should_not_exist_in_the_output
+
+START X END
\ No newline at end of file
Index: flang/test/Flang-Driver/macro_def_undef.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/macro_def_undef.f90
@@ -0,0 +1,38 @@
+! Ensure arguments -D and -U work as expected.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: %flang-new -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang-new -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -E -DX=A -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang-new -fc1 -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -fc1 -E -DX -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+
+!
+! EXPECTED OUTPUT FOR AN UNDEFINED MACRO
+!
+! UNDEFINED:program b
+! UNDEFINED-NOT:program x
+! UNDEFINED-NEXT:end
+
+!
+! EXPECTED OUTPUT FOR MACRO 'X' DEFINED AS A
+!
+! DEFINED:program a
+! DEFINED-NOT:program b
+! DEFINED-NEXT:end
+
+#ifdef X
+program X
+#else
+program B
+#endif
+end
\ No newline at end of file
Index: flang/test/Flang-Driver/driver-help.f90
===
--- flang/test/Flang-Driver/driver-help.f90
+++ flang/test/Flang-Driver/driver-help.f90
@@ -19,11 +19,13 @@
 ! HELP-EMPTY:
 ! HELP-NEXT:OPTIONS:
 ! HELP-NEXT: -###   Print (but do not run) the commands to run for this compilation
+! HELP-NEXT: -D = Define  to  (or 1 if  omitted)
 ! HELP-NEXT: -E Only run the preprocessor
 ! HELP-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! HELP-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! HELP-NEXT: -help  Display available options
 ! HELP-NEXT: -o   Write output to 
+! HELP-NEXT: -U  Undefine macro 
 ! HELP-NEXT: --version  Print version information
 
 !-
@@ -32,10 +34,12 @@
 ! HELP-FC1:USAGE: flang-new
 ! HELP-FC1-EMPTY:
 ! HELP-FC1-NEXT:OPTIONS:
-! HELP-FC1-NEXT: -EOnly run the preprocessor
-! HELP-FC1-NEXT: -help Display available options
-! HELP-FC1-NEXT: -o  Write output to 
-! HELP-FC1-NEXT: --version Print version information
+! HELP-FC1-NEXT: -D = Define  to  (or 1 if  omitted)
+! HELP-FC1-NEXT: -E Only run the preprocessor
+! HELP-FC1-NEXT: -help  Display a

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

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

Use arrow instead of dot in keypath


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

Files:
  clang/include/clang/Basic/DiagnosticOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp
  llvm/include/llvm/Option/OptParser.td
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -66,6 +66,7 @@
   static constexpr const char *MacroName = "OPTION_WITH_MARSHALLING";
   const Record &R;
   bool ShouldAlwaysEmit;
+  StringRef MacroPrefix;
   StringRef KeyPath;
   StringRef DefaultValue;
   StringRef NormalizedValuesScope;
@@ -99,6 +100,10 @@
 
   MarshallingInfo(const Record &R) : R(R) {}
 
+  std::string getMacroName() const {
+return (MacroPrefix + MarshallingInfo::MacroName).str();
+  }
+
   void emit(raw_ostream &OS) const {
 write_cstring(OS, StringRef(getOptionSpelling(R)));
 OS << ", ";
@@ -160,6 +165,7 @@
   MarshallingInfo Ret(R);
 
   Ret.ShouldAlwaysEmit = R.getValueAsBit("ShouldAlwaysEmit");
+  Ret.MacroPrefix = R.getValueAsString("MacroPrefix");
   Ret.KeyPath = R.getValueAsString("KeyPath");
   Ret.DefaultValue = R.getValueAsString("DefaultValue");
   Ret.NormalizedValuesScope = R.getValueAsString("NormalizedValuesScope");
@@ -420,13 +426,13 @@
 MarshallingInfos.push_back(createMarshallingInfo(*R));
 
   for (const auto &MI : MarshallingInfos) {
-OS << "#ifdef " << MarshallingInfo::MacroName << "\n";
-OS << MarshallingInfo::MacroName << "(";
+OS << "#ifdef " << MI.getMacroName() << "\n";
+OS << MI.getMacroName() << "(";
 WriteOptRecordFields(OS, MI.R);
 OS << ", ";
 MI.emit(OS);
 OS << ")\n";
-OS << "#endif // " << MarshallingInfo::MacroName << "\n";
+OS << "#endif // " << MI.getMacroName() << "\n";
   }
 
   OS << "\n";
Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -97,6 +97,7 @@
   OptionGroup Group = ?;
   Option Alias = ?;
   list AliasArgs = [];
+  code MacroPrefix = "";
   code KeyPath = ?;
   code DefaultValue = ?;
   code ImpliedValue = ?;
Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -606,4 +606,19 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
 }
+
+// Diagnostic option.
+
+TEST_F(CommandLineTest, DiagnosticOptionPresent) {
+  const char *Args[] = {"-verify=xyz"};
+
+  ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
+
+  ASSERT_EQ(Invocation.getDiagnosticOpts().VerifyPrefixes,
+std::vector({"xyz"}));
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, ContainsN(StrEq("-verify=xyz"), 1));
+}
 } // anonymous namespace
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -386,7 +386,6 @@
 DiagnosticsEngine &Diags,
 const InputArgList &Args) {
   LangOptions &LangOpts = *Invocation.getLangOpts();
-  DiagnosticOptions &DiagOpts = Invocation.getDiagnosticOpts();
   CodeGenOptions &CodeGenOpts = Invocation.getCodeGenOpts();
   TargetOptions &TargetOpts = Invocation.getTargetOpts();
   FrontendOptions &FrontendOpts = Invocation.getFrontendOpts();
@@ -400,8 +399,6 @@
   LangOpts.SpeculativeLoadHardening = CodeGenOpts.SpeculativeLoadHardening;
   LangOpts.CurrentModule = LangOpts.ModuleName;
 
-  llvm::sys::Process::UseANSIEscapeCodes(DiagOpts.UseANSIEscapeCodes);
-
   llvm::Triple T(TargetOpts.Triple);
   llvm::Triple::ArchType Arch = T.getArch();
 
@@ -1401,13 +1398,12 @@
 ARGS, DIAGS, SUCCESS, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,\
 IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX) \
   if ((FLAGS)&options::CC1Option) {\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
+KEYPATH = MERGER(KEYPATH, DEFAULT_VALUE);  \
 if (IMPLIED_CHECK) \
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
+  KEYPATH = MERGE

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

[David Sherwood via Phabricator via cfe-commits]

david-arm added a comment.

Hi everyone, I realise that most people have probably been on holiday recently, 
but just a gentle ping here to see if anyone could take another look? Thanks!


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

https://reviews.llvm.org/D89031

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

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: llvm/utils/TableGen/OptParserEmitter.cpp:102-107
+  std::string getMacroName() const {
+if (KeyPath.startswith("DiagnosticOpts."))
+  return (Twine("DIAG_") + MarshallingInfo::MacroName).str();
+
+return MarshallingInfo::MacroName;
+  }

dexonsmith wrote:
> jansvoboda11 wrote:
> > dexonsmith wrote:
> > > This seems like a bit of a semantic layering violation. It'd be pretty 
> > > unexpected if someone renamed `DiagnosticOpts` in clang that they'd have 
> > > to update this code in llvm. Is there another way to solve this problem?
> > I don't like it either, but the alternatives I can think of are worse.
> > 
> > We could add a `string MacroPrefix;` field to LLVM's `Option` class and 
> > populate it in Clang's TableGen file:
> > 1. Via something like an `IsDiag` multiclass that we'd need to remember to 
> > apply to each diagnostic option. I don't like it as it seems error prone 
> > and introduces duplication.
> > 2. Put all diagnostic options into a single `let MacroPrefix = "DIAG_" in { 
> > ... }` block. This removes the duplication, but doesn't ensure an option is 
> > in that block iff it's a diagnostic option with `"DiagnosticOpts.*"` 
> > keypath.
> > 3. More involved approach would be to duplicate the LLVM's `Option` and 
> > related stuff in Clang. That would get us a place to put the custom 
> > `KeyPath.startswith("DiagnosticOpts.")` logic and then forward to LLVM's 
> > `Option` with the appropriate `MacroPrefix`.
> > 
> > I'll think some more about it.
> Doing #1 + #2 seems like an okay tradeoff to me (looking back at the old 
> diff, it seems like that's similar to what @dang originally implemented 
> (except adding a more generic `MacroPrefix`), and it seems fairly clean / 
> obvious to me).
> 
> > [...] but doesn't ensure an option is in that block iff it's a diagnostic 
> > option with "DiagnosticOpts.*" keypath.
> 
> The reason I'm okay with this is that I'm having trouble envisioning how this 
> would go wrong practice.
> - If someone adds somethings to `DiagnosticOptions`, they're likely to grep 
> for how the adjacent field was defined / marshalled, duplicate the line, and 
> modify it. I'm not seeing a likely path for them to copy/paste from a 
> non-diagnostic option and/or miss adding this to the `let` block.
> - If someone accidentally adds something to the `let` block that isn't in 
> `DiagnosticOptions`, they'll get a compiler error in `ParseDiagnosticArgs`.
> 
> If you're still concerned, I wonder if there's a way to add a check in 
> asserts builds that confirms that `ParseDiagnosticArgs` fills in 
> `DiagnosticOptions` equivalently to how `createFromCommandLine` does? (and/or 
> could the latter call the former as an implementation strategy?)
> - If someone adds somethings to `DiagnosticOptions`, they're likely to grep 
> for how the adjacent field was defined / marshalled, duplicate the line, and 
> modify it. I'm not seeing a likely path for them to copy/paste from a 
> non-diagnostic option and/or miss adding this to the `let` block.

I think that's a fair assumption.

> - If someone accidentally adds something to the `let` block that isn't in 
> `DiagnosticOptions`, they'll get a compiler error in `ParseDiagnosticArgs`.

That's right.

I think it's fine to move from the check in `OptParserEmitter` to a 
`MacroPrefix` then.
I chose the `IsDiag` mixin as opposed to `let MacroPrefix = "_DIAG" in { ... 
}`, as it doesn't require moving options around - cleaner diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

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

[PATCH] D93702: [clang][cli] NFC: Make marshalling macros reusable

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3040
 
-#define OPTION_WITH_MARSHALLING(   
\
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
-TABLE_INDEX)   
\
-  if ((FLAGS)&options::CC1Option) {
\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  
\
-if (IMPLIED_CHECK) 
\
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);
\
-if (auto MaybeValue =  
\
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   
\
-  this->KEYPATH = MERGER(  
\
-  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   
\
-  }
-
+#define OPTION_WITH_MARSHALLING PARSE_OPTION_WITH_MARSHALLING
 #include "clang/Driver/Options.inc"

dexonsmith wrote:
> jansvoboda11 wrote:
> > dexonsmith wrote:
> > > One concern I have with this change is that the macro is using local 
> > > variable names; it really would be better to have the macro content local 
> > > to the function(s) where the variables are defined.
> > > 
> > > Can you give more context about why this has to be called from another 
> > > place? Maybe there's another way to solve the problem.
> > I've provided more context here: D93701.
> > 
> > We can solve the problem with implicit use of local variables inside the 
> > macro by promoting them to macro parameters.
> > This will make the forwarding call from `OPTION_WITH_MARSHALLING` to 
> > `PARSE_OPTION_WITH_MARSHALLING` longer, as it will need to spell out all 
> > parameters, but it would solve your concern I think.
> I like that idea. That approach also allows you to drop unused parameters 
> entirely in `PARSE_OPTIONS_WITH_MARSHALLING` (only forward the parameters 
> that get used).
I've dropped the unused parameters for the `PARSE_` macro. D84673 does the same 
for the `GENERATE_` macro.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3331-3332
+
+#undef GENERATE_OPTION_WITH_MARSHALLING
+#undef PARSE_OPTION_WITH_MARSHALLING

dexonsmith wrote:
> I like the idea of `#undef`'ing these macros to make their scope of use 
> clear, but I'm not sure doing it at the end of file is adding a lot of value.
> 
> Is there a way of moving the call sites for each to be next to each other in 
> the file, so you can `#define` and then `#undef` in a more limited scope? 
> E.g.,
> ```
> // maybe other content...
> 
> #define PARSE_OPTION_WITH_MARSHALLING(...) ...
> void f1(...) { /* use PARSE_OPTION_WITH_MARSHALLING */ }
> void f2(...) { /* use PARSE_OPTION_WITH_MARSHALLING */ }
> #undef PARSE_OPTION_WITH_MARSHALLING
> 
> // maybe other content...
> 
> #define GENERATE_OPTION_WITH_MARSHALLING(...) ...
> void f3(...) { /* use GENERATE_OPTION_WITH_MARSHALLING*/ }
> void f4(...) { /* use GENERATE_OPTION_WITH_MARSHALLING*/ }
> #undef GENERATE_OPTION_WITH_MARSHALLING
> 
> // maybe other content...
> ```
> (If so, the code movement should be done in a separate NFC prep commit...)
Yeah, limiting the scope where the macro is defined would be nice. I've moved 
things around and we'll be able to keep the `GENERATE_` macro local to the 
function, while the `PARSE_` macro will span only the two functions that'll 
make use of it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93702

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

[PATCH] D93901: [NFC] Renaming PackStack to AlignPackStack

[Xiangling Liao via Phabricator via cfe-commits]

Xiangling_L updated this revision to Diff 314911.
Xiangling_L marked 3 inline comments as done.
Xiangling_L added a comment.

Add pre-committing tests with the incorrect behaviour as part of the NFC patch.


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

https://reviews.llvm.org/D93901

Files:
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Sema/Inputs/pragma-align-pack1.h
  clang/test/Sema/misleading-pragma-align-pack-diagnostics.c

Index: clang/test/Sema/misleading-pragma-align-pack-diagnostics.c
===
--- /dev/null
+++ clang/test/Sema/misleading-pragma-align-pack-diagnostics.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -triple i686-apple-darwin9 -fsyntax-only -Wpragma-pack-suspicious-include -I %S/Inputs -DALIGN_SET_HERE -verify %s
+// RUN: %clang_cc1 -triple i686-apple-darwin9 -fsyntax-only -Wpragma-pack-suspicious-include -I %S/Inputs -DRECORD_ALIGN -verify %s
+
+#ifdef ALIGN_SET_HERE
+#pragma align = natural // expected-warning {{unterminated '#pragma pack (push, ...)' at end of file}}
+// expected-warning@+9 {{the current #pragma pack alignment value is modified in the included file}}
+#endif
+
+#ifdef RECORD_ALIGN
+#pragma align = mac68k
+// expected-note@-1 {{previous '#pragma pack' directive that modifies alignment is here}}
+// expected-warning@+3 {{non-default #pragma pack value changes the alignment of struct or union members in the included file}}
+#endif
+
+#include "pragma-align-pack1.h"
+
+#ifdef RECORD_ALIGN
+#pragma align = reset
+#endif
Index: clang/test/Sema/Inputs/pragma-align-pack1.h
===
--- /dev/null
+++ clang/test/Sema/Inputs/pragma-align-pack1.h
@@ -0,0 +1,11 @@
+#ifdef ALIGN_SET_HERE
+#pragma align = mac68k
+// expected-note@-1 {{previous '#pragma pack' directive that modifies alignment is here}}
+// expected-warning@-2 {{unterminated '#pragma pack (push, ...)' at end of file}}
+#endif
+
+#ifdef RECORD_ALIGN
+struct S {
+  int x;
+};
+#endif
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -4151,24 +4151,24 @@
   Stream.EmitRecord(POINTERS_TO_MEMBERS_PRAGMA_OPTIONS, Record);
 }
 
-/// Write the state of 'pragma pack' at the end of the module.
+/// Write the state of 'pragma align/pack' at the end of the module.
 void ASTWriter::WritePackPragmaOptions(Sema &SemaRef) {
-  // Don't serialize pragma pack state for modules, since it should only take
-  // effect on a per-submodule basis.
+  // Don't serialize pragma align/pack state for modules, since it should only
+  // take effect on a per-submodule basis.
   if (WritingModule)
 return;
 
   RecordData Record;
-  Record.push_back(SemaRef.PackStack.CurrentValue);
-  AddSourceLocation(SemaRef.PackStack.CurrentPragmaLocation, Record);
-  Record.push_back(SemaRef.PackStack.Stack.size());
-  for (const auto &StackEntry : SemaRef.PackStack.Stack) {
+  Record.push_back(SemaRef.AlignPackStack.CurrentValue);
+  AddSourceLocation(SemaRef.AlignPackStack.CurrentPragmaLocation, Record);
+  Record.push_back(SemaRef.AlignPackStack.Stack.size());
+  for (const auto &StackEntry : SemaRef.AlignPackStack.Stack) {
 Record.push_back(StackEntry.Value);
 AddSourceLocation(StackEntry.PragmaLocation, Record);
 AddSourceLocation(StackEntry.PragmaPushLocation, Record);
 AddString(StackEntry.StackSlotLabel, Record);
   }
-  Stream.EmitRecord(PACK_PRAGMA_OPTIONS, Record);
+  Stream.EmitRecord(ALIGN_PACK_PRAGMA_OPTIONS, Record);
 }
 
 /// Write the state of 'pragma float_control' at the end of the module.
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -3742,25 +3742,25 @@
   ForceCUDAHostDeviceDepth = Record[0];
   break;
 
-case PACK_PRAGMA_OPTIONS: {
+case ALIGN_PACK_PRAGMA_OPTIONS: {
   if (Record.size() < 3) {
 Error("invalid pragma pack record");
 return Failure;
   }
-  PragmaPackCurrentValue = Record[0];
-  PragmaPackCurrentLocation = ReadSourceLocation(F, Record[1]);
+  PragmaAlignPackCurrentValue = Record[0];
+  PragmaAlignPackCurrentLocation = ReadSourceLocation(F, Record[1]);
   unsigned NumStackEntries = Record[2];
   unsigned Idx = 3;
   // Reset the stack when importing a new module.
-  PragmaPackStack.clear();
+  PragmaAlignPackStack.clear();
   for (unsigned I = 0; I < NumStackEntries; ++I) {
-PragmaPackStackEntry Entry;
+PragmaAlignPackStackEntry Entry;
 Entry

[PATCH] D91806: [InstCombine] Update valueCoversEntireFragment to use TypeSize

[Peter Waller 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 rGdfd3384feeca: [InstCombine] Update valueCoversEntireFragment 
to use TypeSize (authored by fpetrogalli, committed by peterwaller-arm).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91806

Files:
  llvm/lib/Transforms/Utils/Local.cpp
  llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll


Index: llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
@@ -0,0 +1,36 @@
+; RUN: opt -instcombine -S < %s 2>%t | FileCheck %s
+; RUN: FileCheck --check-prefix=WARN --allow-empty %s <%t
+
+; This test is defending against a TypeSize message raised in the method
+; `valueCoversEntireFragment` in Local.cpp because of an implicit cast from
+; `TypeSize` to `uint64_t`. This particular TypeSize message only occurred when
+; debug info was available.
+
+; If this check fails please read
+; clang/test/CodeGen/aarch64-sve-intrinsics/README for instructions on
+; how to resolve it.
+; This test must not produce any warnings. Prior to this test being introduced,
+; it produced a warning containing the text "TypeSize is not scalable".
+; WARN-NOT: warning:
+
+; CHECK-LABEL: @debug_local_scalable(
+define  @debug_local_scalable( 
%tostore) {
+  %vx = alloca , align 16
+  call void @llvm.dbg.declare(metadata * %vx, metadata 
!3, metadata !DIExpression()), !dbg !5
+  store  %tostore, * %vx, align 16
+  %ret = call  @f(* %vx)
+  ret  %ret
+}
+
+declare  @f(*)
+
+declare void @llvm.dbg.declare(metadata, metadata, metadata)
+
+!llvm.module.flags = !{!2}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1)
+!1 = !DIFile(filename: "/tmp/test.c", directory: "/tmp/")
+!2 = !{i32 2, !"Debug Info Version", i32 3}
+!3 = !DILocalVariable(scope: !4)
+!4 = distinct !DISubprogram(unit: !0)
+!5 = !DILocation(scope: !4)
Index: llvm/lib/Transforms/Utils/Local.cpp
===
--- llvm/lib/Transforms/Utils/Local.cpp
+++ llvm/lib/Transforms/Utils/Local.cpp
@@ -1340,16 +1340,22 @@
 /// least n bits.
 static bool valueCoversEntireFragment(Type *ValTy, DbgVariableIntrinsic *DII) {
   const DataLayout &DL = DII->getModule()->getDataLayout();
-  uint64_t ValueSize = DL.getTypeAllocSizeInBits(ValTy);
-  if (auto FragmentSize = DII->getFragmentSizeInBits())
-return ValueSize >= *FragmentSize;
+  TypeSize ValueSize = DL.getTypeAllocSizeInBits(ValTy);
+  if (Optional FragmentSize = DII->getFragmentSizeInBits()) {
+assert(!ValueSize.isScalable() &&
+   "Fragments don't work on scalable types.");
+return ValueSize.getFixedSize() >= *FragmentSize;
+  }
   // We can't always calculate the size of the DI variable (e.g. if it is a
   // VLA). Try to use the size of the alloca that the dbg intrinsic describes
   // intead.
   if (DII->isAddressOfVariable())
 if (auto *AI = dyn_cast_or_null(DII->getVariableLocation()))
-  if (auto FragmentSize = AI->getAllocationSizeInBits(DL))
-return ValueSize >= *FragmentSize;
+  if (Optional FragmentSize = AI->getAllocationSizeInBits(DL)) {
+assert(ValueSize.isScalable() == FragmentSize->isScalable() &&
+   "Both sizes should agree on the scalable flag.");
+return TypeSize::isKnownGE(ValueSize, *FragmentSize);
+  }
   // Could not determine size of variable. Conservatively return false.
   return false;
 }


Index: llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
@@ -0,0 +1,36 @@
+; RUN: opt -instcombine -S < %s 2>%t | FileCheck %s
+; RUN: FileCheck --check-prefix=WARN --allow-empty %s <%t
+
+; This test is defending against a TypeSize message raised in the method
+; `valueCoversEntireFragment` in Local.cpp because of an implicit cast from
+; `TypeSize` to `uint64_t`. This particular TypeSize message only occurred when
+; debug info was available.
+
+; If this check fails please read
+; clang/test/CodeGen/aarch64-sve-intrinsics/README for instructions on
+; how to resolve it.
+; This test must not produce any warnings. Prior to this test being introduced,
+; it produced a warning containing the text "TypeSize is not scalable".
+; WARN-NOT: warning:
+
+; CHECK-LABEL: @debug_local_scalable(
+define  @debug_local_scalable( %tostore) {
+  %vx = alloca , align 16
+  call void @llvm.dbg.declare(metadata * %vx, metadata !3, metadata !DIExpression()), !dbg !5
+  store  %tostore, * %vx, align 16
+  %ret = call  @f(* %vx)
+  ret  %ret
+}
+
+declare  @f(*)
+
+declare void @llvm.dbg.declare(metadata, metadata, metadata)
+
+!llvm.module.flags = !

[PATCH] D93095: Introduce -Wreserved-identifier

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/reserved-identifier.c:9
+int _foo() { return 0; }// expected-warning {{'_foo' is a reserved 
identifier}}
+
+// This one is explicitly skipped by -Wreserved-identifier

Can you add a test that we do not warn on an extern declaration? e.g.,
```
extern char *_strdup(const char *);
```
This is sometimes used (esp in older C code bases) to avoid having to include 
an entire header to scrape one declaration out of it, and there are popular 
libraries (like the MSVC CRT) that have APIs starting with a single underscore 
and lowercase letter.

The idea here is: if it's an extern declaration, the identifier is "owned" by 
some other declaration and this is not likely something the user has control 
over.



Comment at: clang/test/Sema/reserved-identifier.c:24
+  _Other, // expected-warning {{'_Other' is a reserved identifier}}
+  _other  // no-warning
+};

I'm on the fence about whether this should have no warning or not. Enumeration 
constants in C (and sometimes in C++, depending on the enumeration) are in the 
enclosing scope. e.g.,
```
enum foo {
  _bar
};

int i = _bar;
```
So if a user has an enumeration constant named `_bar`, the implementation is 
not free to add `int _bar(void);` as it will cause compile errors. WDYT?



Comment at: clang/test/Sema/reserved-identifier.cpp:58
+// we skip this one because it's not at top-level.
+int _barbatruc; // no-warning
+}

This is another case that I'm on the fence about failing to warn on because the 
name `_barbatruc` would conflict with a name introduced by the implementation. 
Another interesting variant of the same problem, for C++:
```
static union {
  int _field;
};
```
I wonder if the rule should not be whether the declaration is at file scope or 
not, but whether the declared identifier can be found at file scope or not?



Comment at: clang/test/Sema/reserved-identifier.cpp:40
+  return foo__bar(); // no-warning
+}

aaron.ballman wrote:
> You should also have some tests for:
> ```
> template 
> void _Foobar(); // Even though it's not instantiated, it's still reserved.
> 
> template  // Reserved
> void whatever();
> 
> void func() {
>   int array[10];
>   for (auto _A : array) // Reserved
> ;
> }
> 
> class _C { // Reserved
> public:
>   _C(); // Not reserved
> };
> 
> unsigned operator "" huttah(unsigned long long); // Reserved 
> (http://eel.is/c++draft/usrlit.suffix#1)
> 
> unsigned operator "" _W(unsigned long long); // Reserved
> unsigned operator "" _w(unsigned long long); // Reserved
> 
> static unsigned operator "" _X(unsigned long long); // Not reserved
> static unsigned operator "" _x(unsigned long long); // Not reserved
> ```
I think some of these tests are still missing. I'm especially worried about the 
user-defined literal cases being diagnosed, as we'd be warning to not do the 
exact thing users are expected to do.


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

https://reviews.llvm.org/D93095

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

[PATCH] D92892: [clang] Change builtin object size to be compatible with GCC when sub-object is invalid

[George Burgess IV via Phabricator via cfe-commits]

george.burgess.iv accepted this revision.
george.burgess.iv added a comment.
This revision is now accepted and ready to land.

thanks for working on this!

just one tiny nit and lgtm




Comment at: clang/lib/AST/ExprConstant.cpp:11408
 
   // If we point to before the start of the object, there are no accessible
   // bytes.

nit: the new part of this condition makes this comment somewhat outdated. 
should it say something like "outside of" instead of "before"?


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

https://reviews.llvm.org/D92892

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

[PATCH] D94067: [clang][ASTImporter] Fix a possible assertion failure `NeedsInjectedClassNameType(Decl)'.

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:2901
+  // Skip the declaration if injected type is already set.
+  if (isa(RI->getTypeForDecl()))
+continue;

balazske wrote:
> shafik wrote:
> > Is this to fix the bug or is this for efficiency sake?
> This is not needed for the fix, it was used in the first version of the fix 
> (still only for efficiency). In the current form this looks like unrelated 
> change (the old fix included other code at the same location) so I am not 
> against removing this part (but add it in a separate change).
Yes, please if we can split the two changes that would be great.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94067

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

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer accepted this revision.
SjoerdMeijer added a comment.

LGTM, perhaps wait a day with committing in case there are more comments.




Comment at: clang/include/clang/Basic/Attr.td:3356
   EnumArgument<"State", "LoopHintState",
-   ["enable", "disable", "numeric", "assume_safety", 
"full"],
-   ["Enable", "Disable", "Numeric", "AssumeSafety", 
"Full"]>,
+   ["enable", "disable", "numeric", "fixed_width", 
"scalable_width", "assume_safety", "full"],
+   ["Enable", "Disable", "Numeric", "FixedWidth", 
"ScalableWidth", "AssumeSafety", "Full"]>,

aaron.ballman wrote:
> david-arm wrote:
> > aaron.ballman wrote:
> > > Should the documentation in AttrDocs.td be updated for this change?
> > Hi @aaron.ballman I had a look at LoopHintDocs in AttrDocs.td and it didn't 
> > explicitly mention these states, i.e. "assume_safety", "numeric", etc., so 
> > I'm not sure if it's necessary to add anything there?
> Oh, I see now, we're deferring to the documentation in the language 
> extensions document. I suppose that's fine as far as this patch goes, sorry 
> for the noise.
Nit: formatting, exceeding 80 columns?



Comment at: clang/include/clang/Basic/Attr.td:3357
+   ["enable", "disable", "numeric", "fixed_width", 
"scalable_width", "assume_safety", "full"],
+   ["Enable", "Disable", "Numeric", "FixedWidth", 
"ScalableWidth", "AssumeSafety", "Full"]>,
   ExprArgument<"Value">];

same?


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

https://reviews.llvm.org/D89031

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

[clang] 7ef9139 - [Clang] Remove unnecessary Attr.isArgIdent checks.

[Florian Hahn via cfe-commits]

Author: Florian Hahn
Date: 2021-01-06T18:01:41Z
New Revision: 7ef9139a391a6d526afab0216a97f9d65a6b5563

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

LOG: [Clang] Remove unnecessary Attr.isArgIdent checks.

The MatrixType, ExtVectorType, VectorSize and AddressSpace attributes
have arguments defined as ExprArguments in Attr.td. So their arguments
should never be ArgIdents and the logic to handle this case can be
removed.

The logic has been replaced by an assertion to ensure the arguments
are always ArgExpressions

Reviewed By: erichkeane

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

Added: 


Modified: 
clang/lib/Sema/SemaType.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 00ec0c4a0cee..3f564541d41d 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -6434,25 +6434,7 @@ static void HandleAddressSpaceTypeAttribute(QualType 
&Type,
   return;
 }
 
-Expr *ASArgExpr;
-if (Attr.isArgIdent(0)) {
-  // Special case where the argument is a template id.
-  CXXScopeSpec SS;
-  SourceLocation TemplateKWLoc;
-  UnqualifiedId id;
-  id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-  ExprResult AddrSpace = S.ActOnIdExpression(
-  S.getCurScope(), SS, TemplateKWLoc, id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-  if (AddrSpace.isInvalid())
-return;
-
-  ASArgExpr = static_cast(AddrSpace.get());
-} else {
-  ASArgExpr = static_cast(Attr.getArgAsExpr(0));
-}
-
+Expr *ASArgExpr = static_cast(Attr.getArgAsExpr(0));
 LangAS ASIdx;
 if (!BuildAddressSpaceIndex(S, ASIdx, ASArgExpr, Attr.getLoc())) {
   Attr.setInvalid();
@@ -7658,25 +7640,7 @@ static void HandleVectorSizeAttr(QualType &CurType, 
const ParsedAttr &Attr,
 return;
   }
 
-  Expr *SizeExpr;
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId Id;
-Id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  Id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-
-if (Size.isInvalid())
-  return;
-SizeExpr = Size.get();
-  } else {
-SizeExpr = Attr.getArgAsExpr(0);
-  }
-
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
   QualType T = S.BuildVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
@@ -7695,28 +7659,8 @@ static void HandleExtVectorTypeAttr(QualType &CurType, 
const ParsedAttr &Attr,
 return;
   }
 
-  Expr *sizeExpr;
-
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-if (Size.isInvalid())
-  return;
-
-sizeExpr = Size.get();
-  } else {
-sizeExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Create the vector type.
-  QualType T = S.BuildExtVectorType(CurType, sizeExpr, Attr.getLoc());
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
+  QualType T = S.BuildExtVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
 }
@@ -7988,49 +7932,8 @@ static void HandleMatrixTypeAttr(QualType &CurType, 
const ParsedAttr &Attr,
 return;
   }
 
-  Expr *RowsExpr = nullptr;
-  Expr *ColsExpr = nullptr;
-
-  // TODO: Refactor parameter extraction into separate function
-  // Get the number of rows
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-ExprResult Rows = S.ActOnIdExpression(S.getCurScope(), SS,
-  TemplateKeywordLoc, id, false, 
false);
-
-if (Rows.isInvalid())
-  // TODO: maybe a good error message would be nice here
-  return;
-RowsExpr = Rows.get();
-  } else {
-assert(Attr.isArgExpr(0) &&
-   "Argument to should either be an identity or expression");
-RowsExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Get the number of columns
-  if (Attr.isArgIdent(1)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(1)->Ident, Attr.getLoc());
-ExprResult Columns =

[PATCH] D94092: [Clang] Remove unnecessary Attr.isArgIdent checks.

[Florian Hahn 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 rG7ef9139a391a: [Clang] Remove unnecessary Attr.isArgIdent 
checks. (authored by fhahn).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94092

Files:
  clang/lib/Sema/SemaType.cpp

Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -6434,25 +6434,7 @@
   return;
 }
 
-Expr *ASArgExpr;
-if (Attr.isArgIdent(0)) {
-  // Special case where the argument is a template id.
-  CXXScopeSpec SS;
-  SourceLocation TemplateKWLoc;
-  UnqualifiedId id;
-  id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-  ExprResult AddrSpace = S.ActOnIdExpression(
-  S.getCurScope(), SS, TemplateKWLoc, id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-  if (AddrSpace.isInvalid())
-return;
-
-  ASArgExpr = static_cast(AddrSpace.get());
-} else {
-  ASArgExpr = static_cast(Attr.getArgAsExpr(0));
-}
-
+Expr *ASArgExpr = static_cast(Attr.getArgAsExpr(0));
 LangAS ASIdx;
 if (!BuildAddressSpaceIndex(S, ASIdx, ASArgExpr, Attr.getLoc())) {
   Attr.setInvalid();
@@ -7658,25 +7640,7 @@
 return;
   }
 
-  Expr *SizeExpr;
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId Id;
-Id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  Id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-
-if (Size.isInvalid())
-  return;
-SizeExpr = Size.get();
-  } else {
-SizeExpr = Attr.getArgAsExpr(0);
-  }
-
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
   QualType T = S.BuildVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
@@ -7695,28 +7659,8 @@
 return;
   }
 
-  Expr *sizeExpr;
-
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-if (Size.isInvalid())
-  return;
-
-sizeExpr = Size.get();
-  } else {
-sizeExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Create the vector type.
-  QualType T = S.BuildExtVectorType(CurType, sizeExpr, Attr.getLoc());
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
+  QualType T = S.BuildExtVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
 }
@@ -7988,49 +7932,8 @@
 return;
   }
 
-  Expr *RowsExpr = nullptr;
-  Expr *ColsExpr = nullptr;
-
-  // TODO: Refactor parameter extraction into separate function
-  // Get the number of rows
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-ExprResult Rows = S.ActOnIdExpression(S.getCurScope(), SS,
-  TemplateKeywordLoc, id, false, false);
-
-if (Rows.isInvalid())
-  // TODO: maybe a good error message would be nice here
-  return;
-RowsExpr = Rows.get();
-  } else {
-assert(Attr.isArgExpr(0) &&
-   "Argument to should either be an identity or expression");
-RowsExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Get the number of columns
-  if (Attr.isArgIdent(1)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(1)->Ident, Attr.getLoc());
-ExprResult Columns = S.ActOnIdExpression(
-S.getCurScope(), SS, TemplateKeywordLoc, id, false, false);
-
-if (Columns.isInvalid())
-  // TODO: a good error message would be nice here
-  return;
-RowsExpr = Columns.get();
-  } else {
-assert(Attr.isArgExpr(1) &&
-   "Argument to should either be an identity or expression");
-ColsExpr = Attr.getArgAsExpr(1);
-  }
-
-  // Create the matrix type.
+  Expr *RowsExpr = Attr.getArgAsExpr(0);
+  Expr *ColsExpr = Attr.getArgAsExpr(1);
   QualType T = S.BuildMatrixType(CurType, RowsExpr, ColsExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

OK with me, @tra ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

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

[PATCH] D94092: [Clang] Remove unnecessary Attr.isArgIdent checks.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D94092#2481857 , @aaron.ballman 
wrote:

> In D94092#2481276 , @rjmccall wrote:
>
>> Without bothering to look it up, I would guess that the attribute-parsing 
>> code used to generically handle the ambiguity between identifier expressions 
>> and identifier attribute arguments by just always parsing simple identifiers 
>> as identifier arguments, making it Sema's responsibility to turn that back 
>> into an expression.  At some point, the parser was made sensitive to the 
>> actual attribute being parsed, but we never bothered to simplify Sema.  At 
>> any rate, the parser does now know exactly which argument of which attribute 
>> it's parsing, so there's zero reason for it to force this complexity on Sema 
>> anymore; if we find a case that parses identifier arguments, we should fix 
>> it in the parser to parse an expression instead.
>
> I don't think it will be quite that trivial (switching all identifiers to be 
> parsed as expressions instead). For instance, attributes that take 
> enumeration arguments can parse those arguments as identifiers, but those 
> identifiers will never be found by usual expression lookup because they don't 
> really exist. That said, any attribute that currently accepts an identifier 
> because it really wants to use that identifier in an expression in Sema 
> should update the attribute argument clauses in Attr.td and make the 
> corresponding changes in SemaDeclAttr.cpp/SemaStmt.cpp/SemaType.cpp as 
> appropriate.

You're exactly right about how it's necessary to parse certain attributes.  
Just to be clear, though, I'm not proposing any change here; I'm describing the 
change that already happened, years ago, by way of trying to identify why this 
particular bit of code was once necessary and thus why it's likely unnecessary 
now.  So I think you will find that those changes to Attr.td are in fact 
already in place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94092

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

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D93747#2481494 , @dblaikie wrote:

> In D93747#2481383 , @hoy wrote:
>
>> In D93747#2481304 , @tmsriram wrote:
>>
>>> In D93747#2481223 , @tmsriram 
>>> wrote:
>>>
 In D93747#2481163 , @dblaikie 
 wrote:

> In D93747#2481095 , @hoy wrote:
>
>> In D93747#2481073 , @dblaikie 
>> wrote:
>>
>>> Suggesting that gdb isn't using the DW_AT_name at all for "break 
>>> " but instead demangling and stripping off the extras 
>>> from the linkage name, and since it can't demangle this uniquified name 
>>> (unlike the mangled name used when using the overloadable attribute) 
>>> that degrades the debugger user experience? I'd have to test that in 
>>> more detail/with some hand-hacked DWARF.
>>
>> Yes, I think in your case the linage name can be demangled by the 
>> debugger. In my previous experiment, the uniquefied names could not be 
>> demangled therefore I was not able to breakpoint.
>
> Ah, did some more testing. Seems it's because it isn't a classically 
> mangled name.
>>>
>>> The simplest fix I can think of is to emit the base 10 number of the 
>>> md5hash.  That would preserve all the existing uniqueness and be demangler 
>>> friendly.  @hoy @dblaikie  WDYT?
>>
>> I think using the base 10 form of md5hash is a smart workaround. Thanks for 
>> the suggestion.
>
> Sure - wouldn't mind having some wording from the Itanium ABI/mangling rules 
> that explain/corroborate what we've seen from testing to ensure we are using 
> it correctly and there aren't any other ways that might be more suitable, or 
> lurking gotchas we haven't tested.

Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
 it is now important that we don't generate 
the DW_AT_linkage_name for C style names using this suffix as it will not 
demangle.  I think this makes it important that we only update this field if it 
already exists.

> It might be possible for this uniquifying step to check if the name is 
> mangled (does it start with "_Z") and if it isn't mangled, it could 
> mangle it (check the length of the name, then "_Zv") and 
> add the unique suffix. That looks to me like it preserves the original 
> debugging behavior?
>
> (has the problem that we don't actually know the mangling scheme at this 
> point - we do know it up in clang (where it might be Itanium mangling or 
> Microsoft mangling), might point again to the possibility this feature is 
> more suitable to implement in the frontend rather than a middle end pass. 
> And also the 'v' in the mangling is 'void return type', which is a lie - 
> not sure if we could do something better there)
>>
>> Doing name unification in the frontend sounds like the ultimate solution and 
>> since the frontend has all the knowledge about the name mangler. I think for 
>> now we can go with the solution @tmsriram suggested, i.e., using the base 10 
>> form of md5 hash.
>
> Any general idea of how long "for now" would be? It doesn't seem like putting 
> this off is going to make things especially better & seems like more bug 
> fixes/changes/etc are being built around the solution as it is at the moment. 
> So I'd be hesitant to put off this kind of restructuring too long.
>
> I think it's pretty important that we don't break tradeoff debuggability 
> for profile accuracy. It'll make for a difficult tradeoff for our/any 
> users.

 Agreed, I didn't expect this.

> (side note: using the original source file name seems problematic - I 
> know in google at least, the same source file is sometimes built into 
> more than one library/form with different preprocessor defines, so this 
> may not produce as unique a name as you are expecting?)

 It was a best effort and I think the hashing can be improved by using more 
 signals other than just the module name if needed.  For hard data though, 
 this does significantly improve performance which clearly comes from 
 better profile attribution so it does something.
>
> I'm OK with the idea that this helped the situation - but it doesn't seem 
> very principled/rigorous. Rather than a sliding scale of "better" I think 
> it'd be worth considering in more detail what would be required to make this 
> correct.
>
> Using the object file name may be more robust - also not perfect for all 
> build systems (one could imagine a distributed build system that /might/ be 
> able to get away with having the distributed builders always build a file 
> named x.o - only to have the distribution system rename the file to its 
> canon

[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D93377#2481957 , 
@hubert.reinterpretcast wrote:

> In D93377#2481312 , @rjmccall wrote:
>
>> Are you committed to the name `__ibm128`?
>
> Insofar as that's what GCC on Power (for example, `gcc (Ubuntu 
> 7.5.0-3ubuntu1~18.04) 7.5.0` from 2017) has shipped with for several years, 
> yes.

Okay, it wasn't clear from the description that this was an already-shipping 
type.  In that case, it's regrettable but obviously just something we have to 
match.


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

https://reviews.llvm.org/D93377

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

[PATCH] D89490: Introduce __attribute__((darwin_abi))

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

I'm not calling Wine a niche use-case, I'm calling this feature a niche 
use-case.  The lack of this feature has not blocked Wine from being a 
successful project.  The feature has to stand on its own and be more broadly 
useful than the momentary convenience of a few developers.

Thinking about it some more, it might be much easier to hack LLVM IR output 
than assembly output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89490

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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra 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/D94123/new/

https://reviews.llvm.org/D94123

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

[PATCH] D93587: [hip] Fix HIP version parsing.

[Michael Liao via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:97
   for (auto Part : VersionParts) {
 auto Splits = Part.split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {

tra wrote:
> `Part.trim().split()` (or, maybe, `rtrim()`if you only care about EOL) would 
> save you trimming in each individual case.
sure, as that file is auto-gen so far, we could simplify the unnecessary 
parsing so far. The EOL is the only issue so far.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

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

[PATCH] D93587: [hip] Fix HIP version parsing.

[Michael Liao via Phabricator via cfe-commits]

hliao updated this revision to Diff 314941.
hliao marked an inline comment as done.
hliao added a comment.

Revise following reviewers' comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/ROCm.h
  clang/test/Driver/Inputs/rocm/bin/.hipVersion


Index: clang/test/Driver/Inputs/rocm/bin/.hipVersion
===
--- clang/test/Driver/Inputs/rocm/bin/.hipVersion
+++ clang/test/Driver/Inputs/rocm/bin/.hipVersion
@@ -1,4 +1,6 @@
 # Auto-generated by cmake
-HIP_VERSION_MAJOR=3
+# NOTE: The trailing whitespace is added on purpose to verify that these
+# whitespaces are trimmed before paring.
+HIP_VERSION_MAJOR=3 
 HIP_VERSION_MINOR=6
 HIP_VERSION_PATCH=20214-a2917cd
Index: clang/lib/Driver/ToolChains/ROCm.h
===
--- clang/lib/Driver/ToolChains/ROCm.h
+++ clang/lib/Driver/ToolChains/ROCm.h
@@ -103,7 +103,7 @@
   }
 
   void scanLibDevicePath(llvm::StringRef Path);
-  void ParseHIPVersionFile(llvm::StringRef V);
+  bool parseHIPVersionFile(llvm::StringRef V);
   SmallVector getInstallationPathCandidates();
 
 public:
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -88,23 +88,30 @@
   }
 }
 
-void RocmInstallationDetector::ParseHIPVersionFile(llvm::StringRef V) {
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {
   SmallVector VersionParts;
   V.split(VersionParts, '\n');
-  unsigned Major;
-  unsigned Minor;
+  unsigned Major = ~0U;
+  unsigned Minor = ~0U;
   for (auto Part : VersionParts) {
-auto Splits = Part.split('=');
-if (Splits.first == "HIP_VERSION_MAJOR")
-  Splits.second.getAsInteger(0, Major);
-else if (Splits.first == "HIP_VERSION_MINOR")
-  Splits.second.getAsInteger(0, Minor);
-else if (Splits.first == "HIP_VERSION_PATCH")
+auto Splits = Part.rtrim().split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {
+  if (Splits.second.getAsInteger(0, Major))
+return true;
+} else if (Splits.first == "HIP_VERSION_MINOR") {
+  if (Splits.second.getAsInteger(0, Minor))
+return true;
+} else if (Splits.first == "HIP_VERSION_PATCH")
   VersionPatch = Splits.second.str();
   }
+  if (Major == ~0U || Minor == ~0U)
+return true;
   VersionMajorMinor = llvm::VersionTuple(Major, Minor);
   DetectedVersion =
   (Twine(Major) + "." + Twine(Minor) + "." + VersionPatch).str();
+  return false;
 }
 
 // For candidate specified by --rocm-path we do not do strict check.
@@ -290,7 +297,8 @@
   continue;
 
 if (HIPVersionArg.empty() && VersionFile)
-  ParseHIPVersionFile((*VersionFile)->getBuffer());
+  if (parseHIPVersionFile((*VersionFile)->getBuffer()))
+continue;
 
 HasHIPRuntime = true;
 return;


Index: clang/test/Driver/Inputs/rocm/bin/.hipVersion
===
--- clang/test/Driver/Inputs/rocm/bin/.hipVersion
+++ clang/test/Driver/Inputs/rocm/bin/.hipVersion
@@ -1,4 +1,6 @@
 # Auto-generated by cmake
-HIP_VERSION_MAJOR=3
+# NOTE: The trailing whitespace is added on purpose to verify that these
+# whitespaces are trimmed before paring.
+HIP_VERSION_MAJOR=3 
 HIP_VERSION_MINOR=6
 HIP_VERSION_PATCH=20214-a2917cd
Index: clang/lib/Driver/ToolChains/ROCm.h
===
--- clang/lib/Driver/ToolChains/ROCm.h
+++ clang/lib/Driver/ToolChains/ROCm.h
@@ -103,7 +103,7 @@
   }
 
   void scanLibDevicePath(llvm::StringRef Path);
-  void ParseHIPVersionFile(llvm::StringRef V);
+  bool parseHIPVersionFile(llvm::StringRef V);
   SmallVector getInstallationPathCandidates();
 
 public:
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -88,23 +88,30 @@
   }
 }
 
-void RocmInstallationDetector::ParseHIPVersionFile(llvm::StringRef V) {
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {
   SmallVector VersionParts;
   V.split(VersionParts, '\n');
-  unsigned Major;
-  unsigned Minor;
+  unsigned Major = ~0U;
+  unsigned Minor = ~0U;
   for (auto Part : VersionParts) {
-auto Splits = Part.split('=');
-if (Splits.first == "HIP_VERSION_MAJOR")
-  Splits.second.getAsInteger(0, Major);
-else if (Splits.first == "HIP_VERSION_MINOR")
-  Splits.second.getAsInteger(0, Minor);
-else if (Spli

[clang] 1ca5e68 - [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[via cfe-commits]

Author: Joseph Huber
Date: 2021-01-06T13:43:22-05:00
New Revision: 1ca5e68aa07e30567c6aa2409c5641e0a2d77355

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

LOG: [NVPTX] Fix debugging information being added to NVPTX target if remarks 
are enabled
Summary:
Optimized debugging is not supported by ptxas. Debugging information is 
degraded to line information only if optimizations are enabled, but debugging 
information would be added back in by the driver if remarks were enabled. This 
solves https://bugs.llvm.org/show_bug.cgi?id=48153.

Reviewers: jdoerfert tra jholewinski serge-sans-paille

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/Cuda.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 917601836c0a..a462758bf1c2 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@ static void RenderDebugOptions(const ToolChain &TC, 
const Driver &D,
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 

diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 58178d5d11bc..95fd5a1fbfee 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@ static DeviceDebugInfoLevel mustEmitDebugInfo(const ArgList 
&Args) {
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation &C, const JobAction &JA,



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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1ca5e68aa07e: [NVPTX] Fix debugging information being added 
to NVPTX target if remarks are… (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

hliao updated this revision to Diff 314943.
hliao added a comment.

Only mark HD attributes in ymath.h wrapper header when compiled with MSVC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

Files:
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/__clang_hip_runtime_wrapper.h
  clang/lib/Headers/cuda_wrappers/ymath.h


Index: clang/lib/Headers/cuda_wrappers/ymath.h
===
--- /dev/null
+++ clang/lib/Headers/cuda_wrappers/ymath.h
@@ -0,0 +1,28 @@
+/*=== ymath.h - HIP wrapper for  --===
+ *
+ * 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 __CLANG_CUDA_WRAPPERS_YMATH_H
+#define __CLANG_CUDA_WRAPPERS_YMATH_H
+
+// Wrapper around  that forces its functions to be __host__
+// __device__.
+
+// Only mark HD when compiled with MSVC as `ymath.h` may be an ordinary user
+// header.
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device begin
+#endif // defined(_MSC_VER)
+
+#include_next 
+
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device end
+#endif // defined(_MSC_VER)
+
+#endif // include guard
Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -61,6 +61,28 @@
 #include 
 #include 
 #include 
+
+// Define math functions from  on MSVC for the device compilation
+// only to avoid conflicts with MSVC runtime in the host compilation.
+#if defined(_MSC_VER) && defined(__HIP_DEVICE_COMPILE__)
+#if defined(__cplusplus)
+extern "C" {
+#endif // defined(__cplusplus)
+#pragma push_macro("__HOST_DEVICE__")
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }
+__HOST_DEVICE__ short _Dtest(double *p) { return fpclassify(*p); }
+__HOST_DEVICE__ short _FDtest(float *p) { return fpclassify(*p); }
+__HOST_DEVICE__ double _Sinh(double x, double y) { return sinh(x) * y; }
+__HOST_DEVICE__ float _FSinh(float x, float y) { return sinhf(x) * y; }
+#pragma pop_macro("__HOST_DEVICE__")
+#if defined(__cplusplus)
+}
+#endif // defined(__cplusplus)
+#endif // defined(_MSC_VER) && defined(__HIP_DEVICE_COMPILE__)
+
 #endif // !_OPENMP || __HIP_ENABLE_CUDA_WRAPPER_FOR_OPENMP__
 
 #define __CLANG_HIP_RUNTIME_WRAPPER_INCLUDED__ 1
Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -142,6 +142,7 @@
   cuda_wrappers/algorithm
   cuda_wrappers/complex
   cuda_wrappers/new
+  cuda_wrappers/ymath.h
 )
 
 set(ppc_wrapper_files


Index: clang/lib/Headers/cuda_wrappers/ymath.h
===
--- /dev/null
+++ clang/lib/Headers/cuda_wrappers/ymath.h
@@ -0,0 +1,28 @@
+/*=== ymath.h - HIP wrapper for  --===
+ *
+ * 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 __CLANG_CUDA_WRAPPERS_YMATH_H
+#define __CLANG_CUDA_WRAPPERS_YMATH_H
+
+// Wrapper around  that forces its functions to be __host__
+// __device__.
+
+// Only mark HD when compiled with MSVC as `ymath.h` may be an ordinary user
+// header.
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device begin
+#endif // defined(_MSC_VER)
+
+#include_next 
+
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device end
+#endif // defined(_MSC_VER)
+
+#endif // include guard
Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -61,6 +61,28 @@
 #include 
 #include 
 #include 
+
+// Define math functions from  on MSVC for the device compilation
+// only to avoid conflicts with MSVC runtime in the host compilation.
+#if defined(_MSC_VER) && defined(__HIP_DEVICE_COMPILE__)
+#if defined(__cplusplus)
+extern "C" {
+#endif // defined(__cplusplus)
+#pragma push_macro("__HOST_DEVICE__")
+#define __HOST_DEVICE__\
+  static __host__ __device__ inlin

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

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



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

tra wrote:
> I don't think we want to provide a HD implementation.
> This will potentially change the meaning of these functions on the host side 
> vs what they do in a C++ compilation.
> It should probably be just `__device__`.
> 
> Next question is -- do we want to provide the definitions, or would just 
> declarations be sufficient?
> In other words -- are these functions needed for some standard C++ library 
> functionality that we expect to work on the GPU?
> If it's just to aid with overload resolution, declarations should do. 
> 
These functions are declared in ymath.h and, in the host compilation, are 
resolved by linking MSVC RT libraries. For the device function, as we already 
mark all prototypes in ymath.h as HD, we have to implement them as HD to match 
the declaration. But, those definitions should be only available in the device 
compilation to avoid conflicts in the host compilation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

If you use `arc diff`, you can obtain `Reviewed-by:` line from Phabricator. It 
is more useful than `Reviewers: `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D94123#2482636 , @MaskRay wrote:

> If you use `arc diff`, you can obtain `Reviewed-by:` line from Phabricator. 
> It is more useful than `Reviewers: ` (a list of reviewers do not mean they 
> endorse or accept the patch)

`arc land`  did work, now it is `arc land --onto main`, but it does these 
things for you. I like it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

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

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

hliao wrote:
> tra wrote:
> > I don't think we want to provide a HD implementation.
> > This will potentially change the meaning of these functions on the host 
> > side vs what they do in a C++ compilation.
> > It should probably be just `__device__`.
> > 
> > Next question is -- do we want to provide the definitions, or would just 
> > declarations be sufficient?
> > In other words -- are these functions needed for some standard C++ library 
> > functionality that we expect to work on the GPU?
> > If it's just to aid with overload resolution, declarations should do. 
> > 
> These functions are declared in ymath.h and, in the host compilation, are 
> resolved by linking MSVC RT libraries. For the device function, as we already 
> mark all prototypes in ymath.h as HD, we have to implement them as HD to 
> match the declaration. But, those definitions should be only available in the 
> device compilation to avoid conflicts in the host compilation.
You don't need the definitions to avoid conflicting declarations.

I'm still not convinced that HD is needed.
Did you try just making these declarations `__device__` and remove the 
`ymath.h` wrapper?
Basically I'm trying to find the bare minimum we need to do to make it work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D94185: [OpenMP][Docs] Mark finished features as done

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added a reviewer: ABataev.
Herald added subscribers: guansong, bollu, yaxunl.
jdoerfert requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94185

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -193,7 +193,7 @@
 
+--+--+--+---+
 | device extension | implicitly map 'this' (this[:1])  
   | :good:`done` | D55982  
  |
 
+--+--+--+---+
-| device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`worked on`|   
|
+| device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`done` |   
|
 
+--+--+--+---+
 | device extension | requires directive
   | :part:`partial`  | 
  |
 
+--+--+--+---+
@@ -215,7 +215,7 @@
 
+--+--+--+---+
 | device extension | support close modifier on map clause  
   | :good:`done` | D55719,D55892   
  |
 
+--+--+--+---+
-| device extension | teams construct on the host device
   | :part:`worked on`| Clang part is done, r371553.
  |
+| device extension | teams construct on the host device
   | :part:`done` | r371553 
  |
 
+--+--+--+---+
 | device extension | support non-contiguous array sections for 
target update  | :good:`done` | 
  |
 
+--+--+--+---+


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -193,7 +193,7 @@
 +--+--+--+---+
 | device extension | implicitly map 'this' (this[:1]) | :good:`done` | D55982|
 +--+--+--+---+
-| device extension | allow access to the reference count (omp_target_is_present)  | :part:`worked on`|   |
+| device extension | allow access to the reference count (omp_target_is_present)  | :part:`done` |   |
 +--+--+--

[PATCH] D93428: [AArch64] Add bti note property when compiling asm files with -mbranch-protection=bti

[Ana Pazos via Phabricator via cfe-commits]

apazos added a comment.

Can you confirm when the GNU toolchain will have this flag supported in their 
assembler? Compatibility between LLVM and GNU toolchains is important.

Stephen - I think we can abandon this review. Users will need to be made aware 
of this additional assembler flag when building .s files with BTI enabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93428

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

[PATCH] D93668: [clang] Add -ffuchsia-c++-abi flag to explicitly use the Fuchsia C++ ABI

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

Generally makes sense, but I had a concern.




Comment at: clang/include/clang/Basic/LangOptions.h:333
+  /// the -ffuchsia-c++-abi flag.
+  bool UseFuchsiaCXXABI;
+

Why isn't this part of the LangOptions.def xmacro list?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668

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

[PATCH] D93587: [hip] Fix HIP version parsing.

[Artem Belevich via Phabricator via cfe-commits]

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

LGTM overall.




Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:92
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {

It still does not desribe what we expect to see in that file.
E.g.:
```
HIP_VERSION_MAJOR=1
HIP_VERSION_MINOR=2
HIP_VERSION_PATCH=3
```



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:100
+auto Splits = Part.rtrim().split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {
+  if (Splits.second.getAsInteger(0, Major))

Perhaps we could use StringSwitch here:

```
  int &Value = llvm::StringSwitch(Splits.first)
  .Case("HIP_VERSION_MAJOR", Major)
  .Case("HIP_VERSION_MINOR", Minor)
  .Case("HIP_VERSION_PATCH", VersionPatch)
  if (Splits.second.getAsInteger(0, Value))
return true;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

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

[PATCH] D94185: [OpenMP][Docs] Mark finished features as done

[Alexey Bataev via Phabricator via cfe-commits]

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

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94185

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

[PATCH] D94186: [FPEnv][PowerPC] Platform builtins edition: clang should get from the AST the metadata for constrained FP builtins

[Kevin P. Neal via Phabricator via cfe-commits]

kpn created this revision.
kpn added reviewers: steven.zhang, nemanjai.
kpn added a project: clang.
Herald added subscribers: shchenz, kbarton.
kpn requested review of this revision.
Herald added a subscriber: cfe-commits.

Currently clang is not correctly retrieving from the AST the metadata for 
constrained FP builtins. This patch fixes that for the PowerPC specific 
builtins.

For previous work in this vein see D92122  for 
example.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94186

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-fma.c
  clang/test/CodeGen/builtins-ppc-fpconstrained.c

Index: clang/test/CodeGen/builtins-ppc-fpconstrained.c
===
--- clang/test/CodeGen/builtins-ppc-fpconstrained.c
+++ clang/test/CodeGen/builtins-ppc-fpconstrained.c
@@ -2,16 +2,23 @@
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
 // RUN: -emit-llvm %s -o - | FileCheck --check-prefix=CHECK-UNCONSTRAINED %s
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
-// RUN:  -ffp-exception-behavior=strict -emit-llvm %s -o - | FileCheck \
-// RUN: --check-prefix=CHECK-CONSTRAINED -vv %s
+// RUN:  -ffp-exception-behavior=maytrap -DSTRICT=1 -emit-llvm %s -o - | \
+// RUN: FileCheck --check-prefix=CHECK-CONSTRAINED -vv %s
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
 // RUN: -fallow-half-arguments-and-returns -S -o - %s | \
 // RUN: FileCheck --check-prefix=CHECK-ASM --check-prefix=NOT-FIXME-CHECK  %s
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
-// RUN: -fallow-half-arguments-and-returns -S -ffp-exception-behavior=strict \
-// RUN: -o - %s | FileCheck --check-prefix=CHECK-ASM \
+// RUN: -fallow-half-arguments-and-returns -S -ffp-exception-behavior=maytrap \
+// RUN: -DSTRICT=1 -o - %s | FileCheck --check-prefix=CHECK-ASM \
 // RUN: --check-prefix=FIXME-CHECK  %s
 
+#ifdef STRICT
+// Test that the constrained intrinsics are picking up the exception
+// metadata from the AST instead of the global default from the command line.
+
+#pragma float_control(except, on)
+#endif
+
 typedef __attribute__((vector_size(4 * sizeof(float float vec_float;
 typedef __attribute__((vector_size(2 * sizeof(double double vec_double;
 
Index: clang/test/CodeGen/builtins-ppc-fma.c
===
--- clang/test/CodeGen/builtins-ppc-fma.c
+++ clang/test/CodeGen/builtins-ppc-fma.c
@@ -1,6 +1,17 @@
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux \
-// RUN: -target-feature +altivec -Wall -Wno-unused -Werror -emit-llvm %s -o - | FileCheck  \
+// RUN: -target-feature +altivec -Wall -Wno-unused -Werror -emit-llvm %s -o - | FileCheck --check-prefix=NOSTRICT --check-prefix=SHARED\
 // RUN: %s
+// RUN: %clang_cc1 -triple powerpc64le-gnu-linux \
+// RUN: -ffp-exception-behavior=maytrap -DSTRICT=1 \
+// RUN: -target-feature +altivec -Wall -Wno-unused -Werror -emit-llvm %s -o - | FileCheck --check-prefix=STRICT --check-prefix=SHARED\
+// RUN: %s
+
+#ifdef STRICT
+// Test that the constrained intrinsics are picking up the exception
+// metadata from the AST instead of the global default from the command line.
+
+#pragma float_control(except, on)
+#endif
 
 typedef __attribute__((vector_size(4 * sizeof(float float vec_float;
 typedef __attribute__((vector_size(2 * sizeof(double double vec_double;
@@ -10,34 +21,42 @@
 
 void test_fma(void) {
   vf = __builtin_vsx_xvmaddasp(vf, vf, vf);
-  // CHECK: @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
+  // NOSTRICT: @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
+  // STRICT: @llvm.experimental.constrained.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
 
   vd = __builtin_vsx_xvmaddadp(vd, vd, vd);
-  // CHECK: @llvm.fma.v2f64(<2 x double> %{{.*}}, <2 x double> %{{.*}}, <2 x double> %{{.*}})
+  // NOSTRICT: @llvm.fma.v2f64(<2 x double> %{{.*}}, <2 x double> %{{.*}}, <2 x double> %{{.*}})
+  // STRICT: @llvm.experimental.constrained.fma.v2f64(<2 x double> %{{.*}}, <2 x double> %{{.*}}, <2 x double> %{{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
 
   vf = __builtin_vsx_xvnmaddasp(vf, vf, vf);
-  // CHECK: [[RESULT:%[^ ]+]] = call <4 x float> @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
-  // CHECK: fneg <4 x float> [[RESULT]]
+  // NOSTRICT: [[RESULT:%[^ ]+]] = call <4 x float> @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
+  // STRICT: [[RESULT:%[^ ]+]] = call <4 x float> @llvm.experimental.constrained.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
+  // SHARED: fneg <4 x float> [[RESULT]]
 

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D93747#2482519 , @tmsriram wrote:

> In D93747#2481494 , @dblaikie wrote:
>
>> In D93747#2481383 , @hoy wrote:
>>
>>> In D93747#2481304 , @tmsriram 
>>> wrote:
>>>
 In D93747#2481223 , @tmsriram 
 wrote:

> In D93747#2481163 , @dblaikie 
> wrote:
>
>> In D93747#2481095 , @hoy wrote:
>>
>>> In D93747#2481073 , @dblaikie 
>>> wrote:
>>>
 Suggesting that gdb isn't using the DW_AT_name at all for "break 
 " but instead demangling and stripping off the extras 
 from the linkage name, and since it can't demangle this uniquified 
 name (unlike the mangled name used when using the overloadable 
 attribute) that degrades the debugger user experience? I'd have to 
 test that in more detail/with some hand-hacked DWARF.
>>>
>>> Yes, I think in your case the linage name can be demangled by the 
>>> debugger. In my previous experiment, the uniquefied names could not be 
>>> demangled therefore I was not able to breakpoint.
>>
>> Ah, did some more testing. Seems it's because it isn't a classically 
>> mangled name.

 The simplest fix I can think of is to emit the base 10 number of the 
 md5hash.  That would preserve all the existing uniqueness and be demangler 
 friendly.  @hoy @dblaikie  WDYT?
>>>
>>> I think using the base 10 form of md5hash is a smart workaround. Thanks for 
>>> the suggestion.
>>
>> Sure - wouldn't mind having some wording from the Itanium ABI/mangling rules 
>> that explain/corroborate what we've seen from testing to ensure we are using 
>> it correctly and there aren't any other ways that might be more suitable, or 
>> lurking gotchas we haven't tested.
>
> Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
>  it is now important that we don't generate 
> the DW_AT_linkage_name for C style names using this suffix as it will not 
> demangle.  I think this makes it important that we only update this field if 
> it already exists.

Yes, it makes sense to do the renaming only if the linkage name preexists to 
not break the debuggability. Unfortunately we won't be able to support C with 
this patch.

>> It might be possible for this uniquifying step to check if the name is 
>> mangled (does it start with "_Z") and if it isn't mangled, it could 
>> mangle it (check the length of the name, then "_Zv") and 
>> add the unique suffix. That looks to me like it preserves the original 
>> debugging behavior?
>>
>> (has the problem that we don't actually know the mangling scheme at this 
>> point - we do know it up in clang (where it might be Itanium mangling or 
>> Microsoft mangling), might point again to the possibility this feature 
>> is more suitable to implement in the frontend rather than a middle end 
>> pass. And also the 'v' in the mangling is 'void return type', which is a 
>> lie - not sure if we could do something better there)
>>>
>>> Doing name unification in the frontend sounds like the ultimate solution 
>>> and since the frontend has all the knowledge about the name mangler. I 
>>> think for now we can go with the solution @tmsriram suggested, i.e., using 
>>> the base 10 form of md5 hash.
>>
>> Any general idea of how long "for now" would be? It doesn't seem like 
>> putting this off is going to make things especially better & seems like more 
>> bug fixes/changes/etc are being built around the solution as it is at the 
>> moment. So I'd be hesitant to put off this kind of restructuring too long.

I'm not sure. It looks like implementation in the front end has more complexity 
as discussed in the other thread D94154 .

>> I think it's pretty important that we don't break tradeoff debuggability 
>> for profile accuracy. It'll make for a difficult tradeoff for our/any 
>> users.
>
> Agreed, I didn't expect this.
>
>> (side note: using the original source file name seems problematic - I 
>> know in google at least, the same source file is sometimes built into 
>> more than one library/form with different preprocessor defines, so this 
>> may not produce as unique a name as you are expecting?)
>
> It was a best effort and I think the hashing can be improved by using 
> more signals other than just the module name if needed.  For hard data 
> though, this does significantly improve performance which clearly comes 
> from better profile attribution so it does something.
>>
>> I'm OK with the idea that this helped the situation - but it 

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Hongtao Yu via Phabricator via cfe-commits]

hoy updated this revision to Diff 314955.
hoy added a comment.

Renaming debug linkage name if it preexisits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

Files:
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll

Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
+++ llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
@@ -3,8 +3,10 @@
 ; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
 ; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
 ; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes=unique-internal-linkage-names -unqiue-debug-linkage-names=0 < %s -o - | FileCheck %s --check-prefix=NODBG
+; RUN: opt -S -passes=unique-internal-linkage-names < %s -o - | FileCheck %s --check-prefix=DBG
 
-define internal i32 @foo() {
+define internal i32 @foo() !dbg !15 {
 entry:
   ret i32 0
 }
@@ -14,6 +16,27 @@
   ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*)
 }
 
+define internal i32 @go() !dbg !19 {
+entry:
+  ret i32 0
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!15 = distinct !DISubprogram(name: "foo", linkageName: "foo", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!13}
+!18 = !DISubprogram(name: "foo", linkageName: "foo", scope: !1, isDefinition: false, flags: DIFlagPrototyped, spFlags: DISPFlagOptimized)
+!19 = distinct !DISubprogram(name: "go", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+
 ; O0: Running pass: UniqueInternalLinkageNamesPass
 
 ;; Check UniqueInternalLinkageNamesPass is scheduled before SampleProfileProbePass.
@@ -22,3 +45,11 @@
 
 ; UNIQUE: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
 ; UNIQUE: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
+
+; NODBG: distinct !DISubprogram(name: "foo", linkageName: "foo", scope: ![[#]]
+; NODBG: !DISubprogram(name: "foo", linkageName: "foo", scope: ![[#]]
+; NODBG: distinct !DISubprogram(name: "go", scope: ![[#]]
+
+; DBG: distinct !DISubprogram(name: "foo", linkageName: "foo.__uniq.{{[0-9a-f]+}}", scope: ![[#]]
+; DBG: !DISubprogram(name: "foo", linkageName: "foo.__uniq.{{[0-9a-f]+}}", scope: ![[#]]
+; DBG: distinct !DISubprogram(name: "go", scope: ![[#]]
Index: llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
===
--- llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -13,13 +13,21 @@
 
 #include "llvm/Transforms/Utils/UniqueInternalLinkageNames.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/IR/DebugInfoMetadata.h"
+#include "llvm/IR/MDBuilder.h"
 #include "llvm/IR/Module.h"
 #include "llvm/InitializePasses.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 
 using namespace llvm;
 
+static cl::opt
+UniqueDebugLinakgeNames("unqiue-debug-linkage-names", cl::init(true),
+cl::Hidden,
+cl::desc("Uniqueify debug linkage Names"));
+
 static bool uniqueifyInternalLinkageNames(Module &M) {
   llvm::MD5 Md5;
   Md5.update(M.getSourceFileName());
@@ -31,11 +39,25 @@
   // this symbol is of internal linkage type.
   std::string ModuleNameHash = (Twine(".__uniq.") + Twine(Str)).str();
   bool Changed = false;
+  MDBuilder MDB(M.getContext());
 
   // Append the module hash to all internal linkage functions.
   for (auto &F : M) {
 if (F.hasInternalLinkage()) {
   F.setName(F.getName() + ModuleNameHash);
+  // Replace linkage names in the debug metadata.
+  if (UniqueDebugLinakgeNames) {
+if (DISubprogram *SP = 

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D93747#2482726 , @hoy wrote:

> In D93747#2482519 , @tmsriram wrote:
>
>> In D93747#2481494 , @dblaikie wrote:
>>
>>> In D93747#2481383 , @hoy wrote:
>>>
 In D93747#2481304 , @tmsriram 
 wrote:

> In D93747#2481223 , @tmsriram 
> wrote:
>
>> In D93747#2481163 , @dblaikie 
>> wrote:
>>
>>> In D93747#2481095 , @hoy wrote:
>>>
 In D93747#2481073 , @dblaikie 
 wrote:

> Suggesting that gdb isn't using the DW_AT_name at all for "break 
> " but instead demangling and stripping off the extras 
> from the linkage name, and since it can't demangle this uniquified 
> name (unlike the mangled name used when using the overloadable 
> attribute) that degrades the debugger user experience? I'd have to 
> test that in more detail/with some hand-hacked DWARF.

 Yes, I think in your case the linage name can be demangled by the 
 debugger. In my previous experiment, the uniquefied names could not be 
 demangled therefore I was not able to breakpoint.
>>>
>>> Ah, did some more testing. Seems it's because it isn't a classically 
>>> mangled name.
>
> The simplest fix I can think of is to emit the base 10 number of the 
> md5hash.  That would preserve all the existing uniqueness and be 
> demangler friendly.  @hoy @dblaikie  WDYT?

 I think using the base 10 form of md5hash is a smart workaround. Thanks 
 for the suggestion.
>>>
>>> Sure - wouldn't mind having some wording from the Itanium ABI/mangling 
>>> rules that explain/corroborate what we've seen from testing to ensure we 
>>> are using it correctly and there aren't any other ways that might be more 
>>> suitable, or lurking gotchas we haven't tested.
>>
>> Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
>>  it is now important that we don't generate 
>> the DW_AT_linkage_name for C style names using this suffix as it will not 
>> demangle.  I think this makes it important that we only update this field if 
>> it already exists.
>
> Yes, it makes sense to do the renaming only if the linkage name preexists to 
> not break the debuggability. Unfortunately we won't be able to support C with 
> this patch.

There is nothing needed to support C right?  overloadable attribute will mangle 
with _Z so it will work as expected?  What did I miss?

>>> It might be possible for this uniquifying step to check if the name is 
>>> mangled (does it start with "_Z") and if it isn't mangled, it could 
>>> mangle it (check the length of the name, then "_Zv") and 
>>> add the unique suffix. That looks to me like it preserves the original 
>>> debugging behavior?
>>>
>>> (has the problem that we don't actually know the mangling scheme at 
>>> this point - we do know it up in clang (where it might be Itanium 
>>> mangling or Microsoft mangling), might point again to the possibility 
>>> this feature is more suitable to implement in the frontend rather than 
>>> a middle end pass. And also the 'v' in the mangling is 'void return 
>>> type', which is a lie - not sure if we could do something better there)

 Doing name unification in the frontend sounds like the ultimate solution 
 and since the frontend has all the knowledge about the name mangler. I 
 think for now we can go with the solution @tmsriram suggested, i.e., using 
 the base 10 form of md5 hash.
>>>
>>> Any general idea of how long "for now" would be? It doesn't seem like 
>>> putting this off is going to make things especially better & seems like 
>>> more bug fixes/changes/etc are being built around the solution as it is at 
>>> the moment. So I'd be hesitant to put off this kind of restructuring too 
>>> long.
>
> I'm not sure. It looks like implementation in the front end has more 
> complexity as discussed in the other thread D94154 
> .
>
>>> I think it's pretty important that we don't break tradeoff 
>>> debuggability for profile accuracy. It'll make for a difficult tradeoff 
>>> for our/any users.
>>
>> Agreed, I didn't expect this.
>>
>>> (side note: using the original source file name seems problematic - I 
>>> know in google at least, the same source file is sometimes built into 
>>> more than one library/form with different preprocessor defines, so this 
>>> may not produce as unique a name as you are expecting?)
>>
>> It was a best effort and I think

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D93747#2482730 , @tmsriram wrote:

> In D93747#2482726 , @hoy wrote:
>
>> In D93747#2482519 , @tmsriram wrote:
>>
>>> In D93747#2481494 , @dblaikie 
>>> wrote:
>>>
 In D93747#2481383 , @hoy wrote:

> In D93747#2481304 , @tmsriram 
> wrote:
>
>> In D93747#2481223 , @tmsriram 
>> wrote:
>>
>>> In D93747#2481163 , @dblaikie 
>>> wrote:
>>>
 In D93747#2481095 , @hoy 
 wrote:

> In D93747#2481073 , 
> @dblaikie wrote:
>
>> Suggesting that gdb isn't using the DW_AT_name at all for "break 
>> " but instead demangling and stripping off the extras 
>> from the linkage name, and since it can't demangle this uniquified 
>> name (unlike the mangled name used when using the overloadable 
>> attribute) that degrades the debugger user experience? I'd have to 
>> test that in more detail/with some hand-hacked DWARF.
>
> Yes, I think in your case the linage name can be demangled by the 
> debugger. In my previous experiment, the uniquefied names could not 
> be demangled therefore I was not able to breakpoint.

 Ah, did some more testing. Seems it's because it isn't a classically 
 mangled name.
>>
>> The simplest fix I can think of is to emit the base 10 number of the 
>> md5hash.  That would preserve all the existing uniqueness and be 
>> demangler friendly.  @hoy @dblaikie  WDYT?
>
> I think using the base 10 form of md5hash is a smart workaround. Thanks 
> for the suggestion.

 Sure - wouldn't mind having some wording from the Itanium ABI/mangling 
 rules that explain/corroborate what we've seen from testing to ensure we 
 are using it correctly and there aren't any other ways that might be more 
 suitable, or lurking gotchas we haven't tested.
>>>
>>> Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
>>>  it is now important that we don't 
>>> generate the DW_AT_linkage_name for C style names using this suffix as it 
>>> will not demangle.  I think this makes it important that we only update 
>>> this field if it already exists.
>>
>> Yes, it makes sense to do the renaming only if the linkage name preexists to 
>> not break the debuggability. Unfortunately we won't be able to support C 
>> with this patch.
>
> There is nothing needed to support C right?  overloadable attribute will 
> mangle with _Z so it will work as expected?  What did I miss?

I mean from the AutoFDO point of view, C programs with static functions are not 
getting the unique debug name support.

 It might be possible for this uniquifying step to check if the name is 
 mangled (does it start with "_Z") and if it isn't mangled, it could 
 mangle it (check the length of the name, then "_Zv") and 
 add the unique suffix. That looks to me like it preserves the original 
 debugging behavior?

 (has the problem that we don't actually know the mangling scheme at 
 this point - we do know it up in clang (where it might be Itanium 
 mangling or Microsoft mangling), might point again to the possibility 
 this feature is more suitable to implement in the frontend rather than 
 a middle end pass. And also the 'v' in the mangling is 'void return 
 type', which is a lie - not sure if we could do something better there)
>
> Doing name unification in the frontend sounds like the ultimate solution 
> and since the frontend has all the knowledge about the name mangler. I 
> think for now we can go with the solution @tmsriram suggested, i.e., 
> using the base 10 form of md5 hash.

 Any general idea of how long "for now" would be? It doesn't seem like 
 putting this off is going to make things especially better & seems like 
 more bug fixes/changes/etc are being built around the solution as it is at 
 the moment. So I'd be hesitant to put off this kind of restructuring too 
 long.
>>
>> I'm not sure. It looks like implementation in the front end has more 
>> complexity as discussed in the other thread D94154 
>> .
>>
 I think it's pretty important that we don't break tradeoff 
 debuggability for profile accuracy. It'll make for a difficult 
 tradeoff for our/any users.
>>>
>>> Agreed, I didn't expect this.
>>>
 (side note: using the original so

[clang-tools-extra] 0bfe100 - [NFC] Test case refactor

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2021-01-06T20:00:15Z
New Revision: 0bfe100145634988e4a914da776b55509ba0bec0

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

LOG: [NFC] Test case refactor

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index a51067896432..c87c1be6f8e9 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -1042,7 +1042,7 @@ TEST_F(TUSchedulerTests, CommandLineWarnings) {
 
 TEST(DebouncePolicy, Compute) {
   namespace c = std::chrono;
-  std::vector History = {
+  DebouncePolicy::clock::duration History[] = {
   c::seconds(0),
   c::seconds(5),
   c::seconds(10),
@@ -1053,8 +1053,9 @@ TEST(DebouncePolicy, Compute) {
   Policy.Max = c::seconds(25);
   // Call Policy.compute(History) and return seconds as a float.
   auto Compute = [&](llvm::ArrayRef History) {
-using FloatingSeconds = c::duration;
-return static_cast(Policy.compute(History) / FloatingSeconds(1));
+return c::duration_cast>(
+   Policy.compute(History))
+.count();
   };
   EXPECT_NEAR(10, Compute(History), 0.01) << "(upper) median = 10";
   Policy.RebuildRatio = 1.5;



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

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

We bisected a test failure to this 
(https://bugs.chromium.org/p/angleproject/issues/detail?id=5500#c17). Can you 
expand a bit on what this patch means in practice? I'm guessing it makes UB in 
C++ code have bad effects more often? If so, what type of UB?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92270

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

[PATCH] D92954: [clang-offload-bundler] Add option -list

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked 4 inline comments as done.
yaxunl added inline comments.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:176
+  /// List bundle IDs in \a Input.
+  virtual Error listBundleIDs(MemoryBuffer &Input) {
+if (Error Err = ReadHeader(Input))

tra wrote:
> Now that listBundleIDs is only used by ` ListBundleIDsInFile()`, perhaps it 
> could all be simplified and moved out of the class.
listBundleIDsCallback needs to be a virtual function and it is called by 
listBundleIDs. Keep listBundleIDs as a member function together with 
listBundleIDsCallback shows their relation and is more readable.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:882
+// List bundle IDs. Return true if an error was found.
+static Error ListBundleIDsInFile() {
+  // Open Input file.

tra wrote:
> I'd pass InputFileNames as an argument. Makes it easier to tell what the 
> function needs.
done



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:1031-1035
+  Error = true;
+  reportError(createStringError(
+  errc::invalid_argument,
+  "for the --outputs option: must be specified at least once!"));
+}

tra wrote:
> Does it make sense to continue once we know that CLI options are wrong?
> If we just early-exit with an error that may help simplifying the code below 
> a bit.
> 
> 
done



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:1047
+errc::invalid_argument, "-unbundle and -list cannot be used 
together"));
+  } else if (ListBundleIDs) {
+if (InputFileNames.size() != 1) {

tra wrote:
> Perhaps we can separate list option processing from bundle/unbundle?
> 
> I think if we could do something like this it would be more readable:
> ```
> if (ListBundleIDs) {
>   if (Unbundle) {
> error...
> exit.
>   }
>   ... other list-specific checks...
>   ListBundleIDsInFile(InputFileNames)
>   exit 0;
> }
> 
> // complicated bundle/unbundle logic can proceed without having to bother 
> about `list` option.
> ```
done


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

https://reviews.llvm.org/D92954

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

[PATCH] D92954: [clang-offload-bundler] Add option -list

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 314957.
yaxunl marked 4 inline comments as done.
yaxunl added a comment.

revised by Artem's comments


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

https://reviews.llvm.org/D92954

Files:
  clang/test/Driver/clang-offload-bundler.c
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -63,11 +63,11 @@
cl::desc("[,...]"),
cl::cat(ClangOffloadBundlerCategory));
 static cl::list
-OutputFileNames("outputs", cl::CommaSeparated, cl::OneOrMore,
+OutputFileNames("outputs", cl::CommaSeparated,
 cl::desc("[,...]"),
 cl::cat(ClangOffloadBundlerCategory));
 static cl::list
-TargetNames("targets", cl::CommaSeparated, cl::OneOrMore,
+TargetNames("targets", cl::CommaSeparated,
 cl::desc("[-,...]"),
 cl::cat(ClangOffloadBundlerCategory));
 static cl::opt
@@ -90,6 +90,10 @@
  cl::desc("Unbundle bundled file into several output files.\n"),
  cl::init(false), cl::cat(ClangOffloadBundlerCategory));
 
+static cl::opt
+ListBundleIDs("list", cl::desc("List bundle IDs in the bundled file.\n"),
+  cl::init(false), cl::cat(ClangOffloadBundlerCategory));
+
 static cl::opt PrintExternalCommands(
 "###",
 cl::desc("Print any external commands that are to be executed "
@@ -134,6 +138,10 @@
 /// Generic file handler interface.
 class FileHandler {
 public:
+  struct BundleInfo {
+StringRef BundleID;
+  };
+
   FileHandler() {}
 
   virtual ~FileHandler() {}
@@ -170,6 +178,48 @@
 
   /// Write the bundle from \a Input into \a OS.
   virtual Error WriteBundle(raw_fd_ostream &OS, MemoryBuffer &Input) = 0;
+
+  /// List bundle IDs in \a Input.
+  virtual Error listBundleIDs(MemoryBuffer &Input) {
+if (Error Err = ReadHeader(Input))
+  return Err;
+
+return forEachBundle(Input, [&](const BundleInfo &Info) -> Error {
+  llvm::outs() << Info.BundleID << '\n';
+  Error Err = listBundleIDsCallback(Input, Info);
+  if (Err)
+return Err;
+  return Error::success();
+});
+  }
+
+  /// For each bundle in \a Input, do \a Func.
+  Error forEachBundle(MemoryBuffer &Input,
+  std::function Func) {
+while (true) {
+  Expected> CurTripleOrErr = ReadBundleStart(Input);
+  if (!CurTripleOrErr)
+return CurTripleOrErr.takeError();
+
+  // No more bundles.
+  if (!*CurTripleOrErr)
+break;
+
+  StringRef CurTriple = **CurTripleOrErr;
+  assert(!CurTriple.empty());
+
+  BundleInfo Info{CurTriple};
+  if (Error Err = Func(Info))
+return Err;
+}
+return Error::success();
+  }
+
+protected:
+  virtual Error listBundleIDsCallback(MemoryBuffer &Input,
+  const BundleInfo &Info) {
+return Error::success();
+  }
 };
 
 /// Handler for binary files. The bundled file will have the following format
@@ -219,22 +269,23 @@
 
 class BinaryFileHandler final : public FileHandler {
   /// Information about the bundles extracted from the header.
-  struct BundleInfo final {
+  struct BinaryBundleInfo final : public BundleInfo {
 /// Size of the bundle.
 uint64_t Size = 0u;
 /// Offset at which the bundle starts in the bundled file.
 uint64_t Offset = 0u;
 
-BundleInfo() {}
-BundleInfo(uint64_t Size, uint64_t Offset) : Size(Size), Offset(Offset) {}
+BinaryBundleInfo() {}
+BinaryBundleInfo(uint64_t Size, uint64_t Offset)
+: Size(Size), Offset(Offset) {}
   };
 
   /// Map between a triple and the corresponding bundle information.
-  StringMap BundlesInfo;
+  StringMap BundlesInfo;
 
   /// Iterator for the bundle information that is being read.
-  StringMap::iterator CurBundleInfo;
-  StringMap::iterator NextBundleInfo;
+  StringMap::iterator CurBundleInfo;
+  StringMap::iterator NextBundleInfo;
 
   /// Current bundle target to be written.
   std::string CurWriteBundleTarget;
@@ -304,7 +355,7 @@
 
   assert(BundlesInfo.find(Triple) == BundlesInfo.end() &&
  "Triple is duplicated??");
-  BundlesInfo[Triple] = BundleInfo(Size, Offset);
+  BundlesInfo[Triple] = BinaryBundleInfo(Size, Offset);
 }
 // Set the iterator to where we will start to read.
 CurBundleInfo = BundlesInfo.end();
@@ -358,7 +409,7 @@
   Write8byteIntegerToBuffer(OS, HeaderSize);
   // Size of the bundle (adds to the next bundle's offset)
   Write8byteIntegerToBuffer(OS, MB.getBufferSize());
-  BundlesInfo[T] = BundleInfo(MB.getBufferSize(), HeaderSize);
+  BundlesInfo[T] = BinaryBundleInfo(MB.getBufferSize(), HeaderSize);
   HeaderSize += MB.getBufferS

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

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

dexonsmith added inline comments.



Comment at: clang/include/clang/Driver/Options.td:1193-1195
+defm caret_diagnostics : BoolFOption<"caret-diagnostics",
+  "DiagnosticOpts->ShowCarets", DefaultsToTrue,
+  ChangedBy, ResetBy>, IsDiag;

There was one thing in the original patch that was a bit of sanity check for 
whether `IsDiag` was added to the wrong option: the `DiagnosticOpts->` part of 
the keypath was implicit. What do you think of adding that back? That would 
make the keypath here `ShowCarets`.

It highlights that diagnostics are special (since `DiagnosticOpts` is never 
mentioned in the file, and any mistakes could be found with a `grep`).



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3212
+
+#define DIAG_OPTION_WITH_MARSHALLING OPTION_WITH_MARSHALLING
+

Making `DiagnosticOpts->` implicit requires a little more code here:
```
#define DIAG_OPTION_WITH_MARSHALLING(  \
PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
TABLE_INDEX)   \
  GENERATE_OPTION_WITH_MARSHALLING(\
  Args, SA, KIND, FLAGS, SPELLING, ALWAYS_EMIT, DiagnosticOpts->KEYPATH,   \
  DEFAULT_VALUE, IMPLIED_CHECK, IMPLIED_VALUE, DENORMALIZER, EXTRACTOR,\
  TABLE_INDEX)
```
But I think it might be worth it for the sanity check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

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

[PATCH] D94172: [clang][cli] NFC: Move parseSimpleArgs

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

dexonsmith accepted this revision.
dexonsmith 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/D94172/new/

https://reviews.llvm.org/D94172

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

[PATCH] D93702: [clang][cli] NFC: Make marshalling macros reusable

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

dexonsmith accepted this revision.
dexonsmith 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/D93702/new/

https://reviews.llvm.org/D93702

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

[clang] 4fde2b6 - [OpenCL] Add clang extension for function pointers.

[Anastasia Stulova via cfe-commits]

Author: Anastasia Stulova
Date: 2021-01-06T20:39:57Z
New Revision: 4fde2b6a0c080cb2a598383b5850038d67ca6833

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

LOG: [OpenCL] Add clang extension for function pointers.

The new clang internal extension '__cl_clang_function_pointers'
allows use of function pointers and other features that have
the same functionality:
- Use of member function pointers;
- Unrestricted use of references to functions;
- Virtual member functions.

This not a vendor extension and therefore it doesn't require any
special target support. Exposing this functionality fully
will require vendor or Khronos extension.

Tags: #clang

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

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/OpenCLExtensions.def
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Basic/Targets/NVPTX.h
clang/lib/Parse/ParseDecl.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaType.cpp
clang/test/Misc/amdgcn.languageOptsOpenCL.cl
clang/test/Misc/nvptx.languageOptsOpenCL.cl
clang/test/Misc/r600.languageOptsOpenCL.cl
clang/test/Parser/opencl-cxx-virtual.cl
clang/test/SemaOpenCL/extension-version.cl
clang/test/SemaOpenCL/func.cl
clang/test/SemaOpenCLCXX/members.cl

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 6280c486ccbb..fd011b101b6e 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1722,6 +1722,58 @@ syntax to be used with ``std::complex`` with the same 
meaning.)
 For GCC compatibility, ``__builtin_complex(re, im)`` can also be used to
 construct a complex number from the given real and imaginary components.
 
+OpenCL Features
+===
+
+Clang supports internal OpenCL extensions documented below.
+
+``__cl_clang_function_pointers``
+
+
+With this extension it is possible to enable various language features that
+are relying on function pointers using regular OpenCL extension pragma
+mechanism detailed in `the OpenCL Extension Specification,
+section 1.2
+`_.
+
+In C++ for OpenCL this also enables:
+
+- Use of member function pointers;
+
+- Unrestricted use of references to functions;
+
+- Virtual member functions.
+
+Such functionality is not conformant and does not guarantee to compile
+correctly in any circumstances. It can be used if:
+
+- the kernel source does not contain call expressions to (member-) function
+  pointers, or virtual functions. For example this extension can be used in
+  metaprogramming algorithms to be able to specify/detect types generically.
+
+- the generated kernel binary does not contain indirect calls because they
+  are eliminated using compiler optimizations e.g. devirtualization. 
+
+- the selected target supports the function pointer like functionality e.g.
+  most CPU targets.
+
+**Example of Use**:
+
+.. code-block:: c++
+
+  #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+  void foo()
+  {
+void (*fp)(); // compiled - no diagnostic generated
+  }
+
+  #pragma OPENCL EXTENSION __cl_clang_function_pointers : disable
+  void bar()
+  {
+void (*fp)(); // error - pointers to function are not allowed
+  }
+
+
 Builtin Functions
 =
 

diff  --git a/clang/include/clang/Basic/OpenCLExtensions.def 
b/clang/include/clang/Basic/OpenCLExtensions.def
index 17d402f300f1..149594ed40b0 100644
--- a/clang/include/clang/Basic/OpenCLExtensions.def
+++ b/clang/include/clang/Basic/OpenCLExtensions.def
@@ -69,6 +69,7 @@ OPENCLEXT_INTERNAL(cl_khr_subgroups, 200, ~0U)
 
 // Clang Extensions.
 OPENCLEXT_INTERNAL(cl_clang_storage_class_specifiers, 100, ~0U)
+OPENCLEXT_INTERNAL(__cl_clang_function_pointers, 100, ~0U)
 
 // AMD OpenCL extensions
 OPENCLEXT_INTERNAL(cl_amd_media_ops, 100, ~0U)

diff  --git a/clang/lib/Basic/Targets/AMDGPU.h 
b/clang/lib/Basic/Targets/AMDGPU.h
index 8b3f30ed70e9..3fdbf320a329 100644
--- a/clang/lib/Basic/Targets/AMDGPU.h
+++ b/clang/lib/Basic/Targets/AMDGPU.h
@@ -285,6 +285,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : 
public TargetInfo {
   void setSupportedOpenCLOpts() override {
 auto &Opts = getSupportedOpenCLOpts();
 Opts.support("cl_clang_storage_class_specifiers");
+Opts.support("__cl_clang_function_pointers");
 
 bool IsAMDGCN = isAMDGCN(getTriple());
 

diff  --git a/clang/lib/Basic/Targets/NVPTX.h b/clang/lib/Basic/Targets/NVPTX.h
index f8d0afdcceae..8e0da6554708 100644
--- a/clang/lib/Basic/Targets/NVPTX.h
+++ b/clang/lib/Basic/Targets/NVPTX.h
@@ -128,6 +128,7 @@ class LLVM_LIBRARY_VISIBILITY NVPTXTarget