[PATCH] D93240: [clang-format] Add SpaceBeforeCaseColon option

2020-12-16 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

Nit: Please just separate your test from old test




Comment at: clang/unittests/Format/FormatTest.cpp:12158
"default:\n"
+   "  break;\n"
"}",

HazardyKnusperkeks wrote:
> MyDeveloperDay wrote:
> > Add new test leave the old one alone
> Do you mean a whole new function? I would strongly disagree, because this 
> function is the right one since its called `ConfigurableSpaceBeforeColon`. 
> And without it I would not have got the wrong assignment of the colon of a 
> default statement.
> 
> Or do you mean the function is okay, but I should not touch this string (and 
> probably the other strings too)? I would mildly disagree because I all to 
> have to have the same unformatted text. But this one I'm willing to revert if 
> that's what it's takes.
I mean your own unique verifyFormat() but keeping it in the same function is 
ok, (sorry I wasn't clear)

The real problem is that clang-format has so many interactions with the code 
that is around it I personally like to keep the old tests and new tests 
separate as much as possible to ensure we don't regress anything, but also so I 
know you are not changing behaviour

Whilst in this case you don't really change anything this test was testing a 
case and default with no `}` before the default

I don't mind the repetition in the test if in my view its testing a slightly 
difference scenario (however slight)

There are so many billions of lines of code which are now formatted throughout 
all the software project in the world , the thought of introducing regressions 
is a little scary.

I like to use the "Beyonce Rule" when it comes to tests, so from my perspective 
that means no changes to existing tests unless absolutely necessary or the test 
is in fact wrong.



Comment at: clang/unittests/Format/FormatTest.cpp:12179
   FormatStyle NoSpaceStyle = getLLVMStyle();
+  NoSpaceStyle.SpaceBeforeCaseColon = false;
   NoSpaceStyle.SpaceBeforeCtorInitializerColon = false;

I guess you shouldn't need this right? if false is the default then you could 
just add

`EXPECT_EQ(NoSpaceStyle.SpaceBeforeCaseColon,false);`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93240

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


[clang] 95114f2 - [clang][cli] Do not marshall only CC1Option flags in BoolOption

2020-12-16 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2020-12-16T09:29:40+01:00
New Revision: 95114f21f5bf1704672dadb45ca7c25efca72e03

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

LOG: [clang][cli] Do not marshall only CC1Option flags in BoolOption

We cannot be sure whether a flag is CC1Option inside the definition of 
`BoolOption`. Take the example below:

```
let Flags = [CC1Option] in {
  defm xxx : BoolOption<...>;
}
```

where TableGen applies `Flags = [CC1Option]` to the `xxx` and `no_xxx` records 
**after** they have been is fully declared by `BoolOption`.

For the refactored `-f[no-]debug-pass-manager` flags (see the diff), this means 
`BoolOption` never adds any marshalling info, as it doesn't see either of the 
flags as `CC1Option`.

For that reason, we should defensively append the marshalling information to 
both flags inside `BoolOption`. Now the check for `CC1Option` needs to happen 
later, in the parsing macro, when all TableGen logic has been resolved.

However, for some flags defined through `BoolOption`, we can run into issues:

```
// Options.td
def fenable_xxx : /* ... */;

// Both flags are CC1Option, the first is implied.
defm xxx : BoolOption<"xxx,
  "Opts.Xxx", DefaultsToFalse,
  ChangedBy,
  ResetBy>;
```

When parsing `clang -cc1 -fenable-xxx`:
* we run parsing for `PosFlag`:
  * set `Opts.Xxx` to default `false`,
  * discover `PosFlag` is implied by `-fenable-xxx`: set `Opts.Xxx` to `true`,
  * don't see `-fxxx` on command line: do nothing,
* we run parsing for `NegFlag`:
  * set `Opts.Xxx` to default `false`,
  * discover `NegFlag` cannot be implied: do nothing,
  * don't see `-fno-xxx` on command line: do nothing.

Now we ended up with `Opts.Xxx` set to `false` instead of `true`. For this 
reason, we need to ensure to append the same `ImpliedByAnyOf` instance to both 
flags.

This means both parsing runs now behave identically (they set the same default 
value, run the same "implied by" check, and call `makeBooleanOptionNormalizer` 
that already has information on both flags, so it returns the same value in 
both calls).

The solution works well, but what might be confusing is this: you have defined 
a flag **A** that is not `CC1Option`, but can be implied by another flag **B** 
that is `CC1Option`:
* if **A** is defined manually, it will never get implied, as the code never 
runs
```
def no_signed_zeros : Flag<["-"], "fno-signed-zeros">, Group, 
Flags<[]>,
  MarshallingInfoFlag<"LangOpts->NoSignedZero">, 
ImpliedByAnyOf<[menable_unsafe_fp_math]>;
```
* if **A** is defined by `BoolOption`, it could get implied, as the code is run 
by its `CC1Option` counterpart:
```
defm signed_zeros : BoolOption<"signed-zeros",
  "LangOpts->NoSignedZero", DefaultsToFalse,
  ChangedBy,
  ResetBy, "f">, Group;
```

This is a surprising inconsistency.

One solution might be to somehow propagate the final `Flags` of the implied 
flag in `ImpliedByAnyOf` and check whether it has `CC1Option` in the parsing 
macro. However, I think it doesn't make sense to spend time thinking about a 
corner case that won't come up in real code.

An observation: it is unfortunate that the marshalling information is a part of 
the flag definition. If we represented it in a separate structure, we could 
avoid the "double parsing" problem by having a single source of truth. This 
would require a lot of additional work though.

Note: the original patch missed the `CC1Option` check in the parsing macro, 
making my reasoning here incomplete. Moreover, it contained a change to 
denormalization that wasn't necessarily related to these changes, so I've 
extracted that to a follow-up patch: D93094.

Reviewed By: dexonsmith, Bigcheese

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Frontend/CompilerInvocation.cpp
clang/unittests/Frontend/CompilerInvocationTest.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index f3aa6750b794..0da6a43b6986 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -325,10 +325,6 @@ class FlagDefExpanded
   string Spelling
 = prefix#!cond(flag.Polarity.Value : "", true : "no-")#spelling;
 
-  // Does the flag have CC1Option?
-  bit IsCC1 = !not(!empty(!filter(opt_flag, flag.OptionFlags,
-  !eq(opt_flag, CC1Option;
-
   // Can the flag be implied by another flag?
   bit CanBeImplied = !not(!empty(flag.ImpliedBy));
 
@@ -336,18 +332,14 @@ class FlagDefExpanded
   code ValueAsCode = !cond(flag.Value : "true", true: "false");
 }
 
-// Creates simple flag record.
-class BoolOptionFlag
-  : Flag<["-"], flag.Spelling>, Flags, HelpText {}
-
-// Creates marshalled flag rec

[PATCH] D93008: [clang][cli] Do not marshall only CC1Option flags in BoolOption

2020-12-16 Thread Jan Svoboda 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 rG95114f21f5bf: [clang][cli] Do not marshall only CC1Option 
flags in BoolOption (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D93008?vs=311134&id=312144#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93008

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -238,6 +238,55 @@
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq(PassManagerChangedByFlag;
 }
 
+// Boolean option that gets the CC1Option flag from a let statement (which
+// is applied **after** the record is defined):
+//
+//   let Flags = [CC1Option] in {
+// defm option : BoolOption<...>;
+//   }
+
+TEST_F(CommandLineTest, BoolOptionCC1ViaLetPresentNone) {
+  const char *Args[] = {""};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_FALSE(Invocation.getCodeGenOpts().DebugPassManager);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fdebug-pass-manager";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fno-debug-pass-manager";
+}
+
+TEST_F(CommandLineTest, BoolOptionCC1ViaLetPresentPos) {
+  const char *Args[] = {"-fdebug-pass-manager"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getCodeGenOpts().DebugPassManager);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fdebug-pass-manager")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fno-debug-pass-manager";
+}
+
+TEST_F(CommandLineTest, BoolOptionCC1ViaLetPresentNeg) {
+  const char *Args[] = {"-fno-debug-pass-manager"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_FALSE(Invocation.getCodeGenOpts().DebugPassManager);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fno-debug-pass-manager";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fdebug-pass-manager";
+}
+
 TEST_F(CommandLineTest, CanGenerateCC1CommandLineFlag) {
   const char *Args[] = {"-fmodules-strict-context-hash"};
 
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -869,10 +869,6 @@
 }
   }
 
-  Opts.DebugPassManager =
-  Args.hasFlag(OPT_fdebug_pass_manager, OPT_fno_debug_pass_manager,
-   /* Default */ false);
-
   if (Arg *A = Args.getLastArg(OPT_fveclib)) {
 StringRef Name = A->getValue();
 if (Name == "Accelerate")
@@ -3767,7 +3763,7 @@
 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);\
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -325,10 +325,6 @@
   string Spelling
 = prefix#!cond(flag.Polarity.Value : "", true : "no-")#spelling;
 
-  // Does the flag have CC1Option?
-  bit IsCC1 = !not(!empty(!filter(opt_flag, flag.OptionFlags,
-  !eq(opt_flag, CC1Option;
-
   // Can the flag be implied by another flag?
   bit CanBeImplied = !not(!empty(flag.ImpliedBy));
 
@@ -336,18 +332,14 @@
   code ValueAsCode = !cond(flag.Value : "true", true: "false");
 }
 
-// Creates simple flag record.
-class BoolOptionFlag
-  : Flag<["-"], flag.Spelling>, Flags, HelpText {}
-
-// Creates marshalled flag record.
-class CC1BoolOptionFlag
+// Creates record with a marshalled flag.
+class BoolOptionFlag
   : Flag<["-"], flag.Spelling>, Flags, HelpText,
 MarshallingInfoBooleanFlag,
-ImpliedByAnyOf {}
+

[clang] f2661be - [clang][cli] Prevent double denormalization

2020-12-16 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2020-12-16T09:44:54+01:00
New Revision: f2661bed185e14a8f5aa9a54565a8b938a7a10aa

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

LOG: [clang][cli] Prevent double denormalization

If both flags created through BoolOption are CC1Option and the keypath has a 
non-default or non-implied value, the denormalizer gets called twice. If the 
denormalizer has the ability to generate both flags, we can end up generating 
the same flag twice.

Reviewed By: dexonsmith, Bigcheese

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Frontend/CompilerInvocation.cpp
clang/unittests/Frontend/CompilerInvocationTest.cpp
llvm/include/llvm/Option/OptParser.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 0da6a43b6986..a2208f2e2c5c 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -338,7 +338,7 @@ class BoolOptionFlag, Flags, HelpText,
 MarshallingInfoBooleanFlag,
+   other.RecordName>,
 ImpliedByAnyOf {}
 
 // Generates TableGen records for two command line flags that control the same

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 1a863a739156..bdadaa9a0b5c 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -197,12 +197,11 @@ static auto makeBooleanOptionNormalizer(bool Value, bool 
OtherValue,
   };
 }
 
-static auto makeBooleanOptionDenormalizer(bool Value,
-  const char *OtherSpelling) {
-  return [Value, OtherSpelling](
- SmallVectorImpl &Args, const char *Spelling,
- CompilerInvocation::StringAllocator, unsigned, bool KeyPath) {
-Args.push_back(KeyPath == Value ? Spelling : OtherSpelling);
+static auto makeBooleanOptionDenormalizer(bool Value) {
+  return [Value](SmallVectorImpl &Args, const char *Spelling,
+ CompilerInvocation::StringAllocator, unsigned, bool KeyPath) {
+if (KeyPath == Value)
+  Args.push_back(Spelling);
   };
 }
 

diff  --git a/clang/unittests/Frontend/CompilerInvocationTest.cpp 
b/clang/unittests/Frontend/CompilerInvocationTest.cpp
index 156e3393acd6..51b7ba8c147f 100644
--- a/clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ b/clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -269,7 +269,7 @@ TEST_F(CommandLineTest, BoolOptionCC1ViaLetPresentPos) {
 
   Invocation.generateCC1CommandLine(GeneratedArgs, *this);
 
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fdebug-pass-manager")));
+  ASSERT_EQ(count(GeneratedArgs, StringRef("-fdebug-pass-manager")), 1);
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fno-debug-pass-manager";
 }
 

diff  --git a/llvm/include/llvm/Option/OptParser.td 
b/llvm/include/llvm/Option/OptParser.td
index 9e0ff1450920..d35a3e5fec7f 100644
--- a/llvm/include/llvm/Option/OptParser.td
+++ b/llvm/include/llvm/Option/OptParser.td
@@ -176,10 +176,10 @@ class MarshallingInfoBitfieldFlag
 
 // Marshalling info for booleans. Applied to the flag setting keypath to false.
 class MarshallingInfoBooleanFlag
+ code other_value, code other_name>
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", 
OPT_"#other_name#")";
-  code Denormalizer = "makeBooleanOptionDenormalizer("#value#", 
\""#other_spelling#"\")";
+  code Denormalizer = "makeBooleanOptionDenormalizer("#value#")";
 }
 
 // Mixins for additional marshalling attributes.



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


[PATCH] D93094: [clang][cli] Prevent double denormalization

2020-12-16 Thread Jan Svoboda 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 rGf2661bed185e: [clang][cli] Prevent double denormalization 
(authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D93094?vs=311216&id=312145#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93094

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp
  llvm/include/llvm/Option/OptParser.td


Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -176,10 +176,10 @@
 
 // Marshalling info for booleans. Applied to the flag setting keypath to false.
 class MarshallingInfoBooleanFlag
+ code other_value, code other_name>
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", 
OPT_"#other_name#")";
-  code Denormalizer = "makeBooleanOptionDenormalizer("#value#", 
\""#other_spelling#"\")";
+  code Denormalizer = "makeBooleanOptionDenormalizer("#value#")";
 }
 
 // Mixins for additional marshalling attributes.
Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -269,7 +269,7 @@
 
   Invocation.generateCC1CommandLine(GeneratedArgs, *this);
 
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fdebug-pass-manager")));
+  ASSERT_EQ(count(GeneratedArgs, StringRef("-fdebug-pass-manager")), 1);
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fno-debug-pass-manager";
 }
 
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -197,12 +197,11 @@
   };
 }
 
-static auto makeBooleanOptionDenormalizer(bool Value,
-  const char *OtherSpelling) {
-  return [Value, OtherSpelling](
- SmallVectorImpl &Args, const char *Spelling,
- CompilerInvocation::StringAllocator, unsigned, bool KeyPath) {
-Args.push_back(KeyPath == Value ? Spelling : OtherSpelling);
+static auto makeBooleanOptionDenormalizer(bool Value) {
+  return [Value](SmallVectorImpl &Args, const char *Spelling,
+ CompilerInvocation::StringAllocator, unsigned, bool KeyPath) {
+if (KeyPath == Value)
+  Args.push_back(Spelling);
   };
 }
 
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -338,7 +338,7 @@
   : Flag<["-"], flag.Spelling>, Flags, HelpText,
 MarshallingInfoBooleanFlag,
+   other.RecordName>,
 ImpliedByAnyOf {}
 
 // Generates TableGen records for two command line flags that control the same


Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -176,10 +176,10 @@
 
 // Marshalling info for booleans. Applied to the flag setting keypath to false.
 class MarshallingInfoBooleanFlag
+ code other_value, code other_name>
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", OPT_"#other_name#")";
-  code Denormalizer = "makeBooleanOptionDenormalizer("#value#", \""#other_spelling#"\")";
+  code Denormalizer = "makeBooleanOptionDenormalizer("#value#")";
 }
 
 // Mixins for additional marshalling attributes.
Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -269,7 +269,7 @@
 
   Invocation.generateCC1CommandLine(GeneratedArgs, *this);
 
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fdebug-pass-manager")));
+  ASSERT_EQ(count(GeneratedArgs, StringRef("-fdebug-pass-manager")), 1);
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fno-debug-pass-manager";
 }
 
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -197,12 +197,11 @@
   };
 }
 
-static auto makeBooleanOptionDenormalizer(bool Value,
-  const char *OtherSpelling) {
-  return [Value, OtherSpelling](
- S

[clang] 741978d - [clang][cli] Port CodeGen option flags to new option parsing system

2020-12-16 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2020-12-16T10:00:33+01:00
New Revision: 741978d727a445fa279d5952a86ea634adb7dc52

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

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

Depends on D83697.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index a2208f2e2c5c2..65c3ad1a3943d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1053,7 +1053,8 @@ def fprofile_sample_accurate : Flag<["-"], 
"fprofile-sample-accurate">,
 DocBrief<[{Specifies that the sample profile is accurate. If the sample
profile is accurate, callsites without profile samples are 
marked
as cold. Otherwise, treat callsites without profile samples as 
if
-   we have no profile}]>;
+   we have no profile}]>,
+   MarshallingInfoFlag<"CodeGenOpts.ProfileSampleAccurate">;
 def fno_profile_sample_accurate : Flag<["-"], "fno-profile-sample-accurate">,
   Group, Flags<[NoXarchOption]>;
 def fauto_profile : Flag<["-"], "fauto-profile">, Group,
@@ -1072,8 +1073,10 @@ def fdebug_compilation_dir : Separate<["-"], 
"fdebug-compilation-dir">,
 def fdebug_compilation_dir_EQ : Joined<["-"], "fdebug-compilation-dir=">,
 Group, Flags<[CC1Option, CC1AsOption, CoreOption]>,
 Alias;
-defm debug_info_for_profiling : OptInFFlag<"debug-info-for-profiling",
-  "Emit extra debug info to make sample profile more accurate">;
+defm debug_info_for_profiling : BoolFOption<"debug-info-for-profiling",
+  "CodeGenOpts.DebugInfoForProfiling", DefaultsToFalse,
+  ChangedBy,
+  ResetBy>;
 def fprofile_instr_generate : Flag<["-"], "fprofile-instr-generate">,
 Group, Flags<[CoreOption]>,
 HelpText<"Generate instrumented code to collect execution counts into 
default.profraw file (overridden by '=' form of option or LLVM_PROFILE_FILE env 
var)">;
@@ -1090,9 +1093,10 @@ def fprofile_remapping_file_EQ : Joined<["-"], 
"fprofile-remapping-file=">,
 HelpText<"Use the remappings described in  to match the profile data 
against names in the program">;
 def fprofile_remapping_file : Separate<["-"], "fprofile-remapping-file">,
 Group, Flags<[CoreOption]>, Alias;
-defm coverage_mapping : OptInFFlag<"coverage-mapping",
-  "Generate coverage mapping to enable code coverage analysis", "Disable code 
coverage analysis", "",
-  [CoreOption]>;
+defm coverage_mapping : BoolFOption<"coverage-mapping",
+  "CodeGenOpts.CoverageMapping", DefaultsToFalse,
+  ChangedBy,
+  ResetBy, 
BothFlags<[CoreOption]>>;
 def fprofile_generate : Flag<["-"], "fprofile-generate">,
 Group, Flags<[CoreOption]>,
 HelpText<"Generate instrumented code to collect execution counts into 
default.profraw (overridden by LLVM_PROFILE_FILE env var)">;
@@ -1129,18 +1133,20 @@ def fprofile_exclude_files_EQ : Joined<["-"], 
"fprofile-exclude-files=">,
 HelpText<"Instrument only functions from files where names don't match all 
the regexes separated by a semi-colon">;
 def fprofile_update_EQ : Joined<["-"], "fprofile-update=">,
 Group, Flags<[CC1Option, CoreOption]>, 
Values<"atomic,prefer-atomic,single">,
-MetaVarName<"">, HelpText<"Set update method of profile counters 
(atomic,prefer-atomic,single)">;
-def fpseudo_probe_for_profiling : Flag<["-"], "fpseudo-probe-for-profiling">,
-Group, Flags<[NoXarchOption, CC1Option]>,
-HelpText<"Emit pseudo probes for sample profiler">;
-def fno_pseudo_probe_for_profiling : Flag<["-"], 
"fno-pseudo-probe-for-profiling">,
-Group, Flags<[NoXarchOption, CC1Option]>,
-HelpText<"Do not emit pseudo probes for sample profiler.">;
+MetaVarName<"">, HelpText<"Set update method of profile counters 
(atomic,prefer-atomic,single)">,
+MarshallingInfoFlag<"CodeGenOpts.AtomicProfileUpdate">;
+defm pseudo_probe_for_profiling : BoolFOption<"pseudo-probe-for-profiling",
+  "CodeGenOpts.PseudoProbeForProfiling", DefaultsToFalse,
+  ChangedBy, ResetBy,
+  BothFlags<[NoXarchOption, CC1Option], " pseudo probes for sample profiler">>;
 def forder_file_instrumentation : Flag<["-"], "forder-file-instrumentation">,
 Group, Flags<[CC1Option, CoreOption]>,
 HelpText<"Generate instrumented code to collect order file into 
default.profraw file (overridden by '=' form of option or LLVM_PROFILE_FILE env 
var)">;
 
-defm addrsig : OptInFFlag<"addrsig", "Emit", "Don't emit", " an 
address-significance table", [CoreOption]>;
+defm addrsig : BoolFOption<"addrsig",
+  "CodeGenOpts.Addrsig", DefaultsToFalse,
+  ChangedBy, Re

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

2020-12-16 Thread Jan Svoboda 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 rG741978d727a4: [clang][cli] Port CodeGen option flags to new 
option parsing system (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D83892?vs=311217&id=312147#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83892

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -325,6 +325,7 @@
   CodeGenOpts.XRayInstrumentFunctions = LangOpts.XRayInstrument;
   CodeGenOpts.XRayAlwaysEmitCustomEvents = LangOpts.XRayAlwaysEmitCustomEvents;
   CodeGenOpts.XRayAlwaysEmitTypedEvents = LangOpts.XRayAlwaysEmitTypedEvents;
+  CodeGenOpts.DisableFree = FrontendOpts.DisableFree;
   FrontendOpts.GenerateGlobalModuleIndex = FrontendOpts.UseGlobalModuleIndex;
 
   llvm::sys::Process::UseANSIEscapeCodes(DiagOpts.UseANSIEscapeCodes);
@@ -919,22 +920,9 @@
   Opts.setDebuggerTuning(static_cast(Val));
   }
   Opts.DwarfVersion = getLastArgIntValue(Args, OPT_dwarf_version_EQ, 0, Diags);
-  Opts.DebugColumnInfo = !Args.hasArg(OPT_gno_column_info);
-  Opts.EmitCodeView = Args.hasArg(OPT_gcodeview);
-  Opts.MacroDebugInfo = Args.hasArg(OPT_debug_info_macro);
-  Opts.WholeProgramVTables = Args.hasArg(OPT_fwhole_program_vtables);
-  Opts.VirtualFunctionElimination =
-  Args.hasArg(OPT_fvirtual_function_elimination);
-  Opts.LTOVisibilityPublicStd = Args.hasArg(OPT_flto_visibility_public_std);
   Opts.SplitDwarfFile = std::string(Args.getLastArgValue(OPT_split_dwarf_file));
   Opts.SplitDwarfOutput =
   std::string(Args.getLastArgValue(OPT_split_dwarf_output));
-  Opts.SplitDwarfInlining = !Args.hasArg(OPT_fno_split_dwarf_inlining);
-  Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Args.hasArg(OPT_dwarf_explicit_import);
-  Opts.DebugFwdTemplateParams = Args.hasArg(OPT_debug_forward_template_params);
-  Opts.EmbedSource = Args.hasArg(OPT_gembed_source);
-  Opts.ForceDwarfFrameSection = Args.hasArg(OPT_fforce_dwarf_frame);
 
   for (const auto &Arg : Args.getAllArgValues(OPT_fdebug_prefix_map_EQ)) {
 auto Split = StringRef(Arg).split('=');
@@ -942,13 +930,6 @@
 {std::string(Split.first), std::string(Split.second)});
   }
 
-  if (const Arg *A =
-  Args.getLastArg(OPT_emit_llvm_uselists, OPT_no_emit_llvm_uselists))
-Opts.EmitLLVMUseLists = A->getOption().getID() == OPT_emit_llvm_uselists;
-
-  Opts.DisableLLVMPasses = Args.hasArg(OPT_disable_llvm_passes);
-  Opts.DisableLifetimeMarkers = Args.hasArg(OPT_disable_lifetimemarkers);
-
   const llvm::Triple::ArchType DebugEntryValueArchs[] = {
   llvm::Triple::x86, llvm::Triple::x86_64, llvm::Triple::aarch64,
   llvm::Triple::arm, llvm::Triple::armeb, llvm::Triple::mips,
@@ -959,29 +940,12 @@
   llvm::is_contained(DebugEntryValueArchs, T.getArch()))
 Opts.EmitCallSiteInfo = true;
 
-  Opts.ValueTrackingVariableLocations =
-  Args.hasArg(OPT_fexperimental_debug_variable_locations);
-
-  Opts.DisableO0ImplyOptNone = Args.hasArg(OPT_disable_O0_optnone);
-  Opts.DisableRedZone = Args.hasArg(OPT_disable_red_zone);
-  Opts.IndirectTlsSegRefs = Args.hasArg(OPT_mno_tls_direct_seg_refs);
-  Opts.ForbidGuardVariables = Args.hasArg(OPT_fforbid_guard_variables);
-  Opts.UseRegisterSizedBitfieldAccess = Args.hasArg(
-OPT_fuse_register_sized_bitfield_access);
-  Opts.RelaxedAliasing = Args.hasArg(OPT_relaxed_aliasing);
-  Opts.StructPathTBAA = !Args.hasArg(OPT_no_struct_path_tbaa);
   Opts.NewStructPathTBAA = !Args.hasArg(OPT_no_struct_path_tbaa) &&
Args.hasArg(OPT_new_struct_path_tbaa);
-  Opts.FineGrainedBitfieldAccesses =
-  Args.hasFlag(OPT_ffine_grained_bitfield_accesses,
-   OPT_fno_fine_grained_bitfield_accesses, false);
   Opts.DwarfDebugFlags =
   std::string(Args.getLastArgValue(OPT_dwarf_debug_flags));
   Opts.RecordCommandLine =
   std::string(Args.getLastArgValue(OPT_record_command_line));
-  Opts.MergeAllConstants = Args.hasArg(OPT_fmerge_all_constants);
-  Opts.NoCommon = !Args.hasArg(OPT_fcommon);
-  Opts.NoImplicitFloat = Args.hasArg(OPT_no_implicit_float);
   Opts.OptimizeSize = getOptimizationLevelSize(Args);
   Opts.SimplifyLibCalls = !(Args.hasArg(OPT_fno_builtin) ||
 Args.hasArg(OPT_ffreestanding));
@@ -990,26 +954,17 @@
   Opts.UnrollLoops =
   Args.hasFlag(OPT_funroll_loops, OPT_fno_unroll_loops,
(Opts.OptimizationLevel > 1));
-  Opts.RerollLoops = Args.hasArg(OPT_freroll_loops);
 
-  Opts.DisableIntegratedAS = Args.hasArg(OPT_fno_integrated_as);
   Opts.SampleProfileFile =

[PATCH] D92039: [-Wcalled-once-parameter] Introduce 'called_once' attribute

2020-12-16 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 312149.
vsavchenko added a comment.

Turn off conventional check heuristic


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92039

Files:
  clang/include/clang/Analysis/Analyses/CalledOnceCheck.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/CalledOnceCheck.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaObjC/attr-called-once.m
  clang/test/SemaObjC/warn-called-once.m

Index: clang/test/SemaObjC/warn-called-once.m
===
--- /dev/null
+++ clang/test/SemaObjC/warn-called-once.m
@@ -0,0 +1,1029 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fblocks -fobjc-exceptions -Wcompletion-handler %s
+
+#define NULL (void *)0
+#define nil (id)0
+#define CALLED_ONCE __attribute__((called_once))
+#define NORETURN __attribute__((noreturn))
+
+@protocol NSObject
+@end
+@interface NSObject 
+- (id)copy;
+- (id)class;
+- autorelease;
+@end
+
+typedef unsigned int NSUInteger;
+typedef struct {
+} NSFastEnumerationState;
+
+@interface NSArray <__covariant NSFastEnumeration>
+- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state objects:(id *)stackbuf count:(NSUInteger)len;
+@end
+@interface NSMutableArray : NSArray 
+- addObject:anObject;
+@end
+@class NSString, Protocol;
+extern void NSLog(NSString *format, ...);
+
+void escape(void (^callback)(void));
+void escape_void(void *);
+void indirect_call(void (^callback)(void) CALLED_ONCE);
+void indirect_conv(void (^completionHandler)(void));
+void filler(void);
+void exit(int) NORETURN;
+
+void double_call_one_block(void (^callback)(void) CALLED_ONCE) {
+  callback(); // expected-note{{previous call is here}}
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_one_block_parens(void (^callback)(void) CALLED_ONCE) {
+  (callback)(); // expected-note{{previous call is here}}
+  (callback)(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_one_block_ptr(void (*callback)(void) CALLED_ONCE) {
+  callback(); // expected-note{{previous call is here}}
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_one_block_ptr_deref(void (*callback)(void) CALLED_ONCE) {
+  (*callback)(); // expected-note{{previous call is here}}
+  (*callback)(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void multiple_call_one_block(void (^callback)(void) CALLED_ONCE) {
+  // We don't really need to repeat the same warning for the same parameter.
+  callback(); // no-warning
+  callback(); // no-warning
+  callback(); // no-warning
+  callback(); // expected-note{{previous call is here}}
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_branching_1(int cond, void (^callback)(void) CALLED_ONCE) {
+  if (cond) {
+callback(); // expected-note{{previous call is here}}
+  } else {
+cond += 42;
+  }
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_branching_2(int cond, void (^callback)(void) CALLED_ONCE) {
+  callback();
+  // expected-note@-1{{previous call is here; set to nil to indicate it cannot be called afterwards}}
+
+  if (cond) {
+callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+  } else {
+cond += 42;
+  }
+}
+
+void double_call_branching_3(int cond, void (^callback)(void) CALLED_ONCE) {
+  if (cond) {
+callback();
+  } else {
+callback();
+  }
+  // no-warning
+}
+
+void double_call_branching_4(int cond1, int cond2, void (^callback)(void) CALLED_ONCE) {
+  if (cond1) {
+cond2 = !cond2;
+  } else {
+callback();
+// expected-note@-1{{previous call is here; set to nil to indicate it cannot be called afterwards}}
+  }
+
+  if (cond2) {
+callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+  }
+}
+
+void double_call_loop(int counter, void (^callback)(void) CALLED_ONCE) {
+  while (counter > 0) {
+counter--;
+// Both note and warning are on the same line, which is a common situation
+// in loops.
+callback(); // expected-note{{previous call is here}}
+// expected-warning@-1{{'callback' parameter marked 'called_once' is called twice}}
+  }
+}
+
+void never_called_trivial(void (^callback)(void) CALLED_ONCE) {
+  // expected-warning@-1{{'callback' parameter marked 'called_once' is ne

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

2020-12-16 Thread Qing Shan Zhang via Phabricator via cfe-commits
steven.zhang added inline comments.



Comment at: clang/lib/AST/ItaniumMangle.cpp:2668
   // ::= g  # __float128
+  // ::= g  # __ibm128
   // UNSUPPORTED:::= Dd # IEEE 754r decimal floating point (64 bits)

This is a bit confusing as the 'g' is for both __float128 and __ibm128. I know 
that PowerPC will mangle the __float128 as "u9__ieee128", and "g" for __ibm128. 
But c++filt demangle the "g" as __float128 which seems not right. 


Repository:
  rG LLVM Github Monorepo

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] D92761: [clang][AArch64][SVE] Avoid going through memory for VLAT <-> VLST casts

2020-12-16 Thread Joe Ellis via Phabricator via cfe-commits
joechrisellis updated this revision to Diff 312150.
joechrisellis added a comment.

Address @c-rhodes's comments.

- Add a comment stating that we intend to eliminate going through memory when 
the element types of the vectors are not the same (for example, with 
predicates).
- Doc comments for the new methods in `IRBuilder.h`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92761

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
  llvm/include/llvm/IR/IRBuilder.h

Index: llvm/include/llvm/IR/IRBuilder.h
===
--- llvm/include/llvm/IR/IRBuilder.h
+++ llvm/include/llvm/IR/IRBuilder.h
@@ -923,6 +923,22 @@
 return CreateBinaryIntrinsic(Intrinsic::maximum, LHS, RHS, nullptr, Name);
   }
 
+  /// Create a call to the experimental.vector.extract intrinsic.
+  CallInst *CreateExtractVector(Type *DstType, Value *SrcVec, Value *Idx,
+const Twine &Name = "") {
+return CreateIntrinsic(Intrinsic::experimental_vector_extract,
+   {DstType, SrcVec->getType()}, {SrcVec, Idx}, nullptr,
+   Name);
+  }
+
+  /// Create a call to the experimental.vector.insert intrinsic.
+  CallInst *CreateInsertVector(Type *DstType, Value *SrcVec, Value *SubVec,
+   Value *Idx, const Twine &Name = "") {
+return CreateIntrinsic(Intrinsic::experimental_vector_insert,
+   {DstType, SubVec->getType()}, {SrcVec, SubVec, Idx},
+   nullptr, Name);
+  }
+
 private:
   /// Create a call to a masked intrinsic with given Id.
   CallInst *CreateMaskedIntrinsic(Intrinsic::ID Id, ArrayRef Ops,
Index: clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
@@ -21,40 +21,28 @@
 
 // CHECK-128-LABEL: @write_global_i64(
 // CHECK-128-NEXT:  entry:
-// CHECK-128-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-128-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-128-NEXT:[[TMP0:%.*]] = bitcast * [[V_ADDR]] to <2 x i64>*
-// CHECK-128-NEXT:[[TMP1:%.*]] = load <2 x i64>, <2 x i64>* [[TMP0]], align 16, [[TBAA10:!tbaa !.*]]
-// CHECK-128-NEXT:store <2 x i64> [[TMP1]], <2 x i64>* @global_i64, align 16, [[TBAA10]]
+// CHECK-128-NEXT:[[CASTFIXEDSVE:%.*]] = call <2 x i64> @llvm.experimental.vector.extract.v2i64.nxv2i64( [[V:%.*]], i64 0)
+// CHECK-128-NEXT:store <2 x i64> [[CASTFIXEDSVE]], <2 x i64>* @global_i64, align 16, [[TBAA6:!tbaa !.*]]
 // CHECK-128-NEXT:ret void
 //
 // CHECK-512-LABEL: @write_global_i64(
 // CHECK-512-NEXT:  entry:
-// CHECK-512-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-512-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-512-NEXT:[[TMP0:%.*]] = bitcast * [[V_ADDR]] to <8 x i64>*
-// CHECK-512-NEXT:[[TMP1:%.*]] = load <8 x i64>, <8 x i64>* [[TMP0]], align 16, [[TBAA10:!tbaa !.*]]
-// CHECK-512-NEXT:store <8 x i64> [[TMP1]], <8 x i64>* @global_i64, align 16, [[TBAA10]]
+// CHECK-512-NEXT:[[CASTFIXEDSVE:%.*]] = call <8 x i64> @llvm.experimental.vector.extract.v8i64.nxv2i64( [[V:%.*]], i64 0)
+// CHECK-512-NEXT:store <8 x i64> [[CASTFIXEDSVE]], <8 x i64>* @global_i64, align 16, [[TBAA6:!tbaa !.*]]
 // CHECK-512-NEXT:ret void
 //
 void write_global_i64(svint64_t v) { global_i64 = v; }
 
 // CHECK-128-LABEL: @write_global_bf16(
 // CHECK-128-NEXT:  entry:
-// CHECK-128-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-128-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA11:!tbaa !.*]]
-// CHECK-128-NEXT:[[TMP0:%.*]] = bitcast * [[V_ADDR]] to <8 x bfloat>*
-// CHECK-128-NEXT:[[TMP1:%.*]] = load <8 x bfloat>, <8 x bfloat>* [[TMP0]], align 16, [[TBAA10]]
-// CHECK-128-NEXT:store <8 x bfloat> [[TMP1]], <8 x bfloat>* @global_bf16, align 16, [[TBAA10]]
+// CHECK-128-NEXT:[[CASTFIXEDSVE:%.*]] = call <8 x bfloat> @llvm.experimental.vector.extract.v8bf16.nxv8bf16( [[V:%.*]], i64 0)
+// CHECK-128-NEXT:store <8 x bfloat> [[CASTFIXEDSVE]], <8 x bfloat>* @global_bf16, align 16, [[TBAA6]]
 // CHECK-128-NEXT:ret void
 //
 // CHECK-512-LABEL: @write_global_bf16(
 // CHECK-512-NEXT:  entry:
-// CHECK-512-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-512-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA11:!tbaa !.*]]
-// CHECK-512-NEXT:[[TMP0:%.*]] = bitcast

[PATCH] D83979: [clang][cli] Port LangOpts option flags to new option parsing system

2020-12-16 Thread Jan Svoboda 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 rG383778e2171b: [clang][cli] Port LangOpts option flags to new 
option parsing system (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D83979?vs=311545&id=312152#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83979

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -328,6 +328,9 @@
   CodeGenOpts.DisableFree = FrontendOpts.DisableFree;
   FrontendOpts.GenerateGlobalModuleIndex = FrontendOpts.UseGlobalModuleIndex;
 
+  LangOpts.ForceEmitVTables = CodeGenOpts.ForceEmitVTables;
+  LangOpts.SpeculativeLoadHardening = CodeGenOpts.SpeculativeLoadHardening;
+
   llvm::sys::Process::UseANSIEscapeCodes(DiagOpts.UseANSIEscapeCodes);
 
   llvm::Triple T(TargetOpts.Triple);
@@ -336,6 +339,9 @@
   T.isWindowsMSVCEnvironment())
 Diags.Report(diag::err_fe_invalid_exception_model)
 << static_cast(LangOpts.getExceptionHandling()) << T.str();
+
+  if (LangOpts.AppleKext && !LangOpts.CPlusPlus)
+Diags.Report(diag::warn_c_kext);
 }
 
 //===--===//
@@ -2431,9 +2437,6 @@
 }
   }
 
-  if (Args.hasArg(OPT_fno_dllexport_inlines))
-Opts.DllExportInlines = false;
-
   if (const Arg *A = Args.getLastArg(OPT_fcf_protection_EQ)) {
 StringRef Name = A->getValue();
 if (Name == "full" || Name == "branch") {
@@ -2462,7 +2465,6 @@
   LangStd = OpenCLLangStd;
   }
 
-  Opts.SYCL = Args.hasArg(options::OPT_fsycl);
   Opts.SYCLIsDevice = Opts.SYCL && Args.hasArg(options::OPT_fsycl_is_device);
   if (Opts.SYCL) {
 // -sycl-std applies to any SYCL source, not only those containing kernels,
@@ -2480,9 +2482,6 @@
 }
   }
 
-  Opts.IncludeDefaultHeader = Args.hasArg(OPT_finclude_default_header);
-  Opts.DeclareOpenCLBuiltins = Args.hasArg(OPT_fdeclare_opencl_builtins);
-
   llvm::Triple T(TargetOpts.Triple);
   CompilerInvocation::setLangDefaults(Opts, IK, T, PPOpts, LangStd);
 
@@ -2509,25 +2508,9 @@
   if (Args.hasArg(OPT_fno_operator_names))
 Opts.CXXOperatorNames = 0;
 
-  if (Args.hasArg(OPT_fcuda_is_device))
-Opts.CUDAIsDevice = 1;
-
-  if (Args.hasArg(OPT_fcuda_allow_variadic_functions))
-Opts.CUDAAllowVariadicFunctions = 1;
-
-  if (Args.hasArg(OPT_fno_cuda_host_device_constexpr))
-Opts.CUDAHostDeviceConstexpr = 0;
-
-  if (Args.hasArg(OPT_fgpu_exclude_wrong_side_overloads))
-Opts.GPUExcludeWrongSideOverloads = 1;
-
-  if (Args.hasArg(OPT_fgpu_defer_diag))
-Opts.GPUDeferDiag = 1;
-
   if (Opts.CUDAIsDevice && Args.hasArg(OPT_fcuda_approx_transcendentals))
 Opts.CUDADeviceApproxTranscendentals = 1;
 
-  Opts.GPURelocatableDeviceCode = Args.hasArg(OPT_fgpu_rdc);
   if (Args.hasArg(OPT_fgpu_allow_device_init)) {
 if (Opts.HIP)
   Opts.GPUAllowDeviceInit = 1;
@@ -2535,7 +2518,6 @@
   Diags.Report(diag::warn_ignored_hip_only_option)
   << Args.getLastArg(OPT_fgpu_allow_device_init)->getAsString(Args);
   }
-  Opts.HIPUseNewLaunchAPI = Args.hasArg(OPT_fhip_new_launch_api);
   if (Opts.HIP)
 Opts.GPUMaxThreadsPerBlock = getLastArgIntValue(
 Args, OPT_gpu_max_threads_per_block_EQ, Opts.GPUMaxThreadsPerBlock);
@@ -2585,9 +2567,6 @@
   Opts.ObjCWeak = Opts.ObjCWeakRuntime;
 }
 
-if (Args.hasArg(OPT_fno_objc_infer_related_result_type))
-  Opts.ObjCInferRelatedResultType = 0;
-
 if (Args.hasArg(OPT_fobjc_subscripting_legacy_runtime))
   Opts.ObjCSubscriptingLegacyRuntime =
 (Opts.ObjCRuntime.getKind() == ObjCRuntime::FragileMacOSX);
@@ -2616,18 +2595,6 @@
   Opts.GNUInline = 1;
   }
 
-  if (Args.hasArg(OPT_fapple_kext)) {
-if (!Opts.CPlusPlus)
-  Diags.Report(diag::warn_c_kext);
-else
-  Opts.AppleKext = 1;
-  }
-
-  if (Args.hasArg(OPT_print_ivar_layout))
-Opts.ObjCGCBitmapPrint = 1;
-
-  if (Args.hasArg(OPT_fno_constant_cfstrings))
-Opts.NoConstantCFStrings = 1;
   if (const auto *A = Args.getLastArg(OPT_fcf_runtime_abi_EQ))
 Opts.CFRuntime =
 llvm::StringSwitch(A->getValue())
@@ -2639,12 +2606,6 @@
 .Case("swift-4.1", LangOptions::CoreFoundationABI::Swift4_1)
 .Default(LangOptions::CoreFoundationABI::ObjectiveC);
 
-  if (Args.hasArg(OPT_fzvector))
-Opts.ZVector = 1;
-
-  if (Args.hasArg(OPT_pthread))
-Opts.POSIXThreads = 1;
-
   // The value-visibility mode defaults to "default".
   if (Arg *visOpt = Args.getLastArg(OPT_fvisibility)) {
 Opts.setValueVisibilityMode(parseVisibility(visOpt, Args, Diags));
@@ -2659,18 +2620,6 @@
 Opts.setTypeVisibilityMode

[clang] 383778e - [clang][cli] Port LangOpts option flags to new option parsing system

2020-12-16 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2020-12-16T10:16:27+01:00
New Revision: 383778e2171b4993f555433745466e211e713548

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

LOG: [clang][cli] Port LangOpts option flags to new option parsing system

Depends on D83892 & D83694 & D93104.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 65c3ad1a3943..76deb9de708b 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -908,8 +908,10 @@ def fcuda_flush_denormals_to_zero : Flag<["-"], 
"fcuda-flush-denormals-to-zero">
 def fno_cuda_flush_denormals_to_zero : Flag<["-"], 
"fno-cuda-flush-denormals-to-zero">;
 defm cuda_approx_transcendentals : OptInFFlag<"cuda-approx-transcendentals", 
"Use", "Don't use",
   " approximate transcendental functions">;
-defm gpu_rdc : OptInFFlag<"gpu-rdc",
-  "Generate relocatable device code, also known as separate compilation mode", 
"", "">;
+defm gpu_rdc : BoolFOption<"gpu-rdc",
+  "LangOpts->GPURelocatableDeviceCode", DefaultsToFalse,
+  ChangedBy,
+  ResetBy>;
 def : Flag<["-"], "fcuda-rdc">, Alias;
 def : Flag<["-"], "fno-cuda-rdc">, Alias;
 defm cuda_short_ptr : OptInFFlag<"cuda-short-ptr",
@@ -926,16 +928,21 @@ def hip_version_EQ : Joined<["--"], "hip-version=">,
   HelpText<"HIP version in the format of major.minor.patch">;
 def fhip_dump_offload_linker_script : Flag<["-"], 
"fhip-dump-offload-linker-script">,
   Group, Flags<[NoArgumentUnused, HelpHidden]>;
-defm hip_new_launch_api : OptInFFlag<"hip-new-launch-api",
-  "Use", "Don't use", " new kernel launching API for HIP">;
+defm hip_new_launch_api : BoolFOption<"hip-new-launch-api",
+  "LangOpts->HIPUseNewLaunchAPI", DefaultsToFalse,
+  ChangedBy, ResetBy,
+  BothFlags<[], " new kernel launching API for HIP">>;
 defm gpu_allow_device_init : OptInFFlag<"gpu-allow-device-init",
   "Allow", "Don't allow", " device side init function in HIP">;
-defm gpu_defer_diag : OptInFFlag<"gpu-defer-diag",
-  "Defer", "Don't defer", " host/device related diagnostic messages"
-  " for CUDA/HIP">;
-defm gpu_exclude_wrong_side_overloads : 
OptInFFlag<"gpu-exclude-wrong-side-overloads",
-  "Always exclude wrong side overloads", "Exclude wrong side overloads only if 
there are same side overloads",
-  " in overloading resolution for CUDA/HIP", [HelpHidden]>;
+defm gpu_defer_diag : BoolFOption<"gpu-defer-diag",
+  "LangOpts->GPUDeferDiag", DefaultsToFalse,
+  ChangedBy, ResetBy,
+  BothFlags<[], " host/device related diagnostic messages for CUDA/HIP">>;
+defm gpu_exclude_wrong_side_overloads : 
BoolFOption<"gpu-exclude-wrong-side-overloads",
+  "LangOpts->GPUExcludeWrongSideOverloads", DefaultsToFalse,
+  ChangedBy,
+  ResetBy,
+  BothFlags<[HelpHidden], " in overloading resolution for CUDA/HIP">>;
 def gpu_max_threads_per_block_EQ : Joined<["--"], 
"gpu-max-threads-per-block=">,
   Flags<[CC1Option]>,
   HelpText<"Default max threads per block for kernel launch bounds for HIP">;
@@ -989,16 +996,25 @@ def fPIC : Flag<["-"], "fPIC">, Group;
 def fno_PIC : Flag<["-"], "fno-PIC">, Group;
 def fPIE : Flag<["-"], "fPIE">, Group;
 def fno_PIE : Flag<["-"], "fno-PIE">, Group;
-defm access_control : OptOutFFlag<"access-control", "", "Disable C++ access 
control">;
+defm access_control : BoolFOption<"access-control",
+  "LangOpts->AccessControl", DefaultsToTrue,
+  ChangedBy,
+  ResetBy>;
 def falign_functions : Flag<["-"], "falign-functions">, Group;
 def falign_functions_EQ : Joined<["-"], "falign-functions=">, Group;
 def fno_align_functions: Flag<["-"], "fno-align-functions">, Group;
-defm allow_editor_placeholders : OptInFFlag<"allow-editor-placeholders", 
"Treat editor placeholders as valid source code">;
+defm allow_editor_placeholders : BoolFOption<"allow-editor-placeholders",
+  "LangOpts->AllowEditorPlaceholders", DefaultsToFalse,
+  ChangedBy,
+  ResetBy>;
 def fallow_unsupported : Flag<["-"], "fallow-unsupported">, Group;
 def fapple_kext : Flag<["-"], "fapple-kext">, Group, 
Flags<[CC1Option]>,
-  HelpText<"Use Apple's kernel extensions ABI">;
-def fapple_pragma_pack : Flag<["-"], "fapple-pragma-pack">, Group, 
Flags<[CC1Option]>,
-  HelpText<"Enable Apple gcc-compatible #pragma pack handling">;
+  HelpText<"Use Apple's kernel extensions ABI">,
+  MarshallingInfoFlag<"LangOpts->AppleKext">;
+defm apple_pragma_pack : BoolFOption<"apple-pragma-pack",
+  "LangOpts->ApplePragmaPack", DefaultsToFalse,
+  ChangedBy,
+  ResetBy>;
 def shared_libsan : Flag<["-"], "shared-libsan">,
   HelpText<"Dynamically link the sanitizer runtime">;
 def stati

[clang] f141d1a - [NFC] Pre-commit test for long-double builtins

2020-12-16 Thread Qiu Chaofan via cfe-commits

Author: Qiu Chaofan
Date: 2020-12-16T17:19:54+08:00
New Revision: f141d1afc5068d5c5e2c47e25a5d4b4914116b92

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

LOG: [NFC] Pre-commit test for long-double builtins

This test reflects clang behavior on long-double type math library
builtins under default or explicit 128-bit long-double options.

Added: 
clang/test/CodeGen/math-builtins-long.c

Modified: 


Removed: 




diff  --git a/clang/test/CodeGen/math-builtins-long.c 
b/clang/test/CodeGen/math-builtins-long.c
new file mode 100644
index ..bf7ebd31
--- /dev/null
+++ b/clang/test/CodeGen/math-builtins-long.c
@@ -0,0 +1,371 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -w -S -o - -emit-llvm %s \
+// RUN:   -fmath-errno | FileCheck %s -check-prefix=F80
+// RUN: %clang_cc1 -triple ppc64le-unknown-unknown -w -S -o - -emit-llvm %s \
+// RUN:   -fmath-errno | FileCheck %s -check-prefix=PPC
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -mlong-double-128 -w -S \
+// RUN:   -o - -emit-llvm %s -fmath-errno | FileCheck %s -check-prefix=X86F128
+// RUN: %clang_cc1 -triple ppc64le-unknown-unknown -mabi=ieeelongdouble -w -S \
+// RUN:   -o - -emit-llvm %s -fmath-errno | FileCheck %s -check-prefix=PPCF128
+
+void bar(long double);
+
+void foo(long double f, long double *l, int *i, const char *c) {
+  // F80: call x86_fp80 @fmodl(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
+  // PPC: call ppc_fp128 @fmodl(ppc_fp128 %{{.+}}, ppc_fp128 %{{.+}})
+  // X86F128: call fp128 @fmodl(fp128 %{{.+}}, fp128 %{{.+}})
+  // PPCF128: call fp128 @fmodl(fp128 %{{.+}}, fp128 %{{.+}})
+  __builtin_fmodl(f,f);
+
+  // F80: call x86_fp80 @atan2l(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
+  // PPC: call ppc_fp128 @atan2l(ppc_fp128 %{{.+}}, ppc_fp128 %{{.+}})
+  // X86F128: call fp128 @atan2l(fp128 %{{.+}}, fp128 %{{.+}})
+  // PPCF128: call fp128 @atan2l(fp128 %{{.+}}, fp128 %{{.+}})
+  __builtin_atan2l(f,f);
+
+  // F80: call x86_fp80 @llvm.copysign.f80(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
+  // PPC: call ppc_fp128 @llvm.copysign.ppcf128(ppc_fp128 %{{.+}}, ppc_fp128 
%{{.+}})
+  // X86F128: call fp128 @llvm.copysign.f128(fp128 %{{.+}}, fp128 %{{.+}})
+  // PPCF128: call fp128 @llvm.copysign.f128(fp128 %{{.+}}, fp128 %{{.+}})
+  __builtin_copysignl(f,f);
+
+  // F80: call x86_fp80 @llvm.fabs.f80(x86_fp80 %{{.+}})
+  // PPC: call ppc_fp128 @llvm.fabs.ppcf128(ppc_fp128 %{{.+}})
+  // X86F128: call fp128 @llvm.fabs.f128(fp128 %{{.+}})
+  // PPCF128: call fp128 @llvm.fabs.f128(fp128 %{{.+}})
+  __builtin_fabsl(f);
+
+  // F80: call x86_fp80 @frexpl(x86_fp80 %{{.+}}, i32* %{{.+}})
+  // PPC: call ppc_fp128 @frexpl(ppc_fp128 %{{.+}}, i32* %{{.+}})
+  // X86F128: call fp128 @frexpl(fp128 %{{.+}}, i32* %{{.+}})
+  // PPCF128: call fp128 @frexpl(fp128 %{{.+}}, i32* %{{.+}})
+  __builtin_frexpl(f,i);
+
+  // F80: store x86_fp80 0xK7FFF8000, x86_fp80*
+  // PPC: store ppc_fp128 0xM7FF0, ppc_fp128*
+  // X86F128: store fp128 0xL7FFF, fp128*
+  // PPCF128: store fp128 0xL7FFF, fp128*
+  *l = __builtin_huge_vall();
+
+  // F80: store x86_fp80 0xK7FFF8000, x86_fp80*
+  // PPC: store ppc_fp128 0xM7FF0, ppc_fp128*
+  // X86F128: store fp128 0xL7FFF, fp128*
+  // PPCF128: store fp128 0xL7FFF, fp128*
+  *l = __builtin_infl();
+
+  // F80: call x86_fp80 @ldexpl(x86_fp80 %{{.+}}, i32 %{{.+}})
+  // PPC: call ppc_fp128 @ldexpl(ppc_fp128 %{{.+}}, {{(signext)?.+}})
+  // X86F128: call fp128 @ldexpl(fp128 %{{.+}}, {{(signext)?.+}})
+  // PPCF128: call fp128 @ldexpl(fp128 %{{.+}}, {{(signext)?.+}})
+  __builtin_ldexpl(f,f);
+
+  // F80: call x86_fp80 @modfl(x86_fp80 %{{.+}}, x86_fp80* %{{.+}})
+  // PPC: call ppc_fp128 @modfl(ppc_fp128 %{{.+}}, ppc_fp128* %{{.+}})
+  // X86F128: call fp128 @modfl(fp128 %{{.+}}, fp128* %{{.+}})
+  // PPCF128: call fp128 @modfl(fp128 %{{.+}}, fp128* %{{.+}})
+  __builtin_modfl(f,l);
+
+  // F80: call x86_fp80 @nanl(i8* %{{.+}})
+  // PPC: call ppc_fp128 @nanl(i8* %{{.+}})
+  // X86F128: call fp128 @nanl(i8* %{{.+}})
+  // PPCF128: call fp128 @nanl(i8* %{{.+}})
+  __builtin_nanl(c);
+
+  // F80: call x86_fp80 @nansl(i8* %{{.+}})
+  // PPC: call ppc_fp128 @nansl(i8* %{{.+}})
+  // X86F128: call fp128 @nansl(i8* %{{.+}})
+  // PPCF128: call fp128 @nansl(i8* %{{.+}})
+  __builtin_nansl(c);
+
+  // F80: call x86_fp80 @powl(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
+  // PPC: call ppc_fp128 @powl(ppc_fp128 %{{.+}}, ppc_fp128 %{{.+}})
+  // X86F128: call fp128 @powl(fp128 %{{.+}}, fp128 %{{.+}})
+  // PPCF128: call fp128 @powl(fp128 %{{.+}}, fp128 %{{.+}})
+  __builtin_powl(f,f);
+
+  // F80: call x86_fp80 @acosl(x86_fp80 

[PATCH] D92080: [Clang] Mutate long-double math builtins into f128 under IEEE-quad

2020-12-16 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf updated this revision to Diff 312153.
qiucf edited the summary of this revision.
qiucf added a comment.

- Diff based on pre-commit
- Restrict to PPC64


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

https://reviews.llvm.org/D92080

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/math-builtins-long.c

Index: clang/test/CodeGen/math-builtins-long.c
===
--- clang/test/CodeGen/math-builtins-long.c
+++ clang/test/CodeGen/math-builtins-long.c
@@ -13,13 +13,13 @@
   // F80: call x86_fp80 @fmodl(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @fmodl(ppc_fp128 %{{.+}}, ppc_fp128 %{{.+}})
   // X86F128: call fp128 @fmodl(fp128 %{{.+}}, fp128 %{{.+}})
-  // PPCF128: call fp128 @fmodl(fp128 %{{.+}}, fp128 %{{.+}})
+  // PPCF128: call fp128 @fmodf128(fp128 %{{.+}}, fp128 %{{.+}})
   __builtin_fmodl(f,f);
 
   // F80: call x86_fp80 @atan2l(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @atan2l(ppc_fp128 %{{.+}}, ppc_fp128 %{{.+}})
   // X86F128: call fp128 @atan2l(fp128 %{{.+}}, fp128 %{{.+}})
-  // PPCF128: call fp128 @atan2l(fp128 %{{.+}}, fp128 %{{.+}})
+  // PPCF128: call fp128 @atan2f128(fp128 %{{.+}}, fp128 %{{.+}})
   __builtin_atan2l(f,f);
 
   // F80: call x86_fp80 @llvm.copysign.f80(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
@@ -37,7 +37,7 @@
   // F80: call x86_fp80 @frexpl(x86_fp80 %{{.+}}, i32* %{{.+}})
   // PPC: call ppc_fp128 @frexpl(ppc_fp128 %{{.+}}, i32* %{{.+}})
   // X86F128: call fp128 @frexpl(fp128 %{{.+}}, i32* %{{.+}})
-  // PPCF128: call fp128 @frexpl(fp128 %{{.+}}, i32* %{{.+}})
+  // PPCF128: call fp128 @frexpf128(fp128 %{{.+}}, i32* %{{.+}})
   __builtin_frexpl(f,i);
 
   // F80: store x86_fp80 0xK7FFF8000, x86_fp80*
@@ -55,73 +55,73 @@
   // F80: call x86_fp80 @ldexpl(x86_fp80 %{{.+}}, i32 %{{.+}})
   // PPC: call ppc_fp128 @ldexpl(ppc_fp128 %{{.+}}, {{(signext)?.+}})
   // X86F128: call fp128 @ldexpl(fp128 %{{.+}}, {{(signext)?.+}})
-  // PPCF128: call fp128 @ldexpl(fp128 %{{.+}}, {{(signext)?.+}})
+  // PPCF128: call fp128 @ldexpf128(fp128 %{{.+}}, {{(signext)?.+}})
   __builtin_ldexpl(f,f);
 
   // F80: call x86_fp80 @modfl(x86_fp80 %{{.+}}, x86_fp80* %{{.+}})
   // PPC: call ppc_fp128 @modfl(ppc_fp128 %{{.+}}, ppc_fp128* %{{.+}})
   // X86F128: call fp128 @modfl(fp128 %{{.+}}, fp128* %{{.+}})
-  // PPCF128: call fp128 @modfl(fp128 %{{.+}}, fp128* %{{.+}})
+  // PPCF128: call fp128 @modff128(fp128 %{{.+}}, fp128* %{{.+}})
   __builtin_modfl(f,l);
 
   // F80: call x86_fp80 @nanl(i8* %{{.+}})
   // PPC: call ppc_fp128 @nanl(i8* %{{.+}})
   // X86F128: call fp128 @nanl(i8* %{{.+}})
-  // PPCF128: call fp128 @nanl(i8* %{{.+}})
+  // PPCF128: call fp128 @nanf128(i8* %{{.+}})
   __builtin_nanl(c);
 
   // F80: call x86_fp80 @nansl(i8* %{{.+}})
   // PPC: call ppc_fp128 @nansl(i8* %{{.+}})
   // X86F128: call fp128 @nansl(i8* %{{.+}})
-  // PPCF128: call fp128 @nansl(i8* %{{.+}})
+  // PPCF128: call fp128 @nansf128(i8* %{{.+}})
   __builtin_nansl(c);
 
   // F80: call x86_fp80 @powl(x86_fp80 %{{.+}}, x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @powl(ppc_fp128 %{{.+}}, ppc_fp128 %{{.+}})
   // X86F128: call fp128 @powl(fp128 %{{.+}}, fp128 %{{.+}})
-  // PPCF128: call fp128 @powl(fp128 %{{.+}}, fp128 %{{.+}})
+  // PPCF128: call fp128 @powf128(fp128 %{{.+}}, fp128 %{{.+}})
   __builtin_powl(f,f);
 
   // F80: call x86_fp80 @acosl(x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @acosl(ppc_fp128 %{{.+}})
   // X86F128: call fp128 @acosl(fp128 %{{.+}})
-  // PPCF128: call fp128 @acosl(fp128 %{{.+}})
+  // PPCF128: call fp128 @acosf128(fp128 %{{.+}})
   __builtin_acosl(f);
 
   // F80: call x86_fp80 @acoshl(x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @acoshl(ppc_fp128 %{{.+}})
   // X86F128: call fp128 @acoshl(fp128 %{{.+}})
-  // PPCF128: call fp128 @acoshl(fp128 %{{.+}})
+  // PPCF128: call fp128 @acoshf128(fp128 %{{.+}})
   __builtin_acoshl(f);
 
   // F80: call x86_fp80 @asinl(x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @asinl(ppc_fp128 %{{.+}})
   // X86F128: call fp128 @asinl(fp128 %{{.+}})
-  // PPCF128: call fp128 @asinl(fp128 %{{.+}})
+  // PPCF128: call fp128 @asinf128(fp128 %{{.+}})
   __builtin_asinl(f);
 
   // F80: call x86_fp80 @asinhl(x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @asinhl(ppc_fp128 %{{.+}})
   // X86F128: call fp128 @asinhl(fp128 %{{.+}})
-  // PPCF128: call fp128 @asinhl(fp128 %{{.+}})
+  // PPCF128: call fp128 @asinhf128(fp128 %{{.+}})
   __builtin_asinhl(f);
 
   // F80: call x86_fp80 @atanl(x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @atanl(ppc_fp128 %{{.+}})
   // X86F128: call fp128 @atanl(fp128 %{{.+}})
-  // PPCF128: call fp128 @atanl(fp128 %{{.+}})
+  // PPCF128: call fp128 @atanf128(fp128 %{{.+}})
   __builtin_atanl(f);
 
   // F80: call x86_fp80 @atanhl(x86_fp80 %{{.+}})
   // PPC: call ppc_fp128 @atanhl(ppc_fp128 %{{.+}})
   // X86F128: call fp128 @atanhl(fp128 %{{.+}})
-  // PPCF128: call fp128 @atanhl(fp128 %{{.+}})
+  // 

[PATCH] D92080: [Clang] Mutate long-double math builtins into f128 under IEEE-quad

2020-12-16 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf added a comment.

In D92080#2449236 , @craig.topper 
wrote:

> D91675  has PowerPC only changes to make the 
> f128 calls get emitted. If you change the frontend in a target independent 
> way as proposed here, won't that make the frontend and backend not match for 
> targets like X86?

Ah, yes. I should keep it as PPC64-only here, with TODO comments for it.


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

https://reviews.llvm.org/D92080

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


[clang] 0da240c - [clang][cli] Port DependencyOutput string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2020-12-16T10:28:37+01:00
New Revision: 0da240c2d050303c99564f1901b0d1548ffe2323

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

LOG: [clang][cli] Port DependencyOutput string based options to new option 
parsing system

Depends on D84186

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 76deb9de708b..dd23d810e388 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -960,11 +960,14 @@ def dM : Flag<["-"], "dM">, Group, 
Flags<[CC1Option]>,
   HelpText<"Print macro definitions in -E mode instead of normal output">;
 def dead__strip : Flag<["-"], "dead_strip">;
 def dependency_file : Separate<["-"], "dependency-file">, Flags<[CC1Option]>,
-  HelpText<"Filename (or -) to write dependency output to">;
+  HelpText<"Filename (or -) to write dependency output to">,
+  MarshallingInfoString<"DependencyOutputOpts.OutputFile">;
 def dependency_dot : Separate<["-"], "dependency-dot">, Flags<[CC1Option]>,
-  HelpText<"Filename to write DOT-formatted header dependencies to">;
+  HelpText<"Filename to write DOT-formatted header dependencies to">,
+  MarshallingInfoString<"DependencyOutputOpts.DOTOutputFile">;
 def module_dependency_dir : Separate<["-"], "module-dependency-dir">,
-  Flags<[CC1Option]>, HelpText<"Directory to dump module dependencies to">;
+  Flags<[CC1Option]>, HelpText<"Directory to dump module dependencies to">,
+  MarshallingInfoString<"DependencyOutputOpts.ModuleDependencyOutputDir">;
 def dsym_dir : JoinedOrSeparate<["-"], "dsym-dir">,
   Flags<[NoXarchOption, RenderAsInput]>,
   HelpText<"Directory to output dSYM's (if any) to">, MetaVarName<"">;
@@ -4514,7 +4517,8 @@ def module_file_deps : Flag<["-"], "module-file-deps">,
   HelpText<"Include module files in dependency output">,
   MarshallingInfoFlag<"DependencyOutputOpts.IncludeModuleFiles">;
 def header_include_file : Separate<["-"], "header-include-file">,
-  HelpText<"Filename (or -) to write header include output to">;
+  HelpText<"Filename (or -) to write header include output to">,
+  MarshallingInfoString<"DependencyOutputOpts.HeaderIncludeOutputFile">;
 def show_includes : Flag<["--"], "show-includes">,
   HelpText<"Print cl.exe style /showIncludes to stdout">;
 

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 2d6cb3bb878f..5fbafa3b2583 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -1447,10 +1447,7 @@ static bool ParseCodeGenArgs(CodeGenOptions &Opts, 
ArgList &Args, InputKind IK,
 
 static void ParseDependencyOutputArgs(DependencyOutputOptions &Opts,
   ArgList &Args) {
-  Opts.OutputFile = std::string(Args.getLastArgValue(OPT_dependency_file));
   Opts.Targets = Args.getAllArgValues(OPT_MT);
-  Opts.HeaderIncludeOutputFile =
-  std::string(Args.getLastArgValue(OPT_header_include_file));
   if (Args.hasArg(OPT_show_includes)) {
 // Writing both /showIncludes and preprocessor output to stdout
 // would produce interleaved output, so use stderr for /showIncludes.
@@ -1462,9 +1459,6 @@ static void 
ParseDependencyOutputArgs(DependencyOutputOptions &Opts,
   } else {
 Opts.ShowIncludesDest = ShowIncludesDestination::None;
   }
-  Opts.DOTOutputFile = std::string(Args.getLastArgValue(OPT_dependency_dot));
-  Opts.ModuleDependencyOutputDir =
-  std::string(Args.getLastArgValue(OPT_module_dependency_dir));
   // Add sanitizer blacklists as extra dependencies.
   // They won't be discovered by the regular preprocessor, so
   // we let make / ninja to know about this implicit dependency.



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


[PATCH] D84187: [clang][cli] Port DependencyOutput string based options to new option parsing system

2020-12-16 Thread Jan Svoboda 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 rG0da240c2d050: [clang][cli] Port DependencyOutput string 
based options to new option parsing… (authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84187

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1447,10 +1447,7 @@
 
 static void ParseDependencyOutputArgs(DependencyOutputOptions &Opts,
   ArgList &Args) {
-  Opts.OutputFile = std::string(Args.getLastArgValue(OPT_dependency_file));
   Opts.Targets = Args.getAllArgValues(OPT_MT);
-  Opts.HeaderIncludeOutputFile =
-  std::string(Args.getLastArgValue(OPT_header_include_file));
   if (Args.hasArg(OPT_show_includes)) {
 // Writing both /showIncludes and preprocessor output to stdout
 // would produce interleaved output, so use stderr for /showIncludes.
@@ -1462,9 +1459,6 @@
   } else {
 Opts.ShowIncludesDest = ShowIncludesDestination::None;
   }
-  Opts.DOTOutputFile = std::string(Args.getLastArgValue(OPT_dependency_dot));
-  Opts.ModuleDependencyOutputDir =
-  std::string(Args.getLastArgValue(OPT_module_dependency_dir));
   // Add sanitizer blacklists as extra dependencies.
   // They won't be discovered by the regular preprocessor, so
   // we let make / ninja to know about this implicit dependency.
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -960,11 +960,14 @@
   HelpText<"Print macro definitions in -E mode instead of normal output">;
 def dead__strip : Flag<["-"], "dead_strip">;
 def dependency_file : Separate<["-"], "dependency-file">, Flags<[CC1Option]>,
-  HelpText<"Filename (or -) to write dependency output to">;
+  HelpText<"Filename (or -) to write dependency output to">,
+  MarshallingInfoString<"DependencyOutputOpts.OutputFile">;
 def dependency_dot : Separate<["-"], "dependency-dot">, Flags<[CC1Option]>,
-  HelpText<"Filename to write DOT-formatted header dependencies to">;
+  HelpText<"Filename to write DOT-formatted header dependencies to">,
+  MarshallingInfoString<"DependencyOutputOpts.DOTOutputFile">;
 def module_dependency_dir : Separate<["-"], "module-dependency-dir">,
-  Flags<[CC1Option]>, HelpText<"Directory to dump module dependencies to">;
+  Flags<[CC1Option]>, HelpText<"Directory to dump module dependencies to">,
+  MarshallingInfoString<"DependencyOutputOpts.ModuleDependencyOutputDir">;
 def dsym_dir : JoinedOrSeparate<["-"], "dsym-dir">,
   Flags<[NoXarchOption, RenderAsInput]>,
   HelpText<"Directory to output dSYM's (if any) to">, MetaVarName<"">;
@@ -4514,7 +4517,8 @@
   HelpText<"Include module files in dependency output">,
   MarshallingInfoFlag<"DependencyOutputOpts.IncludeModuleFiles">;
 def header_include_file : Separate<["-"], "header-include-file">,
-  HelpText<"Filename (or -) to write header include output to">;
+  HelpText<"Filename (or -) to write header include output to">,
+  MarshallingInfoString<"DependencyOutputOpts.HeaderIncludeOutputFile">;
 def show_includes : Flag<["--"], "show-includes">,
   HelpText<"Print cl.exe style /showIncludes to stdout">;
 


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1447,10 +1447,7 @@
 
 static void ParseDependencyOutputArgs(DependencyOutputOptions &Opts,
   ArgList &Args) {
-  Opts.OutputFile = std::string(Args.getLastArgValue(OPT_dependency_file));
   Opts.Targets = Args.getAllArgValues(OPT_MT);
-  Opts.HeaderIncludeOutputFile =
-  std::string(Args.getLastArgValue(OPT_header_include_file));
   if (Args.hasArg(OPT_show_includes)) {
 // Writing both /showIncludes and preprocessor output to stdout
 // would produce interleaved output, so use stderr for /showIncludes.
@@ -1462,9 +1459,6 @@
   } else {
 Opts.ShowIncludesDest = ShowIncludesDestination::None;
   }
-  Opts.DOTOutputFile = std::string(Args.getLastArgValue(OPT_dependency_dot));
-  Opts.ModuleDependencyOutputDir =
-  std::string(Args.getLastArgValue(OPT_module_dependency_dir));
   // Add sanitizer blacklists as extra dependencies.
   // They won't be discovered by the regular preprocessor, so
   // we let make / ninja to know about this implicit dependency.
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/

[PATCH] D92039: [-Wcalled-once-parameter] Introduce 'called_once' attribute

2020-12-16 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 312155.
vsavchenko added a comment.

Add more info to the docs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92039

Files:
  clang/include/clang/Analysis/Analyses/CalledOnceCheck.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/CalledOnceCheck.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaObjC/attr-called-once.m
  clang/test/SemaObjC/warn-called-once.m

Index: clang/test/SemaObjC/warn-called-once.m
===
--- /dev/null
+++ clang/test/SemaObjC/warn-called-once.m
@@ -0,0 +1,1029 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fblocks -fobjc-exceptions -Wcompletion-handler %s
+
+#define NULL (void *)0
+#define nil (id)0
+#define CALLED_ONCE __attribute__((called_once))
+#define NORETURN __attribute__((noreturn))
+
+@protocol NSObject
+@end
+@interface NSObject 
+- (id)copy;
+- (id)class;
+- autorelease;
+@end
+
+typedef unsigned int NSUInteger;
+typedef struct {
+} NSFastEnumerationState;
+
+@interface NSArray <__covariant NSFastEnumeration>
+- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state objects:(id *)stackbuf count:(NSUInteger)len;
+@end
+@interface NSMutableArray : NSArray 
+- addObject:anObject;
+@end
+@class NSString, Protocol;
+extern void NSLog(NSString *format, ...);
+
+void escape(void (^callback)(void));
+void escape_void(void *);
+void indirect_call(void (^callback)(void) CALLED_ONCE);
+void indirect_conv(void (^completionHandler)(void));
+void filler(void);
+void exit(int) NORETURN;
+
+void double_call_one_block(void (^callback)(void) CALLED_ONCE) {
+  callback(); // expected-note{{previous call is here}}
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_one_block_parens(void (^callback)(void) CALLED_ONCE) {
+  (callback)(); // expected-note{{previous call is here}}
+  (callback)(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_one_block_ptr(void (*callback)(void) CALLED_ONCE) {
+  callback(); // expected-note{{previous call is here}}
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_one_block_ptr_deref(void (*callback)(void) CALLED_ONCE) {
+  (*callback)(); // expected-note{{previous call is here}}
+  (*callback)(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void multiple_call_one_block(void (^callback)(void) CALLED_ONCE) {
+  // We don't really need to repeat the same warning for the same parameter.
+  callback(); // no-warning
+  callback(); // no-warning
+  callback(); // no-warning
+  callback(); // expected-note{{previous call is here}}
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_branching_1(int cond, void (^callback)(void) CALLED_ONCE) {
+  if (cond) {
+callback(); // expected-note{{previous call is here}}
+  } else {
+cond += 42;
+  }
+  callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+}
+
+void double_call_branching_2(int cond, void (^callback)(void) CALLED_ONCE) {
+  callback();
+  // expected-note@-1{{previous call is here; set to nil to indicate it cannot be called afterwards}}
+
+  if (cond) {
+callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+  } else {
+cond += 42;
+  }
+}
+
+void double_call_branching_3(int cond, void (^callback)(void) CALLED_ONCE) {
+  if (cond) {
+callback();
+  } else {
+callback();
+  }
+  // no-warning
+}
+
+void double_call_branching_4(int cond1, int cond2, void (^callback)(void) CALLED_ONCE) {
+  if (cond1) {
+cond2 = !cond2;
+  } else {
+callback();
+// expected-note@-1{{previous call is here; set to nil to indicate it cannot be called afterwards}}
+  }
+
+  if (cond2) {
+callback(); // expected-warning{{'callback' parameter marked 'called_once' is called twice}}
+  }
+}
+
+void double_call_loop(int counter, void (^callback)(void) CALLED_ONCE) {
+  while (counter > 0) {
+counter--;
+// Both note and warning are on the same line, which is a common situation
+// in loops.
+callback(); // expected-note{{previous call is here}}
+// expected-warning@-1{{'callback' parameter marked 'called_once' is called twice}}
+  }
+}
+
+void never_called_trivial(void (^callback)(void) CALLED_ONCE) {
+  // expected-warning@-1{{'callback' parameter marked 'called_once' is never called}}

[PATCH] D84186: [clang][cli] Convert Analyzer option string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 312157.
jansvoboda11 added a comment.

Reduce number of instantiations of denormalizeString template


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84186

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  clang/lib/Frontend/CompilerInvocation.cpp
  llvm/include/llvm/Option/OptParser.td

Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -161,6 +161,12 @@
   code Denormalizer = "denormalizeString";
 }
 
+class MarshallingInfoStringInt
+  : MarshallingInfo {
+  code Normalizer = "normalizeStringIntegral<"#type#">";
+  code Denormalizer = "denormalizeString";
+}
+
 class MarshallingInfoFlag
   : MarshallingInfo {
   code Normalizer = "normalizeSimpleFlag";
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -93,6 +93,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -282,12 +283,38 @@
 
 static void denormalizeString(SmallVectorImpl &Args,
   const char *Spelling,
-  CompilerInvocation::StringAllocator SA,
-  unsigned TableIndex, const std::string &Value) {
+  CompilerInvocation::StringAllocator SA, unsigned,
+  Twine Value) {
   Args.push_back(Spelling);
   Args.push_back(SA(Value));
 }
 
+template ::value &&
+   std::is_constructible::value,
+   bool> = false>
+static void denormalizeString(SmallVectorImpl &Args,
+  const char *Spelling,
+  CompilerInvocation::StringAllocator SA,
+  unsigned TableIndex, T Value) {
+  denormalizeString(Args, Spelling, SA, TableIndex, Twine(Value));
+}
+
+template 
+static Optional normalizeStringIntegral(OptSpecifier Opt, int,
+   const ArgList &Args,
+   DiagnosticsEngine &Diags) {
+  auto *Arg = Args.getLastArg(Opt);
+  if (!Arg)
+return None;
+  IntTy Res;
+  if (StringRef(Arg->getValue()).getAsInteger(0, Res)) {
+Diags.Report(diag::err_drv_invalid_int_value)
+<< Arg->getAsString(Args) << Arg->getValue();
+  }
+  return Res;
+}
+
 static Optional normalizeTriple(OptSpecifier Opt, int TableIndex,
  const ArgList &Args,
  DiagnosticsEngine &Diags) {
@@ -522,14 +549,6 @@
 .Case("false", false)
 .Default(false);
 
-  Opts.AnalyzeSpecificFunction =
-  std::string(Args.getLastArgValue(OPT_analyze_function));
-  Opts.maxBlockVisitOnPath =
-  getLastArgIntValue(Args, OPT_analyzer_max_loop, 4, Diags);
-  Opts.InlineMaxStackDepth =
-  getLastArgIntValue(Args, OPT_analyzer_inline_max_stack_depth,
- Opts.InlineMaxStackDepth, Diags);
-
   Opts.CheckersAndPackages.clear();
   for (const Arg *A :
Args.filtered(OPT_analyzer_checker, OPT_analyzer_disable_checker)) {
Index: clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
===
--- clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
+++ clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
@@ -259,8 +259,7 @@
   bool AnalyzerWerror : 1;
 
   /// The inlining stack depth limit.
-  // Cap the stack depth at 4 calls (5 stack frames, base + 4 calls).
-  unsigned InlineMaxStackDepth = 5;
+  unsigned InlineMaxStackDepth;
 
   /// The mode of function selection used during inlining.
   AnalysisInliningMode InliningMode = NoRedundancy;
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4110,7 +4110,8 @@
   HelpText<"Emit verbose output about the analyzer's progress">,
   MarshallingInfoFlag<"AnalyzerOpts->AnalyzerDisplayProgress">;
 def analyze_function : Separate<["-"], "analyze-function">,
-  HelpText<"Run analysis on specific function (for C++ include parameters in name)">;
+  HelpText<"Run analysis on specific function (for C++ include parameters in name)">,
+  MarshallingInfoString<"AnalyzerOpts->AnalyzeSpecificFunction">;
 def analyze_function_EQ : Joined<["-"], "analyze-function=">, Alias;
 def trim_egraph : Flag<["-"], "trim-egraph">,
   HelpText<"Only show error-related paths in the analysis graph">,
@@ -4124,7 +4125,9 @@
 def analyzer_dump_egraph_EQ : Joined<["-"], "analyzer-dump-

[PATCH] D93296: [clang-format] PR35514 brace-init member initializers in function-try-blocks are not formatted correctly

2020-12-16 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius accepted this revision.
curdeius added a comment.

I'd like to see a test with braces inside the try (intoducing scope), just to 
verify it doesn't break.

E.g.:

  verifyFormat("class A {\n"
   "  int a;\n"
   "  A() try : a(0), b{1}, c{2} {\n"
   "{ // New scope.\n"
   "}\n"
   "  } catch (...) {\n"
   "throw;\n"
   "  }\n"
   "};\n");

Otherwise LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93296

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


[PATCH] D93296: [clang-format] PR35514 brace-init member initializers in function-try-blocks are not formatted correctly

2020-12-16 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

In D93296#2457366 , @curdeius wrote:

> I'd like to see a test with braces inside the try (intoducing scope), just to 
> verify it doesn't break.

Sure let me add that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93296

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


[PATCH] D84186: [clang][cli] Convert Analyzer option string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h:261-263
   /// The inlining stack depth limit.
-  // Cap the stack depth at 4 calls (5 stack frames, base + 4 calls).
-  unsigned InlineMaxStackDepth = 5;
+  unsigned InlineMaxStackDepth;
 

dexonsmith wrote:
> Hmm, I wonder if this is entirely better. It's not obvious at all, looking at 
> the code here, whether `InlineMaxStackDepth` can be used without getting 
> initialized at all.
> 
> I agree we should have the default value in two places -- I think removing 
> assignment to 5 is the right thing to do -- but I'm not sure leaving this 
> entirely uninitialized is a good thing. WDYT of initializing it to 0?
I think leaving this uninitialized communicates the fact that it will be 
initialized somewhere else.

If I saw `unsigned InlineMacStackDepth = 0;` and then observed it changing to 
`5` without passing `-analyzer-inline-max-stack-depth=5`, I'd be surprised.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:287
+static void
+denormalizeString(SmallVectorImpl &Args, const char *Spelling,
+  CompilerInvocation::StringAllocator SA, unsigned, T &&Value) 
{

dexonsmith wrote:
> jansvoboda11 wrote:
> > dexonsmith wrote:
> > > jansvoboda11 wrote:
> > > > We should keep an eye on the number of instantiations of this function 
> > > > template (and `normalizeStringIntegral`).
> > > > 
> > > > If it grows, we can employ the SFINAE trick used for 
> > > > `makeFlagToValueNormalizer`.
> > > Does it work to take the parameter as a `Twine` to avoid the template?
> > > ```
> > > static void
> > > denormalizeString(SmallVectorImpl &Args, const char 
> > > *Spelling,
> > >   CompilerInvocation::StringAllocator SA, unsigned, Twine 
> > > Value) {
> > >   Args.push_back(Spelling);
> > >   Args.push_back(SA(Value));
> > > }
> > > ```
> > In general no. The `Twine` constructor is `explicit` for some types 
> > (integers, chars, etc.).
> Okay, then I suggest at least handling the ones that are convertible 
> separately (without the template):
> ```
> static void denormalizeString(..., Twine Value) {
>   Args.push_back(Spelling);
>   Args.push_back(SA(Value));
> }
> 
> templatestd::enable_if_t::value &&
>std::is_constructible::value, bool> = 
> false>
> static void denormalizeString(..., T Value) {
>   denormalizeString(..., Twine(Value));
> }
> ```
> 
That looks good, thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84186

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


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

2020-12-16 Thread Yvan Roux via Phabricator via cfe-commits
yroux created this revision.
yroux added reviewers: paquette, efriedma, samparker.
Herald added a subscriber: inglorion.
yroux requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

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


Repository:
  rG LLVM Github Monorepo

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
@@ -623,6 +623,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,
@@ -1585,3 +1588,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
@@ -6373,26 +6373,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 ||

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

2020-12-16 Thread Balázs Benics via Phabricator via cfe-commits
steakhal marked an inline comment as done.
steakhal added a comment.

I want to highlight, that the 4th part of the stack is not yet done.
Partially because I'm not quite familiar with CTU.
AFAIK, CTU creates compiler invocations, which are going to call Parse at some 
point.
I'm not sure how to configure, apply the callbacks, etc. on the Preprocessor in 
the middle of that process.
I'm also reluctant to pass this domain-specific `MacroExpansionContext` as the 
23rd parameter to that generic function (`ASTUnit::LoadFromCommandLine`).

I'm not even sure if there will be a Preprocessor, which would generate the 
'OnToken' or PPCallbacks calls if we are parsing a PCH or some other serialized 
source.
That would be crucial for this MacroExpansion machinery. I hope you can ensure 
that I'm on the right path.




Comment at: clang/include/clang/Analysis/MacroExpansionContext.h:79-80
+  /// substituted in place of the macro.
+  /// If no macro was expanded at that location, returns an empty
+  /// string.
+  MacroExpansionText

martong wrote:
> I think we should have an Optional as a return type, so we'd be able 
> to detect if no macro expansion happened. (?)
Yes, it depends on what interface we want to provide.
If we expect it to be called on source locations that participate in a macro 
expansion, then it would be somewhat redundant.
I don't mind if it returns an Optional<>.



Comment at: clang/include/clang/Analysis/MacroExpansionContext.h:81
+  /// string.
+  MacroExpansionText
+  getExpandedMacroForLocation(SourceLocation MacroExpansionLoc) const;

martong wrote:
> Could this be `StringRef` also?
We could return a `StringRef`, but that would point to an entry of a DenseMap. 
That could be invalidated later if the preprocessor still generates tokens.

If we say that these calls should be called after the preprocessing is 
completely done, it could just return a `StringRef`.



Comment at: clang/include/clang/Analysis/MacroExpansionContext.h:82
+  MacroExpansionText
+  getExpandedMacroForLocation(SourceLocation MacroExpansionLoc) const;
+

martong wrote:
> `getExpandedText` ? Since what you get back is not a macro anymore.
You are right! I like it.



Comment at: clang/include/clang/Analysis/MacroExpansionContext.h:87-88
+  /// the macro expansion chain from the given location.
+  /// If no macro was expanded at that location, returns an empty
+  /// string.
+  StringRef

martong wrote:
> We should be able to distinguish between no macro expansion (1) and expansion 
> to an empty string (2). So, I think we should have an Optional as 
> a return type.
I'm not sure about this.
If a SourceLocation is not a macro expansion, then the `isFileID()` would 
return false AFAIK.
Otherwise, if the result is an empty string, that means that the macro indeed 
expanded to no tokens.



Comment at: clang/include/clang/Analysis/MacroExpansionContext.h:90
+  StringRef
+  getSubstitutedTextForLocation(SourceLocation MacroExpansionLoc) const;
+

martong wrote:
> `Substituted` is a bit ambiguous to me. What about `getOriginalText` ?
I agree.



Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:22
+: PP(PP), SM(PP.getSourceManager()), LangOpts(LangOpts) {
+  class MacroExpansionRangeRecorder : public PPCallbacks {
+const Preprocessor &PP;

xazax.hun wrote:
> It may be more idiomatic to put classes in an anonymous namespace rather than 
> expanding them in a method.
I tried, but I could not hide the `MacroExpansionRangeRecorder` class as a 
detail.
https://godbolt.org/z/bcYK7x
Let me know if there is a better way to hide details.



Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:39
+
+  SourceLocation ExpansionEnd = [Range, &SM = SM, &MacroName] {
+// If the range is empty, use the length of the macro.

xazax.hun wrote:
> martong wrote:
> > ?
> Why do you need the assignment in `&SM = SM`?
`SM` is an object member.
The lambda should either capture the `this` pointer or a pointer/reference to 
the referred member (`SM`).
I preferred the latter as the lambda doesn't want to access all of the members 
except this one.



Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:94
+  if (it == ExpandedTokens.end())
+return MacroExpansionText("");
+  return it->getSecond();

xazax.hun wrote:
> I am a bit uneasy about this. As far as I understand a macro could be 
> expanded to an empty string. How could the user differentiate between a valid 
> empty expansion and a lookup failure. Also, can this lookup ever fail in a 
> well behaving code? Do we need to add `llvm_unreachable()` or something?
Yes, I should have put an `unreachable` there as you suggested.



Comment at: cla

[PATCH] D92852: [NFC] Reduce include files dependency and AA header cleanup (part 2).

2020-12-16 Thread Daniil Fukalov via Phabricator via cfe-commits
dfukalov added a comment.

Ping...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92852

___
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

2020-12-16 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:22
+: PP(PP), SM(PP.getSourceManager()), LangOpts(LangOpts) {
+  class MacroExpansionRangeRecorder : public PPCallbacks {
+const Preprocessor &PP;

steakhal wrote:
> xazax.hun wrote:
> > It may be more idiomatic to put classes in an anonymous namespace rather 
> > than expanding them in a method.
> I tried, but I could not hide the `MacroExpansionRangeRecorder` class as a 
> detail.
> https://godbolt.org/z/bcYK7x
> Let me know if there is a better way to hide details.
I don't see any problems with the code you linked. What do you mean by could 
not hide it better? I think, it is very common to have utility functions with 
the current file as the visibility. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93222

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


[PATCH] D93314: [clangd] go-to-definition on auto unwraps array/pointer types

2020-12-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall planned changes to this revision.
sammccall added a comment.

In D93314#2455884 , @qchateau wrote:

> Ah good catch, I agree this is the behavior we want.
>
> Concerning cases like `unique_ptr`, the only generic behavior I can think 
> of would be to suggest multiple `LocatedSymbol` when `auto` is deduced to a 
> template class: the template class itself, and all its template type 
> parameters.

Right. There are not-completely-generic options too though :-)

I'm inclined to agree that `unique_ptr` should resolve to both 
`unique_ptr` and `MemoryBuffer`.
But not `std::default_deleter`, and probably not even a custom deleter.

Similarly, maybe `vector` should resolve to both, but I'm not 
sure that holds for all templates (e.g. `lock_guard`).

So I'm leaning towards defining these behaviors for **pointers and containers** 
rather than **templates** per se. There's a nice symmetry with the raw pointer 
and array types that this patch.
(We have some precedent and code for detecting smart pointers, see 
`getPointeeType()` in FindTarget.cpp.)

We could land this as-is (just handling the built-in types) but it will need 
some structural changes for dealing with multiple results (including recursive 
cases like vector) so I'll take a stab at doing all that at once.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93314

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


[PATCH] D93223: [RFC][analyzer] Create MacroExpansionContext member in AnalysisConsumer and pass down to the diagnostics consumers

2020-12-16 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

Thanks for the review.




Comment at: clang/include/clang/Analysis/PathDiagnostic.h:911
 
+void createHTMLSingleFileDiagnosticConsumer(
+PathDiagnosticConsumerOptions DiagOpts,

martong wrote:
> Why do we need this prototype here?
Thanks. I probably accidentally let it there :D I will remove this.
I had a hard time figuring out where and how to modify the signature of this.



Comment at: clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:129
+Plugins(plugins), Injector(injector), CTU(CI),
+MacroExpansions(PP, CI.getLangOpts()) {
 DigestAnalyzerOptions();

xazax.hun wrote:
> This will always record macro related information right? Some of the 
> diagnostic consumers might not ever touch macro expansions. I think it would 
> be great to only record expansions when we actually will end up using them.  
> Alternatively, a benchmark proving the runtime of recording negligible on 
> macro heavy code (boost maybe?) might be sufficient.
To be fair, we already have an analyzer config exactly for this.
If I would introduce a function like `registerForPreprocessor(PP)`, the 
constructor would be freed up to be essentially a noop.
I think I will follow this path.
This approach would fit nicely in the final patch, where I want to put them in 
a map. Default constructability would be a nice property.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93223

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


[PATCH] D93224: [RFC][analyzer] Use the MacroExpansionContext for macro expansions in plists

2020-12-16 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:826-833
+static MacroExpansionContext::MacroExpansionText
+getExpandedMacro(SourceLocation MacroExpansionLoc,
+ const cross_tu::CrossTranslationUnitContext &CTU,
+ const MacroExpansionContext &MacroExpansions,
+ const SourceManager &SM) {
+  if (auto LocAndUnit = CTU.getImportedFromSourceLocation(MacroExpansionLoc)) {
+// TODO: Implement macro expansions for CTU.

I don't like that I will ruin the CTU expansions - even temporarily.
I will probably commit this patch together with the 4th one, where I will use 
the same macro expansion mechanism for CTU too.
So these two patches are for 'logical' separation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93224

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


[PATCH] D92852: [NFC] Reduce include files dependency and AA header cleanup (part 2).

2020-12-16 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon accepted this revision.
RKSimon added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: llvm/lib/Analysis/AliasAnalysis.cpp:685
+  }
+}
+

dfukalov wrote:
> RKSimon wrote:
> > This should probably be pulled out too
> It uses `dyn_cast(I)` so clang-tidy reports //incomplete type 
> 'llvm::CallBase' named in nested name specifier// if the function definition 
> is in header. This is result of removing include Instructions.h from 
> AliasAnalysis.h.
> 
> Actually there is one more same clang-tidy report on `isa` in 
> MemorySSA.h that includes AliasAnalysis.h (and so included Instructions.h 
> through it). I thought to fix it the same way - moving function with 
> `isa` to MemorySSA.cpp
> 
> Or should I leave include Instructions.h in AliasAnalysis.h?
No, moving into a cpp file make sense - sorry for the noise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92852

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


[PATCH] D87030: Adapt CastExpr::getSubExprAsWritten to ConstantExpr

2020-12-16 Thread Stephan Bergmann via Phabricator via cfe-commits
sberg added a comment.

Ping; OK to submit?  (I meanwhile also get this when compiling some code with 
plain Clang, not just with the LibreOffice Clang plugin where I saw it 
originally.)


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

https://reviews.llvm.org/D87030

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


[PATCH] D84668: [clang][cli] Port TargetOpts simple string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:248
+template ::value, bool> = true>
 static void denormalizeSimpleEnum(SmallVectorImpl &Args,

dexonsmith wrote:
> I don't think this needs to be templated; it can just use the same prototype 
> it did before this patch (using `unsigned` directly).
I can remove it. I originally put it in there to be symmetrical with the 
template below.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:264-265
 
+template ::value, bool> = true>
+static void denormalizeSimpleEnum(SmallVectorImpl &Args,

dexonsmith wrote:
> Once the template is gone from the `unsigned` overload above, I wonder if we 
> can use `!std::is_convertible` here, and let the `unsigned` 
> overload directly catch any enums that aren't strongly typed.
Unfortunately, `std::is_convertible::value == false` when `T` is 
an `enum class` (and it's the same for `std::is_constructible::value`): .

I didn't find any type trait in the standard library that would have the same 
semantics as `static_cast`, but we could use something like this: 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84668

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


[PATCH] D84668: [clang][cli] Port TargetOpts simple string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 312171.
jansvoboda11 added a comment.

Remove template


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84668

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -259,6 +259,16 @@
   }
 }
 
+template ::value, bool> = true>
+static void denormalizeSimpleEnum(SmallVectorImpl &Args,
+  const char *Spelling,
+  CompilerInvocation::StringAllocator SA,
+  unsigned TableIndex, T Value) {
+  return denormalizeSimpleEnum(Args, Spelling, SA, TableIndex,
+   static_cast(Value));
+}
+
 static void denormalizeSimpleEnumJoined(SmallVectorImpl &Args,
 const char *Spelling,
 CompilerInvocation::StringAllocator SA,
@@ -3724,28 +3734,7 @@
 
 static void ParseTargetArgs(TargetOptions &Opts, ArgList &Args,
 DiagnosticsEngine &Diags) {
-  Opts.CodeModel = std::string(Args.getLastArgValue(OPT_mcmodel_EQ, "default"));
-  Opts.ABI = std::string(Args.getLastArgValue(OPT_target_abi));
-  if (Arg *A = Args.getLastArg(OPT_meabi)) {
-StringRef Value = A->getValue();
-llvm::EABI EABIVersion = llvm::StringSwitch(Value)
- .Case("default", llvm::EABI::Default)
- .Case("4", llvm::EABI::EABI4)
- .Case("5", llvm::EABI::EABI5)
- .Case("gnu", llvm::EABI::GNU)
- .Default(llvm::EABI::Unknown);
-if (EABIVersion == llvm::EABI::Unknown)
-  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
-<< Value;
-else
-  Opts.EABIVersion = EABIVersion;
-  }
-  Opts.CPU = std::string(Args.getLastArgValue(OPT_target_cpu));
-  Opts.TuneCPU = std::string(Args.getLastArgValue(OPT_tune_cpu));
-  Opts.FPMath = std::string(Args.getLastArgValue(OPT_mfpmath));
   Opts.FeaturesAsWritten = Args.getAllArgValues(OPT_target_feature);
-  Opts.LinkerVersion =
-  std::string(Args.getLastArgValue(OPT_target_linker_version));
   Opts.OpenCLExtensionsAsWritten = Args.getAllArgValues(OPT_cl_ext_EQ);
   Opts.AllowAMDGPUUnsafeFPAtomics =
   Args.hasFlag(options::OPT_munsafe_fp_atomics,
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2603,7 +2603,8 @@
 def mwatchsimulator_version_min_EQ : Joined<["-"], "mwatchsimulator-version-min=">, Alias;
 def march_EQ : Joined<["-"], "march=">, Group, Flags<[CoreOption]>;
 def masm_EQ : Joined<["-"], "masm=">, Group, Flags<[NoXarchOption]>;
-def mcmodel_EQ : Joined<["-"], "mcmodel=">, Group, Flags<[CC1Option]>;
+def mcmodel_EQ : Joined<["-"], "mcmodel=">, Group, Flags<[CC1Option]>,
+  MarshallingInfoString<"TargetOpts->CodeModel", [{std::string("default")}]>;
 def mtls_size_EQ : Joined<["-"], "mtls-size=">, Group, Flags<[NoXarchOption, CC1Option]>,
   HelpText<"Specify bit size of immediate TLS offsets (AArch64 ELF only): "
"12 (for 4KB) | 24 (for 16MB, default) | 32 (for 4GB) | 48 (for 256TB, needs -mcmodel=large)">;
@@ -2669,7 +2670,10 @@
 def mthread_model : Separate<["-"], "mthread-model">, Group, Flags<[CC1Option]>,
   HelpText<"The thread model to use, e.g. posix, single (posix by default)">, Values<"posix,single">;
 def meabi : Separate<["-"], "meabi">, Group, Flags<[CC1Option]>,
-  HelpText<"Set EABI type, e.g. 4, 5 or gnu (default depends on triple)">, Values<"default,4,5,gnu">;
+  HelpText<"Set EABI type, e.g. 4, 5 or gnu (default depends on triple)">, Values<"default,4,5,gnu">,
+  MarshallingInfoString<"TargetOpts->EABIVersion", "Default">,
+  NormalizedValuesScope<"llvm::EABI">,
+  NormalizedValues<["Default", "EABI4", "EABI5", "GNU"]>, AutoNormalizeEnum;
 
 def mno_constant_cfstrings : Flag<["-"], "mno-constant-cfstrings">, Group;
 def mno_global_merge : Flag<["-"], "mno-global-merge">, Group, Flags<[CC1Option]>,
@@ -3935,9 +3939,11 @@
 let Flags = [CC1Option, CC1AsOption, NoDriverOption] in {
 
 def target_cpu : Separate<["-"], "target-cpu">,
-  HelpText<"Target a specific cpu type">;
+  HelpText<"Target a specific cpu type">,
+  MarshallingInfoString<"TargetOpts->CPU">;
 def tune_cpu : Separate<["-"], "tune-cpu">,
-  HelpText<"Tune for a specific cpu type">;
+  HelpText<"Tune for a specific cpu type">,
+  MarshallingInfoString<"TargetOpts->TuneCPU">;
 def target_feature : Separate<["-"], "target-feature">,
   HelpText<"T

[PATCH] D93103: Enable the _ExtInt extension on the BPF Target

2020-12-16 Thread Sean Young via Phabricator via cfe-commits
seanyoung updated this revision to Diff 312172.
seanyoung added a comment.

Add tests cases for _ExtInt on BPF. This makes the _ExtInt testing equivalent 
to the testing on every platform except x86-64.

The use-case is to use _ExtInt on BPF when targeting Solana BPF smart 
contracts. I am writing a solidity to BPF compiler which includes a standard 
library written in C. Solidity has types of 256 bits.

https://github.com/hyperledger-labs/solang/blob/master/stdlib/bigint.c#L378


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93103

Files:
  clang/lib/Basic/Targets/BPF.h
  clang/test/CodeGen/ext-int-cc.c


Index: clang/test/CodeGen/ext-int-cc.c
===
--- clang/test/CodeGen/ext-int-cc.c
+++ clang/test/CodeGen/ext-int-cc.c
@@ -28,6 +28,7 @@
 // RUN: %clang_cc1 -triple arm64_32-apple-ios -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=AARCH64
 // RUN: %clang_cc1 -triple arm64_32-apple-ios -target-abi darwinpcs -O3 
-disable-llvm-passes -emit-llvm -o - %s | FileCheck %s 
--check-prefixes=AARCH64DARWIN
 // RUN: %clang_cc1 -triple arm -O3 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s --check-prefixes=ARM
+// RUN: %clang_cc1 -triple bpf -O3 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s --check-prefixes=BPF
 
 // Make sure 128 and 64 bit versions are passed like integers, and that >128
 // is passed indirectly.
@@ -59,6 +60,7 @@
 // AARCH64: define void @ParamPassing(i129* byval(i129) align 8 %{{.+}}, i128 
%{{.+}}, i64 %{{.+}})
 // AARCH64DARWIN: define void @ParamPassing(i129* byval(i129) align 8 %{{.+}}, 
i128 %{{.+}}, i64 %{{.+}})
 // ARM: define arm_aapcscc void @ParamPassing(i129* byval(i129) align 8 
%{{.+}}, i128* byval(i128) align 8 %{{.+}}, i64 %{{.+}})
+// BPF: define void @ParamPassing(i129* byval(i129) align 8 %{{.+}}, i128 
%{{.+}}, i64 %{{.+}})
 
 void ParamPassing2(_ExtInt(129) a, _ExtInt(127) b, _ExtInt(63) c) {}
 // LIN64: define void @ParamPassing2(i129* byval(i129) align 8 %{{.+}}, i64 
%{{.+}}, i64 %{{.+}}, i64 %{{.+}})
@@ -88,6 +90,7 @@
 // AARCH64: define void @ParamPassing2(i129* byval(i129) align 8 %{{.+}}, i127 
%{{.+}}, i63 %{{.+}})
 // AARCH64DARWIN: define void @ParamPassing2(i129* byval(i129) align 8 
%{{.+}}, i127 %{{.+}}, i63 %{{.+}})
 // ARM: define arm_aapcscc void @ParamPassing2(i129* byval(i129) align 8 
%{{.+}}, i127* byval(i127) align 8 %{{.+}}, i63 %{{.+}})
+// BPF: define void @ParamPassing2(i129* byval(i129) align 8 %{{.+}}, i127 
%{{.+}}, i63 %{{.+}})
 
 // Make sure we follow the signext rules for promotable integer types.
 void ParamPassing3(_ExtInt(15) a, _ExtInt(31) b) {}
@@ -118,6 +121,7 @@
 // AARCH64: define void @ParamPassing3(i15 %{{.+}}, i31 %{{.+}})
 // AARCH64DARWIN: define void @ParamPassing3(i15 signext %{{.+}}, i31 signext 
%{{.+}})
 // ARM: define arm_aapcscc void @ParamPassing3(i15 signext %{{.+}}, i31 
signext %{{.+}})
+// BPF: define void @ParamPassing3(i15 signext %{{.+}}, i31 signext %{{.+}})
 
 _ExtInt(63) ReturnPassing(){}
 // LIN64: define i64 @ReturnPassing(
@@ -147,6 +151,7 @@
 // AARCH64: define i63 @ReturnPassing(
 // AARCH64DARWIN: define i63 @ReturnPassing(
 // ARM: define arm_aapcscc i63 @ReturnPassing(
+// BPF: define i63 @ReturnPassing(
 
 _ExtInt(64) ReturnPassing2(){}
 // LIN64: define i64 @ReturnPassing2(
@@ -176,6 +181,7 @@
 // AARCH64: define i64 @ReturnPassing2(
 // AARCH64DARWIN: define i64 @ReturnPassing2(
 // ARM: define arm_aapcscc i64 @ReturnPassing2(
+// BPF: define i64 @ReturnPassing2(
 
 _ExtInt(127) ReturnPassing3(){}
 // LIN64: define { i64, i64 } @ReturnPassing3(
@@ -207,6 +213,7 @@
 // AARCH64: define i127 @ReturnPassing3(
 // AARCH64DARWIN: define i127 @ReturnPassing3(
 // ARM: define arm_aapcscc void @ReturnPassing3(i127* noalias sret
+// BPF: define i127 @ReturnPassing3(
 
 _ExtInt(128) ReturnPassing4(){}
 // LIN64: define { i64, i64 } @ReturnPassing4(
@@ -236,6 +243,7 @@
 // AARCH64: define i128 @ReturnPassing4(
 // AARCH64DARWIN: define i128 @ReturnPassing4(
 // ARM: define arm_aapcscc void @ReturnPassing4(i128* noalias sret
+// BPF: define i128 @ReturnPassing4(
 
 _ExtInt(129) ReturnPassing5(){}
 // LIN64: define void @ReturnPassing5(i129* noalias sret
@@ -265,6 +273,7 @@
 // AARCH64: define void @ReturnPassing5(i129* noalias sret
 // AARCH64DARWIN: define void @ReturnPassing5(i129* noalias sret
 // ARM: define arm_aapcscc void @ReturnPassing5(i129* noalias sret
+// BPF: define void @ReturnPassing5(i129* noalias sret
 
 // SparcV9 is odd in that it has a return-size limit of 256, not 128 or 64
 // like other platforms, so test to make sure this behavior will still work.
Index: clang/lib/Basic/Targets/BPF.h
===
--- clang/lib/Basic/Targets/BPF.h
+++ clang/lib/Basic/Targets/BPF.h
@@ -96,6 +96,8 @@
 StringRef CPUName(Name);
 return isValidCPUName(CPUName);
 

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

2020-12-16 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:22
+: PP(PP), SM(PP.getSourceManager()), LangOpts(LangOpts) {
+  class MacroExpansionRangeRecorder : public PPCallbacks {
+const Preprocessor &PP;

xazax.hun wrote:
> steakhal wrote:
> > xazax.hun wrote:
> > > It may be more idiomatic to put classes in an anonymous namespace rather 
> > > than expanding them in a method.
> > I tried, but I could not hide the `MacroExpansionRangeRecorder` class as a 
> > detail.
> > https://godbolt.org/z/bcYK7x
> > Let me know if there is a better way to hide details.
> I don't see any problems with the code you linked. What do you mean by could 
> not hide it better? I think, it is very common to have utility functions with 
> the current file as the visibility. 
@steakhal You need to forward declare the class in the detail namespace first 
**within the header** (so both the namespace and the qualified name 
`detail::Class` is introduced), and then the `friend class` declaration works 
as intended, see: https://godbolt.org/z/hs45ze


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93222

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


[PATCH] D84670: Port HeaderSearch simple string options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 commandeered this revision.
jansvoboda11 added a reviewer: dang.
jansvoboda11 added a reviewer: dexonsmith.
jansvoboda11 added a comment.

Taking over this patch, as Daniel is no longer involved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84670

___
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

2020-12-16 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:22
+: PP(PP), SM(PP.getSourceManager()), LangOpts(LangOpts) {
+  class MacroExpansionRangeRecorder : public PPCallbacks {
+const Preprocessor &PP;

whisperity wrote:
> xazax.hun wrote:
> > steakhal wrote:
> > > xazax.hun wrote:
> > > > It may be more idiomatic to put classes in an anonymous namespace 
> > > > rather than expanding them in a method.
> > > I tried, but I could not hide the `MacroExpansionRangeRecorder` class as 
> > > a detail.
> > > https://godbolt.org/z/bcYK7x
> > > Let me know if there is a better way to hide details.
> > I don't see any problems with the code you linked. What do you mean by 
> > could not hide it better? I think, it is very common to have utility 
> > functions with the current file as the visibility. 
> @steakhal You need to forward declare the class in the detail namespace first 
> **within the header** (so both the namespace and the qualified name 
> `detail::Class` is introduced), and then the `friend class` declaration works 
> as intended, see: https://godbolt.org/z/hs45ze
Oh, I see the problem now. Somehow I did not see the error message. I would 
also not mind not hiding the `using ExpansionRangeMap ...` part,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93222

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


[clang] dad07ba - [clang][AArch64][SVE] Avoid going through memory for VLAT <-> VLST casts

2020-12-16 Thread Joe Ellis via cfe-commits

Author: Joe Ellis
Date: 2020-12-16T12:24:32Z
New Revision: dad07baf123e672b1d5d5e7c21e73b92399d5a0c

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

LOG: [clang][AArch64][SVE] Avoid going through memory for VLAT <-> VLST casts

This change makes use of the llvm.vector.extract intrinsic to avoid
going through memory when performing bitcasts between vector-length
agnostic types and vector-length specific types.

Depends on D91362

Reviewed By: c-rhodes

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

Added: 


Modified: 
clang/lib/CodeGen/CGExprScalar.cpp
clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
llvm/include/llvm/IR/IRBuilder.h

Removed: 




diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index 973cefd831e6..c9cf1d0dfd89 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -1996,7 +1996,39 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) {
   }
 }
 
+// If Src is a fixed vector and Dst is a scalable vector, and both have the
+// same element type, use the llvm.experimental.vector.insert intrinsic to
+// perform the bitcast.
+if (const auto *FixedSrc = dyn_cast(SrcTy)) {
+  if (const auto *ScalableDst = dyn_cast(DstTy)) 
{
+if (FixedSrc->getElementType() == ScalableDst->getElementType()) {
+  llvm::Value *UndefVec = llvm::UndefValue::get(DstTy);
+  llvm::Value *Zero = llvm::Constant::getNullValue(CGF.CGM.Int64Ty);
+  return Builder.CreateInsertVector(DstTy, UndefVec, Src, Zero,
+"castScalableSve");
+}
+  }
+}
+
+// If Src is a scalable vector and Dst is a fixed vector, and both have the
+// same element type, use the llvm.experimental.vector.extract intrinsic to
+// perform the bitcast.
+if (const auto *ScalableSrc = dyn_cast(SrcTy)) {
+  if (const auto *FixedDst = dyn_cast(DstTy)) {
+if (ScalableSrc->getElementType() == FixedDst->getElementType()) {
+  llvm::Value *Zero = llvm::Constant::getNullValue(CGF.CGM.Int64Ty);
+  return Builder.CreateExtractVector(DstTy, Src, Zero, "castFixedSve");
+}
+  }
+}
+
 // Perform VLAT <-> VLST bitcast through memory.
+// TODO: since the llvm.experimental.vector.{insert,extract} intrinsics
+//   require the element types of the vectors to be the same, we
+//   need to keep this around for casting between predicates, or more
+//   generally for bitcasts between VLAT <-> VLST where the element
+//   types of the vectors are not the same, until we figure out a 
better
+//   way of doing these casts.
 if ((isa(SrcTy) &&
  isa(DstTy)) ||
 (isa(SrcTy) &&

diff  --git 
a/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c 
b/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
index fed7708c6893..beba6a3f0199 100644
--- a/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
+++ b/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
@@ -51,34 +51,22 @@ vec2048 x2048 = {0, 1, 2, 3, 3 , 2 , 1, 0, 0, 1, 2, 3, 3 , 
2 , 1, 0,
 typedef int8_t vec_int8 __attribute__((vector_size(N / 8)));
 // CHECK128-LABEL: define <16 x i8> @f2(<16 x i8> %x)
 // CHECK128-NEXT:  entry:
-// CHECK128-NEXT:%x.addr = alloca <16 x i8>, align 16
-// CHECK128-NEXT:%saved-call-rvalue = alloca , align 16
-// CHECK128-NEXT:store <16 x i8> %x, <16 x i8>* %x.addr, align 16
-// CHECK128-NEXT:%0 = call  
@llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
-// CHECK128-NEXT:%1 = bitcast <16 x i8>* %x.addr to *
-// CHECK128-NEXT:%2 = load , * %1, 
align 16
-// CHECK128-NEXT:%3 = call  
@llvm.aarch64.sve.asrd.nxv16i8( %0,  %2, 
i32 1)
-// CHECK128-NEXT:store  %3, * 
%saved-call-rvalue, align 16
-// CHECK128-NEXT:%castFixedSve = bitcast * 
%saved-call-rvalue to <16 x i8>*
-// CHECK128-NEXT:%4 = load <16 x i8>, <16 x i8>* %castFixedSve, align 16
-// CHECK128-NEXT:ret <16 x i8> %4
+// CHECK128-NEXT:[[TMP0:%.*]] = call  
@llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+// CHECK128-NEXT:[[CASTSCALABLESVE:%.*]] = call  
@llvm.experimental.vector.insert.nxv16i8.v16i8( undef, <16 x 
i8> [[X:%.*]], i64 0)
+// CHECK128-NEXT:[[TMP1:%.*]] = call  
@llvm.aarch64.sve.asrd.nxv16i8( [[TMP0]],  
[[CASTSCALABLESVE]], i32 1)
+// CHECK128-NEXT:

[PATCH] D92761: [clang][AArch64][SVE] Avoid going through memory for VLAT <-> VLST casts

2020-12-16 Thread Joe Ellis 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 rGdad07baf123e: [clang][AArch64][SVE] Avoid going through 
memory for VLAT <-> VLST casts (authored by joechrisellis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92761

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
  llvm/include/llvm/IR/IRBuilder.h

Index: llvm/include/llvm/IR/IRBuilder.h
===
--- llvm/include/llvm/IR/IRBuilder.h
+++ llvm/include/llvm/IR/IRBuilder.h
@@ -923,6 +923,22 @@
 return CreateBinaryIntrinsic(Intrinsic::maximum, LHS, RHS, nullptr, Name);
   }
 
+  /// Create a call to the experimental.vector.extract intrinsic.
+  CallInst *CreateExtractVector(Type *DstType, Value *SrcVec, Value *Idx,
+const Twine &Name = "") {
+return CreateIntrinsic(Intrinsic::experimental_vector_extract,
+   {DstType, SrcVec->getType()}, {SrcVec, Idx}, nullptr,
+   Name);
+  }
+
+  /// Create a call to the experimental.vector.insert intrinsic.
+  CallInst *CreateInsertVector(Type *DstType, Value *SrcVec, Value *SubVec,
+   Value *Idx, const Twine &Name = "") {
+return CreateIntrinsic(Intrinsic::experimental_vector_insert,
+   {DstType, SubVec->getType()}, {SrcVec, SubVec, Idx},
+   nullptr, Name);
+  }
+
 private:
   /// Create a call to a masked intrinsic with given Id.
   CallInst *CreateMaskedIntrinsic(Intrinsic::ID Id, ArrayRef Ops,
Index: clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
@@ -21,40 +21,28 @@
 
 // CHECK-128-LABEL: @write_global_i64(
 // CHECK-128-NEXT:  entry:
-// CHECK-128-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-128-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-128-NEXT:[[TMP0:%.*]] = bitcast * [[V_ADDR]] to <2 x i64>*
-// CHECK-128-NEXT:[[TMP1:%.*]] = load <2 x i64>, <2 x i64>* [[TMP0]], align 16, [[TBAA10:!tbaa !.*]]
-// CHECK-128-NEXT:store <2 x i64> [[TMP1]], <2 x i64>* @global_i64, align 16, [[TBAA10]]
+// CHECK-128-NEXT:[[CASTFIXEDSVE:%.*]] = call <2 x i64> @llvm.experimental.vector.extract.v2i64.nxv2i64( [[V:%.*]], i64 0)
+// CHECK-128-NEXT:store <2 x i64> [[CASTFIXEDSVE]], <2 x i64>* @global_i64, align 16, [[TBAA6:!tbaa !.*]]
 // CHECK-128-NEXT:ret void
 //
 // CHECK-512-LABEL: @write_global_i64(
 // CHECK-512-NEXT:  entry:
-// CHECK-512-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-512-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-512-NEXT:[[TMP0:%.*]] = bitcast * [[V_ADDR]] to <8 x i64>*
-// CHECK-512-NEXT:[[TMP1:%.*]] = load <8 x i64>, <8 x i64>* [[TMP0]], align 16, [[TBAA10:!tbaa !.*]]
-// CHECK-512-NEXT:store <8 x i64> [[TMP1]], <8 x i64>* @global_i64, align 16, [[TBAA10]]
+// CHECK-512-NEXT:[[CASTFIXEDSVE:%.*]] = call <8 x i64> @llvm.experimental.vector.extract.v8i64.nxv2i64( [[V:%.*]], i64 0)
+// CHECK-512-NEXT:store <8 x i64> [[CASTFIXEDSVE]], <8 x i64>* @global_i64, align 16, [[TBAA6:!tbaa !.*]]
 // CHECK-512-NEXT:ret void
 //
 void write_global_i64(svint64_t v) { global_i64 = v; }
 
 // CHECK-128-LABEL: @write_global_bf16(
 // CHECK-128-NEXT:  entry:
-// CHECK-128-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-128-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA11:!tbaa !.*]]
-// CHECK-128-NEXT:[[TMP0:%.*]] = bitcast * [[V_ADDR]] to <8 x bfloat>*
-// CHECK-128-NEXT:[[TMP1:%.*]] = load <8 x bfloat>, <8 x bfloat>* [[TMP0]], align 16, [[TBAA10]]
-// CHECK-128-NEXT:store <8 x bfloat> [[TMP1]], <8 x bfloat>* @global_bf16, align 16, [[TBAA10]]
+// CHECK-128-NEXT:[[CASTFIXEDSVE:%.*]] = call <8 x bfloat> @llvm.experimental.vector.extract.v8bf16.nxv8bf16( [[V:%.*]], i64 0)
+// CHECK-128-NEXT:store <8 x bfloat> [[CASTFIXEDSVE]], <8 x bfloat>* @global_bf16, align 16, [[TBAA6]]
 // CHECK-128-NEXT:ret void
 //
 // CHECK-512-LABEL: @write_global_bf16(
 // CHECK-512-NEXT:  entry:
-// CHECK-512-NEXT:[[V_ADDR:%.*]] = alloca , align 16
-// CHECK-512-NEXT:store  [[V:%.*]], * [[V_ADDR]], align 16, [[TBAA11:!tbaa !.*]]
-// CHECK-512-NEXT:[[TMP0:%.*]] = bitcast * [[V_ADDR]] to <32 x bfloat>*
-// CHECK-512-NEXT:[[TMP1:%.*

[PATCH] D84670: [clang][cli] Port HeaderSearch simple string options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 312176.
jansvoboda11 added a comment.

Rebase, undo unnecessary move of options


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84670

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -2028,10 +2028,8 @@
 
 static void ParseHeaderSearchArgs(HeaderSearchOptions &Opts, ArgList &Args,
   const std::string &WorkingDir) {
-  Opts.Sysroot = std::string(Args.getLastArgValue(OPT_isysroot, "/"));
   if (const Arg *A = Args.getLastArg(OPT_stdlib_EQ))
 Opts.UseLibcxx = (strcmp(A->getValue(), "libc++") == 0);
-  Opts.ResourceDir = std::string(Args.getLastArgValue(OPT_resource_dir));
 
   // Canonicalize -fmodules-cache-path before storing it.
   SmallString<128> P(Args.getLastArgValue(OPT_fmodules_cache_path));
@@ -2044,8 +2042,6 @@
   llvm::sys::path::remove_dots(P);
   Opts.ModuleCachePath = std::string(P.str());
 
-  Opts.ModuleUserBuildPath =
-  std::string(Args.getLastArgValue(OPT_fmodules_user_build_path));
   // Only the -fmodule-file== form.
   for (const auto *A : Args.filtered(OPT_fmodule_file)) {
 StringRef Val = A->getValue();
@@ -2057,14 +2053,6 @@
   }
   for (const auto *A : Args.filtered(OPT_fprebuilt_module_path))
 Opts.AddPrebuiltModulePath(A->getValue());
-  Opts.ModuleCachePruneInterval =
-  getLastArgIntValue(Args, OPT_fmodules_prune_interval, 7 * 24 * 60 * 60);
-  Opts.ModuleCachePruneAfter =
-  getLastArgIntValue(Args, OPT_fmodules_prune_after, 31 * 24 * 60 * 60);
-  Opts.BuildSessionTimestamp =
-  getLastArgUInt64Value(Args, OPT_fbuild_session_timestamp, 0);
-  if (const Arg *A = Args.getLastArg(OPT_fmodule_format_EQ))
-Opts.ModuleFormat = A->getValue();
 
   for (const auto *A : Args.filtered(OPT_fmodules_ignore_macro)) {
 StringRef MacroDef = A->getValue();
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1797,7 +1797,8 @@
   HelpText<"Specify the module cache path">;
 def fmodules_user_build_path : Separate<["-"], "fmodules-user-build-path">, Group,
   Flags<[NoXarchOption, CC1Option]>, MetaVarName<"">,
-  HelpText<"Specify the module user build path">;
+  HelpText<"Specify the module user build path">,
+  MarshallingInfoString<"HeaderSearchOpts->ModuleUserBuildPath">;
 def fprebuilt_module_path : Joined<["-"], "fprebuilt-module-path=">, Group,
   Flags<[NoXarchOption, CC1Option]>, MetaVarName<"">,
   HelpText<"Specify the prebuilt module path">;
@@ -1806,16 +1807,19 @@
   [NoXarchOption, CC1Option], "HeaderSearchOpts->EnablePrebuiltImplicitModules">;
 def fmodules_prune_interval : Joined<["-"], "fmodules-prune-interval=">, Group,
   Flags<[CC1Option]>, MetaVarName<"">,
-  HelpText<"Specify the interval (in seconds) between attempts to prune the module cache">;
+  HelpText<"Specify the interval (in seconds) between attempts to prune the module cache">,
+  MarshallingInfoStringInt<"HeaderSearchOpts->ModuleCachePruneInterval", "7 * 24 * 60 * 60">;
 def fmodules_prune_after : Joined<["-"], "fmodules-prune-after=">, Group,
   Flags<[CC1Option]>, MetaVarName<"">,
-  HelpText<"Specify the interval (in seconds) after which a module file will be considered unused">;
+  HelpText<"Specify the interval (in seconds) after which a module file will be considered unused">,
+  MarshallingInfoStringInt<"HeaderSearchOpts->ModuleCachePruneAfter", "31 * 24 *60 * 60">;
 def fmodules_search_all : Flag <["-"], "fmodules-search-all">, Group,
   Flags<[NoXarchOption, CC1Option]>,
   HelpText<"Search even non-imported modules to resolve references">;
 def fbuild_session_timestamp : Joined<["-"], "fbuild-session-timestamp=">,
   Group, Flags<[CC1Option]>, MetaVarName<"">,
-  HelpText<"Time when the current build session started">;
+  HelpText<"Time when the current build session started">,
+  MarshallingInfoStringInt<"HeaderSearchOpts->BuildSessionTimestamp">;
 def fbuild_session_file : Joined<["-"], "fbuild-session-file=">,
   Group, MetaVarName<"">,
   HelpText<"Use the last modification time of  as the build session timestamp">;
@@ -2602,7 +2606,8 @@
 def iquote : JoinedOrSeparate<["-"], "iquote">, Group, Flags<[CC1Option]>,
   HelpText<"Add directory to QUOTE include search path">, MetaVarName<"">;
 def isysroot : JoinedOrSeparate<["-"], "isysroot">, Group, Flags<[CC1Option]>,
-  HelpText<"Set the system root directory (usually /)">, MetaVarName<"">;
+  HelpText<"Set the system root directory (usually /)">, MetaVarName<"">,
+  MarshallingInfoString<"HeaderSearchOpts->Sysroot", [{std::string("/")}]>;
 def isystem : JoinedOr

[PATCH] D92920: [clang-tidy] Add a diagnostic callback to parseConfiguration

2020-12-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LG!




Comment at: clang-tools-extra/clang-tidy/ClangTidyOptions.cpp:400
+DiagCallback Handler) {
+  llvm::yaml::Input Input(Config, nullptr, Handler ? diagHandlerImpl : nullptr,
+  &Handler);

njames93 wrote:
> aaron.ballman wrote:
> > njames93 wrote:
> > > aaron.ballman wrote:
> > > > njames93 wrote:
> > > > > aaron.ballman wrote:
> > > > > > njames93 wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > Would it make sense to require `Handler` to be nonnull with an 
> > > > > > > > assertion?
> > > > > > > Wasn't sure which way to go with that one, happy to use an assert 
> > > > > > > if you think it's a good idea
> > > > > > Now that I understand the use for this change better, I think the 
> > > > > > code is good as-is.
> > > > > Whoops, just changed it to assert
> > > > Heh, sorry about that! Before changing it again, let's make sure we 
> > > > agree. My thinking is: this is a general API (rather than a specific 
> > > > one only to be used internally) and not every caller may care about 
> > > > reporting diagnostics; the error return code is sufficient to tell any 
> > > > caller whether the parsing was successful or not.
> > > That's pretty much it, For external users. If they don't care about 
> > > capturing the diagnostics then the `parseConfiguration` function should 
> > > be used. If they do care and call this new function with an empty 
> > > callable, they have probably made a mistake. 
> > Okay, then I apologize for the churn, but can you go back to accepting a 
> > null input (and a test case for it)? With that, I think the patch LG.
> With a null handler, we can't capture any test output to validate anything.
I meant more just to demonstrate that it's a supported part of the interface 
and won't crash, assert, or do bad things. If you don't think it will be that 
useful, I don't insist.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92920

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


[PATCH] D93314: [clangd] go-to-definition on auto unwraps array/pointer types

2020-12-16 Thread Quentin Chateau via Phabricator via cfe-commits
qchateau added a comment.

> So I'm leaning towards defining these behaviors for **pointers and 
> containers** rather than **templates** per se. There's a nice symmetry with 
> the raw pointer and array types that this patch.
> (We have some precedent and code for detecting smart pointers, see 
> `getPointeeType()` in FindTarget.cpp.)

If you think it's fine to have specific code using heuristics to try to find 
what the user expects, then **pointers and containers** sounds like a good 
target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93314

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


[PATCH] D91980: [OpenMP] Add initial support for `omp [begin/end] assumes`

2020-12-16 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

In D91980#2456637 , @jdoerfert wrote:

> In D91980#2456600 , @thakis wrote:
>
>> In addition to the build error, it also broke check-clang everywhere as far 
>> as I can tell.
>> mac: http://45.33.8.238/macm1/292/step_6.txt
>> linux: http://45.33.8.238/linux/35399/step_7.txt
>> win: http://45.33.8.238/win/29934/step_7.txt
>
> I think I fixed 2 errors but I'm unsure about the linux one. I changed one 
> test and I'll try it again as I find a workaround for gcc-5

The same tests fail on linux and mac and win at these links:

  Clang :: OpenMP/assumes_codegen.cpp (win, mac/m1)
  Clang :: OpenMP/assumes_include_nvptx.cpp (linux, mac/x86, mac/m1)

(mac/x86 link: http://45.33.8.238/mac/25261/step_7.txt)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91980

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


[PATCH] D93393: [clangd] Ignore the static index refs from the dynamic index files.

2020-12-16 Thread Aleksandr Platonov via Phabricator via cfe-commits
ArcsinX created this revision.
Herald added subscribers: usaxena95, kadircet, arphaman.
ArcsinX requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

This patch fixes the following problem:

- open a file with references to the symbol `Foo`
- remove all references to `Foo` (from the dynamic index).
- `MergedIndex::refs()` result will contain positions of removed references 
(from the static index).

Idea of this patch is to keep a set of files which were used during index build 
inside the index.
Thus at processing the static index references we can check if the file of 
processing reference is a part the dynamic index or not.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93393

Files:
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/index/Index.cpp
  clang-tools-extra/clangd/index/Index.h
  clang-tools-extra/clangd/index/MemIndex.cpp
  clang-tools-extra/clangd/index/MemIndex.h
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/index/Merge.h
  clang-tools-extra/clangd/index/ProjectAware.cpp
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/clangd/index/dex/Dex.h
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/DexTests.cpp
  clang-tools-extra/clangd/unittests/IndexTests.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/TestFS.cpp

Index: clang-tools-extra/clangd/unittests/TestFS.cpp
===
--- clang-tools-extra/clangd/unittests/TestFS.cpp
+++ clang-tools-extra/clangd/unittests/TestFS.cpp
@@ -99,8 +99,9 @@
   llvm::Expected
   getAbsolutePath(llvm::StringRef /*Authority*/, llvm::StringRef Body,
   llvm::StringRef HintPath) const override {
-if (!HintPath.startswith(testRoot()))
-  return error("Hint path doesn't start with test root: {0}", HintPath);
+if (!HintPath.empty() && !HintPath.startswith(testRoot()))
+  return error("Hint path is not empty and doesn't start with {0}: {1}",
+   testRoot(), HintPath);
 if (!Body.consume_front("/"))
   return error("Body of an unittest: URI must start with '/'");
 llvm::SmallString<16> Path(Body.begin(), Body.end());
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -1237,6 +1237,9 @@
 void relations(const RelationsRequest &Req,
llvm::function_ref
Callback) const override {}
+
+bool hasFile(llvm::StringRef) const override { return false; }
+
 size_t estimateMemoryUsage() const override { return 0; }
   } PIndex;
   Results = rename({MainCode.point(),
@@ -1285,6 +1288,9 @@
 void relations(const RelationsRequest &,
llvm::function_ref)
 const override {}
+
+bool hasFile(llvm::StringRef) const override { return false; }
+
 size_t estimateMemoryUsage() const override { return 0; }
 Ref ReturnedRef;
   } DIndex(XRefInBarCC);
Index: clang-tools-extra/clangd/unittests/IndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -224,6 +224,19 @@
   EXPECT_THAT(lookup(*I, SymbolID("ns::nonono")), UnorderedElementsAre());
 }
 
+TEST(MemIndexTest, hasFile) {
+  SymbolSlab Symbols;
+  RefSlab Refs;
+  auto Size = Symbols.bytes() + Refs.bytes();
+  auto Data = std::make_pair(std::move(Symbols), std::move(Refs));
+  llvm::StringSet<> Files = {testPath("foo.cc"), testPath("bar.cc")};
+  MemIndex I(std::move(Data.first), std::move(Data.second), RelationSlab(),
+ std::move(Files), std::move(Data), Size);
+  EXPECT_TRUE(I.hasFile("unittest:///foo.cc"));
+  EXPECT_TRUE(I.hasFile("unittest:///bar.cc"));
+  EXPECT_FALSE(I.hasFile("unittest:///foobar.cc"));
+}
+
 TEST(MemIndexTest, TemplateSpecialization) {
   SymbolSlab::Builder B;
 
@@ -367,7 +380,7 @@
   Test.Code = std::string(Test1Code.code());
   Test.Filename = "test.cc";
   auto AST = Test.build();
-  Dyn.updateMain(Test.Filename, AST);
+  Dyn.updateMain(testPath(Test.Filename), AST);
 
   // Build static index for test.cc.
   Test.HeaderCode = HeaderCode;
@@ -375,7 +388,7 @@
   Test.Filename = "test.cc";
   auto StaticAST = Test.build();
   // Add stale refs for test.cc.
-  StaticIndex.updateMain(Test.Filename, StaticAST);
+  StaticIndex.updateMain(testPath(Test.Filename), StaticAST);
 
   // Add refs for test2.cc
   Annotations Test2Code(R"(class $Foo[[Foo]] {};)");
@@ -384,7 +397,7 @@
   Test2.Code = std::string(Test2Code.code());
   Test2.Filename = "test2.cc";
   StaticAST = Test2.build();

[PATCH] D91944: OpenMP 5.0 metadirective

2020-12-16 Thread Deepak Eachempati via Phabricator via cfe-commits
dreachem added a comment.

In D91944#2414364 , @jdoerfert wrote:

> This looks close to an OpenMP 5.0 implementation. I left comments inlined.
>
> We need tests that show how non-selected alternatives *do not* impact the 
> program. As an example, a template instantiation inside of a non-selected 
> alternative is not actually performed.
>
> We also need test with ill-formed metadirectives.

@jdoerfert I'm still trying to understand this thing regarding template 
instantiations. The spec says that a directive variant associated with a when 
clause can only affect the program if it is a dynamic replacement candidate. I 
had assumed this is referring to the runtime behavior of the program, and not 
(for instance) whether a compiler error is emitted due to a failing static 
assert.

Also, in order to determine what are the dynamic replacement candidates, and 
their order, all specified score expressions would need to be evaluated.  Then, 
you'd need to evaluate the static context selectors, in decreasing order of 
their score, to find which one is the last dynamic replacement candidate. So I 
think template instantiations could be possible for those expressions, even if 
the corresponding variants aren't selected?




Comment at: clang/include/clang/AST/StmtOpenMP.h:373
+///
+class OMPMetaDirective final : public OMPExecutableDirective {
+  friend class ASTStmtReader;

ABataev wrote:
> alokmishra.besu wrote:
> > ABataev wrote:
> > > I think, metadirective should be a kind of a container for different 
> > > sub-directives. The problem is that that subdirectives could be 
> > > completely different, they may capture different variables, using 
> > > different capture kind (by value or by reference) etc.So, you need to 
> > > generate each possible sub-directive independently and store them in the 
> > > meta directive node. Otherwise you won't be able to generate the code 
> > > correctly.
> > In OpenMP 5.0, we do not need to generate every sub-directive. Rather we 
> > need to select one (or none) directive and replace metadirective with it. 
> > So this is not needed.
> > Yes with future specifications we will need to include a list of all valid 
> > directives which need to be resolved at runtime. That is when we will need 
> > to generate and store multiple sub-directives inside the OMPMetaDirective 
> > class.  
> I think you still need to do it even for 5.0. I don't mean y need to emit the 
> code for every sub-directive, but to generate them in the AST. Even in the 
> example above, `when(user={condition(N>10)}` is used in the template and `N` 
> is a template argument, the chosen directive can be selected on the 
> instantiation and, thus, the original templated directive has to contain all 
> possible sub-directives.
r


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91944

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


[PATCH] D84671: Port LangOpts simple string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 commandeered this revision.
jansvoboda11 added a reviewer: dang.
jansvoboda11 added a reviewer: dexonsmith.
jansvoboda11 added a comment.

Taking over this patch, as Daniel is no longer involved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84671

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


[PATCH] D84671: Port LangOpts simple string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 312192.
jansvoboda11 added a comment.

Rebase, move options to their original lines


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84671

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -353,7 +353,8 @@
 }
 
 static void FixupInvocation(CompilerInvocation &Invocation,
-DiagnosticsEngine &Diags) {
+DiagnosticsEngine &Diags,
+InputArgList &Args) {
   LangOptions &LangOpts = *Invocation.getLangOpts();
   DiagnosticOptions &DiagOpts = Invocation.getDiagnosticOpts();
   CodeGenOptions &CodeGenOpts = Invocation.getCodeGenOpts();
@@ -367,10 +368,12 @@
 
   LangOpts.ForceEmitVTables = CodeGenOpts.ForceEmitVTables;
   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();
 
   if (LangOpts.getExceptionHandling() != llvm::ExceptionHandling::None &&
   T.isWindowsMSVCEnvironment())
@@ -379,6 +382,28 @@
 
   if (LangOpts.AppleKext && !LangOpts.CPlusPlus)
 Diags.Report(diag::warn_c_kext);
+
+  if (LangOpts.NewAlignOverride &&
+  !llvm::isPowerOf2_32(LangOpts.NewAlignOverride)) {
+Arg *A = Args.getLastArg(OPT_fnew_alignment_EQ);
+Diags.Report(diag::err_fe_invalid_alignment)
+<< A->getAsString(Args) << A->getValue();
+LangOpts.NewAlignOverride = 0;
+  }
+
+  if (Arg *A = Args.getLastArg(OPT_fdefault_calling_conv_EQ)) {
+auto DefaultCC = LangOpts.getDefaultCallingConv();
+
+bool emitError = (DefaultCC == LangOptions::DCC_FastCall ||
+  DefaultCC == LangOptions::DCC_StdCall) &&
+ Arch != llvm::Triple::x86;
+emitError |= (DefaultCC == LangOptions::DCC_VectorCall ||
+  DefaultCC == LangOptions::DCC_RegCall) &&
+ !T.isX86();
+if (emitError)
+  Diags.Report(diag::err_drv_argument_not_allowed_with)
+  << A->getSpelling() << T.getTriple();
+  }
 }
 
 //===--===//
@@ -2618,24 +2643,6 @@
   Opts.GNUInline = 1;
   }
 
-  if (const auto *A = Args.getLastArg(OPT_fcf_runtime_abi_EQ))
-Opts.CFRuntime =
-llvm::StringSwitch(A->getValue())
-.Cases("unspecified", "standalone", "objc",
-   LangOptions::CoreFoundationABI::ObjectiveC)
-.Cases("swift", "swift-5.0",
-   LangOptions::CoreFoundationABI::Swift5_0)
-.Case("swift-4.2", LangOptions::CoreFoundationABI::Swift4_2)
-.Case("swift-4.1", LangOptions::CoreFoundationABI::Swift4_1)
-.Default(LangOptions::CoreFoundationABI::ObjectiveC);
-
-  // The value-visibility mode defaults to "default".
-  if (Arg *visOpt = Args.getLastArg(OPT_fvisibility)) {
-Opts.setValueVisibilityMode(parseVisibility(visOpt, Args, Diags));
-  } else {
-Opts.setValueVisibilityMode(DefaultVisibility);
-  }
-
   // The type-visibility mode defaults to the value-visibility mode.
   if (Arg *typeVisOpt = Args.getLastArg(OPT_ftype_visibility)) {
 Opts.setTypeVisibilityMode(parseVisibility(typeVisOpt, Args, Diags));
@@ -2709,20 +2716,6 @@
   Opts.DollarIdents = Args.hasFlag(OPT_fdollars_in_identifiers,
OPT_fno_dollars_in_identifiers,
Opts.DollarIdents);
-  Opts.setVtorDispMode(
-  MSVtorDispMode(getLastArgIntValue(Args, OPT_vtordisp_mode_EQ, 1, Diags)));
-  if (Arg *A = Args.getLastArg(OPT_flax_vector_conversions_EQ)) {
-using LaxKind = LangOptions::LaxVectorConversionKind;
-if (auto Kind = llvm::StringSwitch>(A->getValue())
-.Case("none", LaxKind::None)
-.Case("integer", LaxKind::Integer)
-.Case("all", LaxKind::All)
-.Default(llvm::None))
-  Opts.setLaxVectorConversions(*Kind);
-else
-  Diags.Report(diag::err_drv_invalid_value)
-  << A->getAsString(Args) << A->getValue();
-  }
 
   // -ffixed-point
   Opts.FixedPoint =
@@ -2765,15 +2758,6 @@
   Opts.CharIsSigned = Opts.OpenCL || !Args.hasArg(OPT_fno_signed_char);
   Opts.WChar = Opts.CPlusPlus && !Args.hasArg(OPT_fno_wchar);
   Opts.Char8 = Args.hasFlag(OPT_fchar8__t, OPT_fno_char8__t, Opts.CPlusPlus20);
-  if (const Arg *A = Args.getLastArg(OPT_fwchar_type_EQ)) {
-Opts.WCharSize = llvm::StringSwitch(A->getValue())
-   

[PATCH] D92800: [Clang] Make nomerge attribute a function attribute as well as a statement attribute.

2020-12-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1321
   let Documentation = [NoMergeDocs];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+  let SimpleHandler = 1;

Related to my comments in ClangAttrEmitter.cpp, I think you should make these 
changes instead.



Comment at: clang/test/CodeGen/attr-nomerge.cpp:73
+// CHECK-DAG: attributes #[[ATTR2]] = {{{.*}}nomerge{{.*}}}
+// CHECK-DAG: attributes #[[ATTR3]] = {{{.*}}nomerge{{.*}}}

zequanwu wrote:
> aaron.ballman wrote:
> > Can you also add a test case to demonstrate that inheriting the attribute 
> > on a later redeclaration works? It can either be a codegen test or an AST 
> > dump test.
> Do you mean something like this? 
Close. I was thinking something like:
```
int g(int i); // No attr

void something() {
  // call g() here
}

[[clang::nomerge]] int g(int i);

void something_else() {
  // call g() here
}

int g(int i) { return i; }

void something_else_again() {
  // call g() here
}
```
So this tests that the attribute is inherited on redeclarations properly and it 
also tests the merging behavior when the declaration may not have yet had the 
attribute attached.



Comment at: clang/utils/TableGen/ClangAttrEmitter.cpp:3438-3439
   }
+  if (DeclOrStmt)
+DiagList.push_back("statements");
 }

I think this will do the wrong thing when the subject list has more than one 
entry (I think this will add `statements` to the list once for each subject). 
As an experiment, can you add `ObjCMethod` to the list of subjects for 
`NoMerge` in Attr.td? Do the resulting diagnostics list "statements" once or 
twice?

Thinking a bit deeper on this -- I think my original advice may have been too 
ambitious (we don't yet have support for automatically grabbing the names of 
statements for diagnostics like we do for declarations). Trying to add that as 
part of this patch would be a big ask, so I think a better approach is to use a 
custom diagnostic in Attr.td. I'll add a comment there to this effect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92800

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


[PATCH] D92663: [clangd] Add hot-reload of compile_commands.json and compile_flags.txt

2020-12-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall updated this revision to Diff 312193.
sammccall marked 7 inline comments as done.
sammccall added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92663

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp

Index: clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
===
--- clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -11,8 +11,10 @@
 #include "Matchers.h"
 #include "TestFS.h"
 #include "support/Path.h"
+#include "support/ThreadsafeFS.h"
 #include "clang/Tooling/CompilationDatabase.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
@@ -23,6 +25,7 @@
 #include "llvm/Support/raw_ostream.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 #include 
 #include 
 
@@ -40,7 +43,8 @@
 using ::testing::UnorderedElementsAre;
 
 TEST(GlobalCompilationDatabaseTest, FallbackCommand) {
-  DirectoryBasedGlobalCompilationDatabase DB(None);
+  MockFS TFS;
+  DirectoryBasedGlobalCompilationDatabase DB(TFS);
   auto Cmd = DB.getFallbackCommand(testPath("foo/bar.cc"));
   EXPECT_EQ(Cmd.Directory, testPath("foo"));
   EXPECT_THAT(Cmd.CommandLine, ElementsAre("clang", testPath("foo/bar.cc")));
@@ -166,6 +170,7 @@
 }
 
 // Allows placement of files for tests and cleans them up after.
+// FIXME: GlobalCompilationDatabase is mostly VFS-clean now, switch to MockFS?
 class ScratchFS {
   llvm::SmallString<128> Root;
 
@@ -238,13 +243,14 @@
   ]
   )cdb";
   ScratchFS FS;
+  RealThreadsafeFS TFS;
   FS.write("compile_commands.json", CDBOuter);
   FS.write("build/compile_commands.json", CDBInner);
 
   // Note that gen2.cc goes missing with our following model, not sure this
   // happens in practice though.
   {
-DirectoryBasedGlobalCompilationDatabase DB(llvm::None);
+DirectoryBasedGlobalCompilationDatabase DB(TFS);
 std::vector DiscoveredFiles;
 auto Sub =
 DB.watch([&DiscoveredFiles](const std::vector Changes) {
@@ -262,7 +268,9 @@
 
   // With a custom compile commands dir.
   {
-DirectoryBasedGlobalCompilationDatabase DB(FS.root().str());
+DirectoryBasedGlobalCompilationDatabase::Options Opts(TFS);
+Opts.CompileCommandsDir = FS.root().str();
+DirectoryBasedGlobalCompilationDatabase DB(Opts);
 std::vector DiscoveredFiles;
 auto Sub =
 DB.watch([&DiscoveredFiles](const std::vector Changes) {
@@ -282,17 +290,34 @@
 
 TEST(GlobalCompilationDatabaseTest, BuildDir) {
   ScratchFS FS;
+  RealThreadsafeFS TFS;
   auto Command = [&](llvm::StringRef Relative) {
-return DirectoryBasedGlobalCompilationDatabase(llvm::None)
+DirectoryBasedGlobalCompilationDatabase::Options Opts(TFS);
+return DirectoryBasedGlobalCompilationDatabase(Opts)
 .getCompileCommand(FS.path(Relative))
 .getValueOr(tooling::CompileCommand())
 .CommandLine;
   };
   EXPECT_THAT(Command("x/foo.cc"), IsEmpty());
-  FS.write("x/build/compile_flags.txt", "-DXYZZY");
+  const char *const CDB =
+  R"cdb(
+  [
+{
+  "file": "{0}/x/foo.cc",
+  "command": "clang -DXYZZY {0}/x/foo.cc",
+  "directory": "{0}",
+},
+{
+  "file": "{0}/bar.cc",
+  "command": "clang -DXYZZY {0}/bar.cc",
+  "directory": "{0}",
+}
+  ]
+  )cdb";
+  FS.write("x/build/compile_commands.json", CDB);
   EXPECT_THAT(Command("x/foo.cc"), Contains("-DXYZZY"));
   EXPECT_THAT(Command("bar.cc"), IsEmpty())
-  << "x/build/compile_flags.txt only applicable to x/";
+  << "x/build/compile_flags.json only applicable to x/";
 }
 
 TEST(GlobalCompilationDatabaseTest, NonCanonicalFilenames) {
@@ -330,5 +355,108 @@
   EXPECT_EQ(DB.getProjectInfo(Header)->SourceRoot, testRoot());
 }
 } // namespace
+
+// Friend test has access to internals.
+class DirectoryBasedGlobalCompilationDatabaseCacheTest
+: public ::testing::Test {
+protected:
+  std::shared_ptr
+  lookupCDB(const DirectoryBasedGlobalCompilationDatabase &GDB,
+llvm::StringRef Path,
+std::chrono::steady_clock::time_point FreshTime) {
+DirectoryBasedGlobalCompilationDatabase::CDBLookupRequest Req;
+Req.FileName = Path;
+Req.FreshTime = Req.FreshTimeMissing = FreshTime;
+if (auto Result = GDB.lookupCDB(Req))
+  return std::move(Result->CDB);
+return nullptr;
+  }
+};
+
+// Matches non-null CDBs which include the specified flag.
+MATCHER_P2(hasFlag, Flag, Path, "

[PATCH] D92663: [clangd] Add hot-reload of compile_commands.json and compile_flags.txt

2020-12-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/GlobalCompilationDatabase.cpp:206
+  auto Stat = FS.status(Path);
+  if (!Stat || !Stat->isRegularFile()) {
+Size = NoFileCached;

adamcz wrote:
> Here's a fun thought: what if this is a network or otherwise magical 
> filesystem (like a FUSE) and may be temporarily unavailable (due to expiring 
> credentials, network issues, maybe your machine just woke up from suspend and 
> needs to reconnect). 
> 
> Do you think it makes sense to check for things like ENOACCES, ENOKEY, ESTALE 
> and treat them as transient?
Maybe in some cases, it depends a bit on the details...

The decision we're making here is really "retry on next access" vs "retry in 30 
seconds".
The biggest point of the delay is that when loading background index shards 
(each corresponding to a source file), we check for each of them whether the 
stored compile commands are still valid (if not, we still load the shard, but 
schedule a rebuild). If we stat each possible cdb+config+etc each time, it 
significantly increases time before the index becomes available.

With this in mind, I don't think forcing ENOACCESS and ENOKEY to try every time 
is a good idea - the FS might have come back but probably not (user action is 
probably required). ESTALE sounds more plausible, but I don't know the details 
there. I'd probably avoid the complexity of this until we have concrete use 
cases where this is causing problems (e.g. ESTALE isn't portably available 
through std::error_code AFAIK).

In practice if the CDB is on an unavailable network FS then the sources/shards 
probably are too so we never really get here, though there can be exceptions



Comment at: clang-tools-extra/clangd/GlobalCompilationDatabase.cpp:217
+  if (!Buf || (*Buf)->getBufferSize() != Stat->getSize()) {
+Size = NoFileCached;
+elog("Failed to read {0}: {1}", Path,

adamcz wrote:
> Why throw away the information we have? Better keep the cached metadata 
> around, transient error here could mean the build system is re-creating the 
> file, but it may end up being identical to what we already read, it's just 
> that someone re-run cmake or something.
Good point, done.

Of course this relies on us getting "lucky" and seeing two different sizes for 
the file between the calls. If it's being written then we could e.g. see it 
with size 0 on both stat and read, and then we'll throw away the content.

The way around this would be to e.g. call an unparseable file a transient error 
(reuse cached value), which requires some structural changes here I think. What 
do you think about that? (I think this would help with compile_commands.json 
but not compile_flags.txt)
Another way would be to handle a size of 0 as a special case (presumed 
invalid), which may catch the practical cases.



Comment at: 
clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp:424
+"directory": "{0}/foo",
+  }])json",
+testRoot());

adamcz wrote:
> Can you add a couple of calls to test the modtime and size comparison? Like, 
> maybe change DBAZ to DFOO and see that it's picked up despite size being the 
> same if mtime changed?
Done - I'd forgotten we had mtime support in TestFS. Also added some more 
comments to the tests as the list gets longer.

(While writing the original test, I had overwritten -DFOO with -DBAR and spent 
a while debugging why it didn't reload - oops!)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92663

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


[PATCH] D93258: [amdgpu] Default to code object v3

2020-12-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield updated this revision to Diff 312196.
JonChesterfield added a comment.

- Remove hard coded version numbers in tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93258

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/hip-autolink.hip
  clang/test/Driver/hip-code-object-version.hip
  clang/test/Driver/hip-device-compile.hip
  clang/test/Driver/hip-host-cpu-features.hip
  clang/test/Driver/hip-rdc-device-only.hip
  clang/test/Driver/hip-target-id.hip
  clang/test/Driver/hip-toolchain-mllvm.hip
  clang/test/Driver/hip-toolchain-no-rdc.hip
  clang/test/Driver/hip-toolchain-opt.hip
  clang/test/Driver/hip-toolchain-rdc-separate.hip
  clang/test/Driver/hip-toolchain-rdc-static-lib.hip
  clang/test/Driver/hip-toolchain-rdc.hip
  llvm/docs/AMDGPUUsage.rst

Index: llvm/docs/AMDGPUUsage.rst
===
--- llvm/docs/AMDGPUUsage.rst
+++ llvm/docs/AMDGPUUsage.rst
@@ -911,12 +911,12 @@
 
   * ``ELFABIVERSION_AMDGPU_HSA_V3`` is used to specify the version of AMD HSA
 runtime ABI for code object V3. Specify using the Clang option
-``-mcode-object-version=3``.
+``-mcode-object-version=3``. This is the default code object
+version if not specified.
 
   * ``ELFABIVERSION_AMDGPU_HSA_V4`` is used to specify the version of AMD HSA
 runtime ABI for code object V4. Specify using the Clang option
-``-mcode-object-version=4``. This is the default code object
-version if not specified.
+``-mcode-object-version=4``.
 
   * ``ELFABIVERSION_AMDGPU_PAL`` is used to specify the version of AMD PAL
 runtime ABI.
@@ -2871,10 +2871,6 @@
 Code Object V3 Metadata
 +++
 
-.. warning::
-  Code object V3 is not the default code object version emitted by this version
-  of LLVM.
-
 Code object V3 to V4 metadata is specified by the ``NT_AMDGPU_METADATA`` note
 record (see :ref:`amdgpu-note-records-v3-v4`).
 
@@ -3279,6 +3275,10 @@
 Code Object V4 Metadata
 +++
 
+.. warning::
+  Code object V4 is not the default code object version emitted by this version
+  of LLVM.
+
 Code object V4 metadata is the same as
 :ref:`amdgpu-amdhsa-code-object-metadata-v3` with the changes and additions
 defined in table :ref:`amdgpu-amdhsa-code-object-metadata-map-table-v3`.
Index: clang/test/Driver/hip-toolchain-rdc.hip
===
--- clang/test/Driver/hip-toolchain-rdc.hip
+++ clang/test/Driver/hip-toolchain-rdc.hip
@@ -32,7 +32,7 @@
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // generate image for device side path on gfx803
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -43,7 +43,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC1:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
@@ -62,7 +62,7 @@
 // CHECK-SAME: "-o" "[[IMG_DEV1:.*.out]]" [[A_BC1]] [[B_BC1]]
 
 // generate image for device side path on gfx900
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -72,7 +72,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC2:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
Index: clang/test/Driver/hip-toolchain-rdc-static-lib.hip
===
--- clang/test/Driver/hip-toolchain-rdc-static-lib.hip
+++ clang/test/Driver/hip-toolchain-rdc-static-lib.hip
@@ -26,7 +26,7 @@
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // generate image for device side path on gfx803
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amd

[PATCH] D93110: [analyzer] Implement a first version of suppressions via attributes

2020-12-16 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporter.cpp:2907
+// start with it.
+llvm::SmallVector Stack{DynTypedNode::create(*BugStmt)};
+

jkorous wrote:
> Since IIUC a node can have multiple parents - does that mean we could end up 
> traversing a node multiple times?
> BTW do you have an example of a node that have multiple parents?
The vast majority of AST nodes have exactly one parent.  As for the nodes that 
do have multiple parents, I only know about `InitListExpr`.
And yes, I think we can end up traversing a node multiple times, but no one 
seems to be bothered by that



Comment at: clang/lib/StaticAnalyzer/Core/BugReporter.cpp:2936
+  // Let's continue with the current node's parent(s).
+  for (const auto &Parent : AC.getParents(Current)) {
+Stack.push_back(Parent);

jkorous wrote:
> There's a note for `ASTContext::getParents`:
> 
> "New callers should use ParentMapContext::getParents() directly."
> 
> https://clang.llvm.org/doxygen/classclang_1_1ASTContext.html#a32d11844fdb82310b9059784fd4ceb6b
> 
> Shall we do that?
Sure!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93110

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


[PATCH] D20689: [clang-tidy] Add 'readability-suspicious-call-argument' check

2020-12-16 Thread Whisperity via Phabricator via cfe-commits
whisperity added a reviewer: aaron.ballman.
whisperity added a comment.

Right, let's bump. I've checked the output of the checker on a set of test 
projects (our usual testbed, I should say) which contains around 15 projects, 
half of which was C and the other half C++. All projects were analysed 
independently in a virtual machine. All projects were analysed after checking 
out the //latest release tag// that was closest to Jan 2019. (I know this 
sounds dated, but the whole reproduction image was originally constructed for 
another checker I'm working on, and I did not wish to re-do the whole //"What 
is needed to install this particular version?"// pipeline.) The more important 
thing is that //releases// were analysed, which should, in theory, 
under-approximate the findings because releases are generally more polished 
than in-the-works code. The check was run as-is (sans a minor rebase issue that 
does not affect functionality) currently in the patch, namely, Diff 259508 
.

In total, I had received **194 reports** (129 unique (1)). From this, I had 
found **8** (7 unique) **true positives** (marked //Confirmed bug// in 
CodeChecker terms), where something is visibly wrong with the call.
From this, there were 3 in a project where the called function's //comment// 
said that //"The order of arguments <> and <> does not matter."//, however, 
because this can never be figured out totally from the checker, I regarded the 
swapped call as a true positive. The fact that they had to seemingly create, 
inside the called function, some logic to detect and handle the swap shows that 
something was going wrong with the code's design for a long time.

In addition to these findings, I have identified **122** (75 unique) function 
call sites where the report about the potential swap (and the similarity to a 
//different// parameter name) is justifiable because the **understandability** 
of the code (especially to someone who is an outsider from virtually all of the 
projects analysed (2)) **is hindered** by the poor choice of argument or 
parameter names. The conclusions from these cases (marked //Intentional// in 
the CodeChecker database) are consistent with those drawn in [Pradel2013] and 
[Liu2016].

Now, onto the **false positives**. There were **64** (47 unique) cases. 
However, these cases can be further broken down into different categories, 
which I wasn't able to tally easily as CodeChecker only supports 3 unique 
categories, not infinite ones.

- Some of the false positives are what one would say "borderline": if the 
person reading the code reads it accurately, the reported "swap" does not fall 
into the //understandability issue// category. However, a famous case of this 
is from Postgres: `reloid` (IIRC, meaning **rel**ation **o**wner **id**) and 
`roleid` (**role** (user) **id**) are the names of args/params of some 
functions. They are not swapped in the calls that exist in the code, but the 
similarity (swapping only 2 letters) makes it very easy to typo or misread the 
thing. In Postgres, there were 7 such cases.
- Approximately 5+5 cases are false positives but can be dealt with in 
heuristics. However, across the 17 projects, they do not account for a sizeable 
amount of cases.
  - Recursive function calls should be ignored. (This was mentioned in 
[Rice2017].)
  - Swapped and not-swapped calls appearing close to one another (i.e. 
constructs like `b ? f(x,y) : f(y,x)`) should be ignored too. This seems a bit 
harder to implement.
- There is a **bug** in the check's current implementation when calls from/to 
`operator()` is handled. (3) I'll look into fixing this.
- Binary operators should be ignored from reporting in general. Their 
parameters tend to have generic names, and the reports created from them is 
confusing.

Another generic observation is that the check's output is pretty wonky and hard 
to read at a glance, but this should be easy to fix. In addition, the 
observation of [Rice2017] about ignoring "patterned names" (i.e. `arg1, arg2, 
...`) seems like a useful thing to add to the implementation, even though I had 
no findings //at all// where "ignoring patterned names" would've squelched a 
false positive report.

Agreeably, this check is limited compared to the previously linked [Rice2017], 
as it only checks the names in the call, not all variables in the surrounding 
context.



//(1)//: I'm not exactly sure as to what "report uniqueing" in CodeChecker 
precisely does these days, but basically it uses the context of the bug and the 
checker message and whatnot to create a hash for the bug - "unique reports" 
mode shows each report belonging to the same hash only once.
//(2)//: From the set of test projects, I only have some hands-on experience 
with parts of LLVM and Apache Xerces.
//(3)//: Codes similar in nature to the following example of exact value 
forwarding to the call operator seems to still trigger the check. I have yet to

[PATCH] D93395: [clang][cli] Remove -f[no-]trapping-math from -cc1 command line

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith.
Herald added a subscriber: dang.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch removes the `-f[no-]trapping-math` flags from the `-cc1` command 
line. They are currently ignored in the command line parser anyways.

This does not remove `-f[no-]trapping-math` from the driver command line. The 
driver flags are being used and affect the compilation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93395

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/fpconstrained.c
  clang/test/CodeGen/fpconstrained.cpp
  clang/test/CodeGen/noexceptionsfpmath.c
  clang/test/CodeGenCUDA/propagate-metadata.cu
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c
  clang/test/Parser/fp-floatcontrol-syntax.cpp

Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -19,9 +19,9 @@
 }
 #endif
 
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -fdenormal-fp-math=preserve-sign,preserve-sign -ftrapping-math -fsyntax-only %s -DDEFAULT -verify
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fdenormal-fp-math=preserve-sign,preserve-sign -fsyntax-only %s -DDEFAULT -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=fast -DPRECISE -verify
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ftrapping-math -ffp-contract=off -frounding-math -ffp-exception-behavior=strict -DSTRICT -verify
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=off -frounding-math -ffp-exception-behavior=strict -DSTRICT -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -menable-no-infs -menable-no-nans -menable-unsafe-fp-math -fno-signed-zeros -mreassociate -freciprocal-math -ffp-contract=fast -ffast-math -ffinite-math-only -fsyntax-only %s -DFAST -verify
 double a = 0.0;
 double b = 1.0;
Index: clang/test/Driver/fp-model.c
===
--- clang/test/Driver/fp-model.c
+++ clang/test/Driver/fp-model.c
@@ -80,7 +80,6 @@
 // RUN: %clang -### -ftrapping-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-TRAP %s
 // CHECK-TRAP: "-cc1"
-// CHECK-TRAP: "-ftrapping-math"
 // CHECK-TRAP: "-ffp-exception-behavior=strict"
 
 // RUN: %clang -### -nostdinc -ffp-model=fast -c %s 2>&1 \
@@ -106,16 +105,9 @@
 // RUN: %clang -### -nostdinc -ffp-model=strict -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-FPM-STRICT %s
 // CHECK-FPM-STRICT: "-cc1"
-// CHECK-FPM-STRICT: "-ftrapping-math"
 // CHECK-FPM-STRICT: "-frounding-math"
 // CHECK-FPM-STRICT: "-ffp-exception-behavior=strict"
 
-// RUN: %clang -### -nostdinc -ftrapping-math -ffp-exception-behavior=ignore -c %s 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-TRAP-IGNORE %s
-// CHECK-TRAP-IGNORE: "-cc1"
-// CHECK-TRAP-IGNORE: "-fno-rounding-math"
-// CHECK-TRAP-IGNORE: "-ffp-exception-behavior=ignore"
-
 
 // RUN: %clang -### -nostdinc -ffp-exception-behavior=strict -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-FEB-STRICT %s
Index: clang/test/Driver/fast-math.c
===
--- clang/test/Driver/fast-math.c
+++ clang/test/Driver/fast-math.c
@@ -292,10 +292,6 @@
 // CHECK-NO-REASSOC-NO-UNSAFE-MATH: "-o"
 
 
-// RUN: %clang -### -ftrapping-math -fno-trapping-math -c %s 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-NO-TRAPPING-MATH %s
-// CHECK-NO-TRAPPING-MATH: "-fno-trapping-math"
-
 // This isn't fast-math, but the option is handled in the same place as other FP params.
 // Last option wins, and strict behavior is assumed by default. 
 
Index: clang/test/CodeGenCUDA/propagate-metadata.cu
===
--- clang/test/CodeGenCUDA/propagate-metadata.cu
+++ clang/test/CodeGenCUDA/propagate-metadata.cu
@@ -4,28 +4,24 @@
 //
 // In particular, we check that ftz and unsafe-math are propagated into the
 // bitcode library as appropriate.
-//
-// In addition, we set -ftrapping-math on the bitcode library, but then set
-// -fno-trapping-math on the main compilations, and ensure that the latter flag
-// overrides the flag on the bitcode library.
 
 // Build the bitcode library.  This is not built in CUDA mode, otherwise it
 // might have incompatible attributes.  This mirrors how libdevice is built.
-// RUN: %clang_cc1 -x c++ -fconvergent-functions -emit-llvm-bc -ftrapping-math -DLIB \
+// RUN: %clang_cc1 -x c++ -fconvergent-functions -emit-llvm-bc -DLIB \
 // RUN:   %s -o %t.bc -triple nvptx-unknown-unknown
 
 // RUN: %clang_cc1 -x cuda %s -emit-llvm -mlink-builtin-bitcode %t.bc -o - \
-// RUN:   -fno-trapping-ma

[PATCH] D93395: [clang][cli] Remove -f[no-]trapping-math from -cc1 command line

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3080
   }
   Opts.setFPExceptionMode(FPEB);
 

The parsing of `OPT_ftrapping_math` and `OPT_fno_trapping_math` is immediately 
overwritten here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93395

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


[PATCH] D20689: [clang-tidy] Add 'readability-suspicious-call-argument' check

2020-12-16 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

But of course, after having written all of that, I forgot to upload the results 
themselves... 😲 F14738535: SuspiciousCall.sqlite 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D20689

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


[PATCH] D92955: [openmp] Remove clause from OMPKinds.def and use OMP.td info

2020-12-16 Thread Valentin Clement via Phabricator via cfe-commits
clementval added a comment.

Ping since there was a phab email delivery problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92955

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


[PATCH] D93258: [amdgpu] Default to code object v3

2020-12-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

@yaxunl Please see Gerrit 456139 for a close approximation to the test changes 
here. I don't think hip should be hard coding a version number in tests that 
don't care about it, so would like to move trunk and internal to a regex.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93258

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


[PATCH] D93395: [clang][cli] Remove -f[no-]trapping-math from -cc1 command line

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a reviewer: SjoerdMeijer.
jansvoboda11 added a subscriber: SjoerdMeijer.
jansvoboda11 added a comment.

Tagging @SjoerdMeijer, as these flags were pulled into the `-cc1` command-line 
in his patch: D23840 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93395

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


[clang] 95b2dab - [Sema] Fix a miscompile by retaining array qualifiers when folding VLAs to constant arrays

2020-12-16 Thread Erik Pilkington via cfe-commits

Author: Erik Pilkington
Date: 2020-12-16T10:01:24-05:00
New Revision: 95b2dab199100f5a86d3f73a995afea879886d65

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

LOG: [Sema] Fix a miscompile by retaining array qualifiers when folding VLAs to 
constant arrays

rdar://72243125

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

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/test/SemaObjC/arc.m

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 0031f874c05a..6c438f319991 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -5965,8 +5965,9 @@ static QualType 
TryToFixInvalidVariablyModifiedType(QualType T,
 return QualType();
   }
 
-  return Context.getConstantArrayType(ElemTy, Res, VLATy->getSizeExpr(),
-  ArrayType::Normal, 0);
+  QualType FoldedArrayType = Context.getConstantArrayType(
+  ElemTy, Res, VLATy->getSizeExpr(), ArrayType::Normal, 0);
+  return Qs.apply(Context, FoldedArrayType);
 }
 
 static void

diff  --git a/clang/test/SemaObjC/arc.m b/clang/test/SemaObjC/arc.m
index fe5db9ce5384..bcd2f995622c 100644
--- a/clang/test/SemaObjC/arc.m
+++ b/clang/test/SemaObjC/arc.m
@@ -839,3 +839,15 @@ void block_capture_autoreleasing(A * __autoreleasing *a,
 (void)*l;
   }();
 }
+
+void test_vla_fold_keeps_strong(void) {
+  const unsigned bounds = 1;
+
+  static id array[bounds]; // expected-warning {{variable length array folded 
to constant array as an extension}}
+  typedef __typeof__(array) array_type;
+  typedef id __strong array_type[1];
+
+  static id weak_array[bounds] __weak; // expected-warning {{variable length 
array folded to constant array as an extension}}
+  typedef __typeof__(weak_array) weak_array_type;
+  typedef id __weak weak_array_type[1];
+}



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


[clang] 92d6e80 - NFC: balance a quote in AttrDocs.td

2020-12-16 Thread Erik Pilkington via cfe-commits

Author: Erik Pilkington
Date: 2020-12-16T10:01:24-05:00
New Revision: 92d6e8001e20d6d0f457ac7cab8b64f3b1a131bf

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

LOG: NFC: balance a quote in AttrDocs.td

This was confusing my editor.

Added: 


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

Removed: 




diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index a65964e94bf1..4f8cd8ecd86f 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -3346,7 +3346,7 @@ As ``global_device`` and ``global_host`` are a subset of
 ``__global/opencl_global`` address spaces it is allowed to convert
 ``global_device`` and ``global_host`` address spaces to
 ``__global/opencl_global`` address spaces (following ISO/IEC TR 18037 5.1.3
-"Address space nesting and rules for pointers).
+"Address space nesting and rules for pointers").
   }];
 }
 



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


[PATCH] D93247: [Sema] Fix a miscompile by retaining array qualifiers when folding VLAs to constant arrays

2020-12-16 Thread Erik Pilkington via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG95b2dab19910: [Sema] Fix a miscompile by retaining array 
qualifiers when folding VLAs to… (authored by erik.pilkington).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93247

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaObjC/arc.m


Index: clang/test/SemaObjC/arc.m
===
--- clang/test/SemaObjC/arc.m
+++ clang/test/SemaObjC/arc.m
@@ -839,3 +839,15 @@
 (void)*l;
   }();
 }
+
+void test_vla_fold_keeps_strong(void) {
+  const unsigned bounds = 1;
+
+  static id array[bounds]; // expected-warning {{variable length array folded 
to constant array as an extension}}
+  typedef __typeof__(array) array_type;
+  typedef id __strong array_type[1];
+
+  static id weak_array[bounds] __weak; // expected-warning {{variable length 
array folded to constant array as an extension}}
+  typedef __typeof__(weak_array) weak_array_type;
+  typedef id __weak weak_array_type[1];
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -5965,8 +5965,9 @@
 return QualType();
   }
 
-  return Context.getConstantArrayType(ElemTy, Res, VLATy->getSizeExpr(),
-  ArrayType::Normal, 0);
+  QualType FoldedArrayType = Context.getConstantArrayType(
+  ElemTy, Res, VLATy->getSizeExpr(), ArrayType::Normal, 0);
+  return Qs.apply(Context, FoldedArrayType);
 }
 
 static void


Index: clang/test/SemaObjC/arc.m
===
--- clang/test/SemaObjC/arc.m
+++ clang/test/SemaObjC/arc.m
@@ -839,3 +839,15 @@
 (void)*l;
   }();
 }
+
+void test_vla_fold_keeps_strong(void) {
+  const unsigned bounds = 1;
+
+  static id array[bounds]; // expected-warning {{variable length array folded to constant array as an extension}}
+  typedef __typeof__(array) array_type;
+  typedef id __strong array_type[1];
+
+  static id weak_array[bounds] __weak; // expected-warning {{variable length array folded to constant array as an extension}}
+  typedef __typeof__(weak_array) weak_array_type;
+  typedef id __weak weak_array_type[1];
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -5965,8 +5965,9 @@
 return QualType();
   }
 
-  return Context.getConstantArrayType(ElemTy, Res, VLATy->getSizeExpr(),
-  ArrayType::Normal, 0);
+  QualType FoldedArrayType = Context.getConstantArrayType(
+  ElemTy, Res, VLATy->getSizeExpr(), ArrayType::Normal, 0);
+  return Qs.apply(Context, FoldedArrayType);
 }
 
 static void
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D92039: [-Wcalled-once-parameter] Introduce 'called_once' attribute

2020-12-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Is the attribute considered to be a property of the parameter or a property of 
the function the parameter is declared in? e.g.,

  void someOtherFunc(void (^cb)(void)) {
if (something())
  cb();
  }
  
  void barWithCallback(void (^callback)(void) __attribute__((called_once))) {
someOtherFunc(callback);
  }

Should code like that also diagnose given that `callback` is not called on 
every code path? From the test cases you have, it looks like you explicitly 
allow this code without diagnosing it, which suggests the attribute is really a 
property of the function and not a property of the parameter. This in turn 
makes me wonder whether a better design is for `-Wcompletion-handler` to 
diagnose any function with a completion handler-like parameter if the parameter 
is not called exactly once within the function, and the user marks the 
functions that should be exempt from the checking rather than marking the 
parameters that should be checked (or does this have too many false positives 
in practice)? Alternatively, should the check be implemented as a clang static 
analyzer check that tracks an annotated parameter across the inter-procedural 
CFG and diagnoses such code?




Comment at: clang/include/clang/Basic/AttrDocs.td:5133-5134
+
+This attribute is useful for API developers who want to double-check if they
+implemented their method correctly.
+

Oh, I was thinking this attribute was enabling some optimization opportunities 
or doing something more than just acting as a marker to please check this 
function's correctness for some properties. This means that the programmer has 
to annotate their code and enable the warning flag in order for either the 
attribute or the warning flag to have effect, which feels a bit surprising to 
me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92039

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


[PATCH] D84672: Port PreprocessorOpts simple string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 commandeered this revision.
jansvoboda11 added a reviewer: dang.
jansvoboda11 added a reviewer: dexonsmith.
jansvoboda11 added a comment.

Taking over this patch, as Daniel is no longer involved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84672

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


[PATCH] D84672: [clang][cli] Port PreprocessorOpts simple string based options to new option parsing system

2020-12-16 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 312205.
jansvoboda11 added a comment.

Rebase, undo unnecessary move of options


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84672

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3274,11 +3274,8 @@
 static void ParsePreprocessorArgs(PreprocessorOptions &Opts, ArgList &Args,
   DiagnosticsEngine &Diags,
   frontend::ActionKind Action) {
-  Opts.ImplicitPCHInclude = std::string(Args.getLastArgValue(OPT_include_pch));
   Opts.PCHWithHdrStop = Args.hasArg(OPT_pch_through_hdrstop_create) ||
 Args.hasArg(OPT_pch_through_hdrstop_use);
-  Opts.PCHThroughHeader =
-  std::string(Args.getLastArgValue(OPT_pch_through_header_EQ));
   Opts.AllowPCHWithCompilerErrors =
   Args.hasArg(OPT_fallow_pch_with_errors, OPT_fallow_pcm_with_errors);
 
@@ -3346,19 +3343,6 @@
 Opts.addRemappedFile(Split.first, Split.second);
   }
 
-  if (Arg *A = Args.getLastArg(OPT_fobjc_arc_cxxlib_EQ)) {
-StringRef Name = A->getValue();
-unsigned Library = llvm::StringSwitch(Name)
-  .Case("libc++", ARCXX_libcxx)
-  .Case("libstdc++", ARCXX_libstdcxx)
-  .Case("none", ARCXX_nolib)
-  .Default(~0U);
-if (Library == ~0U)
-  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args) << 
Name;
-else
-  Opts.ObjCXXARCStandardLibrary = (ObjCXXARCStandardLibraryKind)Library;
-  }
-
   // Always avoid lexing editor placeholders when we're just running the
   // preprocessor as we never want to emit the
   // "editor placeholder in source file" error in PP only mode.
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2589,7 +2589,8 @@
 def include_ : JoinedOrSeparate<["-", "--"], "include">, Group, 
EnumName<"include">,
 MetaVarName<"">, HelpText<"Include file before parsing">, 
Flags<[CC1Option]>;
 def include_pch : Separate<["-"], "include-pch">, Group, 
Flags<[CC1Option]>,
-  HelpText<"Include precompiled header file">, MetaVarName<"">;
+  HelpText<"Include precompiled header file">, MetaVarName<"">,
+  MarshallingInfoString<"PreprocessorOpts->ImplicitPCHInclude">;
 def relocatable_pch : Flag<["-", "--"], "relocatable-pch">, Flags<[CC1Option]>,
   HelpText<"Whether to build a relocatable precompiled header">,
   MarshallingInfoFlag<"FrontendOpts.RelocatablePCH">;
@@ -4827,7 +4828,8 @@
   HelpText<"Override record layouts with those in the given file">;
 def pch_through_header_EQ : Joined<["-"], "pch-through-header=">,
   HelpText<"Stop PCH generation after including this file.  When using a PCH, "
-   "skip tokens until after this file is included.">;
+   "skip tokens until after this file is included.">,
+  MarshallingInfoString<"PreprocessorOpts->PCHThroughHeader">;
 def pch_through_hdrstop_create : Flag<["-"], "pch-through-hdrstop-create">,
   HelpText<"When creating a PCH, stop PCH generation after #pragma hdrstop.">,
   MarshallingInfoFlag<"PreprocessorOpts->PCHWithHdrStopCreate">;
@@ -4873,7 +4875,9 @@
   MetaVarName<"">,
   HelpText<"Specify the class to use for constant Objective-C string 
objects.">;
 def fobjc_arc_cxxlib_EQ : Joined<["-"], "fobjc-arc-cxxlib=">,
-  HelpText<"Objective-C++ Automatic Reference Counting standard library 
kind">, Values<"libc++,libstdc++,none">;
+  HelpText<"Objective-C++ Automatic Reference Counting standard library 
kind">, Values<"libc++,libstdc++,none">,
+  NormalizedValues<["ARCXX_libcxx", "ARCXX_libstdcxx", "ARCXX_nolib"]>,
+  MarshallingInfoString<"PreprocessorOpts->ObjCXXARCStandardLibrary", 
"ARCXX_nolib">, AutoNormalizeEnum;
 def fobjc_runtime_has_weak : Flag<["-"], "fobjc-runtime-has-weak">,
   HelpText<"The target Objective-C runtime supports ARC weak operations">;
 def fobjc_dispatch_method_EQ : Joined<["-"], "fobjc-dispatch-method=">,


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3274,11 +3274,8 @@
 static void ParsePreprocessorArgs(PreprocessorOptions &Opts, ArgList &Args,
   DiagnosticsEngine &Diags,
   frontend::ActionKind Action) {
-  Opts.ImplicitPCHInclude = std::string(Args.getLastArgValue(OPT_include_pch));
   Opts.PCHWithHdrStop = Args.hasArg(OPT_pch_through_hdrstop_create) ||
 Args.hasArg(OPT_pch_through_hdrstop_use);
-  Opts.PCHThroughHeader =

[PATCH] D93220: [clangd] Add error handling (elog) in code completion.

2020-12-16 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz updated this revision to Diff 312206.
adamcz marked an inline comment as done.
adamcz added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93220

Files:
  clang-tools-extra/clangd/CodeComplete.cpp


Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -182,12 +182,18 @@
 // strings (literal or URI) mapping to the same file. We still want to
 // bundle those, so we must resolve the header to be included here.
 std::string HeaderForHash;
-if (Inserter)
-  if (auto Header = headerToInsertIfAllowed(Opts))
-if (auto HeaderFile = toHeaderFile(*Header, FileName))
+if (Inserter) {
+  if (auto Header = headerToInsertIfAllowed(Opts)) {
+if (auto HeaderFile = toHeaderFile(*Header, FileName)) {
   if (auto Spelled =
   Inserter->calculateIncludePath(*HeaderFile, FileName))
 HeaderForHash = *Spelled;
+} else {
+  vlog("Code completion header path manipulation failed {0}",
+   HeaderFile.takeError());
+}
+  }
+}
 
 llvm::SmallString<256> Scratch;
 if (IndexResult) {


Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -182,12 +182,18 @@
 // strings (literal or URI) mapping to the same file. We still want to
 // bundle those, so we must resolve the header to be included here.
 std::string HeaderForHash;
-if (Inserter)
-  if (auto Header = headerToInsertIfAllowed(Opts))
-if (auto HeaderFile = toHeaderFile(*Header, FileName))
+if (Inserter) {
+  if (auto Header = headerToInsertIfAllowed(Opts)) {
+if (auto HeaderFile = toHeaderFile(*Header, FileName)) {
   if (auto Spelled =
   Inserter->calculateIncludePath(*HeaderFile, FileName))
 HeaderForHash = *Spelled;
+} else {
+  vlog("Code completion header path manipulation failed {0}",
+   HeaderFile.takeError());
+}
+  }
+}
 
 llvm::SmallString<256> Scratch;
 if (IndexResult) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D93220: [clangd] Add error handling (elog) in code completion.

2020-12-16 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz added inline comments.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:193
+} else {
+  elog("Code completion header path manipulation failed {0}",
+   HeaderFile.takeError());

sammccall wrote:
> I think this is too noisy.
> 
> We can hit this in "normal" cases of certain projects.
> For better or worse, we don't currently filter out index results where we 
> know the responsible header and can't include it (because it's not under any 
> include path entry). In these cases toHeaderFile() returns an error.
> 
> Since this can happen in the normal case for *each* completion candidate 
> (default 100), and completion requests are very frequent, this could dominate 
> log output in affected projects.
> 
> It *might* be OK at vlog? I get the desire to not silence errors here. I 
> think the question is what are the error cases we're *trying* to call out 
> loudly. Maybe we can separate out the "shouldn't happen" vs the "fairly 
> expected" cases.
> (Even then there's the prospect that this is either going to not fire or fire 
> dozens of times, which is a little sad)
Originally I didn't even log here. We do this expansion at other places and 
they may log already, I don't think it's critical to log here. Kadir pointed 
out error needs to be handled or it will assert()-fail (that one place returns 
Expected rather than Optional, I missed that), which is the motivation for this 
change.

I made it vlog, but if you think it's too spammy I can remove it and just 
ignore the error (by this time explicitly, so it doesn't crash). I don't think 
we'll see these errors often - this only happens when we failed to parse the 
URI or recognize the scheme, which basically can only happen with remote index 
and some kind of version skew or corrupt data, so I'm fine with vlog() I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93220

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


[PATCH] D93110: [analyzer] Implement a first version of suppressions via attributes

2020-12-16 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporter.cpp:2897
+   ASTContext &AC) {
+  PathDiagnosticLocation Location = BR.getLocation();
+

What will this location return? In case of a leak warning, we might get a 
different instance of the same warning on separate paths. We usually pick the 
shortest path, but it can change when we slightly alter the source code. Maybe 
we want the user to put the suppression at the uniqueing location when such 
location exist? (The allocation in case of a leak warnings.) I think that would 
result in a better user experience and more robust suppression mechanism. An 
open question is how to educate the user about the correct way of suppression. 
Should we emit a suppress location to the user explicitly?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93110

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


[PATCH] D93258: [amdgpu] Default to code object v3

2020-12-16 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

Thanks for fixing the lit tests. Using regex is the right choice.

Do we have a plan about how to merge this to amd-stg-open? Will it cause ePSDB 
to fail? Do you have a follow up patch to make amd-stg-open happy?

Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93258

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


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

2020-12-16 Thread Kito Cheng via Phabricator via cfe-commits
kito-cheng added a comment.

Do you have implement register pair for rv32ifd_zfinx? I didn't saw the related 
implementation, but I could be wrong since I am not LLVM expert, in case you 
have implemented, you need a test case for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93298

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


[PATCH] D93068: [clang-offload-bundler] Add option -allow-missing-bundles

2020-12-16 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 2 inline comments as done.
yaxunl added a comment.

@ABataev Is this patch OK for OpenMP? It is NFC for OpenMP toolchain but 
affects using clang-offload-bundler as a standalone tool. Thanks.




Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:1126
   for (StringRef Target : TargetNames) {
+if (ParsedTargets.count(Target)) {
+  reportError(createStringError(errc::invalid_argument,

tra wrote:
> Nit: `.contains(Target)` ? 
will fix



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:985
+unsigned I = 0;
+unsigned Last = Worklist.size() - 1;
+for (auto &E : Sorted) {

tra wrote:
> yaxunl wrote:
> > tra wrote:
> > > This assumes that all items on the `WorkList` were unique. 
> > > If some of the WorkList items were duplicated, then there will be fewer 
> > > items in `Sorted` and the ` I == Last` comparison will never be true.
> > > I'd use `Sorted.size()` instead.
> > clang-offload-bundler does not allow duplicated targets. It asserts when 
> > duplicated targets in options are found when unbundling. Will add check for 
> > duplicate targets in options and emit error.
> I'd still use `Sorted.size()` as it's the `Sorted` you're iterating on.
will fix


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

https://reviews.llvm.org/D93068

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


[PATCH] D69560: [clang-tidy] Add 'experimental-cppcoreguidelines-avoid-adjacent-parameters-of-the-same-type' check

2020-12-16 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.
Herald added a subscriber: shchenz.

In D69560#2319340 , @aaron.ballman 
wrote:

> Congrats on the SCAM acceptance, I hope the presentation goes well!

The entire event was amazing, even if short. There was another paper which 
seemed to target the issue of swaps at call sites (D20689 
) in the section where I was presenting and 
due to the SCAM being small and having no parallel session, I can say with 
confidence, that it was this particular section where the longest discussion 
was spawned from the topics we discussed. (In every other section people left 
the call a bit too early. The worst problem of online conferencing... 😦)



I've gone over the reports on some projects one by one. Due to the vast number 
of reports on existing projects, I've only selected //3// of them: Bitcoin 
(C++), Postgres (C), and Apache Xerces (C++). I've specifically wanted to add a 
C project, however, Postgres produced so many reports across the configurations 
(1460, 3033, 2415 and 4253, respectively) that it would take multiple inhumane 
months to go over them one by one... So, let's focus on Bitcoin and Xerces. 
Reasonably sized projects both being roughly a single library, they are both 
written to the OOP paradigm and are of reasonably modern C++.

I've run 4 analyses of each project:

- normal mode (named simply `len2` in the uploaded database, only strict type 
equality is reported)
- normal mode, with relatedness heuristics filtering (`len2-rel`, D78652 
, this should be the strictest mode and 
produce the least number of results. **This mode is //most// conformant in 
matching the Guideline rule!**)
- CVR+Imp mode (`len2-cvr-imp`, type equality is relatex to type 
convertibility, which generally means an adjacency of `int, const int` (CVR) 
and `int, double` (Imp) is reported too. CVR is implemented in this patch, Imp 
is added in a subsequent patch, D75041 . This 
should be the broadest configuration.)
- CVR+Imp mode, with relatedness filtering (`len2-cvr-imp-rel`)

The number of reports were, in this order of configurations:

- Bitcoin: 183, 82, 516, 259
- Postgres: 3033, 1460, 4253, 2415
- Xerces: 254, 79, 412, 165

In CodeChecker, I have marked cases where simple refactorings (strong typedef 
or a range-constrained type) could help remove the issue as **Confirmed bug**. 
**False positive**s are cases that cannot be removed by heuristics easily, 
while **Intentional** bugs (this is a classification category in CodeChecker 
you can select for your bug, the naming is wonky here but let's just consider 
it a third bucket) were the ones where sensible heuristics can be devised to 
suppress these reports. We'll get back to this later. I've checked the results 
both with "report uniqueing" (1) on and off.



BitCoin
===

| //Project "component"//  | Confirmed cases (unique) | False 
positive (unique) | Suppressable (unique) |
| Qt MOC generated code|  | 
| 8 |
| Third-party library hosted in repository | 13   | 28 (27) 
| 11|
| Test code| 34   | 20  
| 12|
| Project core | 136  | 137 
| 55 (53)   |
| **Total**| 183  | 185 
(184)   | 86 (84)   |
|

These were the numbers for the "normal mode". Now, let's see how it changes 
when relatedness filtering (as in D78652  Diff 
259231 ) is introduced.

| //Project "component"//  | Confirmed cases (Unique) | False 
positive (Unique) | Suppressable (unique) |
| Qt MOC generated code|  | 
|   |
| Third-party library hosted in repository | 5| 7   
| 4 |
| Test code| 15   | 11  
| 2 |
| Project core | 62   | 37  
| 14|
| **Total**| 82   | 55  
| 20|
|

(Numbers did not change with enabling "unique reports".)

Modelling implicit conversions blows up the result set. Note that for this 
analysis, the definition behind `confirmed bug` is changed a bit: in case of 
reports where implicit conversions are reported, if the swap through the 
implicit conversion //is dangerous// it is reported as a confirmed

[PATCH] D93398: [NFC] Use regex for code object version in hip tests

2020-12-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield created this revision.
JonChesterfield added a reviewer: yaxunl.
JonChesterfield requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

[NFC] Use regex for code object version in hip tests

Extracted from D93258 . Makes tests robust to 
changes in default
code object version.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93398

Files:
  clang/test/Driver/hip-autolink.hip
  clang/test/Driver/hip-code-object-version.hip
  clang/test/Driver/hip-device-compile.hip
  clang/test/Driver/hip-host-cpu-features.hip
  clang/test/Driver/hip-rdc-device-only.hip
  clang/test/Driver/hip-target-id.hip
  clang/test/Driver/hip-toolchain-mllvm.hip
  clang/test/Driver/hip-toolchain-no-rdc.hip
  clang/test/Driver/hip-toolchain-opt.hip
  clang/test/Driver/hip-toolchain-rdc-separate.hip
  clang/test/Driver/hip-toolchain-rdc-static-lib.hip
  clang/test/Driver/hip-toolchain-rdc.hip

Index: clang/test/Driver/hip-toolchain-rdc.hip
===
--- clang/test/Driver/hip-toolchain-rdc.hip
+++ clang/test/Driver/hip-toolchain-rdc.hip
@@ -32,7 +32,7 @@
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // generate image for device side path on gfx803
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -43,7 +43,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC1:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
@@ -62,7 +62,7 @@
 // CHECK-SAME: "-o" "[[IMG_DEV1:.*.out]]" [[A_BC1]] [[B_BC1]]
 
 // generate image for device side path on gfx900
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -72,7 +72,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC2:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
Index: clang/test/Driver/hip-toolchain-rdc-static-lib.hip
===
--- clang/test/Driver/hip-toolchain-rdc-static-lib.hip
+++ clang/test/Driver/hip-toolchain-rdc-static-lib.hip
@@ -26,7 +26,7 @@
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // generate image for device side path on gfx803
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -35,7 +35,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC1:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
@@ -52,7 +52,7 @@
 // CHECK-SAME: "-o" "[[IMG_DEV1:.*out]]" [[A_BC1]] [[B_BC1]]
 
 // generate image for device side path on gfx900
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -61,7 +61,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC2:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CH

[PATCH] D93258: [amdgpu] Default to code object v3

2020-12-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

In D93258#2457905 , @yaxunl wrote:

> Thanks for fixing the lit tests. Using regex is the right choice.
>
> Do we have a plan about how to merge this to amd-stg-open? Will it cause 
> ePSDB to fail? Do you have a follow up patch to make amd-stg-open happy?
>
> Thanks.

Extracted as D93398 . Suggest we land that, 
then it flows into gerrit (where it won't break anything), and rebase this 
patch to reduce the noise.

This will need to be merged carefully into amd-stg-open if the intent is to 
continue using v4 as the default on the internal branch. No follow up patch 
necessary, the trick would be to not land this.

Note that none of this would be necessary if trunk clang hadn't been 
prematurely updated to default to a code object version that llvm trunk doesn't 
use.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93258

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


[PATCH] D93398: [NFC] Use regex for code object version in hip tests

2020-12-16 Thread Tony Tye via Phabricator via cfe-commits
t-tye added inline comments.



Comment at: clang/test/Driver/hip-code-object-version.hip:56
 
-// V4: "-mllvm" "--amdhsa-code-object-version=4"
-// V4: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
+// VD: "-mllvm" "--amdhsa-code-object-version=4"
+// VD: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"

If the upstream default is being changed to 3 does this need to also be 3?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93398

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


[PATCH] D91444: [InstCombine] Preserve !annotation metadata for memory combines.

2020-12-16 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 312216.
fhahn added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In D91444#2394512 , @lebedev.ri wrote:

> What about teaching IRBuilder to deal with it like it deals with debugloc?

Done! Together with D93400  this patch now 
boils down to requesting !annotation to be preserved for instructions created 
by IRBuilder.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91444

Files:
  clang/test/CodeGenCXX/auto-var-init.cpp
  llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
  llvm/test/Transforms/InstCombine/annotations.ll

Index: llvm/test/Transforms/InstCombine/annotations.ll
===
--- llvm/test/Transforms/InstCombine/annotations.ll
+++ llvm/test/Transforms/InstCombine/annotations.ll
@@ -48,8 +48,8 @@
 
 define void @copy_1_byte(i8* %d, i8* %s) {
 ; CHECK-LABEL: define {{.+}} @copy_1_byte({{.+}}
-; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1
-; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1
+; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1, !annotation [[ANN]]
+; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call void @llvm.memcpy.p0i8.p0i8.i32(i8* %d, i8* %s, i32 1, i1 false), !annotation !0
@@ -60,8 +60,8 @@
 
 define void @libcallcopy_1_byte(i8* %d, i8* %s) {
 ; CHECK-LABEL: define {{.+}} @libcallcopy_1_byte({{.+}}
-; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1
-; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1
+; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1, !annotation [[ANN]]
+; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call i8* @memcpy(i8* %d, i8* %s, i64 1), !annotation !0
@@ -72,8 +72,8 @@
 
 define void @libcallcopy_1_byte_chk(i8* %d, i8* %s) {
 ; CHECK-LABEL: define {{.+}} @libcallcopy_1_byte_chk({{.+}}
-; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1
-; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1
+; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1, !annotation [[ANN]]
+; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call i8* @__memcpy_chk(i8* %d, i8* %s, i64 1, i64 1), !annotation !0
@@ -84,8 +84,8 @@
 
 define void @move_1_byte(i8* %d, i8* %s) {
 ; CHECK-LABEL: define {{.+}} @move_1_byte({{.+}}
-; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1
-; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1
+; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1, !annotation [[ANN]]
+; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call void @llvm.memmove.p0i8.p0i8.i32(i8* %d, i8* %s, i32 1, i1 false), !annotation !0
@@ -96,8 +96,8 @@
 
 define void @libcallmove_1_byte(i8* %d, i8* %s) {
 ; CHECK-LABEL: define {{.+}} @libcallmove_1_byte({{.+}}
-; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1
-; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1
+; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1, !annotation [[ANN]]
+; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call i8* @memmove(i8* %d, i8* %s, i64 1), !annotation !0
@@ -108,8 +108,8 @@
 
 define void @libcallmove_1_byte_chk(i8* %d, i8* %s) {
 ; CHECK-LABEL: define {{.+}} @libcallmove_1_byte_chk({{.+}}
-; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1
-; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1
+; CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[S:%.*]], align 1, !annotation [[ANN]]
+; CHECK-NEXT:store i8 [[TMP1]], i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call i8* @__memmove_chk(i8* %d, i8* %s, i64 1, i64 1), !annotation !0
@@ -120,7 +120,7 @@
 
 define void @set_1_byte(i8* %d) {
 ; CHECK-LABEL: define {{.+}} @set_1_byte({{.+}}
-; CHECK-NEXT:store i8 1, i8* [[D:%.*]], align 1
+; CHECK-NEXT:store i8 1, i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call void @llvm.memset.p0i8.i32(i8* %d, i8 1, i32 1, i1 false), !annotation !0
@@ -131,7 +131,7 @@
 
 define void @libcall_set_1_byte(i8* %d) {
 ; CHECK-LABEL: define {{.+}} @libcall_set_1_byte({{.+}}
-; CHECK-NEXT:store i8 1, i8* [[D:%.*]], align 1
+; CHECK-NEXT:store i8 1, i8* [[D:%.*]], align 1, !annotation [[ANN]]
 ; CHECK-NEXT:ret void
 ;
   call i8* @memset(i8* %d, i32 1, i64 1), !annotation !0
@@ -142,7 +142,7 @@
 
 define void @libcall_set_1_byte_chk(i8* %d) {
 ; CHECK-LABEL: define {{.+}} @libcall_set_1_byte_chk({{.+}}
-; CHECK-NEXT:store i8 1, i8* [[D:%.*]], align 1
+; CHEC

[PATCH] D93398: [NFC] Use regex for code object version in hip tests

2020-12-16 Thread Tony Tye via Phabricator via cfe-commits
t-tye added inline comments.



Comment at: clang/test/Driver/hip-code-object-version.hip:56
 
-// V4: "-mllvm" "--amdhsa-code-object-version=4"
-// V4: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
+// VD: "-mllvm" "--amdhsa-code-object-version=4"
+// VD: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"

t-tye wrote:
> If the upstream default is being changed to 3 does this need to also be 3?
I can also help getting this landed in to internal branches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93398

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


[PATCH] D92039: [-Wcalled-once-parameter] Introduce 'called_once' attribute

2020-12-16 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

In D92039#2457867 , @aaron.ballman 
wrote:

> Is the attribute considered to be a property of the parameter or a property 
> of the function the parameter is declared in? e.g.,
>
>   void someOtherFunc(void (^cb)(void)) {
> if (something())
>   cb();
>   }
>   
>   void barWithCallback(void (^callback)(void) __attribute__((called_once))) {
> someOtherFunc(callback);
>   }
>
> Should code like that also diagnose given that `callback` is not called on 
> every code path? From the test cases you have, it looks like you explicitly 
> allow this code without diagnosing it, which suggests the attribute is really 
> a property of the function and not a property of the parameter. This in turn 
> makes me wonder whether a better design is for `-Wcompletion-handler` to 
> diagnose any function with a completion handler-like parameter if the 
> parameter is not called exactly once within the function, and the user marks 
> the functions that should be exempt from the checking rather than marking the 
> parameters that should be checked (or does this have too many false positives 
> in practice)? Alternatively, should the check be implemented as a clang 
> static analyzer check that tracks an annotated parameter across the 
> inter-procedural CFG and diagnoses such code?



> should the check be implemented as a clang static analyzer check that tracks 
> an annotated parameter across the inter-procedural CFG and diagnoses such 
> code?

That was a tough choice whether we should do it in the analyzer or not.
The analyzer check would've been easier in terms of existing infrastructure, 
path sensitivity, and IPA.  It is also much more lenient in terms of false 
positives (it is expected that the analyzer can have those).
However, warnings have much broader audience and we aim for a higher numbers of 
people to check their code (we've been asked to deliver it for 8 years).  And 
because the analyzer doesn't have cross-translation unit analysis, the problem 
with inter procedural bugs appears as well.

> From the test cases you have, it looks like you explicitly allow this code 
> without diagnosing it, which suggests the attribute is really a property of 
> the function and not a property of the parameter.

I have to disagree here.  //Semantically// this is a property of a parameter 
and the fact that we couldn't analyze inter-procedurally is our own problem and 
implementation detail.  We don't want to bother users with this.  As far as I 
understand, the majority of existing warnings are not complete (don't find 
every bug) and this warning is not different.

> and the user marks the functions that should be exempt from the checking 
> rather than marking the parameters that should be checked

Essentially, there is a way to prevent function from being analyzed by 
`-Wcompletion-handler` - annotate it with `__attribute__((swift_async(none)))`.




Comment at: clang/include/clang/Basic/AttrDocs.td:5133-5134
+
+This attribute is useful for API developers who want to double-check if they
+implemented their method correctly.
+

aaron.ballman wrote:
> Oh, I was thinking this attribute was enabling some optimization 
> opportunities or doing something more than just acting as a marker to please 
> check this function's correctness for some properties. This means that the 
> programmer has to annotate their code and enable the warning flag in order 
> for either the attribute or the warning flag to have effect, which feels a 
> bit surprising to me.
For explicitly marked parameters, it's on by default, so the users can simply 
annotate their parameters and get their checks.



Comment at: clang/include/clang/Basic/AttrDocs.td:5098-5102
+* Parameter is not called at all.
+
+* Parameter is called more than once.
+
+* Parameter is not called on one of the execution paths.

aaron.ballman wrote:
> I think you may have to remove the newlines here to make this a single 
> bulleted list in Sphinx.
I checked it, it is one list with newlines: {F14734606}


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92039

___
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

2020-12-16 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

One thing this patch does, is make decisions about default behavior static.  
Meaning, the option behavior cannot depend on other options; specifically, it 
can't be based on the triple, which allows target-specific customization.  PS4 
certainly has cases where our defaults are different from the usual ones, and 
I'd kind of think that was true for other targets as well.

Sorry I didn't notice this patch before, our CI has just tried to merge it.  
We've patched it up in our main branch but I'm not sure what the upstream 
intent is here.


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] D93398: [NFC] Use regex for code object version in hip tests

2020-12-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added inline comments.



Comment at: clang/test/Driver/hip-code-object-version.hip:56
 
-// V4: "-mllvm" "--amdhsa-code-object-version=4"
-// V4: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
+// VD: "-mllvm" "--amdhsa-code-object-version=4"
+// VD: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"

t-tye wrote:
> t-tye wrote:
> > If the upstream default is being changed to 3 does this need to also be 3?
> I can also help getting this landed in to internal branches.
Thanks. And yeah, it'll be changed to =3 as part of D93258. Until then, test 
needs to match the clang front end.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93398

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


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

2020-12-16 Thread Faris via Phabricator via cfe-commits
FarisRehman created this revision.
Herald added a reviewer: sscalpone.
Herald added a subscriber: dang.
FarisRehman requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add support for options -D and -U in the Flang driver along with a regression 
test for them.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93401

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  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.f90

Index: flang/test/Flang-Driver/macro.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/macro.f90
@@ -0,0 +1,49 @@
+! 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 -DNEW %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -E -DNEW -UNEW %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 -DNEW %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -fc1 -E -DNEW -UNEW %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+
+
+!
+! EXPECTED OUTPUT FOR MACRO 'NEW' UNDEFINED
+!
+! flang-new -E %s
+! flang-new -E -DNEW -UNEW %s
+! UNDEFINED:program b
+! UNDEFINED-NOT:program a
+! UNDEFINED-NEXT:x = 1
+! UNDEFINED-NEXT:write(*,*) x
+! UNDEFINED-NEXT:end
+
+!
+! EXPECTED OUTPUT FOR MACRO 'NEW' DEFINED
+!
+! flang-new -E -DNEW %s
+! DEFINED:program a
+! DEFINED-NOT:program b
+! DEFINED-NEXT:x = 1
+! DEFINED-NEXT:write(*,*) x
+! DEFINED-NEXT:end
+
+! Macro.F:
+#ifdef NEW
+program A
+#else
+program B
+#endif
+  x = 1
+  write(*,*) x
+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 available options
+! HELP-FC1-NEXT: -o   Write output to 
+! HELP-FC1-NEXT: -U  Undefine macro 
+! HELP-FC1-NEXT: --version  Print version information
 
 !---
 ! EXPECTED ERROR
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
@@ -19,12 +19,14 @@
 ! CHECK-EMPTY:
 ! CHECK-NEXT:OPTIONS:
 ! CHECK-NEXT: -###  Print (but do not run) the commands to run for this compilation
+! CHECK-NEXT: -D = Define  to  (or 1 if  omitted)
 ! CHECK-NEXT: -EOnly run the preprocessor
 ! CHECK-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! CHECK-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! CHECK-NEXT: -help Display available options
 ! 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 
 ! CHECK-NEXT: --version Print version inform

[PATCH] D93031: Enable fexec-charset option

2020-12-16 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added inline comments.



Comment at: clang/include/clang/Driver/Options.td:3583-3584
 
+def fexec_charset : Separate<["-"], "fexec-charset">, 
MetaVarName<"">,
+  HelpText<"Set the execution  for string and character literals">;
 def target_cpu : Separate<["-"], "target-cpu">,

abhina.sreeskantharajan wrote:
> tahonermann wrote:
> > How about substituting "character set", "character encoding", or "charset" 
> > for "codepage"?
> > 
> > This doesn't state what names are recognized.  The ones provided by the 
> > system iconv() implementation (as is the case for gcc)?  Or all names and 
> > aliases specified by the [[ 
> > https://www.iana.org/assignments/character-sets/character-sets.xhtml | IANA 
> > character set registry ]]?
> > 
> > The set of recognized names can be a superset of the names that are 
> > actually supported.
> I've updated the description from codepage to charset.
> 
> It's hard to specify what charsets are supported because iconv library 
> differs between targets, so the list will not be the same on every platform.
Being dependent on the host iconv library seems fine by me; that is the case 
for gcc today.  I suggest making that explicit here:
  def fexec_charset : Separate<["-"], "fexec-charset">, 
MetaVarName<"">,
HelpText<"Set the execution  for string and character literals.  
Supported character encodings include XXX and those supported by the host iconv 
library.">;



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5969-5977
+  // Pass all -fexec-charset options to cc1.
+  std::vector vList =
+  Args.getAllArgValues(options::OPT_fexec_charset_EQ);
+  // Set the default fexec-charset as the system charset.
+  CmdArgs.push_back("-fexec-charset");
+  CmdArgs.push_back(Args.MakeArgString(Triple.getSystemCharset()));
+  for (auto it = vList.begin(), ie = vList.end(); it != ie; ++it) {

abhina.sreeskantharajan wrote:
> tahonermann wrote:
> > I think it would be preferable to diagnose an unrecognized character 
> > encoding name here if possible.  The current changes will result in an 
> > unrecognized name (as opposed to one that is unsupported for the target) 
> > being diagnosed for each compiler instance.
> Since we do not know what charsets are supported by the iconv library on the 
> target platform, we don't know what charsets are actually invalid until we 
> try creating a CharSetConverter.
Understood, but what would be the harm in performing a lookup (constructing a 
`CharSetConverter`) here?



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3573
+StringRef Value = ExecCharset->getValue();
+Opts.ExecCharset = (std::string)Value;
+  }

abhina.sreeskantharajan wrote:
> tahonermann wrote:
> > I wouldn't expect the cast to `std::string` to be needed here.
> Without that cast, I get the following build error:
> ```
>  error: no viable overloaded '='
> ```
Ok, rather than a cast, I suggest:
  Opts.ExecCharset = Value.str();



Comment at: clang/lib/Lex/LiteralSupport.cpp:1322-1323
+  TranslationState = translationState;
+  if (Kind == tok::wide_string_literal)
+TranslationState = TranslateToSystemCharset;
+  else if (isUTFLiteral(Kind))

Converting wide character literals to the system encoding doesn't seem right to 
me.  For z/OS, this should presumably convert to the wide EBCDIC encoding, but 
for all other supported platforms, the wide execution character set is either 
UTF-16 or UTF-32 depending on the size of `wchar_t` (which may be influenced by 
the `-fshort-wchar` option).



Comment at: clang/lib/Lex/LiteralSupport.cpp:1593-1597
+  ConversionState State = TranslationState;
+  if (Kind == tok::wide_string_literal)
+State = TranslateToSystemCharset;
+  else if (isUTFLiteral(Kind))
+State = NoTranslation;

The stored `TranslationState` should not be completely ignored for wide and UTF 
string literals.  The standard permits things like the following.
  #pragma rigoot L"bozit"
  #pragma rigoot u"bozit"
  _Pragma(L"rigoot bozit")
  _Pragma(u8"rigoot bozit")
For at least the `_Pragma(L"...")` case, the C++ standard [[ 
http://eel.is/c++draft/cpp.pragma.op | states ]] the `L` is ignored, but it 
doesn't say anything about other encoding prefixes.



Comment at: clang/lib/Lex/LiteralSupport.cpp:1594-1595
+  ConversionState State = TranslationState;
+  if (Kind == tok::wide_string_literal)
+State = TranslateToSystemCharset;
+  else if (isUTFLiteral(Kind))

Converting wide string literals to the system encoding doesn't seem right to 
me.  For z/OS, this should presumably convert to the wide EBCDIC encoding, but 
for all other supported platforms, the wide execution character set is either 
UTF-16 or UTF-32 depending on the size of `wchar_t` (which may be influenced by 
the `-fshort-wchar` option).


Repository:
  rG LLVM Github Monorepo

CHAN

[PATCH] D93402: [clang-tidy] prevent readability-identifier-naming from triggering on implicit VarDecls in coroutines

2020-12-16 Thread Emma Blink via Phabricator via cfe-commits
0x1eaf created this revision.
0x1eaf added reviewers: alexfh, njames93, aaron.ballman.
0x1eaf added projects: clang, clang-tools-extra.
Herald added subscribers: lxfind, modocache, xazax.hun.
0x1eaf requested review of this revision.
Herald added a subscriber: cfe-commits.

We have an internal bug report about readability-identifier-naming
warnings on implicit `__coro_gro` and `__promise` variables
in coroutines.

Turns out they haven't been marked as implicit in SemaCoroutine.
This diff resolves that and adds a couroutine test for the check.

Tested with:

> cd build/Debug/bin
> ./llvm-lit -sv --param build_mode=Debug \

  ../../tools/clang/tools/extra/test \
  --filter readability-identifier-naming.cpp


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93402

Files:
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/system/coroutines.h
  clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
  clang/lib/Sema/SemaCoroutine.cpp

Index: clang/lib/Sema/SemaCoroutine.cpp
===
--- clang/lib/Sema/SemaCoroutine.cpp
+++ clang/lib/Sema/SemaCoroutine.cpp
@@ -544,6 +544,7 @@
   auto *VD = VarDecl::Create(Context, FD, FD->getLocation(), FD->getLocation(),
  &PP.getIdentifierTable().get("__promise"), T,
  Context.getTrivialTypeSourceInfo(T, Loc), SC_None);
+  VD->setImplicit(true);
   CheckVariableDeclarationType(VD);
   if (VD->isInvalidDecl())
 return nullptr;
@@ -1577,6 +1578,7 @@
   S.Context, &FD, FD.getLocation(), FD.getLocation(),
   &S.PP.getIdentifierTable().get("__coro_gro"), GroType,
   S.Context.getTrivialTypeSourceInfo(GroType, Loc), SC_None);
+  GroDecl->setImplicit(true);
 
   S.CheckVariableDeclarationType(GroDecl);
   if (GroDecl->isInvalidDecl())
Index: clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
@@ -81,13 +81,14 @@
 // RUN: {key: readability-identifier-naming.LocalPointerPrefix, value: 'l_'}, \
 // RUN: {key: readability-identifier-naming.LocalConstantPointerCase, value: CamelCase}, \
 // RUN: {key: readability-identifier-naming.LocalConstantPointerPrefix, value: 'lc_'}, \
-// RUN:   ]}' -- -fno-delayed-template-parsing -Dbad_macro \
+// RUN:   ]}' -- -fno-delayed-template-parsing -Dbad_macro -std=c++17 -fcoroutines-ts \
 // RUN:   -I%S/Inputs/readability-identifier-naming \
 // RUN:   -isystem %S/Inputs/readability-identifier-naming/system
 
 // clang-format off
 
 #include 
+#include 
 #include "user-header.h"
 // NO warnings or fixes expected from declarations within header files without
 // the -header-filter= option
@@ -287,7 +288,7 @@
   // Overriding a badly-named base isn't a new violation.
   void BadBaseMethod() override {}
   // CHECK-FIXES: {{^}}  void v_Bad_Base_Method() override {}
-  
+
   void foo() {
 BadBaseMethod();
 // CHECK-FIXES: {{^}}v_Bad_Base_Method();
@@ -614,3 +615,14 @@
 auto GetRes(type_t& Param) -> decltype(Param.res());
 // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: invalid case style for parameter 'Param'
 // CHECK-FIXES: auto GetRes(type_t& a_param) -> decltype(a_param.res());
+
+#pragma mark - Check implicit declarations in coroutines
+
+struct async_obj {
+public:
+  never_suspend operator co_await() const noexcept;
+};
+
+task ImplicitDeclTest(async_obj &a_object) {
+  co_await a_object;  // CHECK-MESSAGES-NOT: warning: invalid case style for local variable
+}
Index: clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/system/coroutines.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/system/coroutines.h
@@ -0,0 +1,34 @@
+#pragma once
+
+namespace std {
+namespace experimental {
+
+template 
+struct coroutine_traits {
+  using promise_type = typename ret_t::promise_type;
+};
+
+template 
+struct coroutine_handle {
+  static constexpr coroutine_handle from_address(void *addr) noexcept { return {}; };
+};
+
+} // namespace experimental
+} // namespace std
+
+struct never_suspend {
+  bool await_ready() noexcept { return false; }
+  template 
+  void await_suspend(coro_t handle) noexcept {}
+  void await_resume() noexcept {}
+};
+
+struct task {
+  struct promise_type {
+task get_return_object() noexcept { return {}; }
+never_suspend initial_suspend() noexcept { return {}; }
+never_suspend final_suspend() noexcept { return {}; }
+void return_void() {}
+void unhandled_exception() {}
+  };
+};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma

[PATCH] D93356: [libomptarget][amdgpu] Call into deviceRTL instead of ockl

2020-12-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield planned changes to this revision.
JonChesterfield added a comment.

There's a codegen test that checks for __ockl_get_local_size. Testing a change 
to that test out of tree now, probably need to update said test before landing 
this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93356

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


[PATCH] D92955: [openmp] Remove clause from OMPKinds.def and use OMP.td info

2020-12-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.

LGTM still


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92955

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


[PATCH] D91944: OpenMP 5.0 metadirective

2020-12-16 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D91944#2457744 , @dreachem wrote:

> In D91944#2414364 , @jdoerfert wrote:
>
>> This looks close to an OpenMP 5.0 implementation. I left comments inlined.
>>
>> We need tests that show how non-selected alternatives *do not* impact the 
>> program. As an example, a template instantiation inside of a non-selected 
>> alternative is not actually performed.
>>
>> We also need test with ill-formed metadirectives.
>
> @jdoerfert I'm still trying to understand this thing regarding template 
> instantiations.

The problem is this patch can only resolve to a single directive during 
parsing. Take

  template
  void foo() {
#pragma omp metadirective when(user={condition(b)}) ...
  }

which is not resolvable at parsing time but it is a valid OpenMP 5.0 use of the 
metadirective
that needs to resolve at compile time.

> The spec says that a directive variant associated with a when clause can only 
> affect the program if it is a dynamic replacement candidate. I had assumed 
> this is referring to the runtime behavior of the program, and not (for 
> instance) whether a compiler error is emitted due to a failing static assert.

I always assume(d) that static_assert is something "affecting the program". It 
doesn't matter though because if you instantiate all the clauses eagerly you 
change things for the runtime as well, e.g., you can cause different template 
instances to be selected later on depending on earlier instantiations. So it's 
not "just" static_assert.

> Also, in order to determine what are the dynamic replacement candidates, and 
> their order, all specified score expressions would need to be evaluated.  
> Then, you'd need to evaluate the static context selectors, in decreasing 
> order of their score, to find which one is the last dynamic replacement 
> candidate. So I think template instantiations could be possible for those 
> expressions, even if the corresponding variants aren't selected?

Yes, we will always evaluate selectors and scores. The key is that we won't 
evaluate the directive variant, which is neither a selector nor a score.

I hope this makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91944

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


[PATCH] D93031: Enable fexec-charset option

2020-12-16 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added inline comments.



Comment at: clang/test/CodeGen/systemz-charset.c:4
+
+char *UpperCaseLetters = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
+// CHECK: 
c"\C1\C2\C3\C4\C5\C6\C7\C8\C9\D1\D2\D3\D4\D5\D6\D7\D8\D9\E2\E3\E4\E5\E6\E7\E8\E9\00"

`const char *` please :)



Comment at: clang/test/CodeGen/systemz-charset.c:24
+//CHECK: c"abc\00"
+
+char singleChar = 'a';

Add validation of UCNs.  Something like:
  const char *UcnCharacters = "\u00E2\u00AC\U00DF";
  // CHECK: c"\42\B0\59\00"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93031

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


[PATCH] D93398: [NFC] Use regex for code object version in hip tests

2020-12-16 Thread Tony Tye via Phabricator via cfe-commits
t-tye accepted this revision.
t-tye 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/D93398/new/

https://reviews.llvm.org/D93398

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


[clang] c0619d3 - [NFC] Use regex for code object version in hip tests

2020-12-16 Thread Jon Chesterfield via cfe-commits

Author: Jon Chesterfield
Date: 2020-12-16T17:00:19Z
New Revision: c0619d3b21cd420b9faf15f14db0816787c44ded

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

LOG: [NFC] Use regex for code object version in hip tests

[NFC] Use regex for code object version in hip tests

Extracted from D93258. Makes tests robust to changes in default
code object version.

Reviewed By: t-tye

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

Added: 


Modified: 
clang/test/Driver/hip-autolink.hip
clang/test/Driver/hip-code-object-version.hip
clang/test/Driver/hip-device-compile.hip
clang/test/Driver/hip-host-cpu-features.hip
clang/test/Driver/hip-rdc-device-only.hip
clang/test/Driver/hip-target-id.hip
clang/test/Driver/hip-toolchain-mllvm.hip
clang/test/Driver/hip-toolchain-no-rdc.hip
clang/test/Driver/hip-toolchain-opt.hip
clang/test/Driver/hip-toolchain-rdc-separate.hip
clang/test/Driver/hip-toolchain-rdc-static-lib.hip
clang/test/Driver/hip-toolchain-rdc.hip

Removed: 




diff  --git a/clang/test/Driver/hip-autolink.hip 
b/clang/test/Driver/hip-autolink.hip
index 073c6c4d244a6..5f9311d7ba734 100644
--- a/clang/test/Driver/hip-autolink.hip
+++ b/clang/test/Driver/hip-autolink.hip
@@ -7,7 +7,7 @@
 // RUN: %clang --target=i386-pc-windows-msvc --cuda-gpu-arch=gfx906 -nogpulib \
 // RUN:   --cuda-host-only %s -### 2>&1 | FileCheck --check-prefix=HOST %s
 
-// DEV: "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" 
"amdgcn-amd-amdhsa"
+// DEV: "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" 
"amdgcn-amd-amdhsa"
 // DEV-SAME: "-fno-autolink"
 
 // HOST: "-cc1" "-triple" "i386-pc-windows-msvc{{.*}}"

diff  --git a/clang/test/Driver/hip-code-object-version.hip 
b/clang/test/Driver/hip-code-object-version.hip
index 26ad6f8710cc2..51d9004b0cbf5 100644
--- a/clang/test/Driver/hip-code-object-version.hip
+++ b/clang/test/Driver/hip-code-object-version.hip
@@ -44,12 +44,17 @@
 // RUN:   --offload-arch=gfx906 -nogpulib \
 // RUN:   %s 2>&1 | FileCheck -check-prefix=V4 %s
 
+// V4: "-mllvm" "--amdhsa-code-object-version=4"
+// V4: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
+
+// Check bundle ID for code object version default
+
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --offload-arch=gfx906 -nogpulib \
-// RUN:   %s 2>&1 | FileCheck -check-prefix=V4 %s
+// RUN:   %s 2>&1 | FileCheck -check-prefix=VD %s
 
-// V4: "-mllvm" "--amdhsa-code-object-version=4"
-// V4: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
+// VD: "-mllvm" "--amdhsa-code-object-version=4"
+// VD: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
 
 // Check invalid code object version option.
 

diff  --git a/clang/test/Driver/hip-device-compile.hip 
b/clang/test/Driver/hip-device-compile.hip
index 5fbcbc97bd805..c460ff7e8c67d 100644
--- a/clang/test/Driver/hip-device-compile.hip
+++ b/clang/test/Driver/hip-device-compile.hip
@@ -26,7 +26,7 @@
 // RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
 // RUN: 2>&1 | FileCheck -check-prefixes=CHECK,ASM %s
 
-// CHECK: {{".*clang.*"}} "-cc1" "-mllvm" "--amdhsa-code-object-version=4" 
"-triple" "amdgcn-amd-amdhsa"
+// CHECK: {{".*clang.*"}} "-cc1" "-mllvm" 
"--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // BC-SAME: "-emit-llvm-bc"
 // LL-SAME: "-emit-llvm"

diff  --git a/clang/test/Driver/hip-host-cpu-features.hip 
b/clang/test/Driver/hip-host-cpu-features.hip
index 235f0f1f22c24..8addfb11dc0b6 100644
--- a/clang/test/Driver/hip-host-cpu-features.hip
+++ b/clang/test/Driver/hip-host-cpu-features.hip
@@ -6,14 +6,14 @@
 // RUN: %clang -### -c -target x86_64-linux-gnu -msse3 --cuda-gpu-arch=gfx803 
-nogpulib %s 2>&1 | FileCheck %s -check-prefix=HOSTSSE3
 // RUN: %clang -### -c -target x86_64-linux-gnu --gpu-use-aux-triple-only 
-march=znver2 --cuda-gpu-arch=gfx803 -nogpulib %s 2>&1 | FileCheck %s 
-check-prefix=NOHOSTCPU
 
-// HOSTCPU: "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" 
"amdgcn-amd-amdhsa"
+// HOSTCPU: "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" 
"-triple" "amdgcn-amd-amdhsa"
 // HOSTCPU-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // HOSTCPU-SAME: "-aux-target-cpu" "znver2"
 
-// HOSTSSE3: "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" 
"amdgcn-amd-amdhsa"
+// HOSTSSE3: "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" 
"-triple" "amdgcn-amd-amdhsa"
 // HOSTSSE3-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // HOSTSSE3-SAME: "-aux-target-feature" "+sse3"
 
-// NOHOSTCPU: "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" 
"amdgcn-amd-amdhsa"
+// NOHOSTCPU: "-cc1" "-mllvm" "--amdhsa-code-object-versio

[PATCH] D93393: [clangd] Ignore the static index refs from the dynamic index files.

2020-12-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

TL;DR: Cool! I think we should complicate the signature of `hasFile()` a bit to 
avoid calling SwapIndex::snapshot() for each file. There's also some quadratic 
behavior due to calling index ops from MergeIndex when children are 
MergeIndexes, but N is small and I think we can solve it later.

---

I like the simplicity/elegance of this solution, and the fact that it avoids 
the scaling pitfall of trying to return a list of all the indexed files.

I am concerned about performance though. At a high level, we try to make index 
operations fairly coarse/batched and only do a handful of them. This was 
originally to allow these operations to be RPCs, but of course this assumption 
gets baked in in other ways too. Introducing a fine-grained operation like this 
causes some of the assumptions to be violated.

Concretely, SwapIndex (and ProjectAwareIndex) take a lock to obtain the index 
snapshot to use, and so here we do that for each call to `hasFile()`. Most 
indexes are wrapped in SwapIndex for either lazy-loading or dynamic updating.

And we hammer it reasonably hard here, MergeIndex::refs() will call it in a 
loop for ~100 times, and because there are multiple MergeIndexes in the index 
stack, we end up with duplication: the first index never gets hasFile(), the 
second gets it 100 times, the third 200 times, the fourth 300 times. (Currently 
we have at least 4 indexes in the stack).

Taking 600 locks to call refs() seems... less than ideal. For now they'll 
probably be uncontended as we only call refs() for interactive actions 
(find-references and rename), but fundamentally this applies to all requests, 
not just refs, so I'm not sure this will be true in the future (a fast 
pseudoparser index will want to consult the previous index to resolve symbols).

This all seems related to the idea that `hasFile()` isn't implemented for 
RemoteIndex - it's a pragmatic shortcut, but in principle it'd be nice to be 
able to implement it, and there's some minimum per-RPC overhead.

---

So, can we do anything about all this?

Locking once for each ref: fundamentally we want to lock once to get the 
snapshot, then query the snapshot for each file. This changing hasFile to 
return an oracle that can be cheaply queried, e.g. a signature like 
`unique_function SymbolIndex::indexedFiles()`.

The quadratic nature of calling any index ops in MergedIndex: I guess probably 
not without flattening our binary-tree/linked-list of MergedIndex into an N-way 
merge. Back in the day, we basically had one static index which was huge, and 
one dynamic index which was tiny, and the no-copy aspect of MergedIndex was 
appealing (and it was easy to implement!). But we're probably not coming out 
ahead anymore vs simply committing to copy everything once. The N-way merge 
would have other advantages too: we could query large/slow indexes in parallel 
to improve latency.

Implementing a pseudo-batch form of hasFiles as an RPC for remote-index: we'd 
need to give up on getting answers for files one-by-one. That would be OK for 
an N-way merge (since we'd fetch all results before merging, we could build a 
list). But servers typically index *everything* under a certain directory, so 
fetching the list of directories and evaluating per-file queries client-side is 
a cheap and reasonable alternative (that's more accurate than `return false`!)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93393

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


[PATCH] D93398: [NFC] Use regex for code object version in hip tests

2020-12-16 Thread Jon Chesterfield 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 rGc0619d3b21cd: [NFC] Use regex for code object version in hip 
tests (authored by JonChesterfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93398

Files:
  clang/test/Driver/hip-autolink.hip
  clang/test/Driver/hip-code-object-version.hip
  clang/test/Driver/hip-device-compile.hip
  clang/test/Driver/hip-host-cpu-features.hip
  clang/test/Driver/hip-rdc-device-only.hip
  clang/test/Driver/hip-target-id.hip
  clang/test/Driver/hip-toolchain-mllvm.hip
  clang/test/Driver/hip-toolchain-no-rdc.hip
  clang/test/Driver/hip-toolchain-opt.hip
  clang/test/Driver/hip-toolchain-rdc-separate.hip
  clang/test/Driver/hip-toolchain-rdc-static-lib.hip
  clang/test/Driver/hip-toolchain-rdc.hip

Index: clang/test/Driver/hip-toolchain-rdc.hip
===
--- clang/test/Driver/hip-toolchain-rdc.hip
+++ clang/test/Driver/hip-toolchain-rdc.hip
@@ -32,7 +32,7 @@
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // generate image for device side path on gfx803
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -43,7 +43,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC1:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
@@ -62,7 +62,7 @@
 // CHECK-SAME: "-o" "[[IMG_DEV1:.*.out]]" [[A_BC1]] [[B_BC1]]
 
 // generate image for device side path on gfx900
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -72,7 +72,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC2:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
Index: clang/test/Driver/hip-toolchain-rdc-static-lib.hip
===
--- clang/test/Driver/hip-toolchain-rdc-static-lib.hip
+++ clang/test/Driver/hip-toolchain-rdc-static-lib.hip
@@ -26,7 +26,7 @@
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // generate image for device side path on gfx803
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -35,7 +35,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC1:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip"
@@ -52,7 +52,7 @@
 // CHECK-SAME: "-o" "[[IMG_DEV1:.*out]]" [[A_BC1]] [[B_BC1]]
 
 // generate image for device side path on gfx900
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu"
@@ -61,7 +61,7 @@
 // CHECK-SAME: {{.*}} "-o" [[A_BC2:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
-// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version=4" "-triple" "amdgcn-amd-amdhsa"
+// CHECK: [[CLANG]] "-cc1" "-mllvm" "--amdhsa-code-object-version={{[0-9]+}}" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME

[PATCH] D93220: [clangd] Add error handling (elog) in code completion.

2020-12-16 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:193
+} else {
+  elog("Code completion header path manipulation failed {0}",
+   HeaderFile.takeError());

adamcz wrote:
> sammccall wrote:
> > I think this is too noisy.
> > 
> > We can hit this in "normal" cases of certain projects.
> > For better or worse, we don't currently filter out index results where we 
> > know the responsible header and can't include it (because it's not under 
> > any include path entry). In these cases toHeaderFile() returns an error.
> > 
> > Since this can happen in the normal case for *each* completion candidate 
> > (default 100), and completion requests are very frequent, this could 
> > dominate log output in affected projects.
> > 
> > It *might* be OK at vlog? I get the desire to not silence errors here. I 
> > think the question is what are the error cases we're *trying* to call out 
> > loudly. Maybe we can separate out the "shouldn't happen" vs the "fairly 
> > expected" cases.
> > (Even then there's the prospect that this is either going to not fire or 
> > fire dozens of times, which is a little sad)
> Originally I didn't even log here. We do this expansion at other places and 
> they may log already, I don't think it's critical to log here. Kadir pointed 
> out error needs to be handled or it will assert()-fail (that one place 
> returns Expected rather than Optional, I missed that), which is the 
> motivation for this change.
> 
> I made it vlog, but if you think it's too spammy I can remove it and just 
> ignore the error (by this time explicitly, so it doesn't crash). I don't 
> think we'll see these errors often - this only happens when we failed to 
> parse the URI or recognize the scheme, which basically can only happen with 
> remote index and some kind of version skew or corrupt data, so I'm fine with 
> vlog() I think.
Oh wow, I totally missed that the Expected was unhandled before!

Yeah let's go with vlog.
(If you like, downgrading the log() to vlog() for the callsite in 
CodeComplete.cpp seems like a good idea)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93220

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


[PATCH] D93102: [Clang][Sema] Detect section type conflicts between functions and variables

2020-12-16 Thread Tomas Matheson via Phabricator via cfe-commits
tmatheson updated this revision to Diff 312232.
tmatheson added a comment.
Herald added a subscriber: jdoerfert.

Extended to Objective-C methods and properties.
Added suggested C tests, C++ template function test and Objective-C tests.
I had to removed PSF_Implicit flag so that cases where the function was 
declared before the global variable were caught.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93102

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-section.c
  clang/test/SemaCXX/attr-section.cpp
  clang/test/SemaObjC/method-attributes.m

Index: clang/test/SemaObjC/method-attributes.m
===
--- clang/test/SemaObjC/method-attributes.m
+++ clang/test/SemaObjC/method-attributes.m
@@ -99,3 +99,18 @@
 
 + (void) CMethod : (id) Obj __attribute__((section("__TEXT,fee")));
 @end
+
+// Section type conflicts between methods/properties and global variables
+const int global1 __attribute__((section("seg1,sec1"))) = 10; // expected-note {{declared here}} expected-note {{declared here}} expected-note {{declared here}}
+int global2 __attribute__((section("seg2,sec2"))) = 10;   // expected-note {{declared here}} expected-note {{declared here}} expected-note {{declared here}}
+
+@interface section_conflicts : NSObject
+@property int p1 __attribute__((section("seg1,sec1"))); // expected-error {{'p1' causes a section type conflict with 'global1'}}
+@property int p2 __attribute__((section("seg2,sec2"))); // expected-error {{'p2' causes a section type conflict with 'global2'}}
+
+- (void)imethod1 __attribute__((section("seg1,sec1"))); // expected-error {{'imethod1' causes a section type conflict with 'global1'}}
+- (void)imethod2 __attribute__((section("seg2,sec2"))); // expected-error {{'imethod2' causes a section type conflict with 'global2'}}
+
++ (void)cmethod1:(id)Obj __attribute__((section("seg1,sec1"))); // expected-error {{'cmethod1:' causes a section type conflict with 'global1'}}
++ (void)cmethod2:(id)Obj __attribute__((section("seg2,sec2"))); // expected-error {{'cmethod2:' causes a section type conflict with 'global2'}}
+@end
Index: clang/test/SemaCXX/attr-section.cpp
===
--- clang/test/SemaCXX/attr-section.cpp
+++ clang/test/SemaCXX/attr-section.cpp
@@ -42,3 +42,9 @@
   __attribute__((section("baz"))) // expected-warning {{section does not match}}
   void C::f() {}
 }
+
+// Check for section type conflicts between global variables and function templates
+template  __attribute__((section("template_fn1"))) void template_fn1() {} // expected-note {{declared here}}
+const int const_global_var __attribute__((section("template_fn1"))) = 42;   // expected-error {{'const_global_var' causes a section type conflict with 'template_fn1'}}
+int mut_global_var __attribute__((section("template_fn2"))) = 42;   // expected-note {{declared here}}
+template  __attribute__((section("template_fn2"))) void template_fn2() {} // expected-error {{'template_fn2' causes a section type conflict with 'mut_global_var'}}
Index: clang/test/Sema/attr-section.c
===
--- clang/test/Sema/attr-section.c
+++ clang/test/Sema/attr-section.c
@@ -26,9 +26,27 @@
 
 // Not a warning.
 int c;
-int c __attribute__((section("foo,zed")));
+int c __attribute__((section("seg1,sec1")));
 
 // Also OK.
 struct r_debug {};
 extern struct r_debug _r_debug;
 struct r_debug _r_debug __attribute__((nocommon, section(".r_debug,bar")));
+
+// Section type conflicts between functions and variables
+void test3(void) __attribute__((section("seg3,sec3"))); // expected-note {{declared here}}
+void test3(void) {}
+const int const_global_var __attribute__((section("seg3,sec3"))) = 10; // expected-error {{'const_global_var' causes a section type conflict with 'test3'}}
+
+void test4(void) __attribute__((section("seg4,sec4"))); // expected-note {{declared here}}
+void test4(void) {}
+int mut_global_var __attribute__((section("seg4,sec4"))) = 10; // expected-error {{'mut_global_var' causes a section type conflict with 'test4'}}
+
+const int global_seg5sec5 __attribute__((section("seg5,sec5"))) = 10; // expected-note {{declared here}}
+void test5(void) __attribute__((section("seg5,sec5")));   // expected-error {{'test5' causes a section type conflict with 'global_seg5sec5'}}
+void test5(void) {}
+
+void test6(void);
+const int global_seg6sec6 __attribute__((section("seg6,sec6"))) = 10; // expected-note {{declared here}}
+void test6(void) __attribute__((section("seg6,sec6")));   // expected-error {{'test6' causes a section type conflict with 'global_seg6sec6'}}
+void test6(void) {}
Index: clang/lib/Sema/SemaDeclAttr.cpp
==

[PATCH] D93258: [amdgpu] Default to code object v3

2020-12-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield updated this revision to Diff 312236.
JonChesterfield added a comment.

- rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93258

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/hip-code-object-version.hip
  llvm/docs/AMDGPUUsage.rst


Index: llvm/docs/AMDGPUUsage.rst
===
--- llvm/docs/AMDGPUUsage.rst
+++ llvm/docs/AMDGPUUsage.rst
@@ -911,12 +911,12 @@
 
   * ``ELFABIVERSION_AMDGPU_HSA_V3`` is used to specify the version of AMD HSA
 runtime ABI for code object V3. Specify using the Clang option
-``-mcode-object-version=3``.
+``-mcode-object-version=3``. This is the default code object
+version if not specified.
 
   * ``ELFABIVERSION_AMDGPU_HSA_V4`` is used to specify the version of AMD HSA
 runtime ABI for code object V4. Specify using the Clang option
-``-mcode-object-version=4``. This is the default code object
-version if not specified.
+``-mcode-object-version=4``.
 
   * ``ELFABIVERSION_AMDGPU_PAL`` is used to specify the version of AMD PAL
 runtime ABI.
@@ -2871,10 +2871,6 @@
 Code Object V3 Metadata
 +++
 
-.. warning::
-  Code object V3 is not the default code object version emitted by this version
-  of LLVM.
-
 Code object V3 to V4 metadata is specified by the ``NT_AMDGPU_METADATA`` note
 record (see :ref:`amdgpu-note-records-v3-v4`).
 
@@ -3279,6 +3275,10 @@
 Code Object V4 Metadata
 +++
 
+.. warning::
+  Code object V4 is not the default code object version emitted by this version
+  of LLVM.
+
 Code object V4 metadata is the same as
 :ref:`amdgpu-amdhsa-code-object-metadata-v3` with the changes and additions
 defined in table :ref:`amdgpu-amdhsa-code-object-metadata-map-table-v3`.
Index: clang/test/Driver/hip-code-object-version.hip
===
--- clang/test/Driver/hip-code-object-version.hip
+++ clang/test/Driver/hip-code-object-version.hip
@@ -53,7 +53,7 @@
 // RUN:   --offload-arch=gfx906 -nogpulib \
 // RUN:   %s 2>&1 | FileCheck -check-prefix=VD %s
 
-// VD: "-mllvm" "--amdhsa-code-object-version=4"
+// VD: "-mllvm" "--amdhsa-code-object-version=3"
 // VD: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
 
 // Check invalid code object version option.
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1549,7 +1549,7 @@
 const Driver &D, const llvm::opt::ArgList &Args, bool Diagnose) {
   const unsigned MinCodeObjVer = 2;
   const unsigned MaxCodeObjVer = 4;
-  unsigned CodeObjVer = 4;
+  unsigned CodeObjVer = 3;
 
   // Emit warnings for legacy options even if they are overridden.
   if (Diagnose) {
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2909,7 +2909,7 @@
  HelpText<"Execution model (WebAssembly only)">;
 
 def mcode_object_version_EQ : Joined<["-"], "mcode-object-version=">, 
Group,
-  HelpText<"Specify code object ABI version. Defaults to 4. (AMDGPU only)">,
+  HelpText<"Specify code object ABI version. Defaults to 3. (AMDGPU only)">,
   MetaVarName<"">, Values<"2,3,4">;
 
 def mcode_object_v3_legacy : Flag<["-"], "mcode-object-v3">, Group,


Index: llvm/docs/AMDGPUUsage.rst
===
--- llvm/docs/AMDGPUUsage.rst
+++ llvm/docs/AMDGPUUsage.rst
@@ -911,12 +911,12 @@
 
   * ``ELFABIVERSION_AMDGPU_HSA_V3`` is used to specify the version of AMD HSA
 runtime ABI for code object V3. Specify using the Clang option
-``-mcode-object-version=3``.
+``-mcode-object-version=3``. This is the default code object
+version if not specified.
 
   * ``ELFABIVERSION_AMDGPU_HSA_V4`` is used to specify the version of AMD HSA
 runtime ABI for code object V4. Specify using the Clang option
-``-mcode-object-version=4``. This is the default code object
-version if not specified.
+``-mcode-object-version=4``.
 
   * ``ELFABIVERSION_AMDGPU_PAL`` is used to specify the version of AMD PAL
 runtime ABI.
@@ -2871,10 +2871,6 @@
 Code Object V3 Metadata
 +++
 
-.. warning::
-  Code object V3 is not the default code object version emitted by this version
-  of LLVM.
-
 Code object V3 to V4 metadata is specified by the ``NT_AMDGPU_METADATA`` note
 record (see :ref:`amdgpu-note-records-v3-v4`).
 
@@ -3279,6 +3275,10 @@
 Code Object V4 Metadata
 +++
 
+.. warning::
+  Code object V4 is not the default code object version emitted by this version
+  of LLVM.
+
 Code obj

[PATCH] D91974: [PowerPC] Rename the vector pair intrinsics and builtins to replace the _mma_ prefix by _vsx_

2020-12-16 Thread Baptiste Saleil via Phabricator via cfe-commits
bsaleil updated this revision to Diff 312238.
bsaleil added a comment.

Rebase and fix comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91974

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-mma.c
  clang/test/CodeGen/builtins-ppc-pair-mma.c
  clang/test/Sema/ppc-mma-types.c
  clang/test/Sema/ppc-pair-mma-types.c
  clang/test/SemaCXX/ppc-mma-types.cpp
  clang/test/SemaCXX/ppc-pair-mma-types.cpp
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/lib/Target/PowerPC/PPCLoopInstrFormPrep.cpp
  llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
  llvm/test/CodeGen/PowerPC/dform-pair-load-store.ll
  llvm/test/CodeGen/PowerPC/loop-p10-pair-prepare.ll
  llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
  llvm/test/CodeGen/PowerPC/mma-outer-product.ll
  llvm/test/CodeGen/PowerPC/mma-phi-accs.ll
  llvm/test/CodeGen/PowerPC/more-dq-form-prepare.ll
  llvm/test/CodeGen/PowerPC/paired-vector-intrinsics-without-mma.ll
  llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll

Index: llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
@@ -0,0 +1,357 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O3 \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr \
+; RUN:   < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O3 \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr -mattr=-mma \
+; RUN:   < %s | FileCheck %s --check-prefix=CHECK-NOMMA
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O3 \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr \
+; RUN:   < %s | FileCheck %s --check-prefix=CHECK-BE
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O3 \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr -mattr=-mma \
+; RUN:   < %s | FileCheck %s --check-prefix=CHECK-BE-NOMMA
+
+; This test also checks that the paired vector intrinsics are available even
+; when MMA is disabled.
+
+; assemble_pair
+declare <256 x i1> @llvm.ppc.vsx.assemble.pair(<16 x i8>, <16 x i8>)
+define void @ass_pair(<256 x i1>* %ptr, <16 x i8> %vc) {
+; CHECK-LABEL: ass_pair:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vmr v3, v2
+; CHECK-NEXT:stxv v2, 16(r3)
+; CHECK-NEXT:stxv v3, 0(r3)
+; CHECK-NEXT:blr
+;
+; CHECK-NOMMA-LABEL: ass_pair:
+; CHECK-NOMMA:   # %bb.0: # %entry
+; CHECK-NOMMA-NEXT:vmr v3, v2
+; CHECK-NOMMA-NEXT:stxv v2, 16(r3)
+; CHECK-NOMMA-NEXT:stxv v3, 0(r3)
+; CHECK-NOMMA-NEXT:blr
+;
+; CHECK-BE-LABEL: ass_pair:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:vmr v3, v2
+; CHECK-BE-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NEXT:stxv v2, 0(r3)
+; CHECK-BE-NEXT:blr
+;
+; CHECK-BE-NOMMA-LABEL: ass_pair:
+; CHECK-BE-NOMMA:   # %bb.0: # %entry
+; CHECK-BE-NOMMA-NEXT:vmr v3, v2
+; CHECK-BE-NOMMA-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NOMMA-NEXT:stxv v2, 0(r3)
+; CHECK-BE-NOMMA-NEXT:blr
+entry:
+  %0 = tail call <256 x i1> @llvm.ppc.vsx.assemble.pair(<16 x i8> %vc, <16 x i8> %vc)
+  store <256 x i1> %0, <256 x i1>* %ptr, align 32
+  ret void
+}
+
+; disassemble_pair
+declare { <16 x i8>, <16 x i8> } @llvm.ppc.vsx.disassemble.pair(<256 x i1>)
+define void @disass_pair(<256 x i1>* %ptr1, <16 x i8>* %ptr2, <16 x i8>* %ptr3) {
+; CHECK-LABEL: disass_pair:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lxv vs1, 0(r3)
+; CHECK-NEXT:lxv vs0, 16(r3)
+; CHECK-NEXT:stxv vs1, 0(r4)
+; CHECK-NEXT:stxv vs0, 0(r5)
+; CHECK-NEXT:blr
+;
+; CHECK-NOMMA-LABEL: disass_pair:
+; CHECK-NOMMA:   # %bb.0: # %entry
+; CHECK-NOMMA-NEXT:lxv vs1, 0(r3)
+; CHECK-NOMMA-NEXT:lxv vs0, 16(r3)
+; CHECK-NOMMA-NEXT:stxv vs1, 0(r4)
+; CHECK-NOMMA-NEXT:stxv vs0, 0(r5)
+; CHECK-NOMMA-NEXT:blr
+;
+; CHECK-BE-LABEL: disass_pair:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:lxv vs1, 16(r3)
+; CHECK-BE-NEXT:lxv vs0, 0(r3)
+; CHECK-BE-NEXT:stxv vs0, 0(r4)
+; CHECK-BE-NEXT:stxv vs1, 0(r5)
+; CHECK-BE-NEXT:blr
+;
+; CHECK-BE-NOMMA-LABEL: disass_pair:
+; CHECK-BE-NOMMA:   # %bb.0: # %entry
+; CHECK-BE-NOMMA-NEXT:lxv vs1, 16(r3)
+; CHECK-BE-NOMMA-NEXT:lxv vs0, 0(r3)
+; CHECK-BE-NOMMA-NEXT:stxv vs0, 0(r4)
+; CHECK-BE-NOMMA-NEXT:stxv vs1, 0(r5)
+; CHECK-BE-NOMMA-NEXT:blr
+entry:
+  %0 = load <256 x i1>, <256 x i1>* %ptr1, align 32
+  %1 = tail call { <16 x i8>, <16 x i8> } @llvm.ppc.vsx.disassemble.pair(<256 x i1> %0)
+  %2 = extractvalue { <16 x i8>, <16 x i8> } %1

[PATCH] D90159: [DDG] Data Dependence Graph - DOT printer

2020-12-16 Thread Bardia Mahjour via Phabricator via cfe-commits
bmahjour added a comment.

In D90159#2454905 , @bmahjour wrote:

> In D90159#2453805 , @Meinersbur 
> wrote:
>
>> Can I help fixing the Windows build problem?
>
> I think I have a fix (please see the updated patch), but don't have access to 
> a windows machine to verify. Would you be able to try building with MSVC and 
> let me know if it passes?

I'll try to recommit and watch the windows buildbots.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90159

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


[PATCH] D93102: [Clang][Sema] Detect section type conflicts between functions and variables

2020-12-16 Thread Tomas Matheson via Phabricator via cfe-commits
tmatheson marked 3 inline comments as done.
tmatheson added inline comments.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:3048
 D->addAttr(NewAttr);
+if (auto FD = dyn_cast(D))
+  if (auto SA = dyn_cast(NewAttr))

aaron.ballman wrote:
> Does this need to be limited to function declarations? It seems to me that 
> this should also be used on say ObjCMethod declarations or global variables 
> as well, right?
> 
> If so, then `Sema::UnifySection()` may need to be updated as well as it 
> currently accepts a `DeclaratorDecl` but some of these constructs (like 
> `ObjcMethodDecl` and `ObjCPropertyDecl`) are `NamedDecl`s and not declarators.
I've extended this to include Objective-C methods and properties and template 
functions. Gobal variables are handled by 
Sema::CheckCompleteVariableDeclaration.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93102

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


[clang] 6eff127 - [DDG] Data Dependence Graph - DOT printer - recommit

2020-12-16 Thread Bardia Mahjour via cfe-commits

Author: Bardia Mahjour
Date: 2020-12-16T12:37:36-05:00
New Revision: 6eff12788ee8d3f85f6e57809e757ca3250813d8

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

LOG: [DDG] Data Dependence Graph - DOT printer - recommit

This is being recommitted to try and address the MSVC complaint.

This patch implements a DDG printer pass that generates a graph in
the DOT description language, providing a more visually appealing
representation of the DDG. Similar to the CFG DOT printer, this
functionality is provided under an option called -dot-ddg and can
be generated in a less verbose mode under -dot-ddg-only option.

Reviewed By: Meinersbur

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

Added: 
llvm/include/llvm/Analysis/DDGPrinter.h
llvm/lib/Analysis/DDGPrinter.cpp

Modified: 
clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
llvm/include/llvm/Analysis/CFGPrinter.h
llvm/include/llvm/Analysis/DDG.h
llvm/include/llvm/Support/DOTGraphTraits.h
llvm/include/llvm/Support/GraphWriter.h
llvm/lib/Analysis/CFGPrinter.cpp
llvm/lib/Analysis/CMakeLists.txt
llvm/lib/Analysis/CallPrinter.cpp
llvm/lib/CodeGen/MachineScheduler.cpp
llvm/lib/CodeGen/ScheduleDAGPrinter.cpp
llvm/lib/Passes/PassBuilder.cpp
llvm/lib/Passes/PassRegistry.def

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp 
b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
index 409741cdb6e4..f285b652c175 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -3149,7 +3149,7 @@ struct DOTGraphTraits : public 
DefaultDOTGraphTraits {
   if (Stop(N))
 return true;
 
-  if (N->succ_size() != 1 || !isNodeHidden(N->getFirstSucc()))
+  if (N->succ_size() != 1 || !isNodeHidden(N->getFirstSucc(), nullptr))
 break;
   PostCallback(N);
 
@@ -3158,7 +3158,7 @@ struct DOTGraphTraits : public 
DefaultDOTGraphTraits {
 return false;
   }
 
-  static bool isNodeHidden(const ExplodedNode *N) {
+  static bool isNodeHidden(const ExplodedNode *N, const ExplodedGraph *G) {
 return N->isTrivial();
   }
 

diff  --git a/llvm/include/llvm/Analysis/CFGPrinter.h 
b/llvm/include/llvm/Analysis/CFGPrinter.h
index bc6a19f2e2b9..53700798b6b3 100644
--- a/llvm/include/llvm/Analysis/CFGPrinter.h
+++ b/llvm/include/llvm/Analysis/CFGPrinter.h
@@ -295,7 +295,7 @@ struct DOTGraphTraits : public 
DefaultDOTGraphTraits {
 " fillcolor=\"" + Color + "70\"";
 return Attrs;
   }
-  bool isNodeHidden(const BasicBlock *Node);
+  bool isNodeHidden(const BasicBlock *Node, const DOTFuncInfo *CFGInfo);
   void computeHiddenNodes(const Function *F);
 };
 } // End llvm namespace

diff  --git a/llvm/include/llvm/Analysis/DDG.h 
b/llvm/include/llvm/Analysis/DDG.h
index 9e2b7907eaec..8d225c155cd4 100644
--- a/llvm/include/llvm/Analysis/DDG.h
+++ b/llvm/include/llvm/Analysis/DDG.h
@@ -290,6 +290,12 @@ template  class DependenceGraphInfo {
   bool getDependencies(const NodeType &Src, const NodeType &Dst,
DependenceList &Deps) const;
 
+  /// Return a string representing the type of dependence that the dependence
+  /// analysis identified between the two given nodes. This function assumes
+  /// that there is a memory dependence between the given two nodes.
+  const std::string getDependenceString(const NodeType &Src,
+const NodeType &Dst) const;
+
 protected:
   // Name of the graph.
   std::string Name;
@@ -463,6 +469,26 @@ bool DependenceGraphInfo::getDependencies(
   return !Deps.empty();
 }
 
+template 
+const std::string
+DependenceGraphInfo::getDependenceString(const NodeType &Src,
+   const NodeType &Dst) const {
+  std::string Str;
+  raw_string_ostream OS(Str);
+  DependenceList Deps;
+  if (!getDependencies(Src, Dst, Deps))
+return OS.str();
+  interleaveComma(Deps, OS, [&](const std::unique_ptr &D) {
+D->dump(OS);
+// Remove the extra new-line character printed by the dump
+// method
+if (OS.str().back() == '\n')
+  OS.str().pop_back();
+  });
+
+  return OS.str();
+}
+
 //======//
 // GraphTraits specializations for the DDG
 //======//

diff  --git a/llvm/include/llvm/Analysis/DDGPrinter.h 
b/llvm/include/llvm/Analysis/DDGPrinter.h
new file mode 100644
index ..4477b387fe50
--- /dev/null
+++ b/llvm/include/llvm/Analysis/DDGPrinter.h
@@ -0,0 +1,91 @@
+//===- llvm/Analysis/DDGPrinter.h ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exception

[PATCH] D87146: [analyzer] Implement shared semantics checks for XNU functions in PthreadLockChecker

2020-12-16 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

Hey, folk. Please, look at this revision.
This is the **2nd** revision from the //stack of 3//. Its aim is preparing the 
field for the **3rd** revision (also welcome to review). The **1st** one has 
been closed.


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

https://reviews.llvm.org/D87146

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


[PATCH] D93068: [clang-offload-bundler] Add option -allow-missing-bundles

2020-12-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D93068#2457946 , @yaxunl wrote:

> @ABataev Is this patch OK for OpenMP? It is NFC for OpenMP toolchain but 
> affects using clang-offload-bundler as a standalone tool. Thanks.

Yes, I think it is ok.


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

https://reviews.llvm.org/D93068

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


  1   2   >