Re: [clang] 4a0267e - Convert a reachable llvm_unreachable into an assert.

[David Blaikie via cfe-commits]

On Mon, Mar 23, 2020 at 5:24 AM Aaron Ballman 
wrote:

> On Sun, Mar 22, 2020 at 3:31 PM David Blaikie  wrote:
> >
> > On Sun, Mar 22, 2020 at 9:34 AM Aaron Ballman 
> wrote:
> >>
> >> On Sun, Mar 22, 2020 at 12:19 PM David Blaikie 
> wrote:
> >> >
> >> > On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballman 
> wrote:
> >> >>
> >> >> On Sat, Mar 21, 2020 at 11:31 PM David Blaikie 
> wrote:
> >> >> >
> >> >> > Why the change? this seems counter to LLVM's style which pretty
> consistently uses unreachable rather than assert(false), so far as I know?
> >> >>
> >> >> We're not super consistent (at least within Clang), but the rules as
> >> >> I've generally understood them are to use llvm_unreachable only for
> >> >> truly unreachable code and to use assert(false) when the code is
> >> >> technically reachable but is a programmer mistake to have gotten
> >> >> there.
> >> >
> >> >
> >> > I don't see those as two different things personally -
> llvm_unreachable is used when the programmer believes it to be unreachable
> (not that it must be proven to be unreachable - we have message text there
> so it's informative if the assumption turns out not to hold)
> >>
> >> The message text doesn't help when the code is reached in release
> >> mode, which was the issue. Asserts + release you still get some
> >> helpful text saying "you screwed up". llvm_unreachable in release
> >> mode, you may get lucky or you may not (in this case, I didn't get
> >> lucky -- there was no text, just a crash).
> >
> >
> > That doesn't seem to be what it's documented to do:
> >
> > /// Marks that the current location is not supposed to be reachable.
> > /// In !NDEBUG builds, prints the message and location info to stderr.
> > /// In NDEBUG builds, becomes an optimizer hint that the current location
> > /// is not supposed to be reachable.  On compilers that don't support
> > /// such hints, prints a reduced message instead.
> >
> > & certainly I think the documentation is what it /should/ be doing.
> >
> > /maybe/
> https://reviews.llvm.org/rG5f4535b974e973d52797945fbf80f19ffba8c4ad broke
> that contract on Windows, but I'm not sure how? (an unreachable at the end
> of that function shouldn't cause the whole function to be unreachable -
> because abort could have side effects and halt the program before the
> unreachable is reached)
>
> Agreed. It could also be that my machine is in a weird state (I'm
> currently battling a situation where the command line parser appears
> to be totally broken on Windows due to misuse of a ManagedStatic
> somewhere but I've not seen any commits that relate to the issues).
>
> >> >> In this particular case, the code is very much reachable
> >> >
> >> >
> >> > In what sense? If it is actually reachable - shouldn't it be tested?
> (& in which case the assert(false) will get in the way of that testing)
> >>
> >> In the sense that normal code paths reach that code easily. Basically,
> >> that code is checking to see whether a plugin you've written properly
> >> sets up its options or not. When you're developing a plugin, it's
> >> quite reasonable to expect you won't get it just right on the first
> >> try, so you hit the code path but only as a result of you not writing
> >> the plugin quite right. So under normal conditions (once the plugin is
> >> working), the code path should not be reached but under development
> >> the code path gets reached accidentally.
> >>
> >> >> and I
> >> >> spent a lot more time debugging than I should have because I was
> using
> >> >> a release + asserts build and the semantics of llvm_unreachable made
> >> >> unfortunate codegen (switching to an assert makes the issue
> >> >> immediately obvious).
> >> >
> >> >
> >> > I think it might be reasonable to say that release+asserts to have
> unreachable behave the same way unreachable behaves at -O0 (which is to
> say, much like assert(false)). Clearly release+asserts effects code
> generation, so there's nothing like the "debug info invariance" goal that
> this would be tainting, etc.
> >> >
> >> > Certainly opinions vary here, but here are some commits that show the
> sort of general preference:
> >> > http://llvm.org/viewvc/llvm-project?view=revision=259302
> >> > http://llvm.org/viewvc/llvm-project?view=revision=253005
> >> > http://llvm.org/viewvc/llvm-project?view=revision=251266
> >> >
> >> > And some counter examples:
> >> > http://llvm.org/viewvc/llvm-project?view=revision=225043
> >> > Including this thread where Chandler originally (not sure what his
> take on it is these days) expressed some ideas more along your lines:
> >> >
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20110919/thread.html#46583
> >> >
> >> > But I'm always pretty concerned about the idea that assertions should
> be used in places where the behavior of the program has any constraints
> when the assertion is false...
> >>
> >> I'm opposed to using unreachability hints on control flow paths you
> >> expect to reach -- the semantics are just 

Re: [clang] 43606ef - Suppress an "unused variable" warning in release build

[David Blaikie via cfe-commits]

Ah, thanks. (I'm going to see about renaming/restructuring that API - to
return Optional and be called 'get' rather than 'is' to make this
more clear)

On Mon, Mar 23, 2020 at 5:04 AM Mikhail Maltsev 
wrote:

> Yes, it does. isIntegerConstantExpr assigns a value to CoprocNoAP.
>
> --
> Regards,
>Mikhail Maltsev
>
> 
> From: David Blaikie 
> Sent: Sunday, March 22, 2020 03:32
> To: Mikhail Maltsev; Mikhail Maltsev
> Cc: cfe-commits
> Subject: Re: [clang] 43606ef - Suppress an "unused variable" warning in
> release build
>
> Does "isIntegerConstantExpr" have side effects that are desired/necessary?
> Otherwise please change this to roll the isIntegerConstantExpr into the
> assert (so that it is only executed when asserts are enabled)
>
> On Tue, Mar 10, 2020 at 10:11 AM Mikhail Maltsev via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: Mikhail Maltsev
> Date: 2020-03-10T17:10:52Z
> New Revision: 43606efb6847fc9c79e7d93760a2a6191e8a8539
>
> URL:
> https://github.com/llvm/llvm-project/commit/43606efb6847fc9c79e7d93760a2a6191e8a8539
> DIFF:
> https://github.com/llvm/llvm-project/commit/43606efb6847fc9c79e7d93760a2a6191e8a8539.diff
>
> LOG: Suppress an "unused variable" warning in release build
>
> Added:
>
>
> Modified:
> clang/lib/Sema/SemaChecking.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/Sema/SemaChecking.cpp
> b/clang/lib/Sema/SemaChecking.cpp
> index 24d0d9209a1d..8a2b4b019663 100644
> --- a/clang/lib/Sema/SemaChecking.cpp
> +++ b/clang/lib/Sema/SemaChecking.cpp
> @@ -2094,6 +2094,7 @@ bool Sema::CheckARMCoprocessorImmediate(const Expr
> *CoprocArg, bool WantCDE) {
>
>llvm::APSInt CoprocNoAP;
>bool IsICE = CoprocArg->isIntegerConstantExpr(CoprocNoAP, Context);
> +  (void)IsICE;
>assert(IsICE && "Coprocossor immediate is not a constant expression");
>int64_t CoprocNo = CoprocNoAP.getExtValue();
>assert(CoprocNo >= 0 && "Coprocessor immediate must be non-negative");
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 2ec59a0 - Buildbot debugging of 0d0b90105f92f6cd9cc7004d565834f4429183fb (lambda/function_ref lifetime issues)

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2020-03-22T22:43:44-07:00
New Revision: 2ec59a0a40f4ec02e6b2dbe5f12261959c191aa9

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

LOG: Buildbot debugging of 0d0b90105f92f6cd9cc7004d565834f4429183fb 
(lambda/function_ref lifetime issues)

This is failing on several buildbots with some inexplicable (to me,
right now) crashes. Let's see if this change is adequate to unblock the
buildbots & further understanding can be gained later.

Added: 


Modified: 
clang/include/clang/AST/OpenMPClause.h

Removed: 




diff  --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index 548328d36a79..a781797c2d56 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -7061,9 +7061,9 @@ struct OMPTraitInfo {
 
   bool anyScoreOrCondition(
   llvm::function_ref Cond) {
-return llvm::any_of(Sets, [Cond](OMPTraitInfo::OMPTraitSet ) {
+return llvm::any_of(Sets, [&](OMPTraitInfo::OMPTraitSet ) {
   return llvm::any_of(
-  Set.Selectors, [Cond](OMPTraitInfo::OMPTraitSelector ) {
+  Set.Selectors, [&](OMPTraitInfo::OMPTraitSelector ) {
 return Cond(Selector.ScoreOrCondition,
 /* IsScore */ Selector.Kind !=
 llvm::omp::TraitSelector::user_condition);



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

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

[David Blaikie via cfe-commits]

Reverted in 0d0b90105f92f6cd9cc7004d565834f4429183fb & I'll see what
happens with the buildbots.

On Sun, Mar 22, 2020 at 5:47 PM Johannes Doerfert 
wrote:

>
> Apologies for the confusion.
>
> I wrote the commit message after looking into this and I though the
> issue was related to the capture by copy in the inner llvm::any_of and
> the reuse in the outer. Looking back at the code I cannot say anymore
> how I got that impression.
>
> If you think the reference is problematic, I'm totally happy to remove
> it. If the windows bots (or any other ones) don't like it we need to
> investigate why. As mentioned, I had a problem recreating the problem
> locally before.
>
> Cheers,
>Johannes
>
>
> On 3/22/20 1:37 PM, Arthur O'Dwyer wrote:
>  > On Sun, Mar 22, 2020 at 1:48 PM David Blaikie via cfe-commits <
>  > cfe-commits@lists.llvm.org> wrote:
>  >
>  >> On Sun, Mar 22, 2020 at 10:40 AM Johannes Doerfert
> 
>  >> wrote:
>  >>
>  >>> Some buildbots, I think only Windows buildbots for some reason,
> crashed
>  >>> in this function.
>  >>>
>  >>> The reason, as described, is that an `llvm::function_ref` cannot be
>  >>> copied and then reused. It just happened to work on almost all
>  >>> configurations.
>  >>>
>  >>
>  >> That doesn't seem to be accurate, or if it is there's a lot of
> mistakes in
>  >> the codebase - basically every function_ref parameter I can see in
> LLVM is
>  >> passing by value, not by const ref. The implementation of
>  >> llvm::function_ref looks quite copyable so long as it doesn't
> outlive the
>  >> functor it is pointing to.
>  >>
>  >
>  > David is correct. llvm::function_ref, like std::reference_wrapper, is a
>  > trivially copyable type, and it's designed to be copied.
>  > Like string_view and reference_wrapper, function_ref is designed to be
>  > passed by value. Redundantly passing function_ref *again by
> reference* is a
>  > code smell.
>  >
>  > I've also checked the code here, and it looks like there are only two
>  > callers of `anyScoreOrCondition` — both in Sema/SemaOpenMP.cpp — and
> they
>  > are both fine. FWIW, I would recommend reverting Johannes' change and
>  > seeing if those Windows buildbots are still unhappy (and if so, why).
>  >
>  >
>  > Btw, one failure mode I'm aware of, but which I believe is NOT
> relevant in
>  > Johannes' case, is that `function_ref`'s converting constructor behaves
>  > differently from its copy constructor.
>  >
>  > int main()
>  >
>  > {
>  >
>  > auto lamb = [](){ return 42; };
>  >
>  > auto sheep = [](){ return 43; };
>  >
>  > llvm::function_ref one = lamb;
>  >
>  >
>  > llvm::function_ref twoA = one;// twoA refers to lamb
>  >
>  > llvm::function_ref twoB = one;  // twoB refers to one which
>  > refers to lamb
>  >
>  >
>  > one = sheep;
>  >
>  >
>  > assert(twoA() == 42);  // twoA refers to lamb
>  >
>  > assert(twoB() == 43);  // twoB refers to one which refers to sheep
>  >
>  > }
>  >
>  > That is, if you have a function that takes a parameter of type
>  > function_ref, and someone passes it an argument of type
> function_ref,
>  > then inside the function your parameter will be referring to that
> argument
>  > itself instead of to its referent.
>  > However, in Johannes' particular case, we have no function_refs
> referring
>  > to other function_refs. We just make a lambda and take a function_ref to
>  > it, the end. So I'm pretty sure this pitfall is irrelevant.
>  >
>  > –Arthur
>  >
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 0d0b901 - Revert "[FIX] Do not copy an llvm::function_ref if it has to be reused"

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2020-03-22T18:43:39-07:00
New Revision: 0d0b90105f92f6cd9cc7004d565834f4429183fb

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

LOG: Revert "[FIX] Do not copy an llvm::function_ref if it has to be reused"

This fix doesn't seem to be right (function_ref can/should be passed by
value) so I'm reverted it to see if the buildbots decide to explain
what's wrong.

This reverts commit 857bf5da35af8e1f9425e1865dab5f5fce5e38f2.

Added: 


Modified: 
clang/include/clang/AST/OpenMPClause.h

Removed: 




diff  --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index 38485cb1ad7e..548328d36a79 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -7060,10 +7060,10 @@ struct OMPTraitInfo {
   llvm::SmallVector Sets;
 
   bool anyScoreOrCondition(
-  const llvm::function_ref ) {
-return llvm::any_of(Sets, [](OMPTraitInfo::OMPTraitSet ) {
+  llvm::function_ref Cond) {
+return llvm::any_of(Sets, [Cond](OMPTraitInfo::OMPTraitSet ) {
   return llvm::any_of(
-  Set.Selectors, [](OMPTraitInfo::OMPTraitSelector ) {
+  Set.Selectors, [Cond](OMPTraitInfo::OMPTraitSelector ) {
 return Cond(Selector.ScoreOrCondition,
 /* IsScore */ Selector.Kind !=
 llvm::omp::TraitSelector::user_condition);



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

Re: [clang] 4a0267e - Convert a reachable llvm_unreachable into an assert.

[David Blaikie via cfe-commits]

On Sun, Mar 22, 2020 at 9:34 AM Aaron Ballman 
wrote:

> On Sun, Mar 22, 2020 at 12:19 PM David Blaikie  wrote:
> >
> > On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballman 
> wrote:
> >>
> >> On Sat, Mar 21, 2020 at 11:31 PM David Blaikie 
> wrote:
> >> >
> >> > Why the change? this seems counter to LLVM's style which pretty
> consistently uses unreachable rather than assert(false), so far as I know?
> >>
> >> We're not super consistent (at least within Clang), but the rules as
> >> I've generally understood them are to use llvm_unreachable only for
> >> truly unreachable code and to use assert(false) when the code is
> >> technically reachable but is a programmer mistake to have gotten
> >> there.
> >
> >
> > I don't see those as two different things personally - llvm_unreachable
> is used when the programmer believes it to be unreachable (not that it must
> be proven to be unreachable - we have message text there so it's
> informative if the assumption turns out not to hold)
>
> The message text doesn't help when the code is reached in release
> mode, which was the issue. Asserts + release you still get some
> helpful text saying "you screwed up". llvm_unreachable in release
> mode, you may get lucky or you may not (in this case, I didn't get
> lucky -- there was no text, just a crash).
>

That doesn't seem to be what it's documented to do:

/// Marks that the current location is not supposed to be reachable.
/// In !NDEBUG builds, prints the message and location info to stderr.
/// In NDEBUG builds, becomes an optimizer hint that the current location
/// is not supposed to be reachable.  On compilers that don't support
/// such hints, prints a reduced message instead.

& certainly I think the documentation is what it /should/ be doing.

/maybe/ https://reviews.llvm.org/rG5f4535b974e973d52797945fbf80f19ffba8c4ad
broke
that contract on Windows, but I'm not sure how? (an unreachable at the end
of that function shouldn't cause the whole function to be unreachable -
because abort could have side effects and halt the program before the
unreachable is reached)


> >> In this particular case, the code is very much reachable
> >
> >
> > In what sense? If it is actually reachable - shouldn't it be tested? (&
> in which case the assert(false) will get in the way of that testing)
>
> In the sense that normal code paths reach that code easily. Basically,
> that code is checking to see whether a plugin you've written properly
> sets up its options or not. When you're developing a plugin, it's
> quite reasonable to expect you won't get it just right on the first
> try, so you hit the code path but only as a result of you not writing
> the plugin quite right. So under normal conditions (once the plugin is
> working), the code path should not be reached but under development
> the code path gets reached accidentally.
>
> >> and I
> >> spent a lot more time debugging than I should have because I was using
> >> a release + asserts build and the semantics of llvm_unreachable made
> >> unfortunate codegen (switching to an assert makes the issue
> >> immediately obvious).
> >
> >
> > I think it might be reasonable to say that release+asserts to have
> unreachable behave the same way unreachable behaves at -O0 (which is to
> say, much like assert(false)). Clearly release+asserts effects code
> generation, so there's nothing like the "debug info invariance" goal that
> this would be tainting, etc.
> >
> > Certainly opinions vary here, but here are some commits that show the
> sort of general preference:
> > http://llvm.org/viewvc/llvm-project?view=revision=259302
> > http://llvm.org/viewvc/llvm-project?view=revision=253005
> > http://llvm.org/viewvc/llvm-project?view=revision=251266
> >
> > And some counter examples:
> > http://llvm.org/viewvc/llvm-project?view=revision=225043
> > Including this thread where Chandler originally (not sure what his take
> on it is these days) expressed some ideas more along your lines:
> >
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20110919/thread.html#46583
> >
> > But I'm always pretty concerned about the idea that assertions should be
> used in places where the behavior of the program has any constraints when
> the assertion is false...
>
> I'm opposed to using unreachability hints on control flow paths you
> expect to reach -- the semantics are just plain wrong, even if you can
> get the same end result of controlled crash + message. In this
> particular case, the code is reachable but erroneous to do so -- and
> that's what assertions are intended to be used for. My preference is
> to use llvm_unreachable because the code is unreachable, not because
> the code should not be reachable only if everything works out right.
>
> It may be that we're not in agreement about the definition of "expects
> to reach" here. To me, this code clearly expects to reach that path:
> it's a search over a finite collection where it's possible the thing
> being searched for is not found. The "we didn't 

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

[David Blaikie via cfe-commits]

On Sun, Mar 22, 2020 at 10:40 AM Johannes Doerfert 
wrote:

> Some buildbots, I think only Windows buildbots for some reason, crashed
> in this function.
>
> The reason, as described, is that an `llvm::function_ref` cannot be
> copied and then reused. It just happened to work on almost all
> configurations.
>

That doesn't seem to be accurate, or if it is there's a lot of mistakes in
the codebase - basically every function_ref parameter I can see in LLVM is
passing by value, not by const ref. The implementation of
llvm::function_ref looks quite copyable so long as it doesn't outlive the
functor it is pointing to.


> The change was not a "shot in the dark" but identified as proper fix by
> examining the `llvm::function_ref` implementation.
>

What aspect of the implementation of llvm::function_ref makes it not safe
to copy in the way the code original did so? My reading of it makes it look
like it's OK to copy so long as it doesn't outlive the functor it is
pointing to (& the code as originall written doesn't look like it's
outliving the caller's functor)


> I could not reproduce the error on any machine I had immediately access
> to so maybe you can call that part "shot in the dark".
>

Sounds like this sort of thing could/should've shown up with msan, maybe?
Were you able to test with any sanitizers?


>
>
> I'm not sure what else you want me to add here as a explanation but
> please let me know if there is anything I can do.
>
>
> On 3/22/20 12:21 AM, David Blaikie wrote:
> > "a problem" seems a smidge vague - was there a specific explanation for
> the
> > kind of problem that was signalled? Or was this fix a bit of a shot in
> the
> > dark?
> >
> > On Sat, Feb 15, 2020 at 10:55 PM Johannes Doerfert via cfe-commits <
> > cfe-commits@lists.llvm.org> wrote:
> >
> >> Author: Johannes Doerfert
> >> Date: 2020-02-16T00:51:11-06:00
> >> New Revision: 857bf5da35af8e1f9425e1865dab5f5fce5e38f2
> >>
> >> URL:
> >>
> https://github.com/llvm/llvm-project/commit/857bf5da35af8e1f9425e1865dab5f5fce5e38f2
> >> DIFF:
> >>
> https://github.com/llvm/llvm-project/commit/857bf5da35af8e1f9425e1865dab5f5fce5e38f2.diff
> >>
> >> LOG: [FIX] Do not copy an llvm::function_ref if it has to be reused
> >>
> >> Some buildbots signaled a problem in this method when the
> >> llvm::function_ref was copied and reused after 1228d42ddab8. To
> >> eliminate the problem we avoid copying the llvm::function_ref and
> >> instead we pass it as a const reference.
> >>
> >> Added:
> >>
> >>
> >> Modified:
> >>  clang/include/clang/AST/OpenMPClause.h
> >>
> >> Removed:
> >>
> >>
> >>
> >>
> >>
> 
> >> diff  --git a/clang/include/clang/AST/OpenMPClause.h
> >> b/clang/include/clang/AST/OpenMPClause.h
> >> index a3831fd5950f..453c068bbeb0 100644
> >> --- a/clang/include/clang/AST/OpenMPClause.h
> >> +++ b/clang/include/clang/AST/OpenMPClause.h
> >> @@ -6682,10 +6682,10 @@ struct OMPTraitInfo {
> >> llvm::SmallVector Sets;
> >>
> >> bool anyScoreOrCondition(
> >> -  llvm::function_ref Cond) {
> >> -return llvm::any_of(Sets, [Cond](OMPTraitInfo::OMPTraitSet ) {
> >> +  const llvm::function_ref
> ) {
> >> +return llvm::any_of(Sets, [](OMPTraitInfo::OMPTraitSet ) {
> >> return llvm::any_of(
> >> -  Set.Selectors, [Cond](OMPTraitInfo::OMPTraitSelector
> )
> >> {
> >> +  Set.Selectors, [](OMPTraitInfo::OMPTraitSelector
> >> ) {
> >>   return Cond(Selector.ScoreOrCondition,
> >>   /* IsScore */ Selector.Kind !=
> >>   llvm::omp::TraitSelector::user_condition);
> >>
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] 4a0267e - Convert a reachable llvm_unreachable into an assert.

[David Blaikie via cfe-commits]

On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballman 
wrote:

> On Sat, Mar 21, 2020 at 11:31 PM David Blaikie  wrote:
> >
> > Why the change? this seems counter to LLVM's style which pretty
> consistently uses unreachable rather than assert(false), so far as I know?
>
> We're not super consistent (at least within Clang), but the rules as
> I've generally understood them are to use llvm_unreachable only for
> truly unreachable code and to use assert(false) when the code is
> technically reachable but is a programmer mistake to have gotten
> there.


I don't see those as two different things personally - llvm_unreachable is
used when the programmer believes it to be unreachable (not that it must be
proven to be unreachable - we have message text there so it's informative
if the assumption turns out not to hold)


> In this particular case, the code is very much reachable


In what sense? If it is actually reachable - shouldn't it be tested? (& in
which case the assert(false) will get in the way of that testing)


> and I
> spent a lot more time debugging than I should have because I was using
> a release + asserts build and the semantics of llvm_unreachable made
> unfortunate codegen (switching to an assert makes the issue
> immediately obvious).
>

I think it might be reasonable to say that release+asserts to have
unreachable behave the same way unreachable behaves at -O0 (which is to
say, much like assert(false)). Clearly release+asserts effects code
generation, so there's nothing like the "debug info invariance" goal that
this would be tainting, etc.

Certainly opinions vary here, but here are some commits that show the sort
of general preference:
http://llvm.org/viewvc/llvm-project?view=revision=259302
http://llvm.org/viewvc/llvm-project?view=revision=253005
http://llvm.org/viewvc/llvm-project?view=revision=251266

And some counter examples:
http://llvm.org/viewvc/llvm-project?view=revision=225043
Including this thread where Chandler originally (not sure what his take on
it is these days) expressed some ideas more along your lines:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20110919/thread.html#46583

But I'm always pretty concerned about the idea that assertions should be
used in places where the behavior of the program has any constraints when
the assertion is false...

- Dave


>
> >
> > On Tue, Mar 10, 2020 at 11:22 AM Aaron Ballman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >>
> >>
> >> Author: Aaron Ballman
> >> Date: 2020-03-10T14:22:21-04:00
> >> New Revision: 4a0267e3ad8c4d47f267d7d960f127e099fb4818
> >>
> >> URL:
> https://github.com/llvm/llvm-project/commit/4a0267e3ad8c4d47f267d7d960f127e099fb4818
> >> DIFF:
> https://github.com/llvm/llvm-project/commit/4a0267e3ad8c4d47f267d7d960f127e099fb4818.diff
> >>
> >> LOG: Convert a reachable llvm_unreachable into an assert.
> >>
> >> Added:
> >>
> >>
> >> Modified:
> >> clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> >>
> >> Removed:
> >>
> >>
> >>
> >>
> 
> >> diff  --git a/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> b/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> >> index 01ac2bc83bb6..99e16752b51a 100644
> >> --- a/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> >> +++ b/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> >> @@ -134,9 +134,9 @@ StringRef
> AnalyzerOptions::getCheckerStringOption(StringRef CheckerName,
> >>  CheckerName = CheckerName.substr(0, Pos);
> >>} while (!CheckerName.empty() && SearchInParents);
> >>
> >> -  llvm_unreachable("Unknown checker option! Did you call
> getChecker*Option "
> >> -   "with incorrect parameters? User input must've been
> "
> >> -   "verified by CheckerRegistry.");
> >> +  assert(false && "Unknown checker option! Did you call
> getChecker*Option "
> >> +  "with incorrect parameters? User input must've been "
> >> +  "verified by CheckerRegistry.");
> >>
> >>return "";
> >>  }
> >>
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] 7a42bab - Reland "[DebugInfo][clang][DWARF5]: Added support for debuginfo generation for defaulted parameters

[David Blaikie via cfe-commits]

In the future, please include more detail in the commit message of a
recommit about how the patch addresses the problems that lead to the
previous revert. This makes it easier for someone reviewing the code to
examine the new changes & ensure they're correct/appropriate.

On Mon, Mar 2, 2020 at 3:16 AM Sourabh Singh Tomar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Awanish Pandey
> Date: 2020-03-02T16:45:48+05:30
> New Revision: 7a42babeb83e3927e89e72a0e7e45be9d41b6c23
>
> URL:
> https://github.com/llvm/llvm-project/commit/7a42babeb83e3927e89e72a0e7e45be9d41b6c23
> DIFF:
> https://github.com/llvm/llvm-project/commit/7a42babeb83e3927e89e72a0e7e45be9d41b6c23.diff
>
> LOG: Reland "[DebugInfo][clang][DWARF5]: Added support for debuginfo
> generation for defaulted parameters
> in C++ templates."
>
> This was reverted in 802b22b5c8c30bebc1695a217478be02653c6b53 due to
> missing .bc file and a chromium bot failure.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1057559#c1
> This revision address both of them.
>
> Summary:
> This patch adds support for debuginfo generation for defaulted
> parameters in clang and also extends corresponding DebugMetadata/IR to
> support this feature.
>
> Reviewers: probinson, aprantl, dblaikie
>
> Reviewed By: aprantl, dblaikie
>
> Differential Revision: https://reviews.llvm.org/D73462
>
> Added:
> llvm/test/Assembler/DIDefaultTemplateParam.ll
> llvm/test/Bitcode/DITemplateParameter-5.0.ll
> llvm/test/Bitcode/DITemplateParameter-5.0.ll.bc
>
> Modified:
> clang/lib/CodeGen/CGDebugInfo.cpp
> llvm/include/llvm/IR/DIBuilder.h
> llvm/include/llvm/IR/DebugInfoMetadata.h
> llvm/lib/AsmParser/LLParser.cpp
> llvm/lib/Bitcode/Reader/MetadataLoader.cpp
> llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
> llvm/lib/IR/AsmWriter.cpp
> llvm/lib/IR/DIBuilder.cpp
> llvm/lib/IR/DebugInfoMetadata.cpp
> llvm/lib/IR/LLVMContextImpl.h
> llvm/unittests/IR/MetadataTest.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp
> b/clang/lib/CodeGen/CGDebugInfo.cpp
> index e171082942f6..cbf45a5cf748 100644
> --- a/clang/lib/CodeGen/CGDebugInfo.cpp
> +++ b/clang/lib/CodeGen/CGDebugInfo.cpp
> @@ -1787,18 +1787,36 @@ CGDebugInfo::CollectTemplateParams(const
> TemplateParameterList *TPList,
>for (unsigned i = 0, e = TAList.size(); i != e; ++i) {
>  const TemplateArgument  = TAList[i];
>  StringRef Name;
> +bool defaultParameter = false;
>  if (TPList)
>Name = TPList->getParam(i)->getName();
>  switch (TA.getKind()) {
>  case TemplateArgument::Type: {
>llvm::DIType *TTy = getOrCreateType(TA.getAsType(), Unit);
> -  TemplateParams.push_back(
> -  DBuilder.createTemplateTypeParameter(TheCU, Name, TTy));
> +
> +  if (TPList)
> +if (auto *templateType =
> +
> dyn_cast_or_null(TPList->getParam(i)))
> +  if (templateType->hasDefaultArgument())
> +defaultParameter =
> +templateType->getDefaultArgument() == TA.getAsType();
> +
> +  TemplateParams.push_back(DBuilder.createTemplateTypeParameter(
> +  TheCU, Name, TTy, defaultParameter));
> +
>  } break;
>  case TemplateArgument::Integral: {
>llvm::DIType *TTy = getOrCreateType(TA.getIntegralType(), Unit);
> +  if (TPList && CGM.getCodeGenOpts().DwarfVersion >= 5)
> +if (auto *templateType =
> +
> dyn_cast_or_null(TPList->getParam(i)))
> +  if (templateType->hasDefaultArgument())
> +defaultParameter =
> +templateType->getDefaultArgument()->EvaluateKnownConstInt(
> +CGM.getContext()) == TA.getAsIntegral();
> +
>TemplateParams.push_back(DBuilder.createTemplateValueParameter(
> -  TheCU, Name, TTy,
> +  TheCU, Name, TTy, defaultParameter,
>llvm::ConstantInt::get(CGM.getLLVMContext(),
> TA.getAsIntegral(;
>  } break;
>  case TemplateArgument::Declaration: {
> @@ -1837,7 +1855,7 @@ CGDebugInfo::CollectTemplateParams(const
> TemplateParameterList *TPList,
>  V = V->stripPointerCasts();
>}
>TemplateParams.push_back(DBuilder.createTemplateValueParameter(
> -  TheCU, Name, TTy, cast_or_null(V)));
> +  TheCU, Name, TTy, defaultParameter,
> cast_or_null(V)));
>  } break;
>  case TemplateArgument::NullPtr: {
>QualType T = TA.getNullPtrType();
> @@ -1855,8 +1873,8 @@ CGDebugInfo::CollectTemplateParams(const
> TemplateParameterList *TPList,
>V = CGM.getCXXABI().EmitNullMemberPointer(MPT);
>if (!V)
>  V = llvm::ConstantInt::get(CGM.Int8Ty, 0);
> -  TemplateParams.push_back(
> -  DBuilder.createTemplateValueParameter(TheCU, Name, TTy, V));
> +  TemplateParams.push_back(DBuilder.createTemplateValueParameter(
> +  TheCU, Name, TTy, defaultParameter, V));
>  } 

Re: [clang] d9b9621 - Reland D73534: [DebugInfo] Enable the debug entry values feature by default

[David Blaikie via cfe-commits]

Also, this patch was reverted and recommitted several times (more than I
think would be ideal) - please include more details in the commit message
about what went wrong, what was fixed, what testing was missed in the first
place and done in subsequent precommit validation (& is there anything more
broadly we could learn from this patches story to avoid this kind of
revert/recommit repetition in the future?)

On Sat, Mar 21, 2020 at 8:13 PM David Blaikie  wrote:

> Please include the "Differential Revision" line so that Phab picks up
> commits like this and ties them into the review (& also makes it
> conveniently clickable to jump from the commit mail to the review)
>
> On Thu, Mar 19, 2020 at 5:58 AM Djordje Todorovic via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: Djordje Todorovic
>> Date: 2020-03-19T13:57:30+01:00
>> New Revision: d9b962100942c71a4c26debaa716f7ab0c4ea8a1
>>
>> URL:
>> https://github.com/llvm/llvm-project/commit/d9b962100942c71a4c26debaa716f7ab0c4ea8a1
>> DIFF:
>> https://github.com/llvm/llvm-project/commit/d9b962100942c71a4c26debaa716f7ab0c4ea8a1.diff
>>
>> LOG: Reland D73534: [DebugInfo] Enable the debug entry values feature by
>> default
>>
>> The issue that was causing the build failures was fixed with the D76164.
>>
>> Added:
>> llvm/test/DebugInfo/X86/no-entry-values-with-O0.ll
>>
>> Modified:
>> clang/include/clang/Basic/CodeGenOptions.def
>> clang/include/clang/Driver/CC1Options.td
>> clang/lib/CodeGen/BackendUtil.cpp
>> clang/lib/CodeGen/CGDebugInfo.cpp
>> clang/lib/Frontend/CompilerInvocation.cpp
>> clang/test/CodeGen/debug-info-extern-call.c
>> clang/test/CodeGenCXX/dbg-info-all-calls-described.cpp
>> lldb/packages/Python/lldbsuite/test/decorators.py
>>
>> lldb/test/API/functionalities/param_entry_vals/basic_entry_values_x86_64/Makefile
>> llvm/include/llvm/Target/TargetMachine.h
>> llvm/include/llvm/Target/TargetOptions.h
>> llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
>> llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h
>> llvm/lib/CodeGen/CommandFlags.cpp
>> llvm/lib/CodeGen/LiveDebugValues.cpp
>> llvm/lib/CodeGen/TargetOptionsImpl.cpp
>> llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
>> llvm/lib/Target/ARM/ARMTargetMachine.cpp
>> llvm/lib/Target/X86/X86TargetMachine.cpp
>> llvm/test/CodeGen/MIR/Hexagon/bundled-call-site-info.mir
>> llvm/test/CodeGen/MIR/X86/call-site-info-error4.mir
>> llvm/test/CodeGen/X86/call-site-info-output.ll
>> llvm/test/DebugInfo/AArch64/dbgcall-site-float-entry-value.ll
>> llvm/test/DebugInfo/MIR/AArch64/dbgcall-site-orr-moves.mir
>> llvm/test/DebugInfo/MIR/ARM/call-site-info-vmovd.mir
>> llvm/test/DebugInfo/MIR/ARM/call-site-info-vmovs.mir
>> llvm/test/DebugInfo/MIR/ARM/dbgcall-site-propagated-value.mir
>>
>> llvm/test/DebugInfo/MIR/Hexagon/dbgcall-site-instr-before-bundled-call.mir
>>
>> llvm/test/DebugInfo/MIR/Hexagon/live-debug-values-bundled-entry-values.mir
>> llvm/test/DebugInfo/MIR/SystemZ/call-site-lzer.mir
>> llvm/test/DebugInfo/MIR/X86/DW_OP_entry_value.mir
>> llvm/test/DebugInfo/MIR/X86/call-site-gnu-vs-dwarf5-attrs.mir
>> llvm/test/DebugInfo/MIR/X86/callsite-stack-value.mir
>> llvm/test/DebugInfo/MIR/X86/dbgcall-site-copy-super-sub.mir
>> llvm/test/DebugInfo/MIR/X86/dbgcall-site-interpretation.mir
>> llvm/test/DebugInfo/MIR/X86/dbgcall-site-lea-interpretation.mir
>> llvm/test/DebugInfo/MIR/X86/dbgcall-site-partial-describe.mir
>> llvm/test/DebugInfo/MIR/X86/dbgcall-site-reference.mir
>> llvm/test/DebugInfo/MIR/X86/dbgcall-site-reg-shuffle.mir
>> llvm/test/DebugInfo/MIR/X86/dbgcall-site-two-fwd-reg-defs.mir
>> llvm/test/DebugInfo/MIR/X86/dbginfo-entryvals.mir
>> llvm/test/DebugInfo/MIR/X86/debug-call-site-param.mir
>> llvm/test/DebugInfo/MIR/X86/entry-value-of-modified-param.mir
>> llvm/test/DebugInfo/MIR/X86/entry-values-diamond-bbs.mir
>> llvm/test/DebugInfo/MIR/X86/propagate-entry-value-cross-bbs.mir
>> llvm/test/DebugInfo/MIR/X86/unreachable-block-call-site.mir
>> llvm/test/DebugInfo/X86/dbg-value-range.ll
>> llvm/test/DebugInfo/X86/dbg-value-regmask-clobber.ll
>> llvm/test/DebugInfo/X86/dbgcall-site-64-bit-imms.ll
>> llvm/test/DebugInfo/X86/dbgcall-site-zero-valued-imms.ll
>> llvm/test/DebugInfo/X86/loclists-dwp.ll
>> llvm/test/tools/llvm-locstats/locstats.ll
>>
>> Removed:
>>
>>
>>
>>
>> 
>> diff  --git a/clang/include/clang/Basic/CodeGenOptions.def
>> b/clang/include/clang/Basic/CodeGenOptions.def
>> index 3c8b0eeb47a5..e047054447f3 100644
>> --- a/clang/include/clang/Basic/CodeGenOptions.def
>> +++ b/clang/include/clang/Basic/CodeGenOptions.def
>> @@ -63,7 +63,6 @@ CODEGENOPT(ExperimentalNewPassManager, 1, 0) ///<
>> Enables the new, experimental
>>  CODEGENOPT(DebugPassManager, 1, 0) ///< Prints debug information for the
>> new
>>   

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

[David Blaikie via cfe-commits]

"a problem" seems a smidge vague - was there a specific explanation for the
kind of problem that was signalled? Or was this fix a bit of a shot in the
dark?

On Sat, Feb 15, 2020 at 10:55 PM Johannes Doerfert via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Johannes Doerfert
> Date: 2020-02-16T00:51:11-06:00
> New Revision: 857bf5da35af8e1f9425e1865dab5f5fce5e38f2
>
> URL:
> https://github.com/llvm/llvm-project/commit/857bf5da35af8e1f9425e1865dab5f5fce5e38f2
> DIFF:
> https://github.com/llvm/llvm-project/commit/857bf5da35af8e1f9425e1865dab5f5fce5e38f2.diff
>
> LOG: [FIX] Do not copy an llvm::function_ref if it has to be reused
>
> Some buildbots signaled a problem in this method when the
> llvm::function_ref was copied and reused after 1228d42ddab8. To
> eliminate the problem we avoid copying the llvm::function_ref and
> instead we pass it as a const reference.
>
> Added:
>
>
> Modified:
> clang/include/clang/AST/OpenMPClause.h
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/include/clang/AST/OpenMPClause.h
> b/clang/include/clang/AST/OpenMPClause.h
> index a3831fd5950f..453c068bbeb0 100644
> --- a/clang/include/clang/AST/OpenMPClause.h
> +++ b/clang/include/clang/AST/OpenMPClause.h
> @@ -6682,10 +6682,10 @@ struct OMPTraitInfo {
>llvm::SmallVector Sets;
>
>bool anyScoreOrCondition(
> -  llvm::function_ref Cond) {
> -return llvm::any_of(Sets, [Cond](OMPTraitInfo::OMPTraitSet ) {
> +  const llvm::function_ref ) {
> +return llvm::any_of(Sets, [](OMPTraitInfo::OMPTraitSet ) {
>return llvm::any_of(
> -  Set.Selectors, [Cond](OMPTraitInfo::OMPTraitSelector )
> {
> +  Set.Selectors, [](OMPTraitInfo::OMPTraitSelector
> ) {
>  return Cond(Selector.ScoreOrCondition,
>  /* IsScore */ Selector.Kind !=
>  llvm::omp::TraitSelector::user_condition);
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] abd0905 - Revert "Revert "Change clang option -ffp-model=precise to select ffp-contract=on""

[David Blaikie via cfe-commits]

Probably worth a bit more detail when recommitting a patch that was
reverted - in the future please include more detail about the reason for
the original revert and the specific changes to the previous version that
address that (so someone who might've reviewed the previous patch can more
quickly examine/assess the new changes compared to the previous version)

On Wed, Feb 12, 2020 at 7:31 AM Melanie Blower via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Melanie Blower
> Date: 2020-02-12T07:30:43-08:00
> New Revision: abd09053bc7aa6144873c196a7d50aa6ce6ca430
>
> URL:
> https://github.com/llvm/llvm-project/commit/abd09053bc7aa6144873c196a7d50aa6ce6ca430
> DIFF:
> https://github.com/llvm/llvm-project/commit/abd09053bc7aa6144873c196a7d50aa6ce6ca430.diff
>
> LOG: Revert "Revert "Change clang option -ffp-model=precise to select
> ffp-contract=on""
>
> This reverts commit 99c5bcbce89f07e68ccd89891a0300346705d013.
> Change clang option -ffp-model=precise to select ffp-contract=on
> Including some small touch-ups to the original commit
>
> Reviewers: rjmccall, Andy Kaylor
>
> Differential Revision: https://reviews.llvm.org/D74436
>
> Added:
>
>
> Modified:
> clang/docs/UsersManual.rst
> clang/lib/Driver/ToolChains/Clang.cpp
> clang/test/CodeGen/ppc-emmintrin.c
> clang/test/CodeGen/ppc-xmmintrin.c
> clang/test/Driver/fp-model.c
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
> index 856d5e34bbcc..6c8c9f802082 100644
> --- a/clang/docs/UsersManual.rst
> +++ b/clang/docs/UsersManual.rst
> @@ -1190,8 +1190,50 @@ installed.
>  Controlling Floating Point Behavior
>  ---
>
> -Clang provides a number of ways to control floating point behavior. The
> options
> -are listed below.
> +Clang provides a number of ways to control floating point behavior,
> including
> +with command line options and source pragmas. This section
> +describes the various floating point semantic modes and the corresponding
> options.
> +
> +.. csv-table:: Floating Point Semantic Modes
> +  :header: "Mode", "Values"
> +  :widths: 15, 30, 30
> +
> +  "except_behavior", "{ignore, strict, may_trap}",
> "ffp-exception-behavior"
> +  "fenv_access", "{off, on}", "(none)"
> +  "rounding_mode", "{dynamic, tonearest, downward, upward, towardzero}",
> "frounding-math"
> +  "contract", "{on, off, fast}", "ffp-contract"
> +  "denormal_fp_math", "{IEEE, PreserveSign, PositiveZero}",
> "fdenormal-fp-math"
> +  "denormal_fp32_math", "{IEEE, PreserveSign, PositiveZero}",
> "fdenormal-fp-math-fp32"
> +  "support_math_errno", "{on, off}", "fmath-errno"
> +  "no_honor_nans", "{on, off}", "fhonor-nans"
> +  "no_honor_infinities", "{on, off}", "fhonor-infinities"
> +  "no_signed_zeros", "{on, off}", "fsigned-zeros"
> +  "allow_reciprocal", "{on, off}", "freciprocal-math"
> +  "allow_approximate_fns", "{on, off}", "(none)"
> +  "allow_reassociation", "{on, off}", "fassociative-math"
> +
> +
> +This table describes the option settings that correspond to the three
> +floating point semantic models: precise (the default), strict, and fast.
> +
> +
> +.. csv-table:: Floating Point Models
> +  :header: "Mode", "Precise", "Strict", "Fast"
> +  :widths: 25, 15, 15, 15
> +
> +  "except_behavior", "ignore", "strict", "ignore"
> +  "fenv_access", "off", "on", "off"
> +  "rounding_mode", "tonearest", "dynamic", "tonearest"
> +  "contract", "on", "off", "fast"
> +  "denormal_fp_math", "IEEE", "IEEE", "PreserveSign"
> +  "denormal_fp32_math", "IEEE","IEEE", "PreserveSign"
> +  "support_math_errno", "on", "on", "off"
> +  "no_honor_nans", "off", "off", "on"
> +  "no_honor_infinities", "off", "off", "on"
> +  "no_signed_zeros", "off", "off", "on"
> +  "allow_reciprocal", "off", "off", "on"
> +  "allow_approximate_fns", "off", "off", "on"
> +  "allow_reassociation", "off", "off", "on"
>
>  .. option:: -ffast-math
>
> @@ -1385,7 +1427,7 @@ Note that floating-point operations performed as
> part of constant initialization
> and ``fast``.
> Details:
>
> -   * ``precise`` Disables optimizations that are not value-safe on
> floating-point data, although FP contraction (FMA) is enabled
> (``-ffp-contract=fast``).  This is the default behavior.
> +   * ``precise`` Disables optimizations that are not value-safe on
> floating-point data, although FP contraction (FMA) is enabled
> (``-ffp-contract=on``).  This is the default behavior.
> * ``strict`` Enables ``-frounding-math`` and
> ``-ffp-exception-behavior=strict``, and disables contractions (FMA).  All
> of the ``-ffast-math`` enablements are disabled.
> * ``fast`` Behaves identically to specifying both ``-ffast-math`` and
> ``ffp-contract=fast``
>
>
> diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp
> b/clang/lib/Driver/ToolChains/Clang.cpp
> index 4424d8e6f72c..a11a5423b0b9 100644
> --- a/clang/lib/Driver/ToolChains/Clang.cpp
> 

Re: [clang] 736385c - EHScopeStack::Cleanup has virtual functions so the destructor should be too.

[David Blaikie via cfe-commits]

I've reverted this in b5eafda8d3ef02f9f78e090725564dd28e573322 - the
warning isn't accurate/appropriate - this type is safe as it was previously
written (having a protected non-virtual dtor and derived classes being
final with a non-virtual dtor - so there's no way (well, inside the base
class you could, but that's a very limited scope) to polymorphically
destroy this type accidentally/slicing, etc).

On Mon, Mar 2, 2020 at 7:07 AM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Simon Pilgrim
> Date: 2020-03-02T15:06:34Z
> New Revision: 736385c0b49d42f398ffa1458883f0d182178ef4
>
> URL:
> https://github.com/llvm/llvm-project/commit/736385c0b49d42f398ffa1458883f0d182178ef4
> DIFF:
> https://github.com/llvm/llvm-project/commit/736385c0b49d42f398ffa1458883f0d182178ef4.diff
>
> LOG: EHScopeStack::Cleanup has virtual functions so the destructor should
> be too.
>
> Fixes cppcheck warning.
>
> Added:
>
>
> Modified:
> clang/lib/CodeGen/EHScopeStack.h
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/CodeGen/EHScopeStack.h
> b/clang/lib/CodeGen/EHScopeStack.h
> index 0ed67aabcd62..4dd3da3e90e7 100644
> --- a/clang/lib/CodeGen/EHScopeStack.h
> +++ b/clang/lib/CodeGen/EHScopeStack.h
> @@ -148,7 +148,7 @@ class EHScopeStack {
>  virtual void anchor();
>
>protected:
> -~Cleanup() = default;
> +virtual ~Cleanup() = default;
>
>public:
>  Cleanup(const Cleanup &) = default;
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b5eafda - Revert "EHScopeStack::Cleanup has virtual functions so the destructor should be too."

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2020-03-21T21:17:33-07:00
New Revision: b5eafda8d3ef02f9f78e090725564dd28e573322

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

LOG: Revert "EHScopeStack::Cleanup has virtual functions so the destructor 
should be too."

This type was already well designed - having a protected destructor, and
derived classes being final/public non-virtual destructors, the type
couldn't be destroyed polymorphically & accidentally cause slicing.

This reverts commit 736385c0b49d42f398ffa1458883f0d182178ef4.

Added: 


Modified: 
clang/lib/CodeGen/EHScopeStack.h

Removed: 




diff  --git a/clang/lib/CodeGen/EHScopeStack.h 
b/clang/lib/CodeGen/EHScopeStack.h
index 4dd3da3e90e7..0ed67aabcd62 100644
--- a/clang/lib/CodeGen/EHScopeStack.h
+++ b/clang/lib/CodeGen/EHScopeStack.h
@@ -148,7 +148,7 @@ class EHScopeStack {
 virtual void anchor();
 
   protected:
-virtual ~Cleanup() = default;
+~Cleanup() = default;
 
   public:
 Cleanup(const Cleanup &) = default;



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

Re: [clang] 43606ef - Suppress an "unused variable" warning in release build

[David Blaikie via cfe-commits]

Does "isIntegerConstantExpr" have side effects that are desired/necessary?
Otherwise please change this to roll the isIntegerConstantExpr into the
assert (so that it is only executed when asserts are enabled)

On Tue, Mar 10, 2020 at 10:11 AM Mikhail Maltsev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Mikhail Maltsev
> Date: 2020-03-10T17:10:52Z
> New Revision: 43606efb6847fc9c79e7d93760a2a6191e8a8539
>
> URL:
> https://github.com/llvm/llvm-project/commit/43606efb6847fc9c79e7d93760a2a6191e8a8539
> DIFF:
> https://github.com/llvm/llvm-project/commit/43606efb6847fc9c79e7d93760a2a6191e8a8539.diff
>
> LOG: Suppress an "unused variable" warning in release build
>
> Added:
>
>
> Modified:
> clang/lib/Sema/SemaChecking.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/Sema/SemaChecking.cpp
> b/clang/lib/Sema/SemaChecking.cpp
> index 24d0d9209a1d..8a2b4b019663 100644
> --- a/clang/lib/Sema/SemaChecking.cpp
> +++ b/clang/lib/Sema/SemaChecking.cpp
> @@ -2094,6 +2094,7 @@ bool Sema::CheckARMCoprocessorImmediate(const Expr
> *CoprocArg, bool WantCDE) {
>
>llvm::APSInt CoprocNoAP;
>bool IsICE = CoprocArg->isIntegerConstantExpr(CoprocNoAP, Context);
> +  (void)IsICE;
>assert(IsICE && "Coprocossor immediate is not a constant expression");
>int64_t CoprocNo = CoprocNoAP.getExtValue();
>assert(CoprocNo >= 0 && "Coprocessor immediate must be non-negative");
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] 4a0267e - Convert a reachable llvm_unreachable into an assert.

[David Blaikie via cfe-commits]

Why the change? this seems counter to LLVM's style which pretty
consistently uses unreachable rather than assert(false), so far as I know?

On Tue, Mar 10, 2020 at 11:22 AM Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Aaron Ballman
> Date: 2020-03-10T14:22:21-04:00
> New Revision: 4a0267e3ad8c4d47f267d7d960f127e099fb4818
>
> URL:
> https://github.com/llvm/llvm-project/commit/4a0267e3ad8c4d47f267d7d960f127e099fb4818
> DIFF:
> https://github.com/llvm/llvm-project/commit/4a0267e3ad8c4d47f267d7d960f127e099fb4818.diff
>
> LOG: Convert a reachable llvm_unreachable into an assert.
>
> Added:
>
>
> Modified:
> clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> b/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> index 01ac2bc83bb6..99e16752b51a 100644
> --- a/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> +++ b/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
> @@ -134,9 +134,9 @@ StringRef
> AnalyzerOptions::getCheckerStringOption(StringRef CheckerName,
>  CheckerName = CheckerName.substr(0, Pos);
>} while (!CheckerName.empty() && SearchInParents);
>
> -  llvm_unreachable("Unknown checker option! Did you call
> getChecker*Option "
> -   "with incorrect parameters? User input must've been "
> -   "verified by CheckerRegistry.");
> +  assert(false && "Unknown checker option! Did you call getChecker*Option
> "
> +  "with incorrect parameters? User input must've been "
> +  "verified by CheckerRegistry.");
>
>return "";
>  }
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] d9b9621 - Reland D73534: [DebugInfo] Enable the debug entry values feature by default

[David Blaikie via cfe-commits]

Please include the "Differential Revision" line so that Phab picks up
commits like this and ties them into the review (& also makes it
conveniently clickable to jump from the commit mail to the review)

On Thu, Mar 19, 2020 at 5:58 AM Djordje Todorovic via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Djordje Todorovic
> Date: 2020-03-19T13:57:30+01:00
> New Revision: d9b962100942c71a4c26debaa716f7ab0c4ea8a1
>
> URL:
> https://github.com/llvm/llvm-project/commit/d9b962100942c71a4c26debaa716f7ab0c4ea8a1
> DIFF:
> https://github.com/llvm/llvm-project/commit/d9b962100942c71a4c26debaa716f7ab0c4ea8a1.diff
>
> LOG: Reland D73534: [DebugInfo] Enable the debug entry values feature by
> default
>
> The issue that was causing the build failures was fixed with the D76164.
>
> Added:
> llvm/test/DebugInfo/X86/no-entry-values-with-O0.ll
>
> Modified:
> clang/include/clang/Basic/CodeGenOptions.def
> clang/include/clang/Driver/CC1Options.td
> clang/lib/CodeGen/BackendUtil.cpp
> clang/lib/CodeGen/CGDebugInfo.cpp
> clang/lib/Frontend/CompilerInvocation.cpp
> clang/test/CodeGen/debug-info-extern-call.c
> clang/test/CodeGenCXX/dbg-info-all-calls-described.cpp
> lldb/packages/Python/lldbsuite/test/decorators.py
>
> lldb/test/API/functionalities/param_entry_vals/basic_entry_values_x86_64/Makefile
> llvm/include/llvm/Target/TargetMachine.h
> llvm/include/llvm/Target/TargetOptions.h
> llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h
> llvm/lib/CodeGen/CommandFlags.cpp
> llvm/lib/CodeGen/LiveDebugValues.cpp
> llvm/lib/CodeGen/TargetOptionsImpl.cpp
> llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
> llvm/lib/Target/ARM/ARMTargetMachine.cpp
> llvm/lib/Target/X86/X86TargetMachine.cpp
> llvm/test/CodeGen/MIR/Hexagon/bundled-call-site-info.mir
> llvm/test/CodeGen/MIR/X86/call-site-info-error4.mir
> llvm/test/CodeGen/X86/call-site-info-output.ll
> llvm/test/DebugInfo/AArch64/dbgcall-site-float-entry-value.ll
> llvm/test/DebugInfo/MIR/AArch64/dbgcall-site-orr-moves.mir
> llvm/test/DebugInfo/MIR/ARM/call-site-info-vmovd.mir
> llvm/test/DebugInfo/MIR/ARM/call-site-info-vmovs.mir
> llvm/test/DebugInfo/MIR/ARM/dbgcall-site-propagated-value.mir
>
> llvm/test/DebugInfo/MIR/Hexagon/dbgcall-site-instr-before-bundled-call.mir
>
> llvm/test/DebugInfo/MIR/Hexagon/live-debug-values-bundled-entry-values.mir
> llvm/test/DebugInfo/MIR/SystemZ/call-site-lzer.mir
> llvm/test/DebugInfo/MIR/X86/DW_OP_entry_value.mir
> llvm/test/DebugInfo/MIR/X86/call-site-gnu-vs-dwarf5-attrs.mir
> llvm/test/DebugInfo/MIR/X86/callsite-stack-value.mir
> llvm/test/DebugInfo/MIR/X86/dbgcall-site-copy-super-sub.mir
> llvm/test/DebugInfo/MIR/X86/dbgcall-site-interpretation.mir
> llvm/test/DebugInfo/MIR/X86/dbgcall-site-lea-interpretation.mir
> llvm/test/DebugInfo/MIR/X86/dbgcall-site-partial-describe.mir
> llvm/test/DebugInfo/MIR/X86/dbgcall-site-reference.mir
> llvm/test/DebugInfo/MIR/X86/dbgcall-site-reg-shuffle.mir
> llvm/test/DebugInfo/MIR/X86/dbgcall-site-two-fwd-reg-defs.mir
> llvm/test/DebugInfo/MIR/X86/dbginfo-entryvals.mir
> llvm/test/DebugInfo/MIR/X86/debug-call-site-param.mir
> llvm/test/DebugInfo/MIR/X86/entry-value-of-modified-param.mir
> llvm/test/DebugInfo/MIR/X86/entry-values-diamond-bbs.mir
> llvm/test/DebugInfo/MIR/X86/propagate-entry-value-cross-bbs.mir
> llvm/test/DebugInfo/MIR/X86/unreachable-block-call-site.mir
> llvm/test/DebugInfo/X86/dbg-value-range.ll
> llvm/test/DebugInfo/X86/dbg-value-regmask-clobber.ll
> llvm/test/DebugInfo/X86/dbgcall-site-64-bit-imms.ll
> llvm/test/DebugInfo/X86/dbgcall-site-zero-valued-imms.ll
> llvm/test/DebugInfo/X86/loclists-dwp.ll
> llvm/test/tools/llvm-locstats/locstats.ll
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/include/clang/Basic/CodeGenOptions.def
> b/clang/include/clang/Basic/CodeGenOptions.def
> index 3c8b0eeb47a5..e047054447f3 100644
> --- a/clang/include/clang/Basic/CodeGenOptions.def
> +++ b/clang/include/clang/Basic/CodeGenOptions.def
> @@ -63,7 +63,6 @@ CODEGENOPT(ExperimentalNewPassManager, 1, 0) ///<
> Enables the new, experimental
>  CODEGENOPT(DebugPassManager, 1, 0) ///< Prints debug information for the
> new
> ///< pass manager.
>  CODEGENOPT(DisableRedZone, 1, 0) ///< Set when -mno-red-zone is
> enabled.
> -CODEGENOPT(EnableDebugEntryValues, 1, 0) ///< Emit call site parameter
> dbg info
>  CODEGENOPT(EmitCallSiteInfo, 1, 0) ///< Emit call site info only in the
> case of
> ///< '-g' + 'O>0' level.
>  CODEGENOPT(IndirectTlsSegRefs, 1, 0) ///< Set when
> -mno-tls-direct-seg-refs
>
> diff  --git a/clang/include/clang/Driver/CC1Options.td
> b/clang/include/clang/Driver/CC1Options.td
> index 

Re: [clang] bde15de - Revert "Allow remapping the sysroot with -fdebug-prefix-map."

[David Blaikie via cfe-commits]

Please include the reason for the revert in the revert message (including
links/quotes from buildbots, etc)

On Fri, Mar 20, 2020 at 4:28 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Adrian Prantl
> Date: 2020-03-20T16:27:23-07:00
> New Revision: bde15de3cabff6363008e67a999e6e4559743867
>
> URL:
> https://github.com/llvm/llvm-project/commit/bde15de3cabff6363008e67a999e6e4559743867
> DIFF:
> https://github.com/llvm/llvm-project/commit/bde15de3cabff6363008e67a999e6e4559743867.diff
>
> LOG: Revert "Allow remapping the sysroot with -fdebug-prefix-map."
>
> This reverts commit 6725c4836a5b3c11227869a6f456019a244aa29f.
>
> Added:
>
>
> Modified:
> clang/lib/CodeGen/CGDebugInfo.cpp
> clang/test/CodeGen/debug-prefix-map.c
> llvm/lib/DWARFLinker/DWARFLinker.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp
> b/clang/lib/CodeGen/CGDebugInfo.cpp
> index da6cb458982b..a98d82f7152c 100644
> --- a/clang/lib/CodeGen/CGDebugInfo.cpp
> +++ b/clang/lib/CodeGen/CGDebugInfo.cpp
> @@ -631,7 +631,7 @@ void CGDebugInfo::CreateCompileUnit() {
>? llvm::DICompileUnit::DebugNameTableKind::None
>: static_cast(
>  CGOpts.DebugNameTable),
> -  CGOpts.DebugRangesBaseAddress, remapDIPath(Sysroot), SDK);
> +  CGOpts.DebugRangesBaseAddress, Sysroot, SDK);
>  }
>
>  llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) {
>
> diff  --git a/clang/test/CodeGen/debug-prefix-map.c
> b/clang/test/CodeGen/debug-prefix-map.c
> index 354110d1b0da..5366e19447ae 100644
> --- a/clang/test/CodeGen/debug-prefix-map.c
> +++ b/clang/test/CodeGen/debug-prefix-map.c
> @@ -2,7 +2,6 @@
>  // RUN: %clang_cc1 -debug-info-kind=standalone
> -fdebug-prefix-map=%p=/UNLIKELY_PATH=empty %s -emit-llvm -o - | FileCheck
> %s -check-prefix CHECK-EVIL
>  // RUN: %clang_cc1 -debug-info-kind=standalone
> -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o -
> -main-file-name debug-prefix-map.c | FileCheck %s
>  // RUN: %clang_cc1 -debug-info-kind=standalone
> -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o -
> -fdebug-compilation-dir %p | FileCheck %s -check-prefix
> CHECK-COMPILATION-DIR
> -// RUN: %clang_cc1 -debug-info-kind=standalone
> -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p
> -debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
>  // RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s
> -emit-llvm -o - | FileCheck %s
>  // RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s
> -emit-llvm -o - | FileCheck %s
>
> @@ -41,4 +40,3 @@ void test_rewrite_includes() {
>  // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}", directory:
> "/UNLIKELY_PATH/empty")
>  // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}Inputs/stdio.h",
> directory: "/UNLIKELY_PATH/empty")
>  // CHECK-COMPILATION-DIR-NOT: !DIFile(filename:
> -// CHECK-SYSROOT: !DICompileUnit({{.*}}sysroot: "/UNLIKELY_PATH/empty"
>
> diff  --git a/llvm/lib/DWARFLinker/DWARFLinker.cpp
> b/llvm/lib/DWARFLinker/DWARFLinker.cpp
> index fbc3a3e60cc9..8464c04f801e 100644
> --- a/llvm/lib/DWARFLinker/DWARFLinker.cpp
> +++ b/llvm/lib/DWARFLinker/DWARFLinker.cpp
> @@ -1914,15 +1914,6 @@ static uint64_t getDwoId(const DWARFDie ,
> const DWARFUnit ) {
>return 0;
>  }
>
> -static std::string remapPath(std::string Path,
> - const objectPrefixMap ) {
> -  StringRef PathRef(Path);
> -  for (const auto  : ObjectPrefixMap)
> -if (PathRef.startswith(Entry.first))
> -  return (Twine(Entry.second) +
> PathRef.substr(Entry.first.size())).str();
> -  return Path;
> -}
> -
>  bool DWARFLinker::registerModuleReference(
>  DWARFDie CUDie, const DWARFUnit , const DwarfFile ,
>  OffsetsStringPool , UniquingStringPool ,
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 65eb74e - PointerLikeTypeTraits: Standardize NumLowBitsAvailable on static constexpr rather than anonymous enum

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2020-01-16T15:30:50-08:00
New Revision: 65eb74e94b414fcde6bfa810d1c30c7fcb136b77

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

LOG: PointerLikeTypeTraits: Standardize NumLowBitsAvailable on static constexpr 
rather than anonymous enum

This is (more?) usable by GDB pretty printers and seems nicer to write.

There's one tricky caveat that in C++14 (LLVM's codebase today) the
static constexpr member declaration is not a definition - so odr use of
this constant requires an out of line definition, which won't be
provided (that'd make all these trait classes more annoyidng/expensive
to maintain). But the use of this constant in the library implementation
is/should always be in a non-odr context - only two unit tests needed to
be touched to cope with this/avoid odr using these constants.

Based on/expanded from D72590 by Christian Sigg.

Added: 


Modified: 
clang/include/clang/AST/CanonicalType.h
clang/include/clang/AST/DeclGroup.h
clang/include/clang/AST/ExternalASTSource.h
clang/include/clang/AST/TemplateName.h
clang/include/clang/AST/Type.h
clang/include/clang/Basic/IdentifierTable.h
clang/include/clang/Basic/SourceLocation.h
clang/include/clang/CodeGen/ConstantInitFuture.h
clang/include/clang/Sema/Ownership.h
llvm/include/llvm/ADT/IntervalMap.h
llvm/include/llvm/ADT/PointerEmbeddedInt.h
llvm/include/llvm/ADT/PointerIntPair.h
llvm/include/llvm/IR/Use.h
llvm/include/llvm/Support/PointerLikeTypeTraits.h
llvm/lib/Analysis/GlobalsModRef.cpp
llvm/unittests/ADT/PointerEmbeddedIntTest.cpp
llvm/unittests/ADT/PointerIntPairTest.cpp
mlir/include/mlir/IR/Attributes.h
mlir/include/mlir/IR/Function.h
mlir/include/mlir/IR/Identifier.h
mlir/include/mlir/IR/Location.h
mlir/include/mlir/IR/Module.h
mlir/include/mlir/IR/OperationSupport.h
mlir/include/mlir/IR/Types.h
mlir/include/mlir/IR/Value.h
polly/include/polly/CodeGen/IslExprBuilder.h

Removed: 




diff  --git a/clang/include/clang/AST/CanonicalType.h 
b/clang/include/clang/AST/CanonicalType.h
index 2e00d344533d..64ec1c0ce471 100644
--- a/clang/include/clang/AST/CanonicalType.h
+++ b/clang/include/clang/AST/CanonicalType.h
@@ -384,7 +384,7 @@ struct PointerLikeTypeTraits> {
   }
 
   // qualifier information is encoded in the low bits.
-  enum { NumLowBitsAvailable = 0 };
+  static constexpr int NumLowBitsAvailable = 0;
 };
 
 } // namespace llvm

diff  --git a/clang/include/clang/AST/DeclGroup.h 
b/clang/include/clang/AST/DeclGroup.h
index 2be9dae9431e..672b7b0a9fe2 100644
--- a/clang/include/clang/AST/DeclGroup.h
+++ b/clang/include/clang/AST/DeclGroup.h
@@ -147,7 +147,7 @@ namespace llvm {
   return clang::DeclGroupRef::getFromOpaquePtr(P);
 }
 
-enum { NumLowBitsAvailable = 0 };
+static constexpr int NumLowBitsAvailable = 0;
   };
 
 } // namespace llvm

diff  --git a/clang/include/clang/AST/ExternalASTSource.h 
b/clang/include/clang/AST/ExternalASTSource.h
index 899ac3f66937..75671f777f4f 100644
--- a/clang/include/clang/AST/ExternalASTSource.h
+++ b/clang/include/clang/AST/ExternalASTSource.h
@@ -504,9 +504,8 @@ struct PointerLikeTypeTraits<
   static void *getAsVoidPointer(Ptr P) { return P.getOpaqueValue(); }
   static Ptr getFromVoidPointer(void *P) { return Ptr::getFromOpaqueValue(P); }
 
-  enum {
-NumLowBitsAvailable = PointerLikeTypeTraits::NumLowBitsAvailable - 1
-  };
+  static constexpr int NumLowBitsAvailable =
+  PointerLikeTypeTraits::NumLowBitsAvailable - 1;
 };
 
 } // namespace llvm

diff  --git a/clang/include/clang/AST/TemplateName.h 
b/clang/include/clang/AST/TemplateName.h
index cbbcbf6af8ab..e1315facc966 100644
--- a/clang/include/clang/AST/TemplateName.h
+++ b/clang/include/clang/AST/TemplateName.h
@@ -559,7 +559,7 @@ struct PointerLikeTypeTraits {
   }
 
   // No bits are available!
-  enum { NumLowBitsAvailable = 0 };
+  static constexpr int NumLowBitsAvailable = 0;
 };
 
 } // namespace llvm.

diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index f5955c45fafc..2291d776db3e 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -85,7 +85,7 @@ namespace llvm {
   return static_cast< ::clang::Type*>(P);
 }
 
-enum { NumLowBitsAvailable = clang::TypeAlignmentInBits };
+static constexpr int NumLowBitsAvailable = clang::TypeAlignmentInBits;
   };
 
   template<>
@@ -96,7 +96,7 @@ namespace llvm {
   return static_cast< ::clang::ExtQuals*>(P);
 }
 
-enum { NumLowBitsAvailable = clang::TypeAlignmentInBits };
+static constexpr int NumLowBitsAvailable = clang::TypeAlignmentInBits;
   };
 
 } // namespace llvm
@@ -1295,7 +1295,7 @@ struct PointerLikeTypeTraits {
   }
 
   // 

Re: [clang] d801823 - Revert "CWG2352: Allow qualification conversions during reference binding."

[David Blaikie via cfe-commits]

On Fri, Dec 27, 2019 at 3:48 PM Richard Smith  wrote:

> On Fri, 27 Dec 2019 at 12:27, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: David Blaikie
>> Date: 2019-12-27T12:27:20-08:00
>> New Revision: d8018233d1ea4234de68d5b4593abd773db79484
>>
>> URL:
>> https://github.com/llvm/llvm-project/commit/d8018233d1ea4234de68d5b4593abd773db79484
>> DIFF:
>> https://github.com/llvm/llvm-project/commit/d8018233d1ea4234de68d5b4593abd773db79484.diff
>>
>> LOG: Revert "CWG2352: Allow qualification conversions during reference
>> binding."
>>
>> This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4.
>>
>> Regressed/causes this to error due to ambiguity:
>>
>>   void f(const int * const &);
>>   void f(int *);
>>   int main() {
>> int * x;
>> f(x);
>>   }
>>
>> (in case it's important - the original case where this turned up was a
>> member function overload in a class template with, essentially:
>>
>>   f(const T1&)
>>   f(T2*)
>>
>> (where T1 == X const *, T2 == X))
>>
>> It's not super clear to me if this ^ is expected behavior, in which case
>> I'm sorry about the revert & happy to look into ways to fix the original
>> code.
>>
>
> I believe the new Clang behavior here is correct according to the standard
> wording.
>

Ah, OK. Thanks for looking/checking!


> However, GCC trunk also implements CWG2352 and accepts this,
>

Right, I should've mentioned I checked against GCC trunk. The other case
that showed up with this change:

template
void f(T&&);
void f() {
  int *i;
  f(i);
}

that one failed with both GCC and Clang (& I've written up a fix for it
internally) & /seems/ roughly like what I believe is to be correct behavior
form the compiler/new patch here (& consistent with GCC, giving it a bit
more a vote for "this seems like good behavior")


> and there's a natural-seeming way to get that result, so I'm going to take
> this back to the core reflector and see if people agree that this ought to
> remain valid.
>

OK - happy to help with internal fixes if/when that's needed (I think it
might just be the one, though - so maybe that goes to show this isn't the
worst behavior)


>
>
>> Added:
>>
>>
>> Modified:
>> clang/include/clang/Basic/DiagnosticSemaKinds.td
>> clang/lib/Sema/SemaExprCXX.cpp
>> clang/lib/Sema/SemaInit.cpp
>> clang/lib/Sema/SemaOverload.cpp
>> clang/test/CXX/drs/dr23xx.cpp
>> clang/test/CXX/drs/dr4xx.cpp
>> clang/test/SemaObjCXX/arc-overloading.mm
>> clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
>> clang/www/cxx_dr_status.html
>> clang/www/make_cxx_dr_status
>>
>> Removed:
>>
>>
>>
>>
>> 
>> diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
>> b/clang/include/clang/Basic/DiagnosticSemaKinds.td
>> index b86abd0db73e..54299a0409fd 100644
>> --- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
>> +++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
>> @@ -1933,8 +1933,7 @@ def err_lvalue_reference_bind_to_unrelated : Error<
>>"cannot bind to a value of unrelated type}1,2">;
>>  def err_reference_bind_drops_quals : Error<
>>"binding reference %
>> diff {of type $ to value of type $|to value}0,1 "
>> -  "%select{drops %3 qualifier%plural{1:|2:|4:|:s}4|changes address
>> space|"
>> -  "not permitted due to incompatible qualifiers}2">;
>> +  "%select{drops %3 qualifier%plural{1:|2:|4:|:s}4|changes address
>> space}2">;
>>  def err_reference_bind_failed : Error<
>>"reference %
>> diff {to %select{type|incomplete type}1 $ could not bind to an "
>>"%select{rvalue|lvalue}2 of type $|could not bind to
>> %select{rvalue|lvalue}2 of "
>>
>> diff  --git a/clang/lib/Sema/SemaExprCXX.cpp
>> b/clang/lib/Sema/SemaExprCXX.cpp
>> index cd78f096bb22..cfb3a05e9c14 100644
>> --- a/clang/lib/Sema/SemaExprCXX.cpp
>> +++ b/clang/lib/Sema/SemaExprCXX.cpp
>> @@ -5864,8 +5864,6 @@ QualType
>> Sema::CXXCheckConditionalOperands(ExprResult , ExprResult ,
>>//   one of the operands is reference-compatible with the other, in
>> order
>>//   to support conditionals between functions
>> diff ering in noexcept. This
>>//   will similarly cover
>> diff erence in array bounds

Re: [clang] de21704 - CWG2352: Allow qualification conversions during reference binding.

[David Blaikie via cfe-commits]

Sorry if this is expected behavior, but saw a regression that looks
/plausibly/ correct & is rendered ambiguous by this change so I've gone
ahead and reverted this patch in d8018233d1ea4234de68d5b4593abd773db79484

Comment from the original:

Regressed/causes this to error due to ambiguity:

  void f(const int * const &);
  void f(int *);
  int main() {
int * x;
f(x);
  }

(in case it's important - the original case where this turned up was a
member function overload in a class template with, essentially:

  f(const T1&)
  f(T2*)

(where T1 == X const *, T2 == X))

On Thu, Dec 19, 2019 at 6:56 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Richard Smith
> Date: 2019-12-19T18:37:55-08:00
> New Revision: de21704ba96fa80d3e9402f12c6505917a3885f4
>
> URL:
> https://github.com/llvm/llvm-project/commit/de21704ba96fa80d3e9402f12c6505917a3885f4
> DIFF:
> https://github.com/llvm/llvm-project/commit/de21704ba96fa80d3e9402f12c6505917a3885f4.diff
>
> LOG: CWG2352: Allow qualification conversions during reference binding.
>
> The language wording change forgot to update overload resolution to rank
> implicit conversion sequences based on qualification conversions in
> reference bindings. The anticipated resolution for that oversight is
> implemented here -- we order candidates based on qualification
> conversion, not only on top-level cv-qualifiers.
>
> For OpenCL/C++, this allows reference binding between pointers with
> differing (nested) address spaces. This makes the behavior of reference
> binding consistent with that of implicit pointer conversions, as is the
> purpose of this change, but that pre-existing behavior for pointer
> conversions is itself probably not correct. In any case, it's now
> consistently the same behavior and implemented in only one place.
>
> Added:
>
>
> Modified:
> clang/include/clang/Basic/DiagnosticSemaKinds.td
> clang/lib/Sema/SemaExprCXX.cpp
> clang/lib/Sema/SemaInit.cpp
> clang/lib/Sema/SemaOverload.cpp
> clang/test/CXX/drs/dr23xx.cpp
> clang/test/CXX/drs/dr4xx.cpp
> clang/test/SemaObjCXX/arc-overloading.mm
> clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
> clang/www/cxx_dr_status.html
> clang/www/make_cxx_dr_status
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
> b/clang/include/clang/Basic/DiagnosticSemaKinds.td
> index c7b501b9bb2b..315e836cd397 100644
> --- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
> +++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
> @@ -1927,7 +1927,8 @@ def err_lvalue_reference_bind_to_unrelated : Error<
>"cannot bind to a value of unrelated type}1,2">;
>  def err_reference_bind_drops_quals : Error<
>"binding reference %
> diff {of type $ to value of type $|to value}0,1 "
> -  "%select{drops %3 qualifier%plural{1:|2:|4:|:s}4|changes address
> space}2">;
> +  "%select{drops %3 qualifier%plural{1:|2:|4:|:s}4|changes address space|"
> +  "not permitted due to incompatible qualifiers}2">;
>  def err_reference_bind_failed : Error<
>"reference %
> diff {to %select{type|incomplete type}1 $ could not bind to an "
>"%select{rvalue|lvalue}2 of type $|could not bind to
> %select{rvalue|lvalue}2 of "
>
> diff  --git a/clang/lib/Sema/SemaExprCXX.cpp
> b/clang/lib/Sema/SemaExprCXX.cpp
> index cfb3a05e9c14..cd78f096bb22 100644
> --- a/clang/lib/Sema/SemaExprCXX.cpp
> +++ b/clang/lib/Sema/SemaExprCXX.cpp
> @@ -5864,6 +5864,8 @@ QualType
> Sema::CXXCheckConditionalOperands(ExprResult , ExprResult ,
>//   one of the operands is reference-compatible with the other, in
> order
>//   to support conditionals between functions
> diff ering in noexcept. This
>//   will similarly cover
> diff erence in array bounds after P0388R4.
> +  // FIXME: If LTy and RTy have a composite pointer type, should we
> convert to
> +  //   that instead?
>ExprValueKind LVK = LHS.get()->getValueKind();
>ExprValueKind RVK = RHS.get()->getValueKind();
>if (!Context.hasSameType(LTy, RTy) &&
>
> diff  --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
> index 94d524a63f5a..ef4fa827064e 100644
> --- a/clang/lib/Sema/SemaInit.cpp
> +++ b/clang/lib/Sema/SemaInit.cpp
> @@ -8919,11 +8919,17 @@ bool InitializationSequence::Diagnose(Sema ,
>S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
><< NonRefType << SourceType << 1 /*addr space*/
><< Args[0]->getSourceRange();
> -else
> +else if (DroppedQualifiers.hasQualifiers())
>S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
><< NonRefType << SourceType << 0 /*cv quals*/
><< Qualifiers::fromCVRMask(DroppedQualifiers.getCVRQualifiers())
><< DroppedQualifiers.getCVRQualifiers() <<
> Args[0]->getSourceRange();
> +else
> +  

[clang] d801823 - Revert "CWG2352: Allow qualification conversions during reference binding."

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2019-12-27T12:27:20-08:00
New Revision: d8018233d1ea4234de68d5b4593abd773db79484

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

LOG: Revert "CWG2352: Allow qualification conversions during reference binding."

This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4.

Regressed/causes this to error due to ambiguity:

  void f(const int * const &);
  void f(int *);
  int main() {
int * x;
f(x);
  }

(in case it's important - the original case where this turned up was a
member function overload in a class template with, essentially:

  f(const T1&)
  f(T2*)

(where T1 == X const *, T2 == X))

It's not super clear to me if this ^ is expected behavior, in which case
I'm sorry about the revert & happy to look into ways to fix the original
code.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaInit.cpp
clang/lib/Sema/SemaOverload.cpp
clang/test/CXX/drs/dr23xx.cpp
clang/test/CXX/drs/dr4xx.cpp
clang/test/SemaObjCXX/arc-overloading.mm
clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
clang/www/cxx_dr_status.html
clang/www/make_cxx_dr_status

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index b86abd0db73e..54299a0409fd 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -1933,8 +1933,7 @@ def err_lvalue_reference_bind_to_unrelated : Error<
   "cannot bind to a value of unrelated type}1,2">;
 def err_reference_bind_drops_quals : Error<
   "binding reference %
diff {of type $ to value of type $|to value}0,1 "
-  "%select{drops %3 qualifier%plural{1:|2:|4:|:s}4|changes address space|"
-  "not permitted due to incompatible qualifiers}2">;
+  "%select{drops %3 qualifier%plural{1:|2:|4:|:s}4|changes address space}2">;
 def err_reference_bind_failed : Error<
   "reference %
diff {to %select{type|incomplete type}1 $ could not bind to an "
   "%select{rvalue|lvalue}2 of type $|could not bind to %select{rvalue|lvalue}2 
of "

diff  --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index cd78f096bb22..cfb3a05e9c14 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -5864,8 +5864,6 @@ QualType Sema::CXXCheckConditionalOperands(ExprResult 
, ExprResult ,
   //   one of the operands is reference-compatible with the other, in order
   //   to support conditionals between functions 
diff ering in noexcept. This
   //   will similarly cover 
diff erence in array bounds after P0388R4.
-  // FIXME: If LTy and RTy have a composite pointer type, should we convert to
-  //   that instead?
   ExprValueKind LVK = LHS.get()->getValueKind();
   ExprValueKind RVK = RHS.get()->getValueKind();
   if (!Context.hasSameType(LTy, RTy) &&

diff  --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index ef4fa827064e..94d524a63f5a 100644
--- a/clang/lib/Sema/SemaInit.cpp
+++ b/clang/lib/Sema/SemaInit.cpp
@@ -8919,17 +8919,11 @@ bool InitializationSequence::Diagnose(Sema ,
   S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
   << NonRefType << SourceType << 1 /*addr space*/
   << Args[0]->getSourceRange();
-else if (DroppedQualifiers.hasQualifiers())
+else
   S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
   << NonRefType << SourceType << 0 /*cv quals*/
   << Qualifiers::fromCVRMask(DroppedQualifiers.getCVRQualifiers())
   << DroppedQualifiers.getCVRQualifiers() << Args[0]->getSourceRange();
-else
-  // FIXME: Consider decomposing the type and explaining which qualifiers
-  // were dropped where, or on which level a 'const' is missing, etc.
-  S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
-  << NonRefType << SourceType << 2 /*incompatible quals*/
-  << Args[0]->getSourceRange();
 break;
   }
 

diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 92058c3aa5fd..74a0bc7c78ff 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -3153,70 +3153,6 @@ static bool 
isNonTrivialObjCLifetimeConversion(Qualifiers FromQuals,
   return true;
 }
 
-/// Perform a single iteration of the loop for checking if a qualification
-/// conversion is valid.
-///
-/// Specifically, check whether any change between the qualifiers of \p
-/// FromType and \p ToType is permissible, given knowledge about whether every
-/// outer layer is const-qualified.
-static bool isQualificationConversionStep(QualType FromType, QualType ToType,
-  

Re: [clang] ce1f95a - Reland "[clang] Remove the DIFlagArgumentNotModified debug info flag"

[David Blaikie via cfe-commits]

On Thu, Dec 26, 2019 at 11:58 PM Djordje Todorovic <
djordje.todoro...@rt-rk.com> wrote:

> Hi David,
>
> It's a good question.
>
> Current approach of the debug entry values will consider an entry value as
> a valid value until the variable gets modified.
>
> Please consider this.
>
> void fn(int a) {
>   ...
>   a++;
> }
>
> If there is an instruction that does not affect the code generated, e.g.
> an ADD instruction that gets optimized out from the case above, it won't
> force us to invalidate all the entry values before, since the instruction
> is not there in the final code generated. The GCC does the same thing in
> that situation. But if the instruction were at the beginning of the
> function (or somewhere else), we believe that there is an DBG_VALUE
> representing that variable's change (e.g. generated from the Salvage Debug
> Info), so the entry value would not be used any more.
>
> If we come up with a case where a dead store causing an invalid use of the
> entry values, that will be good point for improvements.
>

Ah, OK, so you actually want to know whether the entry value gets really
modified, makes sense to do that in the backend then - thanks for
explaining!


>
> Best regards,
> Djordje
>
> On 26.12.19. 22:33, David Blaikie wrote:
> >
> >
> > On Wed, Nov 20, 2019 at 1:08 AM Djordje Todorovic via cfe-commits <
> cfe-commits@lists.llvm.org > wrote:
> >
> >
> > Author: Djordje Todorovic
> > Date: 2019-11-20T10:08:07+01:00
> > New Revision: ce1f95a6e077693f93d8869245f911aff3eb7e4c
> >
> > URL:
> https://github.com/llvm/llvm-project/commit/ce1f95a6e077693f93d8869245f911aff3eb7e4c
> > DIFF:
> https://github.com/llvm/llvm-project/commit/ce1f95a6e077693f93d8869245f911aff3eb7e4c.diff
> >
> > LOG: Reland "[clang] Remove the DIFlagArgumentNotModified debug info
> flag"
> >
> > It turns out that the ExprMutationAnalyzer can be very slow when AST
> > gets huge in some cases. The idea is to move this analysis to the
> LLVM
> > back-end level (more precisely, in the LiveDebugValues pass). The new
> > approach will remove the performance regression, simplify the
> > implementation and give us front-end independent implementation.
> >
> >
> > What if the LLVM backend optimized out a dead store? (then we might
> concnlude that the argument is not modified, when it actually is modified?)
> >
> >
> >
> > Differential Revision: https://reviews.llvm.org/D68206
> >
> > Added:
> >
> >
> > Modified:
> > clang/lib/CodeGen/CGDebugInfo.cpp
> > clang/lib/CodeGen/CGDebugInfo.h
> >
> lldb/packages/Python/lldbsuite/test/functionalities/param_entry_vals/basic_entry_values_x86_64/TestBasicEntryValuesX86_64.py
> >
> > Removed:
> > clang/test/CodeGen/debug-info-param-modification.c
> >
> >
> >
>  
> 
> > diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp
> b/clang/lib/CodeGen/CGDebugInfo.cpp
> > index 116517a9cb99..a9b3831aa0b5 100644
> > --- a/clang/lib/CodeGen/CGDebugInfo.cpp
> > +++ b/clang/lib/CodeGen/CGDebugInfo.cpp
> > @@ -18,7 +18,6 @@
> >  #include "CodeGenFunction.h"
> >  #include "CodeGenModule.h"
> >  #include "ConstantEmitter.h"
> > -#include "clang/Analysis/Analyses/ExprMutationAnalyzer.h"
> >  #include "clang/AST/ASTContext.h"
> >  #include "clang/AST/DeclFriend.h"
> >  #include "clang/AST/DeclObjC.h"
> > @@ -3686,15 +3685,6 @@ void
> CGDebugInfo::EmitFunctionStart(GlobalDecl GD, SourceLocation Loc,
> >if (HasDecl && isa(D))
> >  DeclCache[D->getCanonicalDecl()].reset(SP);
> >
> > -  // We use the SPDefCache only in the case when the debug entry
> values option
> > -  // is set, in order to speed up parameters modification analysis.
> > -  //
> > -  // FIXME: Use AbstractCallee here to support ObjCMethodDecl.
> > -  if (CGM.getCodeGenOpts().EnableDebugEntryValues && HasDecl)
> > -if (auto *FD = dyn_cast(D))
> > -  if (FD->hasBody() && !FD->param_empty())
> > -SPDefCache[FD].reset(SP);
> > -
> >// Push the function onto the lexical block stack.
> >LexicalBlockStack.emplace_back(SP);
> >
> > @@ -4097,11 +4087,6 @@ llvm::DILocalVariable
> *CGDebugInfo::EmitDeclare(const VarDecl *VD,
> >   llvm::DebugLoc::get(Line, Column, Scope,
> CurInlinedAt),
> >   Builder.GetInsertBlock());
> >
> > -  if (CGM.getCodeGenOpts().EnableDebugEntryValues && ArgNo) {
> > -if (auto *PD = dyn_cast(VD))
> > -  ParamCache[PD].reset(D);
> > -  }
> > -
> >return D;
> >  }
> >
> > @@ -4717,29 +4702,6 @@ void CGDebugInfo::setDwoId(uint64_t
> Signature) {
> >TheCU->setDWOId(Signature);
> >  }
> >
> > -/// Analyzes each function parameter to determine whether it is
> constant
> > -/// throughout 

Re: [clang] 3f4b70c - Revert "[clang][modules] Add support for merging lifetime-extended temporaries"

[David Blaikie via cfe-commits]

Please include details about the reason for the revert (links to and quotes
from buildbots are helpful, etc) in the commit message - so others can
follow along more easily (if they're seeing a local regression, they might
be able to check if this revert is likely to address it - if they want to
pick up the patch/do some similar change at a later date, this might help
explain what was wrong with this approach & would need to be addressed
before making another attempt)

On Sat, Nov 30, 2019 at 8:53 AM via cfe-commits 
wrote:

>
> Author: Tyker
> Date: 2019-11-30T17:52:26+01:00
> New Revision: 3f4b70c79e686117c2754d2c0a5a44c8b6829e79
>
> URL:
> https://github.com/llvm/llvm-project/commit/3f4b70c79e686117c2754d2c0a5a44c8b6829e79
> DIFF:
> https://github.com/llvm/llvm-project/commit/3f4b70c79e686117c2754d2c0a5a44c8b6829e79.diff
>
> LOG: Revert "[clang][modules] Add support for merging lifetime-extended
> temporaries"
>
> This reverts commit 3c7f6b439699a9cbbc0ac8d288cc70aff357446b.
>
> Added:
>
>
> Modified:
> clang/include/clang/AST/DeclCXX.h
> clang/include/clang/AST/TextNodeDumper.h
> clang/include/clang/Serialization/ASTReader.h
> clang/lib/AST/TextNodeDumper.cpp
> clang/lib/Serialization/ASTReaderDecl.cpp
>
> Removed:
> clang/test/Modules/Inputs/merge-lifetime-extended-temporary/a.h
> clang/test/Modules/Inputs/merge-lifetime-extended-temporary/b.h
> clang/test/Modules/Inputs/merge-lifetime-extended-temporary/c.h
>
> clang/test/Modules/Inputs/merge-lifetime-extended-temporary/module.modulemap
> clang/test/Modules/merge-lifetime-extended-temporary.cpp
>
>
>
> 
> diff  --git a/clang/include/clang/AST/DeclCXX.h
> b/clang/include/clang/AST/DeclCXX.h
> index 0f2018fb9e8c..63d67bd3f55b 100644
> --- a/clang/include/clang/AST/DeclCXX.h
> +++ b/clang/include/clang/AST/DeclCXX.h
> @@ -3041,9 +3041,7 @@ class NamespaceAliasDecl : public NamedDecl,
>
>  /// Implicit declaration of a temporary that was materialized by
>  /// a MaterializeTemporaryExpr and lifetime-extended by a declaration
> -class LifetimeExtendedTemporaryDecl final
> -: public Decl,
> -  public Mergeable {
> +class LifetimeExtendedTemporaryDecl final : public Decl {
>friend class MaterializeTemporaryExpr;
>friend class ASTDeclReader;
>
>
> diff  --git a/clang/include/clang/AST/TextNodeDumper.h
> b/clang/include/clang/AST/TextNodeDumper.h
> index d293ea190aa4..0ff5a614a864 100644
> --- a/clang/include/clang/AST/TextNodeDumper.h
> +++ b/clang/include/clang/AST/TextNodeDumper.h
> @@ -346,8 +346,6 @@ class TextNodeDumper
>void VisitObjCPropertyImplDecl(const ObjCPropertyImplDecl *D);
>void VisitBlockDecl(const BlockDecl *D);
>void VisitConceptDecl(const ConceptDecl *D);
> -  void
> -  VisitLifetimeExtendedTemporaryDecl(const LifetimeExtendedTemporaryDecl
> *D);
>  };
>
>  } // namespace clang
>
> diff  --git a/clang/include/clang/Serialization/ASTReader.h
> b/clang/include/clang/Serialization/ASTReader.h
> index b6dae68b3413..f0b5e9933823 100644
> --- a/clang/include/clang/Serialization/ASTReader.h
> +++ b/clang/include/clang/Serialization/ASTReader.h
> @@ -551,14 +551,6 @@ class ASTReader
>llvm::DenseMap>
>  AnonymousDeclarationsForMerging;
>
> -  /// Key used to identify LifetimeExtendedTemporaryDecl for merging,
> -  /// containing the lifetime-extending declaration and the mangling
> number.
> -  using LETemporaryKey = std::pair;
> -
> -  /// Map of already deserialiazed temporaries.
> -  llvm::DenseMap
> -  LETemporaryForMerging;
> -
>struct FileDeclsInfo {
>  ModuleFile *Mod = nullptr;
>  ArrayRef Decls;
>
> diff  --git a/clang/lib/AST/TextNodeDumper.cpp
> b/clang/lib/AST/TextNodeDumper.cpp
> index 561c76a45cbc..0ff95213118f 100644
> --- a/clang/lib/AST/TextNodeDumper.cpp
> +++ b/clang/lib/AST/TextNodeDumper.cpp
> @@ -1338,17 +1338,6 @@ void TextNodeDumper::VisitFunctionDecl(const
> FunctionDecl *D) {
>  OS << " <>>";
>  }
>
> -void TextNodeDumper::VisitLifetimeExtendedTemporaryDecl(
> -const LifetimeExtendedTemporaryDecl *D) {
> -  OS << " extended by ";
> -  dumpBareDeclRef(D->getExtendingDecl());
> -  OS << " mangling ";
> -  {
> -ColorScope Color(OS, ShowColors, ValueColor);
> -OS << D->getManglingNumber();
> -  }
> -}
> -
>  void TextNodeDumper::VisitFieldDecl(const FieldDecl *D) {
>dumpName(D);
>dumpType(D->getType());
>
> diff  --git a/clang/lib/Serialization/ASTReaderDecl.cpp
> b/clang/lib/Serialization/ASTReaderDecl.cpp
> index d6c57757cf8c..8991a39a7067 100644
> --- a/clang/lib/Serialization/ASTReaderDecl.cpp
> +++ b/clang/lib/Serialization/ASTReaderDecl.cpp
> @@ -424,9 +424,6 @@ namespace clang {
>  template
>  void mergeMergeable(Mergeable *D);
>
> -template <>
> -void mergeMergeable(Mergeable *D);
> -
>  void mergeTemplatePattern(RedeclarableTemplateDecl *D,
>

Re: [clang] ce1f95a - Reland "[clang] Remove the DIFlagArgumentNotModified debug info flag"

[David Blaikie via cfe-commits]

On Wed, Nov 20, 2019 at 1:08 AM Djordje Todorovic via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Djordje Todorovic
> Date: 2019-11-20T10:08:07+01:00
> New Revision: ce1f95a6e077693f93d8869245f911aff3eb7e4c
>
> URL:
> https://github.com/llvm/llvm-project/commit/ce1f95a6e077693f93d8869245f911aff3eb7e4c
> DIFF:
> https://github.com/llvm/llvm-project/commit/ce1f95a6e077693f93d8869245f911aff3eb7e4c.diff
>
> LOG: Reland "[clang] Remove the DIFlagArgumentNotModified debug info flag"
>
> It turns out that the ExprMutationAnalyzer can be very slow when AST
> gets huge in some cases. The idea is to move this analysis to the LLVM
> back-end level (more precisely, in the LiveDebugValues pass). The new
> approach will remove the performance regression, simplify the
> implementation and give us front-end independent implementation.
>

What if the LLVM backend optimized out a dead store? (then we might
concnlude that the argument is not modified, when it actually is modified?)


>
> Differential Revision: https://reviews.llvm.org/D68206
>
> Added:
>
>
> Modified:
> clang/lib/CodeGen/CGDebugInfo.cpp
> clang/lib/CodeGen/CGDebugInfo.h
>
> lldb/packages/Python/lldbsuite/test/functionalities/param_entry_vals/basic_entry_values_x86_64/TestBasicEntryValuesX86_64.py
>
> Removed:
> clang/test/CodeGen/debug-info-param-modification.c
>
>
>
> 
> diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp
> b/clang/lib/CodeGen/CGDebugInfo.cpp
> index 116517a9cb99..a9b3831aa0b5 100644
> --- a/clang/lib/CodeGen/CGDebugInfo.cpp
> +++ b/clang/lib/CodeGen/CGDebugInfo.cpp
> @@ -18,7 +18,6 @@
>  #include "CodeGenFunction.h"
>  #include "CodeGenModule.h"
>  #include "ConstantEmitter.h"
> -#include "clang/Analysis/Analyses/ExprMutationAnalyzer.h"
>  #include "clang/AST/ASTContext.h"
>  #include "clang/AST/DeclFriend.h"
>  #include "clang/AST/DeclObjC.h"
> @@ -3686,15 +3685,6 @@ void CGDebugInfo::EmitFunctionStart(GlobalDecl GD,
> SourceLocation Loc,
>if (HasDecl && isa(D))
>  DeclCache[D->getCanonicalDecl()].reset(SP);
>
> -  // We use the SPDefCache only in the case when the debug entry values
> option
> -  // is set, in order to speed up parameters modification analysis.
> -  //
> -  // FIXME: Use AbstractCallee here to support ObjCMethodDecl.
> -  if (CGM.getCodeGenOpts().EnableDebugEntryValues && HasDecl)
> -if (auto *FD = dyn_cast(D))
> -  if (FD->hasBody() && !FD->param_empty())
> -SPDefCache[FD].reset(SP);
> -
>// Push the function onto the lexical block stack.
>LexicalBlockStack.emplace_back(SP);
>
> @@ -4097,11 +4087,6 @@ llvm::DILocalVariable
> *CGDebugInfo::EmitDeclare(const VarDecl *VD,
>   llvm::DebugLoc::get(Line, Column, Scope,
> CurInlinedAt),
>   Builder.GetInsertBlock());
>
> -  if (CGM.getCodeGenOpts().EnableDebugEntryValues && ArgNo) {
> -if (auto *PD = dyn_cast(VD))
> -  ParamCache[PD].reset(D);
> -  }
> -
>return D;
>  }
>
> @@ -4717,29 +4702,6 @@ void CGDebugInfo::setDwoId(uint64_t Signature) {
>TheCU->setDWOId(Signature);
>  }
>
> -/// Analyzes each function parameter to determine whether it is constant
> -/// throughout the function body.
> -static void analyzeParametersModification(
> -ASTContext ,
> -llvm::DenseMap ,
> -llvm::DenseMap )
> {
> -  for (auto  : SPDefCache) {
> -auto *FD = SP.first;
> -assert(FD->hasBody() && "Functions must have body here");
> -const Stmt *FuncBody = (*FD).getBody();
> -for (auto Parm : FD->parameters()) {
> -  ExprMutationAnalyzer FuncAnalyzer(*FuncBody, Ctx);
> -  if (FuncAnalyzer.isMutated(Parm))
> -continue;
> -
> -  auto I = ParamCache.find(Parm);
> -  assert(I != ParamCache.end() && "Parameters should be already
> cached");
> -  auto *DIParm = cast(I->second);
> -  DIParm->setIsNotModified();
> -}
> -  }
> -}
> -
>  void CGDebugInfo::finalize() {
>// Creating types might create further types - invalidating the current
>// element and the size(), so don't cache/reference them.
> @@ -4812,10 +4774,6 @@ void CGDebugInfo::finalize() {
>  if (auto MD = TypeCache[RT])
>DBuilder.retainType(cast(MD));
>
> -  if (CGM.getCodeGenOpts().EnableDebugEntryValues)
> -// This will be used to emit debug entry values.
> -analyzeParametersModification(CGM.getContext(), SPDefCache,
> ParamCache);
> -
>DBuilder.finalize();
>  }
>
>
> diff  --git a/clang/lib/CodeGen/CGDebugInfo.h
> b/clang/lib/CodeGen/CGDebugInfo.h
> index 9a097615b4b4..5341bfa7f350 100644
> --- a/clang/lib/CodeGen/CGDebugInfo.h
> +++ b/clang/lib/CodeGen/CGDebugInfo.h
> @@ -146,10 +146,6 @@ class CGDebugInfo {
>
>llvm::DenseMap DIFileCache;
>llvm::DenseMap SPCache;
> -  /// Cache function definitions relevant to use for parameters mutation
> -  /// analysis.
> -  llvm::DenseMap SPDefCache;
> -  llvm::DenseMap ParamCache;
>/// Cache 

[clang] e956952 - DebugInfo: Flag Dwarf Version metadata for merging during LTO

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2019-11-22T17:16:35-08:00
New Revision: e956952edec140d2475aa7c8cbe20fbdd3320634

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

LOG: DebugInfo: Flag Dwarf Version metadata for merging during LTO

When the Dwarf Version metadata was initially added (r184276) there was
no support for Module::Max - though the comment suggested that was the
desired behavior. The original behavior was Module::Warn which would
warn and then pick whichever version came first - which is pretty
arbitrary/luck-based if the consumer has some need for one version or
the other.

Now that the functionality's been added (r303590) this change updates
the implementation to match the desired goal.

The general logic here is - if you compile /some/ of your program with a
more recent DWARF version, you must have a consumer that can handle it,
so might as well use it for /everything/.

The only place where this might fall down is if you have a need to use
an old tool (supporting only the older DWARF version) for some subset of
your program. In which case now it'll all be the higher version. That
seems pretty narrow (& the inverse could happen too - you specifically
/need/ the higher DWARF version for some extra expressivity, etc, in
some part of the program)

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/test/CodeGen/dwarf-version.c

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 0e561693f20c..25268efff61b 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -470,9 +470,7 @@ void CodeGenModule::Release() {
   CodeGenOpts.NumRegisterParameters);
 
   if (CodeGenOpts.DwarfVersion) {
-// We actually want the latest version when there are conflicts.
-// We can change from Warning to Latest if such mode is supported.
-getModule().addModuleFlag(llvm::Module::Warning, "Dwarf Version",
+getModule().addModuleFlag(llvm::Module::Max, "Dwarf Version",
   CodeGenOpts.DwarfVersion);
   }
   if (CodeGenOpts.EmitCodeView) {

diff  --git a/clang/test/CodeGen/dwarf-version.c 
b/clang/test/CodeGen/dwarf-version.c
index 10add21d88dd..87143ee13118 100644
--- a/clang/test/CodeGen/dwarf-version.c
+++ b/clang/test/CodeGen/dwarf-version.c
@@ -38,10 +38,10 @@ int main (void) {
 
 // NOCODEVIEW-NOT: !"CodeView"
 
-// VER2: !{i32 2, !"Dwarf Version", i32 2}
-// VER3: !{i32 2, !"Dwarf Version", i32 3}
-// VER4: !{i32 2, !"Dwarf Version", i32 4}
-// VER5: !{i32 2, !"Dwarf Version", i32 5}
+// VER2: !{i32 7, !"Dwarf Version", i32 2}
+// VER3: !{i32 7, !"Dwarf Version", i32 3}
+// VER4: !{i32 7, !"Dwarf Version", i32 4}
+// VER5: !{i32 7, !"Dwarf Version", i32 5}
 
 // NODWARF-NOT: !"Dwarf Version"
 // CODEVIEW: !{i32 2, !"CodeView", i32 1}



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

Re: [clang] dd870f6 - Fix warning about unused std::unique result, erase shifted elements

[David Blaikie via cfe-commits]

OK - thanks for the context!

On Mon, Nov 18, 2019 at 5:07 PM Ben Langmuir  wrote:

> Nice find.
>
> The change LGTM, and is clearly what I always intended it to do.  I was
> confused how this ever worked at all, but I see that (at least in libc++)
> we move the values into place rather than swap them, so the values at the
> end are still the largest values for types with a trivial move constructor.
>
> I am not working in this area these days and am not setup to provide a
> test case in any reasonable amount of time.  I think it would need a gtest,
> as I'm not sure this change is obvservable otherwise.
>
> Ben
>
> On Nov 18, 2019, at 4:44 PM, David Blaikie  wrote:
>
> Hey Ben - if you're still involved with this part of the project - could
> you check that this change (to code you committed back in 2014, r215810) is
> correct & add a test case if possible?
>
> On Thu, Nov 7, 2019 at 10:39 AM Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: Reid Kleckner
>> Date: 2019-11-07T10:39:29-08:00
>> New Revision: dd870f6929ee0b1dfb5fd000c7b826a1bd2d2571
>>
>> URL:
>> https://github.com/llvm/llvm-project/commit/dd870f6929ee0b1dfb5fd000c7b826a1bd2d2571
>> DIFF:
>> https://github.com/llvm/llvm-project/commit/dd870f6929ee0b1dfb5fd000c7b826a1bd2d2571.diff
>>
>> LOG: Fix warning about unused std::unique result, erase shifted elements
>>
>> This is actually a functional change. I haven't added any new test
>> coverage. I'm just trying to fix the warning and hoping for the best.
>>
>> Added:
>>
>>
>> Modified:
>> clang/include/clang/Serialization/ContinuousRangeMap.h
>>
>> Removed:
>>
>>
>>
>>
>> 
>> diff  --git a/clang/include/clang/Serialization/ContinuousRangeMap.h
>> b/clang/include/clang/Serialization/ContinuousRangeMap.h
>> index 0c05537dd108..c2665c097416 100644
>> --- a/clang/include/clang/Serialization/ContinuousRangeMap.h
>> +++ b/clang/include/clang/Serialization/ContinuousRangeMap.h
>> @@ -118,14 +118,17 @@ class ContinuousRangeMap {
>>
>>  ~Builder() {
>>llvm::sort(Self.Rep, Compare());
>> -  std::unique(Self.Rep.begin(), Self.Rep.end(),
>> -  [](const_reference A, const_reference B) {
>> -// FIXME: we should not allow any duplicate keys, but there are
>> a lot of
>> -// duplicate 0 -> 0 mappings to remove first.
>> -assert((A == B || A.first != B.first) &&
>> -   "ContinuousRangeMap::Builder given non-unique keys");
>> -return A == B;
>> -  });
>> +  Self.Rep.erase(
>> +  std::unique(
>> +  Self.Rep.begin(), Self.Rep.end(),
>> +  [](const_reference A, const_reference B) {
>> +// FIXME: we should not allow any duplicate keys, but
>> there are
>> +// a lot of duplicate 0 -> 0 mappings to remove first.
>> +assert((A == B || A.first != B.first) &&
>> +   "ContinuousRangeMap::Builder given non-unique
>> keys");
>> +return A == B;
>> +  }),
>> +  Self.Rep.end());
>>  }
>>
>>  void insert(const value_type ) {
>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] dd870f6 - Fix warning about unused std::unique result, erase shifted elements

[David Blaikie via cfe-commits]

Hey Ben - if you're still involved with this part of the project - could
you check that this change (to code you committed back in 2014, r215810) is
correct & add a test case if possible?

On Thu, Nov 7, 2019 at 10:39 AM Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Reid Kleckner
> Date: 2019-11-07T10:39:29-08:00
> New Revision: dd870f6929ee0b1dfb5fd000c7b826a1bd2d2571
>
> URL:
> https://github.com/llvm/llvm-project/commit/dd870f6929ee0b1dfb5fd000c7b826a1bd2d2571
> DIFF:
> https://github.com/llvm/llvm-project/commit/dd870f6929ee0b1dfb5fd000c7b826a1bd2d2571.diff
>
> LOG: Fix warning about unused std::unique result, erase shifted elements
>
> This is actually a functional change. I haven't added any new test
> coverage. I'm just trying to fix the warning and hoping for the best.
>
> Added:
>
>
> Modified:
> clang/include/clang/Serialization/ContinuousRangeMap.h
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/include/clang/Serialization/ContinuousRangeMap.h
> b/clang/include/clang/Serialization/ContinuousRangeMap.h
> index 0c05537dd108..c2665c097416 100644
> --- a/clang/include/clang/Serialization/ContinuousRangeMap.h
> +++ b/clang/include/clang/Serialization/ContinuousRangeMap.h
> @@ -118,14 +118,17 @@ class ContinuousRangeMap {
>
>  ~Builder() {
>llvm::sort(Self.Rep, Compare());
> -  std::unique(Self.Rep.begin(), Self.Rep.end(),
> -  [](const_reference A, const_reference B) {
> -// FIXME: we should not allow any duplicate keys, but there are a
> lot of
> -// duplicate 0 -> 0 mappings to remove first.
> -assert((A == B || A.first != B.first) &&
> -   "ContinuousRangeMap::Builder given non-unique keys");
> -return A == B;
> -  });
> +  Self.Rep.erase(
> +  std::unique(
> +  Self.Rep.begin(), Self.Rep.end(),
> +  [](const_reference A, const_reference B) {
> +// FIXME: we should not allow any duplicate keys, but
> there are
> +// a lot of duplicate 0 -> 0 mappings to remove first.
> +assert((A == B || A.first != B.first) &&
> +   "ContinuousRangeMap::Builder given non-unique
> keys");
> +return A == B;
> +  }),
> +  Self.Rep.end());
>  }
>
>  void insert(const value_type ) {
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] d0f3c82 - Fix uninitialized variable warnings. NFCI.

[David Blaikie via cfe-commits]

Which compiler/what sort of warning was this addressing? (it can be
beneficial to leave variables uninitialized if their value isn't intended
to be used - so things like asan can catch bugs where the read of
uninitialized is unintended)

On Sat, Nov 2, 2019 at 11:27 AM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Simon Pilgrim
> Date: 2019-11-02T18:03:21Z
> New Revision: d0f3c822160e36e10588bc86dabde6ab8d63cf10
>
> URL:
> https://github.com/llvm/llvm-project/commit/d0f3c822160e36e10588bc86dabde6ab8d63cf10
> DIFF:
> https://github.com/llvm/llvm-project/commit/d0f3c822160e36e10588bc86dabde6ab8d63cf10.diff
>
> LOG: Fix uninitialized variable warnings. NFCI.
>
> Added:
>
>
> Modified:
> clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
> b/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
> index 778375010041..f694c3e4380a 100644
> --- a/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
> +++ b/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
> @@ -134,7 +134,7 @@ namespace {
>
>  const Record *ExplicitDef;
>
> -GroupInfo() : ExplicitDef(nullptr) {}
> +GroupInfo() : IDNo(0), ExplicitDef(nullptr) {}
>};
>  } // end anonymous namespace.
>
> @@ -554,7 +554,7 @@ struct SelectPiece : Piece {
>
>ModifierType ModKind;
>std::vector Options;
> -  int Index;
> +  int Index = 0;
>
>static bool classof(const Piece *P) {
>  return P->getPieceClass() == SelectPieceClass ||
> @@ -566,7 +566,7 @@ struct PluralPiece : SelectPiece {
>PluralPiece() : SelectPiece(PluralPieceClass, MT_Plural) {}
>
>std::vector OptionPrefixes;
> -  int Index;
> +  int Index = 0;
>
>static bool classof(const Piece *P) {
>  return P->getPieceClass() == PluralPieceClass;
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 8d8f9c2 - [clang] Add -fdebug-default-version for specifying the default DWARF version

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2019-11-07T12:05:58-08:00
New Revision: 8d8f9c24407461fadf1730e80ebcf7c767254715

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

LOG: [clang] Add -fdebug-default-version for specifying the default DWARF 
version

This flag decouples specifying the DWARF version from enabling/disabling
DWARF in general (or the gN level - gmlt/limited/standalone, etc) while
still allowing existing -gdwarf-N flags to override this default.

Patch by Caroline Tice!

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

Added: 
clang/test/Driver/debug-default-version.c

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

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8995f3d198e4..dcd2976a97f2 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1958,6 +1958,8 @@ def fsplit_dwarf_inlining: Flag <["-"], 
"fsplit-dwarf-inlining">, Group
   Flags<[CC1Option]>, HelpText<"Provide minimal debug info in the 
object/executable to facilitate online symbolication/stack traces in the 
absence of .dwo/.dwp files when using Split DWARF">;
 def fno_split_dwarf_inlining: Flag<["-"], "fno-split-dwarf-inlining">, 
Group,
   Flags<[CC1Option]>;
+def fdebug_default_version: Joined<["-"], "fdebug-default-version=">, 
Group,
+  HelpText<"Default DWARF version to use, if a -g option caused DWARF debug 
info to be produced">;
 def fdebug_prefix_map_EQ
   : Joined<["-"], "fdebug-prefix-map=">, Group,
 Flags<[CC1Option,CC1AsOption]>,

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 17cb4816e61f..008742aca57f 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3335,7 +3335,6 @@ static void RenderDebugOptions(const ToolChain , const 
Driver ,
   // This avoids having to monkey around further in cc1 other than to disable
   // codeview if not running in a Windows environment. Perhaps even that
   // decision should be made in the driver as well though.
-  unsigned DWARFVersion = 0;
   llvm::DebuggerKind DebuggerTuning = TC.getDefaultDebuggerTuning();
 
   bool SplitDWARFInlining =
@@ -3418,11 +3417,18 @@ static void RenderDebugOptions(const ToolChain , 
const Driver ,
 }
   }
 
+  unsigned DWARFVersion = 0;
+  unsigned DefaultDWARFVersion = ParseDebugDefaultVersion(TC, Args);
   if (EmitDwarf) {
 // Start with the platform default DWARF version
 DWARFVersion = TC.GetDefaultDwarfVersion();
 assert(DWARFVersion && "toolchain default DWARF version must be nonzero");
 
+// If the user specified a default DWARF version, that takes precedence
+// over the platform default.
+if (DefaultDWARFVersion)
+  DWARFVersion = DefaultDWARFVersion;
+
 // Override with a user-specified DWARF version
 if (GDwarfN)
   if (auto ExplicitVersion = DwarfVersionNum(GDwarfN->getSpelling()))
@@ -6354,6 +6360,11 @@ void ClangAs::ConstructJob(Compilation , const 
JobAction ,
 if (WantDebug)
   DwarfVersion = DwarfVersionNum(A->getSpelling());
   }
+
+  unsigned DefaultDwarfVersion = ParseDebugDefaultVersion(getToolChain(), 
Args);
+  if (DwarfVersion == 0)
+DwarfVersion = DefaultDwarfVersion;
+
   if (DwarfVersion == 0)
 DwarfVersion = getToolChain().GetDefaultDwarfVersion();
 

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 10743559e048..709ddaae4ab0 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1138,6 +1138,21 @@ unsigned tools::ParseFunctionAlignment(const ToolChain 
,
   return Value ? llvm::Log2_32_Ceil(std::min(Value, 65536u)) : Value;
 }
 
+unsigned tools::ParseDebugDefaultVersion(const ToolChain ,
+ const ArgList ) {
+  const Arg *A = Args.getLastArg(options::OPT_fdebug_default_version);
+
+  if (!A)
+return 0;
+
+  unsigned Value = 0;
+  if (StringRef(A->getValue()).getAsInteger(10, Value) || Value > 5 ||
+  Value < 2)
+TC.getDriver().Diag(diag::err_drv_invalid_int_value)
+<< A->getAsString(Args) << A->getValue();
+  return Value;
+}
+
 void tools::AddAssemblerKPIC(const ToolChain , const ArgList ,
  ArgStringList ) {
   llvm::Reloc::Model RelocationModel;

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.h 
b/clang/lib/Driver/ToolChains/CommonArgs.h
index 79468e6b8926..cf1ce14249ea 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.h
+++ b/clang/lib/Driver/ToolChains/CommonArgs.h
@@ -68,6 +68,9 @@ 

[clang] 1de2a05 - DebugInfo: Accept -gdwarf even in clang-cl

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2019-11-01T15:36:15-07:00
New Revision: 1de2a05701e73f8ef5914c2f6ea2dcbe617ce18b

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

LOG: DebugInfo: Accept -gdwarf even in clang-cl

Fixes regression introduced by llvmorg-10-init-8908-g098d901bd1b

Added: 


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

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 44259a2a53e8..722427bc35a6 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1974,7 +1974,7 @@ def glldb : Flag<["-"], "glldb">, Group;
 def gsce : Flag<["-"], "gsce">, Group;
 // Equivalent to our default dwarf version. Forces usual dwarf emission when
 // CodeView is enabled.
-def gdwarf : Flag<["-"], "gdwarf">, Group,
+def gdwarf : Flag<["-"], "gdwarf">, Group, Flags<[CoreOption]>,
   HelpText<"Generate source-level debug information with the default dwarf 
version">;
 def gdwarf_2 : Flag<["-"], "gdwarf-2">, Group,
   HelpText<"Generate source-level debug information with dwarf version 2">;



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

[clang] 098d901 - DebugInfo: Let -gdwarf use the toolchain default DWARF version, instead of hardcoded/aliased to -gdwarf-4

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2019-11-01T15:17:51-07:00
New Revision: 098d901bd1be07f60c41450fa4af775b130117b9

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

LOG: DebugInfo: Let -gdwarf use the toolchain default DWARF version, instead of 
hardcoded/aliased to -gdwarf-4

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/dwarf-version.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 07c27ebcefee..44259a2a53e8 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1972,6 +1972,10 @@ def ggdb2 : Flag<["-"], "ggdb2">, Group;
 def ggdb3 : Flag<["-"], "ggdb3">, Group;
 def glldb : Flag<["-"], "glldb">, Group;
 def gsce : Flag<["-"], "gsce">, Group;
+// Equivalent to our default dwarf version. Forces usual dwarf emission when
+// CodeView is enabled.
+def gdwarf : Flag<["-"], "gdwarf">, Group,
+  HelpText<"Generate source-level debug information with the default dwarf 
version">;
 def gdwarf_2 : Flag<["-"], "gdwarf-2">, Group,
   HelpText<"Generate source-level debug information with dwarf version 2">;
 def gdwarf_3 : Flag<["-"], "gdwarf-3">, Group,
@@ -1989,10 +1993,6 @@ def gcodeview_ghash : Flag<["-"], "gcodeview-ghash">,
   Flags<[CC1Option, CoreOption]>;
 def gno_codeview_ghash : Flag<["-"], "gno-codeview-ghash">, 
Flags<[CoreOption]>;
 
-// Equivalent to our default dwarf version. Forces usual dwarf emission when
-// CodeView is enabled.
-def gdwarf : Flag<["-"], "gdwarf">, Alias, Flags<[CoreOption]>;
-
 def gfull : Flag<["-"], "gfull">, Group;
 def gused : Flag<["-"], "gused">, Group;
 def gstabs : Joined<["-"], "gstabs">, Group, Flags<[Unsupported]>;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 9cfa39840566..529c33a16748 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3198,9 +3198,9 @@ static void RenderDebugOptions(const ToolChain , const 
Driver ,
   }
 
   // If a -gdwarf argument appeared, remember it.
-  const Arg *GDwarfN =
-  Args.getLastArg(options::OPT_gdwarf_2, options::OPT_gdwarf_3,
-  options::OPT_gdwarf_4, options::OPT_gdwarf_5);
+  const Arg *GDwarfN = Args.getLastArg(
+  options::OPT_gdwarf_2, options::OPT_gdwarf_3, options::OPT_gdwarf_4,
+  options::OPT_gdwarf_5, options::OPT_gdwarf);
   bool EmitDwarf = false;
   if (GDwarfN) {
 if (checkDebugInfoOption(GDwarfN, Args, D, TC))
@@ -3231,6 +3231,7 @@ static void RenderDebugOptions(const ToolChain , const 
Driver ,
   if (EmitDwarf) {
 // Start with the platform default DWARF version
 DWARFVersion = TC.GetDefaultDwarfVersion();
+assert(DWARFVersion && "toolchain default DWARF version must be nonzero");
 
 // Override with a user-specified DWARF version
 if (GDwarfN)

diff  --git a/clang/test/CodeGen/dwarf-version.c 
b/clang/test/CodeGen/dwarf-version.c
index 39bcbc209037..10add21d88dd 100644
--- a/clang/test/CodeGen/dwarf-version.c
+++ b/clang/test/CodeGen/dwarf-version.c
@@ -14,6 +14,7 @@
 // RUN: %clang -target powerpc-unknown-openbsd -g -S -emit-llvm -o - %s | 
FileCheck %s --check-prefix=VER2
 // RUN: %clang -target powerpc-unknown-freebsd -g -S -emit-llvm -o - %s | 
FileCheck %s --check-prefix=VER2
 // RUN: %clang -target i386-pc-solaris -g -S -emit-llvm -o - %s | FileCheck %s 
--check-prefix=VER2
+// RUN: %clang -target i386-pc-solaris -gdwarf -S -emit-llvm -o - %s | 
FileCheck %s --check-prefix=VER2
 
 // Check which debug info formats we use on Windows. By default, in an MSVC
 // environment, we should use codeview. You can enable dwarf, which implicitly



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

[clang] 42465f4 - DebugInfo: (NFC) Refactor DWARF version calculation to make a future change (-fdebug-default-version) easier

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2019-11-01T14:56:43-07:00
New Revision: 42465f406bcea5ea06001ccc52ab779120b68e87

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

LOG: DebugInfo: (NFC) Refactor DWARF version calculation to make a future 
change (-fdebug-default-version) easier

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 81e01aee1da9..9cfa39840566 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3198,11 +3198,16 @@ static void RenderDebugOptions(const ToolChain , 
const Driver ,
   }
 
   // If a -gdwarf argument appeared, remember it.
-  if (const Arg *A =
+  const Arg *GDwarfN =
   Args.getLastArg(options::OPT_gdwarf_2, options::OPT_gdwarf_3,
-  options::OPT_gdwarf_4, options::OPT_gdwarf_5))
-if (checkDebugInfoOption(A, Args, D, TC))
-  DWARFVersion = DwarfVersionNum(A->getSpelling());
+  options::OPT_gdwarf_4, options::OPT_gdwarf_5);
+  bool EmitDwarf = false;
+  if (GDwarfN) {
+if (checkDebugInfoOption(GDwarfN, Args, D, TC))
+  EmitDwarf = true;
+else
+  GDwarfN = nullptr;
+  }
 
   if (const Arg *A = Args.getLastArg(options::OPT_gcodeview)) {
 if (checkDebugInfoOption(A, Args, D, TC))
@@ -3211,18 +3216,28 @@ static void RenderDebugOptions(const ToolChain , 
const Driver ,
 
   // If the user asked for debug info but did not explicitly specify -gcodeview
   // or -gdwarf, ask the toolchain for the default format.
-  if (!EmitCodeView && DWARFVersion == 0 &&
+  if (!EmitCodeView && !EmitDwarf &&
   DebugInfoKind != codegenoptions::NoDebugInfo) {
 switch (TC.getDefaultDebugFormat()) {
 case codegenoptions::DIF_CodeView:
   EmitCodeView = true;
   break;
 case codegenoptions::DIF_DWARF:
-  DWARFVersion = TC.GetDefaultDwarfVersion();
+  EmitDwarf = true;
   break;
 }
   }
 
+  if (EmitDwarf) {
+// Start with the platform default DWARF version
+DWARFVersion = TC.GetDefaultDwarfVersion();
+
+// Override with a user-specified DWARF version
+if (GDwarfN)
+  if (auto ExplicitVersion = DwarfVersionNum(GDwarfN->getSpelling()))
+DWARFVersion = ExplicitVersion;
+  }
+
   // -gline-directives-only supported only for the DWARF debug info.
   if (DWARFVersion == 0 && DebugInfoKind == 
codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::NoDebugInfo;



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

Re: [PATCH] D67723: [DebugInfo] Add option to disable inline line tables.

[David Blaikie via cfe-commits]

On Thu, Oct 24, 2019 at 3:24 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Oct 24, 2019, at 3:02 PM, David Blaikie via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> dblaikie added a comment.
>
> In D67723#1720509 , @aprantl
> wrote:
>
> In D67723#1720353 , @rnk wrote:
>
> In D67723#1717468 , @aprantl
> wrote:
>
> I agree that it would make sense to have a
> `-ginline-info-threshold=<#insns>` or `-gno-small-inline-functions` with a
> hardcoded threshold to implement the feature Paul described, and this patch
> seems to be a step in that direction, with the threshold being hardcoded to
> 0.
>
>
>
> OK. :)
>
> We are motivated by one tool in particular at the moment, but if we're
> going to take the time to add a knob, we might as well make it work for
> DWARF.
>
>
> Here you got me confused: When I read "we might as well make it work for
> DWARF", I read that as "we should emit the inlined instructions with line 0
> under a DWARF debugger tuning". But that reading seems to to contradict
> your next sentence:
>
> If the user cares enough to find this flag, it seems more user friendly to
> make it behave the same rather than making it format-dependent.
>
>
> Can you clarify?
>
>
> If we use line zero for DWARF, gdb will not behave in the way documented
> by the function attribute in LangRef. I was the one who suggested the
> wording there, so maybe we could come up with new wording that describes
> what the user should expect in the debugger when using line zero. However,
> given the behavior I show below, I have a hard time imagining the use case
> for it.
>
>
>
> I didn't realize that GDB also had problems; I thought that this was a
> problem that only affected Windows debuggers.
>
>
>
> I don't think the behavior Reid described would be a "problem" - it seems
> to me like the only behavior the debugger could provide if those
> instructions are attributed to line zero.
>
>
>
> I applied the version of this patch that uses getMergedLocation, compiled
> this program, and ran it under gdb:
>
>  volatile int x;
>  static inline void foo() {
>++x;
>*(volatile int*)0 = 42; // crash
>++x;
>  }
>  int main() {
>++x;  // line 8
>foo();  // line 9
>++x;
>return x;
>  }
>
>
> If we apply line zero, the debugger stops on line 8:
>
>  Program received signal SIGSEGV, Segmentation fault.
>  0x0040111e in main () at t.cpp:8
>  8 ++x;
>  (gdb) bt
>  #0  0x0040111e in main () at t.cpp:8
>
>
> The inline frame is gone, as expected for this flag, but the current
> location does not reflect the site of the call to `foo`. So, if we want it
> to behave as documented, we have to put the call site location on some
> instructions.
>
> Alternatively, if I arrange things like this, the crash is attributed to
> line `return x`, which is completely unrelated to the inline call site:
>
>  static inline void foo() {
>++x;
>if (x) {
>  *(volatile int*)0 = 42; // crash
>  __builtin_unreachable();
>}
>++x;
>  }
>
>
> This means that if line zero is used, the source location shown in the
> debugger becomes sensitive to code layout, which is arbitrary.
>
> These experiments are convincing me that, in general, line zero isn't that
> helpful for DWARF consumers. If the goal is to get smooth stepping, we may
> want to refocus on getting reliable is_stmt bits in the line table.
>
>
> The Swift compiler is far more aggressive in using line 0 than Clang, and
> consequently LLDB is much better at handling line 0 than even GDB, and that
> can skew my perception :-)
>
>
> What behavior does LLDB have in the example Reid gave?
>
>
> I short-circuited a little by marking the function always_inline and
> putting a .loc 1 0 0  before the inlined instructions, so I hope that
> didn't butcher the example, but I didn't want to wait for clang to compile.
> LLDB says
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x0)
> frame #0: 0x00010f9f a.out`main at reid.c:0 [opt]
>

I meant more as a comparison with the stepping (rather than backtracing)
behavior that Reid mentioned from GDB.


> If the intended behavior is to show the crash at the call site like
> LangRef in the patch suggest then line 0 will certainly not achieve that. I
> implicitly assumed the wording in LangRef would follow the implementation
> if we switched to line 0.
>

Right - I think there's some reasonable discussion about what would be
suitable/useful behavior - and line zero isn't necessarily an experience a
user would want in this situation. (if there's no user for the feature, why
build it - if we have a quality/space tradeoff that seems useful to
CodeView users & we know inlining info is expensive in DWARF too (maybe not
as expensive as CodeView, I'm not sure) & so DWARF users /might/ want 

Re: r374837 - [clang] add requirements to -Wa,-W test cases.

[David Blaikie via cfe-commits]

Thanks for the details! Generally it's fine to have these discussions
on-list, or at least to include a summary reply so it's clear loose ends
were tied up.

On Mon, Oct 28, 2019 at 4:26 PM Jian Cai  wrote:

> Hi David,
>
> Thanks for the follow up. I already discussed it with Nico over email and
> addressed his concerns on llvm-svn: 374932. I did not want to spam everyone
> with all our email exchanges so I did not include the list :).
>
> Thanks,
> Jian
>
> On Mon, Oct 28, 2019 at 3:37 PM David Blaikie  wrote:
>
>> +1 to what Nico said/ping on this.
>>
>> Jian - could you see if these tests could be made portable as Nico's
>> suggested?
>>
>> On Mon, Oct 14, 2019 at 3:54 PM Nico Weber via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hm, this means the test can't run on non-linux, so if someone breaks it
>>> on e.g. win they won't see the failure. Maybe add a
>>> --target=i386-unknown-linux instead? Then it might pass on all platforms.
>>>
>>> On Mon, Oct 14, 2019 at 6:48 PM Jian Cai via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: jcai19
 Date: Mon Oct 14 15:51:12 2019
 New Revision: 374837

 URL: http://llvm.org/viewvc/llvm-project?rev=374837=rev
 Log:
 [clang] add requirements to -Wa,-W test cases.

 Include linux as a test requirement.

 Modified:
 cfe/trunk/test/Driver/as-w-option.c

 Modified: cfe/trunk/test/Driver/as-w-option.c
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/as-w-option.c?rev=374837=374836=374837=diff

 ==
 --- cfe/trunk/test/Driver/as-w-option.c (original)
 +++ cfe/trunk/test/Driver/as-w-option.c Mon Oct 14 15:51:12 2019
 @@ -5,6 +5,9 @@
  // RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings
 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
  // RUN: not %clang %s -c -o %t.o -fno-integrated-as
 -Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s

 +// REQUIRES: clang-driver
 +// REQUIRES: linux
 +
  // CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
  // CHECK-NOIAS: "-W"
  // CHECK-AS-NOWARN-NOT: warning:


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

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

Re: [clang] 9671d1d - [clang]Fixup clang -Werror, , -Wcovered-switch-default build failures

[David Blaikie via cfe-commits]

FWIW that probably produces a -Wreturn-type warning because other compilers
don't conservatively assume that only the enumerator values can be in an
enum variable (rather than all of its representable values). The subsequent
-Wreturn-type warning was fixed in 45787e56829f (moving the unreachable to
after the switch) - just mentioning for next time.

On Thu, Oct 24, 2019 at 3:50 PM Jinsong Ji via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Jinsong Ji
> Date: 2019-10-24T22:49:17Z
> New Revision: 9671d1dc1764701824913ecca2b76ab17c33c29e
>
> URL:
> https://github.com/llvm/llvm-project/commit/9671d1dc1764701824913ecca2b76ab17c33c29e
> DIFF:
> https://github.com/llvm/llvm-project/commit/9671d1dc1764701824913ecca2b76ab17c33c29e.diff
>
> LOG: [clang]Fixup clang -Werror,,-Wcovered-switch-default build failures
>
> llvm/clang/lib/CodeGen/CGBuiltin.cpp:6877:3: error: default label in
> switch which covers all enumeration values
> [-Werror,-Wcovered-switch-default]
>
> Similar to
> https://reviews.llvm.org/rG7b3de1e811972b874d91554642ccb2ef5b32eed6
>
> Added:
>
>
> Modified:
> clang/lib/CodeGen/CGBuiltin.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp
> b/clang/lib/CodeGen/CGBuiltin.cpp
> index c35d0a88e761..2caa8509ea06 100644
> --- a/clang/lib/CodeGen/CGBuiltin.cpp
> +++ b/clang/lib/CodeGen/CGBuiltin.cpp
> @@ -6873,9 +6873,6 @@ Value
> *CodeGenFunction::EmitARMMVEBuiltinExpr(unsigned BuiltinID,
>  }
>  return ToReturn;
>}
> -
> -  default:
> -llvm_unreachable("bad CustomCodegen enum value");
>}
>  }
>
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r374844 - Revert "Dead Virtual Function Elimination"

[David Blaikie via cfe-commits]

+1/ping on this - Jorge, could you include some details about the reason
for the revert & the revision?

On Mon, Oct 14, 2019 at 5:06 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi Jorge,
>
> Please mention the reason for a revert in revert commit messages. Also,
> until SVN stops being our system of record, please use SVN revision numbers
> to reference prior commits in reverts.
>
> On Mon, 14 Oct 2019 at 16:22, Jorge Gorbe Moya via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: jgorbe
>> Date: Mon Oct 14 16:25:25 2019
>> New Revision: 374844
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=374844=rev
>> Log:
>> Revert "Dead Virtual Function Elimination"
>>
>> This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f.
>>
>> Removed:
>> cfe/trunk/test/CodeGenCXX/vcall-visibility-metadata.cpp
>> cfe/trunk/test/CodeGenCXX/virtual-function-elimination.cpp
>> cfe/trunk/test/Driver/virtual-function-elimination.cpp
>> Modified:
>> cfe/trunk/include/clang/Basic/CodeGenOptions.def
>> cfe/trunk/include/clang/Driver/Options.td
>> cfe/trunk/lib/CodeGen/CGClass.cpp
>> cfe/trunk/lib/CodeGen/CGVTables.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.h
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/CodeGenOptions.def
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CodeGenOptions.def?rev=374844=374843=374844=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/CodeGenOptions.def (original)
>> +++ cfe/trunk/include/clang/Basic/CodeGenOptions.def Mon Oct 14 16:25:25
>> 2019
>> @@ -278,10 +278,6 @@ CODEGENOPT(EmitLLVMUseLists, 1, 0) ///<
>>  CODEGENOPT(WholeProgramVTables, 1, 0) ///< Whether to apply whole-program
>>///  vtable optimization.
>>
>> -CODEGENOPT(VirtualFunctionElimination, 1, 0) ///< Whether to apply the
>> dead
>> - /// virtual function
>> elimination
>> - /// optimization.
>> -
>>  /// Whether to use public LTO visibility for entities in std and stdext
>>  /// namespaces. This is enabled by clang-cl's /MT and /MTd flags.
>>  CODEGENOPT(LTOVisibilityPublicStd, 1, 0)
>>
>> Modified: cfe/trunk/include/clang/Driver/Options.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=374844=374843=374844=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Driver/Options.td (original)
>> +++ cfe/trunk/include/clang/Driver/Options.td Mon Oct 14 16:25:25 2019
>> @@ -1863,13 +1863,6 @@ def fforce_emit_vtables : Flag<["-"], "f
>>  HelpText<"Emits more virtual tables to improve devirtualization">;
>>  def fno_force_emit_vtables : Flag<["-"], "fno-force-emit-vtables">,
>> Group,
>>Flags<[CoreOption]>;
>> -
>> -def fvirtual_function_elimination : Flag<["-"],
>> "fvirtual-function-elimination">, Group,
>> -  Flags<[CoreOption, CC1Option]>,
>> -  HelpText<"Enables dead virtual function elimination optimization.
>> Requires -flto=full">;
>> -def fno_virtual_function_elimination : Flag<["-"],
>> "fno-virtual-function_elimination">, Group,
>> -  Flags<[CoreOption]>;
>> -
>>  def fwrapv : Flag<["-"], "fwrapv">, Group, Flags<[CC1Option]>,
>>HelpText<"Treat signed integer overflow as two's complement">;
>>  def fwritable_strings : Flag<["-"], "fwritable-strings">,
>> Group, Flags<[CC1Option]>,
>>
>> Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=374844=374843=374844=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGClass.cpp Mon Oct 14 16:25:25 2019
>> @@ -2784,16 +2784,11 @@ void CodeGenFunction::EmitVTablePtrCheck
>>
>>  bool CodeGenFunction::ShouldEmitVTableTypeCheckedLoad(const
>> CXXRecordDecl *RD) {
>>if (!CGM.getCodeGenOpts().WholeProgramVTables ||
>> +  !SanOpts.has(SanitizerKind::CFIVCall) ||
>> +  !CGM.getCodeGenOpts().SanitizeTrap.has(SanitizerKind::CFIVCall) ||
>>!CGM.HasHiddenLTOVisibility(RD))
>>  return false;
>>
>> -  if (CGM.getCodeGenOpts().VirtualFunctionElimination)
>> -return true;
>> -
>> -  if (!SanOpts.has(SanitizerKind::CFIVCall) ||
>> -  !CGM.getCodeGenOpts().SanitizeTrap.has(SanitizerKind::CFIVCall))
>> -return false;
>> -
>>std::string TypeName = RD->getQualifiedNameAsString();
>>return !getContext().getSanitizerBlacklist().isBlacklistedType(
>>SanitizerKind::CFIVCall, TypeName);
>> @@ -2816,13 +2811,8 @@ llvm::Value *CodeGenFunction::EmitVTable
>> TypeId});
>>llvm::Value 

Re: r374837 - [clang] add requirements to -Wa,-W test cases.

[David Blaikie via cfe-commits]

+1 to what Nico said/ping on this.

Jian - could you see if these tests could be made portable as Nico's
suggested?

On Mon, Oct 14, 2019 at 3:54 PM Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hm, this means the test can't run on non-linux, so if someone breaks it on
> e.g. win they won't see the failure. Maybe add a
> --target=i386-unknown-linux instead? Then it might pass on all platforms.
>
> On Mon, Oct 14, 2019 at 6:48 PM Jian Cai via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: jcai19
>> Date: Mon Oct 14 15:51:12 2019
>> New Revision: 374837
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=374837=rev
>> Log:
>> [clang] add requirements to -Wa,-W test cases.
>>
>> Include linux as a test requirement.
>>
>> Modified:
>> cfe/trunk/test/Driver/as-w-option.c
>>
>> Modified: cfe/trunk/test/Driver/as-w-option.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/as-w-option.c?rev=374837=374836=374837=diff
>>
>> ==
>> --- cfe/trunk/test/Driver/as-w-option.c (original)
>> +++ cfe/trunk/test/Driver/as-w-option.c Mon Oct 14 15:51:12 2019
>> @@ -5,6 +5,9 @@
>>  // RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings
>> 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
>>  // RUN: not %clang %s -c -o %t.o -fno-integrated-as -Wa,--fatal-warnings
>> 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
>>
>> +// REQUIRES: clang-driver
>> +// REQUIRES: linux
>> +
>>  // CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
>>  // CHECK-NOIAS: "-W"
>>  // CHECK-AS-NOWARN-NOT: warning:
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r375304 - DebugInfo: Render the canonical name of a class template specialization, even when nested in another class template specialization

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Oct 18 16:58:34 2019
New Revision: 375304

URL: http://llvm.org/viewvc/llvm-project?rev=375304=rev
Log:
DebugInfo: Render the canonical name of a class template specialization, even 
when nested in another class template specialization

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

Modified:
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-template-explicit-specialization.cpp

Modified: cfe/trunk/lib/AST/TypePrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TypePrinter.cpp?rev=375304=375303=375304=diff
==
--- cfe/trunk/lib/AST/TypePrinter.cpp (original)
+++ cfe/trunk/lib/AST/TypePrinter.cpp Fri Oct 18 16:58:34 2019
@@ -1204,7 +1204,8 @@ void TypePrinter::printTag(TagDecl *D, r
   // arguments.
   if (const auto *Spec = dyn_cast(D)) {
 ArrayRef Args;
-if (TypeSourceInfo *TAW = Spec->getTypeAsWritten()) {
+TypeSourceInfo *TAW = Spec->getTypeAsWritten();
+if (!Policy.PrintCanonicalTypes && TAW) {
   const TemplateSpecializationType *TST =
 cast(TAW->getType());
   Args = TST->template_arguments();

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=375304=375303=375304=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Oct 18 16:58:34 2019
@@ -314,7 +314,9 @@ StringRef CGDebugInfo::getClassName(cons
   if (isa(RD)) {
 SmallString<128> Name;
 llvm::raw_svector_ostream OS(Name);
-RD->getNameForDiagnostic(OS, getPrintingPolicy(),
+PrintingPolicy PP = getPrintingPolicy();
+PP.PrintCanonicalTypes = true;
+RD->getNameForDiagnostic(OS, PP,
  /*Qualified*/ false);
 
 // Copy this name on the side and use its reference.

Modified: 
cfe/trunk/test/CodeGenCXX/debug-info-template-explicit-specialization.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-template-explicit-specialization.cpp?rev=375304=375303=375304=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-template-explicit-specialization.cpp 
(original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-template-explicit-specialization.cpp 
Fri Oct 18 16:58:34 2019
@@ -105,7 +105,12 @@ struct j {
 };
 extern template class j;
 j jj;
+template 
+struct j_wrap {
+};
+j_wrap> j_wrap_j;
 // CHECK: DICompositeType(tag: DW_TAG_structure_type, name: "j"
+// CHECK: DICompositeType(tag: DW_TAG_structure_type, name: "j_wrap >"
 
 template 
 struct k {


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

Re: r373406 - Use scope qualifiers in Clang's tblgen backends to get useful

[David Blaikie via cfe-commits]

(mostly joking) any interest in seeing what it'd take to make Clang/LLVM
-Wmissing-prototype clean? (which would also catch the same sort of issues,
I think?)

On Tue, Oct 1, 2019 at 4:10 PM John McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rjmccall
> Date: Tue Oct  1 16:12:57 2019
> New Revision: 373406
>
> URL: http://llvm.org/viewvc/llvm-project?rev=373406=rev
> Log:
> Use scope qualifiers in Clang's tblgen backends to get useful
> redeclaration checking.  NFC.
>
> Modified:
> cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
> cfe/trunk/utils/TableGen/ClangCommentCommandInfoEmitter.cpp
>
> cfe/trunk/utils/TableGen/ClangCommentHTMLNamedCharacterReferenceEmitter.cpp
> cfe/trunk/utils/TableGen/ClangDataCollectorsEmitter.cpp
> cfe/trunk/utils/TableGen/ClangDiagnosticsEmitter.cpp
> cfe/trunk/utils/TableGen/ClangOpcodesEmitter.cpp
> cfe/trunk/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
> cfe/trunk/utils/TableGen/ClangOptionDocEmitter.cpp
> cfe/trunk/utils/TableGen/ClangSACheckersEmitter.cpp
> cfe/trunk/utils/TableGen/NeonEmitter.cpp
>
> Modified: cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp?rev=373406=373405=373406=diff
>
> ==
> --- cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp (original)
> +++ cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp Tue Oct  1 16:12:57
> 2019
> @@ -10,6 +10,8 @@
>  //
>
>  
> //===--===//
>
> +#include "TableGenBackends.h"
> +
>  #include "llvm/TableGen/Record.h"
>  #include "llvm/TableGen/TableGenBackend.h"
>  #include 
> @@ -173,15 +175,14 @@ void ClangASTNodesEmitter::run(raw_ostre
>OS << "#undef ABSTRACT_" << macroName(Root.getName()) << "\n";
>  }
>
> -namespace clang {
> -void EmitClangASTNodes(RecordKeeper , raw_ostream ,
> -   const std::string , const std::string ) {
> +void clang::EmitClangASTNodes(RecordKeeper , raw_ostream ,
> +  const std::string , const std::string )
> {
>ClangASTNodesEmitter(RK, N, S).run(OS);
>  }
>
>  // Emits and addendum to a .inc file to enumerate the clang declaration
>  // contexts.
> -void EmitClangDeclContext(RecordKeeper , raw_ostream ) {
> +void clang::EmitClangDeclContext(RecordKeeper , raw_ostream ) {
>// FIXME: Find a .td file format to allow for this to be represented
> better.
>
>emitSourceFileHeader("List of AST Decl nodes", OS);
> @@ -225,4 +226,3 @@ void EmitClangDeclContext(RecordKeeper &
>OS << "#undef DECL_CONTEXT\n";
>OS << "#undef DECL_CONTEXT_BASE\n";
>  }
> -} // end namespace clang
>
> Modified: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?rev=373406=373405=373406=diff
>
> ==
> --- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp (original)
> +++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp Tue Oct  1 16:12:57 2019
> @@ -10,6 +10,8 @@
>  //
>
>  
> //===--===//
>
> +#include "TableGenBackends.h"
> +
>  #include "llvm/ADT/ArrayRef.h"
>  #include "llvm/ADT/DenseMap.h"
>  #include "llvm/ADT/DenseSet.h"
> @@ -2219,10 +2221,8 @@ static void emitClangAttrThisIsaIdentifi
>OS << "#endif // CLANG_ATTR_THIS_ISA_IDENTIFIER_ARG_LIST\n\n";
>  }
>
> -namespace clang {
> -
>  // Emits the class definitions for attributes.
> -void EmitClangAttrClass(RecordKeeper , raw_ostream ) {
> +void clang::EmitClangAttrClass(RecordKeeper , raw_ostream ) {
>emitSourceFileHeader("Attribute classes' definitions", OS);
>
>OS << "#ifndef LLVM_CLANG_ATTR_CLASSES_INC\n";
> @@ -2491,7 +2491,7 @@ void EmitClangAttrClass(RecordKeeper 
>  }
>
>  // Emits the class method definitions for attributes.
> -void EmitClangAttrImpl(RecordKeeper , raw_ostream ) {
> +void clang::EmitClangAttrImpl(RecordKeeper , raw_ostream ) {
>emitSourceFileHeader("Attribute classes' member function definitions",
> OS);
>
>std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
> @@ -2556,8 +2556,6 @@ void EmitClangAttrImpl(RecordKeeper 
>EmitFunc("printPretty(OS, Policy)");
>  }
>
> -} // end namespace clang
> -
>  static void emitAttrList(raw_ostream , StringRef Class,
>   const std::vector ) {
>for (auto Cur : AttrList) {
>
> Modified: cfe/trunk/utils/TableGen/ClangCommentCommandInfoEmitter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangCommentCommandInfoEmitter.cpp?rev=373406=373405=373406=diff
>
> ==
> --- 

Re: r372681 - Support for DWARF-5 C++ language tags.

[David Blaikie via cfe-commits]

Yeah, something about linkage - but that's not the part that's as likely to
be a problem as the other part: the other test for C++ language was what
causes LLVM to compute the fully qualified name of an entity in the
accelerator table ("foo::bar" instead of just "bar" (eg: the bug was things
like "std::basic_string<...>::length" showed up in the table as just
"length" or "basic_string<...>" without the "std::" prefix, etc)

On Wed, Oct 2, 2019 at 8:48 AM Adrian Prantl  wrote:

>
> >> On Oct 1, 2019, at 6:40 PM, David Blaikie  wrote:
> >>
> >> This broke gnu_pubnames and other forms of DWARF index of C++ code -
> fixed in r373420 (feel free to post-comimt review, etc, of course)
> >>
> >
>
> patch for reference:
>
> >case dwarf::DW_TAG_union_type:
> >case dwarf::DW_TAG_enumeration_type:
> >  return dwarf::PubIndexEntryDescriptor(
> > -dwarf::GIEK_TYPE, CU->getLanguage() !=
> dwarf::DW_LANG_C_plus_plus
> > -  ? dwarf::GIEL_STATIC
> > -  : dwarf::GIEL_EXTERNAL);
> > +dwarf::GIEK_TYPE,
> > +dwarf::isCPlusPlus((dwarf::SourceLanguage)CU->getLanguage())
> > +? dwarf::GIEL_EXTERNAL
> > +: dwarf::GIEL_STATIC);
> >case dwarf::DW_TAG_typedef:
> >case dwarf::DW_TAG_base_type:
> >case dwarf::DW_TAG_subrange_type:
>
> > On Oct 2, 2019, at 8:32 AM, David Blaikie  wrote:
> >
> > Out of curiosity, should/would this've shown up for you Apple folks too?
> (as a failure in the apple/lldb accelerator tables - because the names
> would be similarly incorrect) had it just not got to the necessary testing
> yet?
> >
>
> +Jonas who knows the accelerator tables better than me.
>
> It certainly didn't show up in our LLDB bots. I'm not familiar with
> GIEL_STATIC vs. GIEL_EXTERNAL; are those linkage specifiers? I don't think
> we have an equivalent in the Apple accelerator tables or .debug_names.
>
> -- adrian
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r372681 - Support for DWARF-5 C++ language tags.

[David Blaikie via cfe-commits]

Out of curiosity, should/would this've shown up for you Apple folks too?
(as a failure in the apple/lldb accelerator tables - because the names
would be similarly incorrect) had it just not got to the necessary testing
yet?

On Wed, Oct 2, 2019 at 8:29 AM Adrian Prantl  wrote:

>
>
> On Oct 1, 2019, at 6:40 PM, David Blaikie  wrote:
>
> This broke gnu_pubnames and other forms of DWARF index of C++ code - fixed
> in r373420 (feel free to post-comimt review, etc, of course)
>
>
> Thanks!
>
> -- adrian
>
> On Mon, Sep 23, 2019 at 5:36 PM Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Mon Sep 23 17:38:49 2019
>> New Revision: 372681
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=372681=rev
>> Log:
>> Support for DWARF-5 C++ language tags.
>>
>> This patch provides support for DW_LANG_C_plus_plus_11,
>> DW_LANG_C_plus_plus_14 tags in the Clang C++ frontend.
>>
>> Patch by Sourabh Singh Tomar!
>> Differential Revision: https://reviews.llvm.org/D67613
>>
>> Reapplies r372663 after adapting a failing test in the LLDB testsuite.
>>
>> Modified:
>> cfe/trunk/include/clang/AST/DeclCXX.h
>> cfe/trunk/lib/AST/DeclPrinter.cpp
>> cfe/trunk/lib/AST/JSONNodeDumper.cpp
>> cfe/trunk/lib/AST/TextNodeDumper.cpp
>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>> cfe/trunk/lib/Sema/SemaModule.cpp
>> cfe/trunk/test/Modules/ModuleDebugInfo.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=372681=372680=372681=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
>> +++ cfe/trunk/include/clang/AST/DeclCXX.h Mon Sep 23 17:38:49 2019
>> @@ -42,6 +42,7 @@
>>  #include "llvm/ADT/PointerUnion.h"
>>  #include "llvm/ADT/STLExtras.h"
>>  #include "llvm/ADT/iterator_range.h"
>> +#include "llvm/BinaryFormat/Dwarf.h"
>>  #include "llvm/Support/Casting.h"
>>  #include "llvm/Support/Compiler.h"
>>  #include "llvm/Support/PointerLikeTypeTraits.h"
>> @@ -2941,8 +2942,10 @@ public:
>>/// ensure a stable ABI for this, we choose the DW_LANG_ encodings
>>/// from the dwarf standard.
>>enum LanguageIDs {
>> -lang_c = /* DW_LANG_C */ 0x0002,
>> -lang_cxx = /* DW_LANG_C_plus_plus */ 0x0004
>> +lang_c = llvm::dwarf::DW_LANG_C,
>> +lang_cxx = llvm::dwarf::DW_LANG_C_plus_plus,
>> +lang_cxx_11 = llvm::dwarf::DW_LANG_C_plus_plus_11,
>> +lang_cxx_14 = llvm::dwarf::DW_LANG_C_plus_plus_14
>>};
>>
>>  private:
>>
>> Modified: cfe/trunk/lib/AST/DeclPrinter.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclPrinter.cpp?rev=372681=372680=372681=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/DeclPrinter.cpp (original)
>> +++ cfe/trunk/lib/AST/DeclPrinter.cpp Mon Sep 23 17:38:49 2019
>> @@ -1001,12 +1001,19 @@ void DeclPrinter::VisitCXXRecordDecl(CXX
>>
>>  void DeclPrinter::VisitLinkageSpecDecl(LinkageSpecDecl *D) {
>>const char *l;
>> -  if (D->getLanguage() == LinkageSpecDecl::lang_c)
>> +  switch (D->getLanguage()) {
>> +  case LinkageSpecDecl::lang_c:
>>  l = "C";
>> -  else {
>> -assert(D->getLanguage() == LinkageSpecDecl::lang_cxx &&
>> -   "unknown language in linkage specification");
>> +break;
>> +  case LinkageSpecDecl::lang_cxx_14:
>> +l = "C++14";
>> +break;
>> +  case LinkageSpecDecl::lang_cxx_11:
>> +l = "C++11";
>> +break;
>> +  case LinkageSpecDecl::lang_cxx:
>>  l = "C++";
>> +break;
>>}
>>
>>Out << "extern \"" << l << "\" ";
>>
>> Modified: cfe/trunk/lib/AST/JSONNodeDumper.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/JSONNodeDumper.cpp?rev=372681=372680=372681=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/JSONNodeDumper.cpp (original)
>> +++ cfe/trunk/lib/AST/JSONNodeDumper.cpp Mon Sep 23 17:38:49 2019
>> @@ -850,6 +850,12 @@ void JSONNodeDumper::VisitLinkageSpecDec
>>switch (LSD->getLanguage()) {
>>case LinkageSpecDecl::lang_c: Lang = "C"; break;
>>case LinkageSpecDecl::lang_cxx: Lang = "C++"; break;
>> +  case LinkageSpecDecl::lang_cxx_11:
>> +Lang = "C++11";
>> +break;
>> +  case LinkageSpecDecl::lang_cxx_14:
>> +Lang = "C++14";
>> +break;
>>}
>>JOS.attribute("language", Lang);
>>attributeOnlyIfTrue("hasBraces", LSD->hasBraces());
>>
>> Modified: cfe/trunk/lib/AST/TextNodeDumper.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TextNodeDumper.cpp?rev=372681=372680=372681=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/TextNodeDumper.cpp (original)
>> +++ cfe/trunk/lib/AST/TextNodeDumper.cpp Mon Sep 

Re: r372681 - Support for DWARF-5 C++ language tags.

[David Blaikie via cfe-commits]

This broke gnu_pubnames and other forms of DWARF index of C++ code - fixed
in r373420 (feel free to post-comimt review, etc, of course)

On Mon, Sep 23, 2019 at 5:36 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Mon Sep 23 17:38:49 2019
> New Revision: 372681
>
> URL: http://llvm.org/viewvc/llvm-project?rev=372681=rev
> Log:
> Support for DWARF-5 C++ language tags.
>
> This patch provides support for DW_LANG_C_plus_plus_11,
> DW_LANG_C_plus_plus_14 tags in the Clang C++ frontend.
>
> Patch by Sourabh Singh Tomar!
> Differential Revision: https://reviews.llvm.org/D67613
>
> Reapplies r372663 after adapting a failing test in the LLDB testsuite.
>
> Modified:
> cfe/trunk/include/clang/AST/DeclCXX.h
> cfe/trunk/lib/AST/DeclPrinter.cpp
> cfe/trunk/lib/AST/JSONNodeDumper.cpp
> cfe/trunk/lib/AST/TextNodeDumper.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/lib/Sema/SemaModule.cpp
> cfe/trunk/test/Modules/ModuleDebugInfo.cpp
>
> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=372681=372680=372681=diff
>
> ==
> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
> +++ cfe/trunk/include/clang/AST/DeclCXX.h Mon Sep 23 17:38:49 2019
> @@ -42,6 +42,7 @@
>  #include "llvm/ADT/PointerUnion.h"
>  #include "llvm/ADT/STLExtras.h"
>  #include "llvm/ADT/iterator_range.h"
> +#include "llvm/BinaryFormat/Dwarf.h"
>  #include "llvm/Support/Casting.h"
>  #include "llvm/Support/Compiler.h"
>  #include "llvm/Support/PointerLikeTypeTraits.h"
> @@ -2941,8 +2942,10 @@ public:
>/// ensure a stable ABI for this, we choose the DW_LANG_ encodings
>/// from the dwarf standard.
>enum LanguageIDs {
> -lang_c = /* DW_LANG_C */ 0x0002,
> -lang_cxx = /* DW_LANG_C_plus_plus */ 0x0004
> +lang_c = llvm::dwarf::DW_LANG_C,
> +lang_cxx = llvm::dwarf::DW_LANG_C_plus_plus,
> +lang_cxx_11 = llvm::dwarf::DW_LANG_C_plus_plus_11,
> +lang_cxx_14 = llvm::dwarf::DW_LANG_C_plus_plus_14
>};
>
>  private:
>
> Modified: cfe/trunk/lib/AST/DeclPrinter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclPrinter.cpp?rev=372681=372680=372681=diff
>
> ==
> --- cfe/trunk/lib/AST/DeclPrinter.cpp (original)
> +++ cfe/trunk/lib/AST/DeclPrinter.cpp Mon Sep 23 17:38:49 2019
> @@ -1001,12 +1001,19 @@ void DeclPrinter::VisitCXXRecordDecl(CXX
>
>  void DeclPrinter::VisitLinkageSpecDecl(LinkageSpecDecl *D) {
>const char *l;
> -  if (D->getLanguage() == LinkageSpecDecl::lang_c)
> +  switch (D->getLanguage()) {
> +  case LinkageSpecDecl::lang_c:
>  l = "C";
> -  else {
> -assert(D->getLanguage() == LinkageSpecDecl::lang_cxx &&
> -   "unknown language in linkage specification");
> +break;
> +  case LinkageSpecDecl::lang_cxx_14:
> +l = "C++14";
> +break;
> +  case LinkageSpecDecl::lang_cxx_11:
> +l = "C++11";
> +break;
> +  case LinkageSpecDecl::lang_cxx:
>  l = "C++";
> +break;
>}
>
>Out << "extern \"" << l << "\" ";
>
> Modified: cfe/trunk/lib/AST/JSONNodeDumper.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/JSONNodeDumper.cpp?rev=372681=372680=372681=diff
>
> ==
> --- cfe/trunk/lib/AST/JSONNodeDumper.cpp (original)
> +++ cfe/trunk/lib/AST/JSONNodeDumper.cpp Mon Sep 23 17:38:49 2019
> @@ -850,6 +850,12 @@ void JSONNodeDumper::VisitLinkageSpecDec
>switch (LSD->getLanguage()) {
>case LinkageSpecDecl::lang_c: Lang = "C"; break;
>case LinkageSpecDecl::lang_cxx: Lang = "C++"; break;
> +  case LinkageSpecDecl::lang_cxx_11:
> +Lang = "C++11";
> +break;
> +  case LinkageSpecDecl::lang_cxx_14:
> +Lang = "C++14";
> +break;
>}
>JOS.attribute("language", Lang);
>attributeOnlyIfTrue("hasBraces", LSD->hasBraces());
>
> Modified: cfe/trunk/lib/AST/TextNodeDumper.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TextNodeDumper.cpp?rev=372681=372680=372681=diff
>
> ==
> --- cfe/trunk/lib/AST/TextNodeDumper.cpp (original)
> +++ cfe/trunk/lib/AST/TextNodeDumper.cpp Mon Sep 23 17:38:49 2019
> @@ -1766,6 +1766,12 @@ void TextNodeDumper::VisitLinkageSpecDec
>case LinkageSpecDecl::lang_cxx:
>  OS << " C++";
>  break;
> +  case LinkageSpecDecl::lang_cxx_11:
> +OS << " C++11";
> +break;
> +  case LinkageSpecDecl::lang_cxx_14:
> +OS << " C++14";
> +break;
>}
>  }
>
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=372681=372680=372681=diff
>
> 

Re: r371080 - [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them as artificial

[David Blaikie via cfe-commits]

Any resolution/discussion on this crash?

On Thu, Sep 5, 2019 at 12:49 PM Erik Pilkington via cfe-commits
 wrote:
>
> Hi Alexandre,
>
> Looks like this commit is causing crashes on darwin, can you take a look 
> please? Here is a failing bot: 
> http://lab.llvm.org:8080/green/job/clang-stage1-RA/1671/
>
> Thanks!
> Erik
>
> On Thu, Sep 5, 2019 at 11:23 AM Alexandre Ganea via cfe-commits 
>  wrote:
>>
>> Author: aganea
>> Date: Thu Sep  5 08:24:49 2019
>> New Revision: 371080
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=371080=rev
>> Log:
>> [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them 
>> as artificial
>>
>> Differential Revision: https://reviews.llvm.org/D66328
>>
>> Added:
>> cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
>> cfe/trunk/test/CodeGenCXX/debug-info-destroy-helper.cpp
>> Modified:
>> cfe/trunk/include/clang/AST/GlobalDecl.h
>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>> cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
>> cfe/trunk/test/CodeGenCXX/debug-info-line.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/GlobalDecl.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/GlobalDecl.h?rev=371080=371079=371080=diff
>> ==
>> --- cfe/trunk/include/clang/AST/GlobalDecl.h (original)
>> +++ cfe/trunk/include/clang/AST/GlobalDecl.h Thu Sep  5 08:24:49 2019
>> @@ -31,6 +31,7 @@ enum class DynamicInitKind : unsigned {
>>NoStub = 0,
>>Initializer,
>>AtExit,
>> +  GlobalArrayDestructor
>>  };
>>
>>  /// GlobalDecl - represents a global declaration. This can either be a
>>
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=371080=371079=371080=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Sep  5 08:24:49 2019
>> @@ -1910,7 +1910,8 @@ StringRef CGDebugInfo::getDynamicInitial
>>   llvm::Function *InitFn) {
>>// If we're not emitting codeview, use the mangled name. For Itanium, 
>> this is
>>// arbitrary.
>> -  if (!CGM.getCodeGenOpts().EmitCodeView)
>> +  if (!CGM.getCodeGenOpts().EmitCodeView ||
>> +  StubKind == DynamicInitKind::GlobalArrayDestructor)
>>  return InitFn->getName();
>>
>>// Print the normal qualified name for the variable, then break off the 
>> last
>> @@ -1935,6 +1936,7 @@ StringRef CGDebugInfo::getDynamicInitial
>>
>>switch (StubKind) {
>>case DynamicInitKind::NoStub:
>> +  case DynamicInitKind::GlobalArrayDestructor:
>>  llvm_unreachable("not an initializer");
>>case DynamicInitKind::Initializer:
>>  OS << "`dynamic initializer for '";
>> @@ -3569,7 +3571,8 @@ void CGDebugInfo::EmitFunctionStart(Glob
>>if (Name.startswith("\01"))
>>  Name = Name.substr(1);
>>
>> -  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
>> +  if (!HasDecl || D->isImplicit() || D->hasAttr() ||
>> +  (isa(D) && GD.getDynamicInitKind() != 
>> DynamicInitKind::NoStub)) {
>>  Flags |= llvm::DINode::FlagArtificial;
>>  // Artificial functions should not silently reuse CurLoc.
>>  CurLoc = SourceLocation();
>>
>> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=371080=371079=371080=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Thu Sep  5 08:24:49 2019
>> @@ -247,6 +247,8 @@ llvm::Function *CodeGenFunction::createA
>>
>>CGF.StartFunction(GlobalDecl(, DynamicInitKind::AtExit),
>>  CGM.getContext().VoidTy, fn, FI, FunctionArgList());
>> +  // Emit an artificial location for this function.
>> +  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
>>
>>llvm::CallInst *call = CGF.Builder.CreateCall(dtor, addr);
>>
>> @@ -642,8 +644,9 @@ void CodeGenFunction::GenerateCXXGlobalV
>>
>>StartFunction(GlobalDecl(D, DynamicInitKind::Initializer),
>>  getContext().VoidTy, Fn, 
>> getTypes().arrangeNullaryFunction(),
>> -FunctionArgList(), D->getLocation(),
>> -D->getInit()->getExprLoc());
>> +FunctionArgList());
>> +  // Emit an artificial location for this function.
>> +  auto AL = ApplyDebugLocation::CreateArtificial(*this);
>>
>>// Use guarded initialization if the global variable is weak. This
>>// occurs for, e.g., instantiated static data members and
>> @@ -768,7 +771,10 @@ llvm::Function *CodeGenFunction::generat
>>
>>CurEHLocation = VD->getBeginLoc();
>>
>> -  StartFunction(VD, getContext().VoidTy, fn, FI, args);
>> +  

Re: r369943 - FileManager: Use llvm::Expected in new getFileRef API

[David Blaikie via cfe-commits]

On Thu, Sep 5, 2019 at 9:57 AM Duncan P. N. Exon Smith 
wrote:

>
>
> On Sep 4, 2019, at 17:39, David Blaikie  wrote:
>
>
>
> On Mon, Aug 26, 2019 at 11:28 AM Duncan P. N. Exon Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dexonsmith
>> Date: Mon Aug 26 11:29:51 2019
>> New Revision: 369943
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=369943=rev
>> Log:
>> FileManager: Use llvm::Expected in new getFileRef API
>>
>> `FileManager::getFileRef` is a modern API which we expect to convert to
>> over time.  We should modernize the error handling as well, using
>> `llvm::Expected` instead of `llvm::ErrorOr`, to help clients that care
>> about errors to ensure nothing is missed.
>>
>> However, not all clients care.  I've also added another path for those
>> that don't:
>>
>> - `FileEntryRef` is now copy- and move-assignable (using a pointer
>>   instead of a reference).
>> - `FileManager::getOptionalFileRef` returns an `llvm::Optional` instead
>>   of `llvm::Expected`.
>> - Added an `llvm::expectedToOptional` utility in case this is useful
>>   elsewhere.
>>
>
> I'd hesitate to add new general constructs that swallow errors like this -
> keeping them manually written might help avoid their use becoming too
> common.
>
> On that note/direction - are there enough callers of getFileRef that don't
> care about errors that it's really impractical for them to each explicitly
> swallow the errors?
>
>
> `getFileRef` is intended to eventually supplant `getFile` which has many
> users.  Most of them don't care about the error, they just want to know
> whether or not they have a file entry.  If it makes sense to change them at
> some point that's great, but I think having them use `getOptionalFileRef`
> makes it easy to track down (and potentially change) the ones that are
> ignoring the specific error, without requiring a ton of boilerplate at each
> call site in the meantime.  An un-posted version of the patch changed all
> the current call sites of getFileRef to handle/ignore the error explicitly
> and it looked like I was making the code worse.
>

Fair enough - thanks for the context :)


> That said, as long as we have the getOptionalFileRef API, I don't feel
> strongly about the llvm::expectedToOptional utility.  The points in favour
> are that it aligns well with llvm::errorToBool, it reduces boilerplate, and
> it seems both explicit and grep'able.  Maybe that's not compelling enough
> though.
>

I'd have objected to errorToBool on the same grounds if I'd seen the review
- and at least like Lang to take a look at llvm::Error API changes like
this to evaluate how they fit into the desire for strong error handling. I
think escape hatches from that should be implemented pretty cautiously. The
original consumeError was meant to be used very sparingly (& I see you've
provided a similar caveat on expectedToOptional (though there is none on
errorToBool) - thanks for that!

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

Re: r369943 - FileManager: Use llvm::Expected in new getFileRef API

[David Blaikie via cfe-commits]

On Mon, Aug 26, 2019 at 11:28 AM Duncan P. N. Exon Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dexonsmith
> Date: Mon Aug 26 11:29:51 2019
> New Revision: 369943
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369943=rev
> Log:
> FileManager: Use llvm::Expected in new getFileRef API
>
> `FileManager::getFileRef` is a modern API which we expect to convert to
> over time.  We should modernize the error handling as well, using
> `llvm::Expected` instead of `llvm::ErrorOr`, to help clients that care
> about errors to ensure nothing is missed.
>
> However, not all clients care.  I've also added another path for those
> that don't:
>
> - `FileEntryRef` is now copy- and move-assignable (using a pointer
>   instead of a reference).
> - `FileManager::getOptionalFileRef` returns an `llvm::Optional` instead
>   of `llvm::Expected`.
> - Added an `llvm::expectedToOptional` utility in case this is useful
>   elsewhere.
>

I'd hesitate to add new general constructs that swallow errors like this -
keeping them manually written might help avoid their use becoming too
common.

On that note/direction - are there enough callers of getFileRef that don't
care about errors that it's really impractical for them to each explicitly
swallow the errors?


>
> https://reviews.llvm.org/D66705
>
> Modified:
> cfe/trunk/include/clang/Basic/FileManager.h
> cfe/trunk/lib/Basic/FileManager.cpp
> cfe/trunk/lib/Frontend/CompilerInstance.cpp
> cfe/trunk/lib/Lex/HeaderMap.cpp
> cfe/trunk/lib/Lex/HeaderSearch.cpp
>
> Modified: cfe/trunk/include/clang/Basic/FileManager.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=369943=369942=369943=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/FileManager.h (original)
> +++ cfe/trunk/include/clang/Basic/FileManager.h Mon Aug 26 11:29:51 2019
> @@ -110,26 +110,27 @@ public:
>  /// accessed by the FileManager's client.
>  class FileEntryRef {
>  public:
> +  FileEntryRef() = delete;
>FileEntryRef(StringRef Name, const FileEntry )
> -  : Name(Name), Entry(Entry) {}
> +  : Name(Name), Entry() {}
>
>const StringRef getName() const { return Name; }
>
> -  const FileEntry () const { return Entry; }
> +  const FileEntry () const { return *Entry; }
>
> -  off_t getSize() const { return Entry.getSize(); }
> +  off_t getSize() const { return Entry->getSize(); }
>
> -  unsigned getUID() const { return Entry.getUID(); }
> +  unsigned getUID() const { return Entry->getUID(); }
>
>const llvm::sys::fs::UniqueID () const {
> -return Entry.getUniqueID();
> +return Entry->getUniqueID();
>}
>
> -  time_t getModificationTime() const { return
> Entry.getModificationTime(); }
> +  time_t getModificationTime() const { return
> Entry->getModificationTime(); }
>
>  private:
>StringRef Name;
> -  const FileEntry 
> +  const FileEntry *Entry;
>  };
>
>  /// Implements support for file system lookup, file system caching,
> @@ -284,9 +285,17 @@ public:
>///
>/// \param CacheFailure If true and the file does not exist, we'll cache
>/// the failure to find this file.
> -  llvm::ErrorOr getFileRef(StringRef Filename,
> - bool OpenFile = false,
> - bool CacheFailure = true);
> +  llvm::Expected getFileRef(StringRef Filename,
> +  bool OpenFile = false,
> +  bool CacheFailure = true);
> +
> +  /// Get a FileEntryRef if it exists, without doing anything on error.
> +  llvm::Optional getOptionalFileRef(StringRef Filename,
> +  bool OpenFile = false,
> +  bool CacheFailure =
> true) {
> +return llvm::expectedToOptional(
> +getFileRef(Filename, OpenFile, CacheFailure));
> +  }
>
>/// Returns the current file system options
>FileSystemOptions () { return FileSystemOpts; }
>
> Modified: cfe/trunk/lib/Basic/FileManager.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileManager.cpp?rev=369943=369942=369943=diff
>
> ==
> --- cfe/trunk/lib/Basic/FileManager.cpp (original)
> +++ cfe/trunk/lib/Basic/FileManager.cpp Mon Aug 26 11:29:51 2019
> @@ -187,10 +187,10 @@ FileManager::getFile(StringRef Filename,
>auto Result = getFileRef(Filename, openFile, CacheFailure);
>if (Result)
>  return >getFileEntry();
> -  return Result.getError();
> +  return llvm::errorToErrorCode(Result.takeError());
>  }
>
> -llvm::ErrorOr
> +llvm::Expected
>  FileManager::getFileRef(StringRef Filename, bool openFile, bool
> CacheFailure) {
>++NumFileLookups;
>
> @@ -199,7 +199,8 @@ FileManager::getFileRef(StringRef Filena
>SeenFileEntries.insert({Filename,
> 

Re: r367940 - [Sema] Add -Wpointer-compare

[David Blaikie via cfe-commits]

This seems a bit narrow - could it be generalized to all cases of '\0' as a
null pointer?

On Mon, Aug 5, 2019 at 3:14 PM George Burgess IV via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: gbiv
> Date: Mon Aug  5 15:15:40 2019
> New Revision: 367940
>
> URL: http://llvm.org/viewvc/llvm-project?rev=367940=rev
> Log:
> [Sema] Add -Wpointer-compare
>
> This patch adds a warning that diagnoses comparisons of pointers to
> '\0'. This is often indicative of a bug (e.g. the user might've
> forgotten to dereference the pointer).
>
> Patch by Elaina Guan!
>
> Differential Revision: https://reviews.llvm.org/D65595
>
> Added:
> cfe/trunk/test/Sema/warn-nullchar-nullptr.c
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Sema/SemaExpr.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=367940=367939=367940=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Aug  5
> 15:15:40 2019
> @@ -3296,6 +3296,10 @@ def warn_impcast_bool_to_null_pointer :
>  def warn_non_literal_null_pointer : Warning<
>  "expression which evaluates to zero treated as a null pointer
> constant of "
>  "type %0">, InGroup;
> +def warn_pointer_compare : Warning<
> +"comparing a pointer to a null character constant; did you mean "
> +"to compare to %select{NULL|(void *)0}0?">,
> +InGroup>;
>  def warn_impcast_null_pointer_to_integer : Warning<
>  "implicit conversion of %select{NULL|nullptr}0 constant to %1">,
>  InGroup;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=367940=367939=367940=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Mon Aug  5 15:15:40 2019
> @@ -10022,6 +10022,7 @@ public:
>QualType CheckShiftOperands( // C99 6.5.7
>  ExprResult , ExprResult , SourceLocation Loc,
>  BinaryOperatorKind Opc, bool IsCompAssign = false);
> +  void CheckPtrComparisonWithNullChar(ExprResult , ExprResult );
>QualType CheckCompareOperands( // C99 6.5.8/9
>ExprResult , ExprResult , SourceLocation Loc,
>BinaryOperatorKind Opc);
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=367940=367939=367940=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Mon Aug  5 15:15:40 2019
> @@ -10443,6 +10443,32 @@ static QualType checkArithmeticOrEnumera
>return S.Context.getLogicalOperationType();
>  }
>
> +void Sema::CheckPtrComparisonWithNullChar(ExprResult , ExprResult
> ) {
> +  if (!NullE.get()->getType()->isAnyPointerType())
> +return;
> +  int NullValue = PP.isMacroDefined("NULL") ? 0 : 1;
> +  if (!E.get()->getType()->isAnyPointerType() &&
> +  E.get()->isNullPointerConstant(Context,
> + Expr::NPC_ValueDependentIsNotNull) ==
> +Expr::NPCK_ZeroExpression) {
> +if (const auto *CL = dyn_cast(E.get())) {
> +  if (CL->getValue() == 0)
> +Diag(E.get()->getExprLoc(), diag::warn_pointer_compare)
> +<< NullValue
> +<< FixItHint::CreateReplacement(E.get()->getExprLoc(),
> +NullValue ? "NULL" : "(void
> *)0");
> +} else if (const auto *CE = dyn_cast(E.get())) {
> +TypeSourceInfo *TI = CE->getTypeInfoAsWritten();
> +QualType T =
> Context.getCanonicalType(TI->getType()).getUnqualifiedType();
> +if (T == Context.CharTy)
> +  Diag(E.get()->getExprLoc(), diag::warn_pointer_compare)
> +  << NullValue
> +  << FixItHint::CreateReplacement(E.get()->getExprLoc(),
> +  NullValue ? "NULL" : "(void
> *)0");
> +  }
> +  }
> +}
> +
>  // C99 6.5.8, C++ [expr.rel]
>  QualType Sema::CheckCompareOperands(ExprResult , ExprResult ,
>  SourceLocation Loc,
> @@ -10476,6 +10502,10 @@ QualType Sema::CheckCompareOperands(Expr
>}
>
>checkArithmeticNull(*this, LHS, RHS, Loc, /*IsCompare=*/true);
> +  if (!getLangOpts().CPlusPlus && BinaryOperator::isEqualityOp(Opc)) {
> +CheckPtrComparisonWithNullChar(LHS, RHS);
> +CheckPtrComparisonWithNullChar(RHS, LHS);
> +  }
>
>// Handle vector comparisons separately.
>if (LHS.get()->getType()->isVectorType() ||
>
> Added: cfe/trunk/test/Sema/warn-nullchar-nullptr.c
> URL:
> 

r365406 - [cxx2a] P0624R2 fix: only lambdas with no lambda-capture are default-constructible and assignable.

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Jul  8 16:24:41 2019
New Revision: 365406

URL: http://llvm.org/viewvc/llvm-project?rev=365406=rev
Log:
[cxx2a] P0624R2 fix: only lambdas with no lambda-capture are 
default-constructible and assignable.

This is a fix for rG864949 which only disabled default construction and
assignment for lambdas with capture-defaults, where the C++2a draft
disables them for lambdas with any lambda-capture at all.

Patch by Logan Smith!

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

Modified:
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/SemaCXX/cxx2a-lambda-default-ctor-assign.cpp

Modified: cfe/trunk/lib/AST/DeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=365406=365405=365406=diff
==
--- cfe/trunk/lib/AST/DeclCXX.cpp (original)
+++ cfe/trunk/lib/AST/DeclCXX.cpp Mon Jul  8 16:24:41 2019
@@ -645,7 +645,8 @@ bool CXXRecordDecl::lambdaIsDefaultConst
   // C++17 [expr.prim.lambda]p21:
   //   The closure type associated with a lambda-expression has no default
   //   constructor and a deleted copy assignment operator.
-  if (getLambdaCaptureDefault() != LCD_None)
+  if (getLambdaCaptureDefault() != LCD_None || 
+  getLambdaData().NumCaptures != 0)
 return false;
   return getASTContext().getLangOpts().CPlusPlus2a;
 }

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=365406=365405=365406=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Jul  8 16:24:41 2019
@@ -7238,7 +7238,7 @@ bool Sema::ShouldDeleteSpecialMember(CXX
   //   The closure type associated with a lambda-expression has a
   //   deleted (8.4.3) default constructor and a deleted copy
   //   assignment operator.
-  // C++2a adds back these operators if the lambda has no capture-default.
+  // C++2a adds back these operators if the lambda has no lambda-capture.
   if (RD->isLambda() && !RD->lambdaIsDefaultConstructibleAndAssignable() &&
   (CSM == CXXDefaultConstructor || CSM == CXXCopyAssignment)) {
 if (Diagnose)

Modified: cfe/trunk/test/SemaCXX/cxx2a-lambda-default-ctor-assign.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx2a-lambda-default-ctor-assign.cpp?rev=365406=365405=365406=diff
==
--- cfe/trunk/test/SemaCXX/cxx2a-lambda-default-ctor-assign.cpp (original)
+++ cfe/trunk/test/SemaCXX/cxx2a-lambda-default-ctor-assign.cpp Mon Jul  8 
16:24:41 2019
@@ -1,37 +1,22 @@
 // RUN: %clang_cc1 -std=c++2a -verify %s
 
-auto a = []{};
-decltype(a) a2;
-void f(decltype(a) x, decltype(a) y) {
-  x = y;
-  x = static_cast(y);
+void no_capture() {
+  auto x = [] {};
+  decltype(x) y;
+  x = x;
+  x = static_cast(x);
 }
 
-template
-struct X {
-  constexpr X() { T::error; } // expected-error {{'::'}}
-  X(const X&);
-  constexpr X =(const X&) { T::error; } // expected-error {{'::'}}
-  constexpr X =(X&&) { T::error; } // expected-error {{'::'}}
-};
-extern X x;
-auto b = [x = x]{}; // expected-note 3{{in instantiation of}}
-decltype(b) b2; // expected-note {{in implicit default constructor}}
-void f(decltype(b) x, decltype(b) y) {
-  x = y; // expected-note {{in implicit copy assignment}}
-  x = static_cast(y); // expected-note {{in implicit move 
assignment}}
+void capture_default(int i) {
+  auto x = [=] {}; // expected-note 2{{candidate constructor}} expected-note 
2{{lambda expression begins here}}
+  decltype(x) y; // expected-error {{no matching constructor}}
+  x = x; // expected-error {{cannot be assigned}}
+  x = static_cast(x); // expected-error {{cannot be assigned}}
 }
 
-struct Y {
-  Y() = delete; // expected-note {{deleted}}
-  Y(const Y&);
-  Y =(const Y&) = delete; // expected-note 2{{deleted}}
-  Y =(Y&&) = delete;
-};
-extern Y y;
-auto c = [y = y]{}; // expected-note 3{{deleted because}}
-decltype(c) c2; // expected-error {{deleted}}
-void f(decltype(c) x, decltype(c) y) {
-  x = y; // expected-error {{deleted}}
-  x = static_cast(y); // expected-error {{deleted}}
+void explicit_capture(int i) {
+  auto x = [i] {}; // expected-note 2{{candidate constructor}} expected-note 
2{{lambda expression begins here}}
+  decltype(x) y; // expected-error {{no matching constructor}}
+  x = x; // expected-error {{cannot be assigned}}
+  x = static_cast(x); // expected-error {{cannot be assigned}}
 }


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

r363606 - PR42205: DebugInfio: Do not attempt to emit debug info metadata for static member variable template partial specializations

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Jun 17 12:40:52 2019
New Revision: 363606

URL: http://llvm.org/viewvc/llvm-project?rev=363606=rev
Log:
PR42205: DebugInfio: Do not attempt to emit debug info metadata for static 
member variable template partial specializations

Would cause a crash in an attempt to create the type for the still
unresolved 'auto' in the partial specialization (& even without the use
of 'auto', the expression would be value dependent &
crash/assertion-fail there).

Added:
cfe/trunk/test/CodeGenCXX/debug-info-var-template-partial-spec.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=363606=363605=363606=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Jun 17 12:40:52 2019
@@ -1410,6 +1410,9 @@ void CGDebugInfo::CollectRecordFields(
 isa(V))
   continue;
 
+if (isa(V))
+  continue;
+
 // Reuse the existing static member declaration if one exists
 auto MI = StaticDataMemberCache.find(V->getCanonicalDecl());
 if (MI != StaticDataMemberCache.end()) {

Added: cfe/trunk/test/CodeGenCXX/debug-info-var-template-partial-spec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-var-template-partial-spec.cpp?rev=363606=auto
==
--- cfe/trunk/test/CodeGenCXX/debug-info-var-template-partial-spec.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/debug-info-var-template-partial-spec.cpp Mon Jun 
17 12:40:52 2019
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 %s -std=c++14 -debug-info-kind=limited -emit-llvm -o - | 
FileCheck %s
+
+// CHECK: ![[empty:[0-9]+]] = !{}
+
+// CHECK: distinct !DICompositeType(tag: DW_TAG_structure_type, name: "B",
+// CHECK-SAME: elements: ![[empty]]
+
+struct B {
+  template 
+  static const int d = 0;
+  template 
+  static const auto d = d;
+} c;


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

Re: r362856 - DebugInfo: Add support for 'nodebug' attribute on typedefs and alias templates

[David Blaikie via cfe-commits]

Oh, yeah - so the trick here is that you don't just drop the typedef, but
you drop an context for that typedef (if it's not otherwise used) - like
namespaces (probably otherwise used) and classes (in the class of C++ type
traits these aren't generally referenced in ways other than the typedef
they contain).

See http://lists.llvm.org/pipermail/libcxx-commits/2019-June/004697.html for
some stats/usage.



On Mon, Jun 17, 2019 at 11:00 AM  wrote:

> Is this really measurable?  All you're suppressing are the typedef DIEs
> and their names; the DIEs are small, although I admit the names can take
> up space.
> (I'm not really objecting, it's just hard to intuit a big size benefit.)
> --paulr
>
> > -Original Message-
> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of
> > David Blaikie via cfe-commits
> > Sent: Friday, June 07, 2019 8:01 PM
> > To: cfe-commits@lists.llvm.org
> > Subject: r362856 - DebugInfo: Add support for 'nodebug' attribute on
> > typedefs and alias templates
> >
> > Author: dblaikie
> > Date: Fri Jun  7 17:01:21 2019
> > New Revision: 362856
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=362856=rev
> > Log:
> > DebugInfo: Add support for 'nodebug' attribute on typedefs and alias
> > templates
> >
> > Seems like a logical extension to me - and of interest because it might
> > help reduce the debug info size of libc++ by applying this attribute to
> > type traits that have a disproportionate debug info cost compared to the
> > benefit (& possibly harm/confusion) they cause users.
> >
> > Modified:
> > cfe/trunk/include/clang/Basic/Attr.td
> > cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> > cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cpp
> > cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
> > cfe/trunk/test/Sema/attr-nodebug.c
> >
> > Modified: cfe/trunk/include/clang/Basic/Attr.td
> > URL: http://llvm.org/viewvc/llvm-
> >
> project/cfe/trunk/include/clang/Basic/Attr.td?rev=362856=362855=3628
> > 56=diff
> >
> ==
> > 
> > --- cfe/trunk/include/clang/Basic/Attr.td (original)
> > +++ cfe/trunk/include/clang/Basic/Attr.td Fri Jun  7 17:01:21 2019
> > @@ -1434,7 +1434,7 @@ def NoCommon : InheritableAttr {
> >
> >  def NoDebug : InheritableAttr {
> >let Spellings = [GCC<"nodebug">];
> > -  let Subjects = SubjectList<[FunctionLike, ObjCMethod, NonParmVar]>;
> > +  let Subjects = SubjectList<[TypedefName, FunctionLike, ObjCMethod,
> > NonParmVar]>;
> >let Documentation = [NoDebugDocs];
> >  }
> >
> >
> > Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> > URL: http://llvm.org/viewvc/llvm-
> >
> project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=362856=362855=3628
> > 56=diff
> >
> ==
> > 
> > --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Jun  7 17:01:21 2019
> > @@ -1091,15 +1091,18 @@ llvm::DIType *CGDebugInfo::CreateType(co
> >assert(Ty->isTypeAlias());
> >llvm::DIType *Src = getOrCreateType(Ty->getAliasedType(), Unit);
> >
> > +  auto *AliasDecl =
> > +  cast(Ty-
> > >getTemplateName().getAsTemplateDecl())
> > +  ->getTemplatedDecl();
> > +
> > +  if (AliasDecl->hasAttr())
> > +return Src;
> > +
> >SmallString<128> NS;
> >llvm::raw_svector_ostream OS(NS);
> >Ty->getTemplateName().print(OS, getPrintingPolicy(), /*qualified*/
> > false);
> >printTemplateArgumentList(OS, Ty->template_arguments(),
> > getPrintingPolicy());
> >
> > -  auto *AliasDecl =
> > -  cast(Ty-
> > >getTemplateName().getAsTemplateDecl())
> > -  ->getTemplatedDecl();
> > -
> >SourceLocation Loc = AliasDecl->getLocation();
> >return DBuilder.createTypedef(Src, OS.str(), getOrCreateFile(Loc),
> >  getLineNumber(Loc),
> > @@ -1108,15 +,20 @@ llvm::DIType *CGDebugInfo::CreateType(co
> >
> >  llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
> >llvm::DIFile *Unit) {
> > +  llvm::DIType *Underlying =
> > +  getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit);
> > +
> > +  if (Ty->getDecl()->hasAttr())
> > +return Underlyi

r362856 - DebugInfo: Add support for 'nodebug' attribute on typedefs and alias templates

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Jun  7 17:01:21 2019
New Revision: 362856

URL: http://llvm.org/viewvc/llvm-project?rev=362856=rev
Log:
DebugInfo: Add support for 'nodebug' attribute on typedefs and alias templates

Seems like a logical extension to me - and of interest because it might
help reduce the debug info size of libc++ by applying this attribute to
type traits that have a disproportionate debug info cost compared to the
benefit (& possibly harm/confusion) they cause users.

Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cpp
cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
cfe/trunk/test/Sema/attr-nodebug.c

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=362856=362855=362856=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Fri Jun  7 17:01:21 2019
@@ -1434,7 +1434,7 @@ def NoCommon : InheritableAttr {
 
 def NoDebug : InheritableAttr {
   let Spellings = [GCC<"nodebug">];
-  let Subjects = SubjectList<[FunctionLike, ObjCMethod, NonParmVar]>;
+  let Subjects = SubjectList<[TypedefName, FunctionLike, ObjCMethod, 
NonParmVar]>;
   let Documentation = [NoDebugDocs];
 }
 

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=362856=362855=362856=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Jun  7 17:01:21 2019
@@ -1091,15 +1091,18 @@ llvm::DIType *CGDebugInfo::CreateType(co
   assert(Ty->isTypeAlias());
   llvm::DIType *Src = getOrCreateType(Ty->getAliasedType(), Unit);
 
+  auto *AliasDecl =
+  cast(Ty->getTemplateName().getAsTemplateDecl())
+  ->getTemplatedDecl();
+
+  if (AliasDecl->hasAttr())
+return Src;
+
   SmallString<128> NS;
   llvm::raw_svector_ostream OS(NS);
   Ty->getTemplateName().print(OS, getPrintingPolicy(), /*qualified*/ false);
   printTemplateArgumentList(OS, Ty->template_arguments(), getPrintingPolicy());
 
-  auto *AliasDecl =
-  cast(Ty->getTemplateName().getAsTemplateDecl())
-  ->getTemplatedDecl();
-
   SourceLocation Loc = AliasDecl->getLocation();
   return DBuilder.createTypedef(Src, OS.str(), getOrCreateFile(Loc),
 getLineNumber(Loc),
@@ -1108,15 +,20 @@ llvm::DIType *CGDebugInfo::CreateType(co
 
 llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
   llvm::DIFile *Unit) {
+  llvm::DIType *Underlying =
+  getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit);
+
+  if (Ty->getDecl()->hasAttr())
+return Underlying;
+
   // We don't set size information, but do specify where the typedef was
   // declared.
   SourceLocation Loc = Ty->getDecl()->getLocation();
 
   // Typedefs are derived from some other type.
-  return DBuilder.createTypedef(
-  getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit),
-  Ty->getDecl()->getName(), getOrCreateFile(Loc), getLineNumber(Loc),
-  getDeclContextDescriptor(Ty->getDecl()));
+  return DBuilder.createTypedef(Underlying, Ty->getDecl()->getName(),
+getOrCreateFile(Loc), getLineNumber(Loc),
+getDeclContextDescriptor(Ty->getDecl()));
 }
 
 static unsigned getDwarfCC(CallingConv CC) {

Modified: cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cpp?rev=362856=362855=362856=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cpp Fri Jun  7 17:01:21 2019
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -DSETNODEBUG=0 -emit-llvm -debug-info-kind=limited %s -o - 
| FileCheck %s --check-prefix=YESINFO
-// RUN: %clang_cc1 -DSETNODEBUG=1 -emit-llvm -debug-info-kind=limited %s -o - 
| FileCheck %s --check-prefix=NOINFO
+// RUN: %clang_cc1 -DSETNODEBUG=0 -emit-llvm -std=c++14 
-debug-info-kind=limited %s -o - | FileCheck %s --check-prefix=YESINFO
+// RUN: %clang_cc1 -DSETNODEBUG=1 -emit-llvm -std=c++14 
-debug-info-kind=limited %s -o - | FileCheck %s --check-prefix=NOINFO
 
 #if SETNODEBUG
 #define NODEBUG __attribute__((nodebug))
@@ -53,3 +53,15 @@ void func4() {
 // NOINFO-NOT:  !DIGlobalVariable(name: "static_local"
 // YESINFO-DAG: !DILocalVariable(name: "normal_local"
 // NOINFO-NOT:  !DILocalVariable(name: "normal_local"
+
+template 
+using y NODEBUG = int;
+void func5() {
+  NODEBUG typedef int x;
+  x a;
+  y b;
+}
+// YESINFO-DAG: !DIDerivedType(tag: DW_TAG_typedef, name: "x"
+// NOINFO-NOT:  

Re: r362005 - Fix an unused-variable error.

[David Blaikie via cfe-commits]

If this is the only use of 'S', might be better/good to roll the expression
into the assertion?

On Wed, May 29, 2019 at 11:33 AM Haojian Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: hokein
> Date: Wed May 29 11:36:54 2019
> New Revision: 362005
>
> URL: http://llvm.org/viewvc/llvm-project?rev=362005=rev
> Log:
> Fix an unused-variable error.
>
> Modified:
> cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp?rev=362005=362004=362005=diff
>
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp Wed May 29 11:36:54
> 2019
> @@ -248,6 +248,7 @@ void Environment::printJson(raw_ostream
>}
>
>const Stmt *S = I->first.getStmt();
> +  (void)S;
>assert(S != nullptr && "Expected non-null Stmt");
>
>LastI = I;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r361439 - Fix r361428 for Windows buildbots/mangling

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed May 22 14:58:17 2019
New Revision: 361439

URL: http://llvm.org/viewvc/llvm-project?rev=361439=rev
Log:
Fix r361428 for Windows buildbots/mangling

Modified:
cfe/trunk/test/Modules/enum-codegen.cpp

Modified: cfe/trunk/test/Modules/enum-codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/enum-codegen.cpp?rev=361439=361438=361439=diff
==
--- cfe/trunk/test/Modules/enum-codegen.cpp (original)
+++ cfe/trunk/test/Modules/enum-codegen.cpp Wed May 22 14:58:17 2019
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -triple %itanium_abi_triple -fmodules 
-fmodules-cache-path=%t %s -emit-llvm -o - | FileCheck %s
 
-// CHECK: @_Z3varIiE = {{.*}} %union.union_type { i8 1 },
+// CHECK: @{{.*var.*}} = {{.*}} %union.union_type { i8 1 },
 
 #pragma clang module build bar
 module bar {


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

Re: r361428 - Modules: Code generation of enum constants for merged enum definitions

[David Blaikie via cfe-commits]

Ah, sure - thanks for the heads up! Fixed in r361439

On Wed, May 22, 2019 at 2:49 PM Galina Kistanova 
wrote:

> Hello David,
>
> This commit broke the test on the builder:
>
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/17793
> Please have a look?
> . . .
> Failing Tests (1):
> Clang :: Modules/enum-codegen.cpp
>
> The builder was already red and did not send any notifications.
>
> Thanks
>
> Galina
>
> On Wed, May 22, 2019 at 1:33 PM David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dblaikie
>> Date: Wed May 22 13:36:06 2019
>> New Revision: 361428
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=361428=rev
>> Log:
>> Modules: Code generation of enum constants for merged enum definitions
>>
>> Found in a bootstrap of LLVM with implicit modules, resulting in a
>> deadlock of some Orc unit tests with libstdc++ 8.1. An enum was used as
>> part of the implementation of std::recursive_mutex and this bug resulted
>> in the constant initialization of zero instead of the desired non-zero
>> value. => Badness.
>>
>> Richard Smith tells me neither of these fields are necessarily canonical
>> & so using declaresSamEntity is the right solution here (rather than
>> changing both of these Fields to be canonical by construction/from their
>> source)
>>
>> Added:
>> cfe/trunk/test/Modules/enum-codegen.cpp
>> Modified:
>> cfe/trunk/lib/CodeGen/CGExprConstant.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGExprConstant.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprConstant.cpp?rev=361428=361427=361428=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGExprConstant.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGExprConstant.cpp Wed May 22 13:36:06 2019
>> @@ -476,7 +476,7 @@ bool ConstStructBuilder::Build(const APV
>>for (RecordDecl::field_iterator Field = RD->field_begin(),
>> FieldEnd = RD->field_end(); Field != FieldEnd; ++Field,
>> ++FieldNo) {
>>  // If this is a union, skip all the fields that aren't being
>> initialized.
>> -if (RD->isUnion() && Val.getUnionField() != *Field)
>> +if (RD->isUnion() && !declaresSameEntity(Val.getUnionField(),
>> *Field))
>>continue;
>>
>>  // Don't emit anonymous bitfields, they just affect layout.
>>
>> Added: cfe/trunk/test/Modules/enum-codegen.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/enum-codegen.cpp?rev=361428=auto
>>
>> ==
>> --- cfe/trunk/test/Modules/enum-codegen.cpp (added)
>> +++ cfe/trunk/test/Modules/enum-codegen.cpp Wed May 22 13:36:06 2019
>> @@ -0,0 +1,36 @@
>> +// RUN: rm -rf %t
>> +// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t %s -emit-llvm -o -
>> | FileCheck %s
>> +
>> +// CHECK: @_Z3varIiE = {{.*}} %union.union_type { i8 1 },
>> +
>> +#pragma clang module build bar
>> +module bar {
>> +  header "bar.h" { size 40 mtime 0 }
>> +  export *
>> +}
>> +#pragma clang module contents
>> +#pragma clang module begin bar
>> +union union_type {
>> +  char h{1};
>> +};
>> +#pragma clang module end
>> +#pragma clang module endbuild
>> +#pragma clang module build foo
>> +module foo {
>> +  header "foo.h" { size 97 mtime 0 }
>> +  export *
>> +}
>> +#pragma clang module contents
>> +#pragma clang module begin foo
>> +union union_type {
>> +  char h{1};
>> +};
>> +#pragma clang module import bar
>> +template
>> +union_type var;
>> +#pragma clang module end
>> +#pragma clang module endbuild
>> +#pragma clang module import foo
>> +int main() {
>> +  (void);
>> +}
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r361428 - Modules: Code generation of enum constants for merged enum definitions

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed May 22 13:36:06 2019
New Revision: 361428

URL: http://llvm.org/viewvc/llvm-project?rev=361428=rev
Log:
Modules: Code generation of enum constants for merged enum definitions

Found in a bootstrap of LLVM with implicit modules, resulting in a
deadlock of some Orc unit tests with libstdc++ 8.1. An enum was used as
part of the implementation of std::recursive_mutex and this bug resulted
in the constant initialization of zero instead of the desired non-zero
value. => Badness.

Richard Smith tells me neither of these fields are necessarily canonical
& so using declaresSamEntity is the right solution here (rather than
changing both of these Fields to be canonical by construction/from their
source)

Added:
cfe/trunk/test/Modules/enum-codegen.cpp
Modified:
cfe/trunk/lib/CodeGen/CGExprConstant.cpp

Modified: cfe/trunk/lib/CodeGen/CGExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprConstant.cpp?rev=361428=361427=361428=diff
==
--- cfe/trunk/lib/CodeGen/CGExprConstant.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprConstant.cpp Wed May 22 13:36:06 2019
@@ -476,7 +476,7 @@ bool ConstStructBuilder::Build(const APV
   for (RecordDecl::field_iterator Field = RD->field_begin(),
FieldEnd = RD->field_end(); Field != FieldEnd; ++Field, ++FieldNo) {
 // If this is a union, skip all the fields that aren't being initialized.
-if (RD->isUnion() && Val.getUnionField() != *Field)
+if (RD->isUnion() && !declaresSameEntity(Val.getUnionField(), *Field))
   continue;
 
 // Don't emit anonymous bitfields, they just affect layout.

Added: cfe/trunk/test/Modules/enum-codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/enum-codegen.cpp?rev=361428=auto
==
--- cfe/trunk/test/Modules/enum-codegen.cpp (added)
+++ cfe/trunk/test/Modules/enum-codegen.cpp Wed May 22 13:36:06 2019
@@ -0,0 +1,36 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t %s -emit-llvm -o - | 
FileCheck %s
+
+// CHECK: @_Z3varIiE = {{.*}} %union.union_type { i8 1 },
+
+#pragma clang module build bar
+module bar {
+  header "bar.h" { size 40 mtime 0 }
+  export *
+}
+#pragma clang module contents
+#pragma clang module begin bar
+union union_type {
+  char h{1};
+};
+#pragma clang module end
+#pragma clang module endbuild
+#pragma clang module build foo
+module foo {
+  header "foo.h" { size 97 mtime 0 }
+  export *
+}
+#pragma clang module contents
+#pragma clang module begin foo
+union union_type {
+  char h{1};
+};
+#pragma clang module import bar
+template
+union_type var;
+#pragma clang module end
+#pragma clang module endbuild
+#pragma clang module import foo
+int main() {
+  (void);
+}


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

Re: r359960 - Reduce amount of work ODR hashing does.

[David Blaikie via cfe-commits]

On Tue, May 7, 2019 at 7:40 PM Richard Trieu  wrote:
>
>
> From: David Blaikie 
> Date: Mon, May 6, 2019 at 4:39 PM
> To: Richard Trieu
> Cc: cfe-commits
>
>> On Mon, May 6, 2019 at 4:24 PM Richard Trieu  wrote:
>> >
>> > There was no cycle for this crash.
>>
>> Oh, yeah, didn't mean to imply there were - but that a system designed
>> to prevent cycles might also be used/help prevent redundant work like
>> this.
>>
>> > What happened is that an exponential runtime is reduced to a linear 
>> > runtime.  Without this revision, ODR hashing would have worked if the 
>> > machine had enough memory and the user waited long enough.
>> >
>> > void foo(int a, int b) {}
>> > When computing the ODR hash for function foo, it will visit the type int 
>> > twice, once per parameter.  In general, re-visiting types shouldn't be a 
>> > problem, and in most cases, should be pretty fast.
>>
>> It does mean some potentially problematic worst-case situations where
>> non-trivial types are mentioned more than once (eg: if, instead of
>> int, it was a complex struct type - it wouldn't cycle, but it would do
>> all that work twice (or many more times if it appears in more places
>> in the entity being hashed)
>
>
> See below in the answer to DWARF.  ODRHash did have a system, it worked for a 
> while until it didn't, and was since removed.
>>
>>
>> > class S {
>> >   void bar(S* s);
>> > };
>> > There's actually two ways to visit the Decl behind S, 
>> > ODR::AddCXXRecordDecl and ODR::AddDecl.  When computing the ODR hash of S, 
>> > ODR::AddCXXRecordDecl is used for a deep dive into the AST of S.  When 
>> > reaching S another way, (via FunctionDecl bar, parameter s, PointerType 
>> > S*, RecordType S), then the CXXRecordDecl gets processed through 
>> > ODR::AddDecl, which only processes enough information to identify S, but 
>> > not any of its deeper details.  This allows self-reference without 
>> > introducing cycles.
>>
>> Ah, OK - specifically to break the cycle.
>>
>> So the ODR hash of the function "void f(S*)" doesn't hash the
>> implementation of S, (it uses AddDecl, not AddCXXRecordDecl)? But if
>> it were "void f(S)" it would hash S? What about a member function that
>> takes a parameter by value? ("struct S { void bar(S); }")
>
>
> The three functions AddCXXRecordDecl, AddFunctionDecl, and AddEnumDecl are 
> the entry points from outside to use the ODRHash and nothing inside ODRHash 
> will call these functions.  That means hashing "class S {};"  
> AddCXXRecordDecl is called with S.  Every other example, "void f(S)", "void 
> bar(S);", etc will be called into AddDecl.  The next question is probably, 
> how do you know if two functions "void f(S)" in two files refer to same class 
> S?  The answer is, ODRHash doesn't know and doesn't care.  But when Clang 
> imports both "void f(S)" functions, it will also import both S classes.  
> Since Clang checks, ODRHash doesn't need to.

Clang checks this by entering ODRHash separately (via AddCXXRecordDecl).

So it's sort of an inductive proof based on the assumptions of the ODR
- >"void f(S)" is ODR compliant if S is ODR compliant<, etc.

That makes sense, though still does mean potentially a lot of
redundant work in cases like this bug, but never circular work -
because anonymous types can't form cycles (because they have no name
to do that).

I think it still /might/ be worth using a type stack/hash so there's
never redundant work, even if it's non-circular work.

>>
>>
>> > I think it would be possible to add some checks in debug mode to catch 
>> > cycles.  I'm not sure it can detect redundant work as the function foo 
>> > example above shows that visiting the same types over multiple times is 
>> > expected.
>>
>> Both for efficiency and to avoid these cycles, it might be worthwhile
>> to consider a different way to resolve this issue
>>
>> The reason these ideas come to my mind is that DWARF has a type hash
>> that works in a different way to avoid cycles and redundant work.
>>
>> http://dwarfstd.org/doc/DWARF5.pdf - 7.32, Type Signature Computation.
>> It works by assigning every type a number when it's first encountered
>> (even before its contents are hashed), and if it's ever encountered
>> again, hash the number again rather than going back into hashing the
>> implementation.
>>
> Originally, ODR hashing did have a system similar to what DWARF had.  
> Relevant portions of 7.32 are 1, 4.a, and 4.b.  Basically, maintain a list of 
> Type's, when first visiting a Type, add it to the list and process it, and if 
> the Type is ever seen again, use the index number instead reprocessing.  
> Worked well, and then the AST had a small change in it where now we needed 
> two different Type's to hash to the same thing.  
> https://reviews.llvm.org/rL335853 ripped this out.  It's possible to replace 
> it, but it needs to be better than what we currently have.

Ah - I think I understand/see. The uniqueness of Type*s is based on
the profile hashing and it varies in 

Re: r360452 - Replace 'REQUIRES: nozlib' with '!zlib' because we don't need two ways

[David Blaikie via cfe-commits]

Fair enough - since they're already there I don't feel super serious
about converging on one (though I probably wouldn't've been in favor
of adding a second spelling at the point it was proposed).

On Tue, May 14, 2019 at 8:03 AM  wrote:
>
> There's no practical difference.  I view it as a matter of documentation of 
> intent, see my commit log comment for r360603.
>
> Arguably we could eliminate UNSUPPORTED and move all the expressions into 
> REQUIRES (appropriately negated), but I'm not sure that's a net win for 
> readability.
>
> --paulr
>
>
>
> From: David Blaikie [mailto:dblai...@gmail.com]
> Sent: Monday, May 13, 2019 10:48 AM
> To: Robinson, Paul
> Cc: cfe-commits
> Subject: Re: r360452 - Replace 'REQUIRES: nozlib' with '!zlib' because we 
> don't need two ways
>
>
>
> What's the practical difference between "UNSUPPORTED: foo" and "REQUIRES: 
> !foo"? (I see some of the fixes you've made go one way, some the other way)
>
>
>
> On Fri, May 10, 2019 at 11:30 AM Paul Robinson via cfe-commits 
>  wrote:
>
> Author: probinson
> Date: Fri May 10 11:32:53 2019
> New Revision: 360452
>
> URL: http://llvm.org/viewvc/llvm-project?rev=360452=rev
> Log:
> Replace 'REQUIRES: nozlib' with '!zlib' because we don't need two ways
> to say the same thing.
>
> Modified:
> cfe/trunk/test/Driver/nozlibcompress.c
>
> Modified: cfe/trunk/test/Driver/nozlibcompress.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/nozlibcompress.c?rev=360452=360451=360452=diff
> ==
> --- cfe/trunk/test/Driver/nozlibcompress.c (original)
> +++ cfe/trunk/test/Driver/nozlibcompress.c Fri May 10 11:32:53 2019
> @@ -1,4 +1,4 @@
> -// REQUIRES: nozlib
> +// REQUIRES: !zlib
>
>  // RUN: %clang -### -fintegrated-as -gz -c %s 2>&1 | FileCheck %s 
> -check-prefix CHECK-WARN
>  // RUN: %clang -### -fintegrated-as -gz=none -c %s 2>&1 | FileCheck 
> -allow-empty -check-prefix CHECK-NOWARN %s
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r360195 - -frewrite-imports: Add support for wildcard rules in umbrella modules with

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue May  7 14:38:51 2019
New Revision: 360195

URL: http://llvm.org/viewvc/llvm-project?rev=360195=rev
Log:
-frewrite-imports: Add support for wildcard rules in umbrella modules with

This trips over a few other limitations, but in the interests of incremental 
development I'm starting here & I'll look at the issues with -verify and 
filesystem checks (the fact that the behavior depends on the existence of a 
'foo' directory even though it shouldn't need it), etc.

Reviewers: rsmith

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

Added:
cfe/trunk/test/Modules/preprocess-umbrella.cpp
Modified:
cfe/trunk/include/clang/Basic/Module.h
cfe/trunk/lib/Basic/Module.cpp
cfe/trunk/lib/Lex/Pragma.cpp

Modified: cfe/trunk/include/clang/Basic/Module.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Module.h?rev=360195=360194=360195=diff
==
--- cfe/trunk/include/clang/Basic/Module.h (original)
+++ cfe/trunk/include/clang/Basic/Module.h Tue May  7 14:38:51 2019
@@ -541,6 +541,7 @@ public:
   ///
   /// \returns The submodule if found, or NULL otherwise.
   Module *findSubmodule(StringRef Name) const;
+  Module *findOrInferSubmodule(StringRef Name);
 
   /// Determine whether the specified module would be visible to
   /// a lookup at the end of this module.

Modified: cfe/trunk/lib/Basic/Module.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Module.cpp?rev=360195=360194=360195=diff
==
--- cfe/trunk/lib/Basic/Module.cpp (original)
+++ cfe/trunk/lib/Basic/Module.cpp Tue May  7 14:38:51 2019
@@ -321,6 +321,21 @@ Module *Module::findSubmodule(StringRef
   return SubModules[Pos->getValue()];
 }
 
+Module *Module::findOrInferSubmodule(StringRef Name) {
+  llvm::StringMap::const_iterator Pos = SubModuleIndex.find(Name);
+  if (Pos != SubModuleIndex.end())
+return SubModules[Pos->getValue()];
+  if (!InferSubmodules)
+return nullptr;
+  Module *Result = new Module(Name, SourceLocation(), this, false, 
InferExplicitSubmodules, 0);
+  Result->InferExplicitSubmodules = InferExplicitSubmodules;
+  Result->InferSubmodules = InferSubmodules;
+  Result->InferExportWildcard = InferExportWildcard;
+  if (Result->InferExportWildcard)
+Result->Exports.push_back(Module::ExportDecl(nullptr, true));
+  return Result;
+}
+
 void Module::getExportedModules(SmallVectorImpl ) const {
   // All non-explicit submodules are exported.
   for (std::vector::const_iterator I = SubModules.begin(),

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=360195=360194=360195=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Tue May  7 14:38:51 2019
@@ -1584,16 +1584,15 @@ struct PragmaModuleBeginHandler : public
 
 // Find the module we're entering. We require that a module map for it
 // be loaded or implicitly loadable.
-// FIXME: We could create the submodule here. We'd need to know whether
-// it's supposed to be explicit, but not much else.
-Module *M = PP.getHeaderSearchInfo().lookupModule(Current);
+auto  = PP.getHeaderSearchInfo();
+Module *M = HSI.lookupModule(Current);
 if (!M) {
   PP.Diag(ModuleName.front().second,
   diag::err_pp_module_begin_no_module_map) << Current;
   return;
 }
 for (unsigned I = 1; I != ModuleName.size(); ++I) {
-  auto *NewM = M->findSubmodule(ModuleName[I].first->getName());
+  auto *NewM = M->findOrInferSubmodule(ModuleName[I].first->getName());
   if (!NewM) {
 PP.Diag(ModuleName[I].second, diag::err_pp_module_begin_no_submodule)
   << M->getFullModuleName() << ModuleName[I].first;

Added: cfe/trunk/test/Modules/preprocess-umbrella.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/preprocess-umbrella.cpp?rev=360195=auto
==
--- cfe/trunk/test/Modules/preprocess-umbrella.cpp (added)
+++ cfe/trunk/test/Modules/preprocess-umbrella.cpp Tue May  7 14:38:51 2019
@@ -0,0 +1,36 @@
+// FIXME: The standalone module still seems to cause clang to want to test for
+// the existence of a 'foo' directory:
+// RUN: mkdir %t
+// RUN: cp %s %t
+// RUN: mkdir %t/foo
+// RUN: cd %t
+// RUN: not %clang_cc1 -fmodules -fsyntax-only %s 2>&1 | FileCheck %s
+
+// CHECK: error: no matching function for call to 'foo'
+// CHECK: note: candidate function not viable: requires 0 arguments, but 1 was 
provided
+
+// FIXME: This should use -verify, but it seems it doesn't hook up the
+// SourceManager correctly or something, and the foo.h note gets attributed to
+// the synthetic module translation unit "foo.map Line 2:...".
+// %clang_cc1 -fmodules 

Re: r359960 - Reduce amount of work ODR hashing does.

[David Blaikie via cfe-commits]

On Mon, May 6, 2019 at 4:24 PM Richard Trieu  wrote:
>
> There was no cycle for this crash.

Oh, yeah, didn't mean to imply there were - but that a system designed
to prevent cycles might also be used/help prevent redundant work like
this.

> What happened is that an exponential runtime is reduced to a linear runtime.  
> Without this revision, ODR hashing would have worked if the machine had 
> enough memory and the user waited long enough.
>
> void foo(int a, int b) {}
> When computing the ODR hash for function foo, it will visit the type int 
> twice, once per parameter.  In general, re-visiting types shouldn't be a 
> problem, and in most cases, should be pretty fast.

It does mean some potentially problematic worst-case situations where
non-trivial types are mentioned more than once (eg: if, instead of
int, it was a complex struct type - it wouldn't cycle, but it would do
all that work twice (or many more times if it appears in more places
in the entity being hashed)

> class S {
>   void bar(S* s);
> };
> There's actually two ways to visit the Decl behind S, ODR::AddCXXRecordDecl 
> and ODR::AddDecl.  When computing the ODR hash of S, ODR::AddCXXRecordDecl is 
> used for a deep dive into the AST of S.  When reaching S another way, (via 
> FunctionDecl bar, parameter s, PointerType S*, RecordType S), then the 
> CXXRecordDecl gets processed through ODR::AddDecl, which only processes 
> enough information to identify S, but not any of its deeper details.  This 
> allows self-reference without introducing cycles.

Ah, OK - specifically to break the cycle.

So the ODR hash of the function "void f(S*)" doesn't hash the
implementation of S, (it uses AddDecl, not AddCXXRecordDecl)? But if
it were "void f(S)" it would hash S? What about a member function that
takes a parameter by value? ("struct S { void bar(S); }")

> I think it would be possible to add some checks in debug mode to catch 
> cycles.  I'm not sure it can detect redundant work as the function foo 
> example above shows that visiting the same types over multiple times is 
> expected.

Both for efficiency and to avoid these cycles, it might be worthwhile
to consider a different way to resolve this issue

The reason these ideas come to my mind is that DWARF has a type hash
that works in a different way to avoid cycles and redundant work.

http://dwarfstd.org/doc/DWARF5.pdf - 7.32, Type Signature Computation.
It works by assigning every type a number when it's first encountered
(even before its contents are hashed), and if it's ever encountered
again, hash the number again rather than going back into hashing the
implementation.

This way no type is hashed more than once, avoiding cycles and redundant work.

>
>
>
> From: David Blaikie 
> Date: Sat, May 4, 2019 at 9:06 AM
> To: Richard Trieu
> Cc: cfe-commits
>
>> Does the ODR hashing have some sort of cycle breaking infrastructure -
>> so that if the same type is seen more than once (eg: classes have
>> members that have pointers back to the outer class type, etc) they
>> don't cause indefinite cycles? Should that infrastructure have caught
>> these cases & avoided the redundant work?
>>
>> I'm curious to understand better how these things work/overlap/or don't.
>>
>> On Fri, May 3, 2019 at 9:20 PM Richard Trieu via cfe-commits
>>  wrote:
>> >
>> > Author: rtrieu
>> > Date: Fri May  3 21:22:33 2019
>> > New Revision: 359960
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=359960=rev
>> > Log:
>> > Reduce amount of work ODR hashing does.
>> >
>> > When a FunctionProtoType is in the original type in a DecayedType, the 
>> > decayed
>> > type is a PointerType which points back the original FunctionProtoType.  
>> > The
>> > visitor for ODRHashing will attempt to process both Type's, doing double 
>> > work.
>> > By chaining together multiple DecayedType's and FunctionProtoType's, this 
>> > would
>> > result in 2^N Type's visited only N DecayedType's and N FunctionProtoType's
>> > exsit.  Another bug where VisitDecayedType and VisitAdjustedType did
>> > redundant work doubled the work at each level, giving 4^N Type's visited.  
>> > This
>> > patch removed the double work and detects when a FunctionProtoType decays 
>> > to
>> > itself to only check the Type once.  This lowers the exponential runtime to
>> > linear runtime.  Fixes https://bugs.llvm.org/show_bug.cgi?id=41625
>> >
>> > Modified:
>> > cfe/trunk/lib/AST/ODRHash.cpp
>> > cfe/trunk/test/Modules/odr_hash.cpp
>> >
>> > Modified: cfe/trunk/lib/AST/ODRHash.cpp
>> > URL: 
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ODRHash.cpp?rev=359960=359959=359960=diff
>> > ==
>> > --- cfe/trunk/lib/AST/ODRHash.cpp (original)
>> > +++ cfe/trunk/lib/AST/ODRHash.cpp Fri May  3 21:22:33 2019
>> > @@ -703,14 +703,36 @@ public:
>> >void VisitType(const Type *T) {}
>> >
>> >void VisitAdjustedType(const AdjustedType *T) {
>> > -

Re: r359960 - Reduce amount of work ODR hashing does.

[David Blaikie via cfe-commits]

Does the ODR hashing have some sort of cycle breaking infrastructure -
so that if the same type is seen more than once (eg: classes have
members that have pointers back to the outer class type, etc) they
don't cause indefinite cycles? Should that infrastructure have caught
these cases & avoided the redundant work?

I'm curious to understand better how these things work/overlap/or don't.

On Fri, May 3, 2019 at 9:20 PM Richard Trieu via cfe-commits
 wrote:
>
> Author: rtrieu
> Date: Fri May  3 21:22:33 2019
> New Revision: 359960
>
> URL: http://llvm.org/viewvc/llvm-project?rev=359960=rev
> Log:
> Reduce amount of work ODR hashing does.
>
> When a FunctionProtoType is in the original type in a DecayedType, the decayed
> type is a PointerType which points back the original FunctionProtoType.  The
> visitor for ODRHashing will attempt to process both Type's, doing double work.
> By chaining together multiple DecayedType's and FunctionProtoType's, this 
> would
> result in 2^N Type's visited only N DecayedType's and N FunctionProtoType's
> exsit.  Another bug where VisitDecayedType and VisitAdjustedType did
> redundant work doubled the work at each level, giving 4^N Type's visited.  
> This
> patch removed the double work and detects when a FunctionProtoType decays to
> itself to only check the Type once.  This lowers the exponential runtime to
> linear runtime.  Fixes https://bugs.llvm.org/show_bug.cgi?id=41625
>
> Modified:
> cfe/trunk/lib/AST/ODRHash.cpp
> cfe/trunk/test/Modules/odr_hash.cpp
>
> Modified: cfe/trunk/lib/AST/ODRHash.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ODRHash.cpp?rev=359960=359959=359960=diff
> ==
> --- cfe/trunk/lib/AST/ODRHash.cpp (original)
> +++ cfe/trunk/lib/AST/ODRHash.cpp Fri May  3 21:22:33 2019
> @@ -703,14 +703,36 @@ public:
>void VisitType(const Type *T) {}
>
>void VisitAdjustedType(const AdjustedType *T) {
> -AddQualType(T->getOriginalType());
> -AddQualType(T->getAdjustedType());
> +QualType Original = T->getOriginalType();
> +QualType Adjusted = T->getAdjustedType();
> +
> +// The original type and pointee type can be the same, as in the case of
> +// function pointers decaying to themselves.  Set a bool and only process
> +// the type once, to prevent doubling the work.
> +SplitQualType split = Adjusted.split();
> +if (auto Pointer = dyn_cast(split.Ty)) {
> +  if (Pointer->getPointeeType() == Original) {
> +Hash.AddBoolean(true);
> +ID.AddInteger(split.Quals.getAsOpaqueValue());
> +AddQualType(Original);
> +VisitType(T);
> +return;
> +  }
> +}
> +
> +// The original type and pointee type are different, such as in the case
> +// of a array decaying to an element pointer.  Set a bool to false and
> +// process both types.
> +Hash.AddBoolean(false);
> +AddQualType(Original);
> +AddQualType(Adjusted);
> +
>  VisitType(T);
>}
>
>void VisitDecayedType(const DecayedType *T) {
> -AddQualType(T->getDecayedType());
> -AddQualType(T->getPointeeType());
> +// getDecayedType and getPointeeType are derived from getAdjustedType
> +// and don't need to be separately processed.
>  VisitAdjustedType(T);
>}
>
>
> Modified: cfe/trunk/test/Modules/odr_hash.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/odr_hash.cpp?rev=359960=359959=359960=diff
> ==
> --- cfe/trunk/test/Modules/odr_hash.cpp (original)
> +++ cfe/trunk/test/Modules/odr_hash.cpp Fri May  3 21:22:33 2019
> @@ -4587,6 +4587,43 @@ int num = bar();
>  #endif
>  }
>
> +namespace FunctionProtoTypeDecay {
> +#if defined(FIRST)
> +struct S1 {
> +  struct X {};
> +  using Y = X(X());
> +};
> +#elif defined(SECOND)
> +struct S1 {
> +  struct X {};
> +  using Y = X(X(X()));
> +};
> +#else
> +S1 s1;
> +// expected-error@first.h:* {{'FunctionProtoTypeDecay::S1::Y' from module 
> 'FirstModule' is not present in definition of 'FunctionProtoTypeDecay::S1' in 
> module 'SecondModule'}}
> +// expected-note@second.h:* {{declaration of 'Y' does not match}}
> +#endif
> +
> +#if defined(FIRST)
> +struct S2 {
> +  struct X {};
> +  using Y =
> +  X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(
> +  X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(
> +  X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(
> +  X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(X(
> +  
> +  
> +  
> +  ;
> +};
> +#elif defined(SECOND)
> +#else
> +S2 s2;
> +#endif
> +
> +}
> +
>  // Keep macros contained to one file.
>  #ifdef FIRST
>  #undef FIRST
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing 

r359913 - Remove else-after-return

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri May  3 11:11:31 2019
New Revision: 359913

URL: http://llvm.org/viewvc/llvm-project?rev=359913=rev
Log:
Remove else-after-return

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=359913=359912=359913=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Fri May  3 11:11:31 2019
@@ -8269,17 +8269,16 @@ bool IntExprEvaluator::VisitBuiltinCallE
 
   case Builtin::BI__builtin_constant_p: {
 const Expr *Arg = E->getArg(0);
-if (EvaluateBuiltinConstantP(Info, Arg)) {
+if (EvaluateBuiltinConstantP(Info, Arg))
   return Success(true, E);
-} else if (Info.InConstantContext || Arg->HasSideEffects(Info.Ctx)) {
+if (Info.InConstantContext || Arg->HasSideEffects(Info.Ctx)) {
   // Outside a constant context, eagerly evaluate to false in the presence
   // of side-effects in order to avoid -Wunsequenced false-positives in
   // a branch on __builtin_constant_p(expr).
   return Success(false, E);
-} else {
-  Info.FFDiag(E, diag::note_invalid_subexpr_in_const_expr);
-  return false;
 }
+Info.FFDiag(E, diag::note_invalid_subexpr_in_const_expr);
+return false;
   }
 
   case Builtin::BI__builtin_is_constant_evaluated:


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

r359854 - SemaOverload: Complete candidates before emitting the error, to ensure diagnostics emitted (or suppressed) during completion don't interfere with the overload notes

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu May  2 17:44:50 2019
New Revision: 359854

URL: http://llvm.org/viewvc/llvm-project?rev=359854=rev
Log:
SemaOverload: Complete candidates before emitting the error, to ensure 
diagnostics emitted (or suppressed) during completion don't interfere with the 
overload notes

Because diagnostics and their notes are not connected at the API level,
if the error message for an overload is emitted, then the overload
candidates are completed - if a diagnostic is emitted during that work,
the notes related to overload candidates would be attached to the latter
diagnostic, not the original error. Sort of worse, if the latter
diagnostic was disabled, the notes are disabled.

Reviewers: rsmith

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

Added:
cfe/trunk/test/SemaCXX/overload-template.cpp
Modified:
cfe/trunk/include/clang/AST/TemplateName.h
cfe/trunk/include/clang/Basic/PartialDiagnostic.h
cfe/trunk/include/clang/Sema/Overload.h
cfe/trunk/lib/AST/TemplateName.cpp
cfe/trunk/lib/Sema/SemaCast.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp

Modified: cfe/trunk/include/clang/AST/TemplateName.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TemplateName.h?rev=359854=359853=359854=diff
==
--- cfe/trunk/include/clang/AST/TemplateName.h (original)
+++ cfe/trunk/include/clang/AST/TemplateName.h Thu May  2 17:44:50 2019
@@ -31,6 +31,7 @@ class NamedDecl;
 class NestedNameSpecifier;
 enum OverloadedOperatorKind : int;
 class OverloadedTemplateStorage;
+class PartialDiagnostic;
 struct PrintingPolicy;
 class QualifiedTemplateName;
 class SubstTemplateTemplateParmPackStorage;
@@ -319,6 +320,8 @@ public:
 /// into a diagnostic with <<.
 const DiagnosticBuilder <<(const DiagnosticBuilder ,
 TemplateName N);
+const PartialDiagnostic <<(const PartialDiagnostic ,
+TemplateName N);
 
 /// A structure for storing the information associated with a
 /// substituted template template parameter.

Modified: cfe/trunk/include/clang/Basic/PartialDiagnostic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/PartialDiagnostic.h?rev=359854=359853=359854=diff
==
--- cfe/trunk/include/clang/Basic/PartialDiagnostic.h (original)
+++ cfe/trunk/include/clang/Basic/PartialDiagnostic.h Thu May  2 17:44:50 2019
@@ -16,6 +16,7 @@
 #define LLVM_CLANG_BASIC_PARTIALDIAGNOSTIC_H
 
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/PartialDiagnostic.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/SmallVector.h"

Modified: cfe/trunk/include/clang/Sema/Overload.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Overload.h?rev=359854=359853=359854=diff
==
--- cfe/trunk/include/clang/Sema/Overload.h (original)
+++ cfe/trunk/include/clang/Sema/Overload.h Thu May  2 17:44:50 2019
@@ -961,13 +961,23 @@ class Sema;
 OverloadingResult BestViableFunction(Sema , SourceLocation Loc,
  OverloadCandidateSet::iterator& Best);
 
-void NoteCandidates(Sema ,
-OverloadCandidateDisplayKind OCD,
-ArrayRef Args,
+SmallVector CompleteCandidates(
+Sema , OverloadCandidateDisplayKind OCD, ArrayRef Args,
+SourceLocation OpLoc = SourceLocation(),
+llvm::function_ref Filter =
+[](OverloadCandidate &) { return true; });
+
+void NoteCandidates(
+PartialDiagnosticAt PA, Sema , OverloadCandidateDisplayKind OCD,
+ArrayRef Args, StringRef Opc = "",
+SourceLocation Loc = SourceLocation(),
+llvm::function_ref Filter =
+[](OverloadCandidate &) { return true; });
+
+void NoteCandidates(Sema , ArrayRef Args,
+ArrayRef Cands,
 StringRef Opc = "",
-SourceLocation Loc = SourceLocation(),
-llvm::function_ref Filter =
-  [](OverloadCandidate&) { return true; });
+SourceLocation OpLoc = SourceLocation());
   };
 
   bool isBetterOverloadCandidate(Sema ,

Modified: cfe/trunk/lib/AST/TemplateName.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TemplateName.cpp?rev=359854=359853=359854=diff
==
--- cfe/trunk/lib/AST/TemplateName.cpp (original)
+++ cfe/trunk/lib/AST/TemplateName.cpp Thu May  2 17:44:50 2019
@@ -250,6 +250,20 @@ const DiagnosticBuilder ::operator
   return DB << NameStr;
 }
 
+const 

r359800 - Do not warn on switches over enums that do not use [[maybe_unused]] enumerators

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu May  2 09:30:49 2019
New Revision: 359800

URL: http://llvm.org/viewvc/llvm-project?rev=359800=rev
Log:
Do not warn on switches over enums that do not use [[maybe_unused]] enumerators

PR36231, [dcl.attr.unused]p3

Reviewers: aaron.ballman

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

Modified:
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.unused/p3.cpp

Modified: cfe/trunk/lib/Sema/SemaStmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaStmt.cpp?rev=359800=359799=359800=diff
==
--- cfe/trunk/lib/Sema/SemaStmt.cpp (original)
+++ cfe/trunk/lib/Sema/SemaStmt.cpp Thu May  2 09:30:49 2019
@@ -1162,6 +1162,9 @@ Sema::ActOnFinishSwitchStmt(SourceLocati
   break;
 }
 
+if (EI->second->hasAttr())
+  continue;
+
 // Drop unneeded case values
 while (CI != CaseVals.end() && CI->first < EI->first)
   CI++;

Modified: cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.unused/p3.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.unused/p3.cpp?rev=359800=359799=359800=diff
==
--- cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.unused/p3.cpp (original)
+++ cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.unused/p3.cpp Thu May  2 
09:30:49 2019
@@ -5,9 +5,17 @@ static_assert(__has_cpp_attribute(maybe_
 
 struct [[maybe_unused]] S {};
 
+enum E1 {
+  EnumVal [[maybe_unused]],
+  UsedEnumVal,
+};
+
 void f() {
   int x; // expected-warning {{unused variable}}
   typedef int I; // expected-warning {{unused typedef 'I'}}
+  E1 e;
+  switch (e) { // expected-warning {{enumeration value 'UsedEnumVal' not 
handled in switch}}
+  }
 
   // Should not warn about these due to not being used.
   [[maybe_unused]] int y;
@@ -17,10 +25,16 @@ void f() {
   S s;
   maybe_unused_int test;
   y = 12;
+  switch (e) {
+  case UsedEnumVal:
+break;
+  }
 }
 
 #ifdef EXT
 // expected-warning@6 {{use of the 'maybe_unused' attribute is a C++17 
extension}}
-// expected-warning@13 {{use of the 'maybe_unused' attribute is a C++17 
extension}}
-// expected-warning@14 {{use of the 'maybe_unused' attribute is a C++17 
extension}}
+// expected-warning@9 {{use of the 'maybe_unused' attribute is a C++17 
extension}}
+// expected-warning@9 {{attributes on an enumerator declaration are a C++17 
extension}}
+// expected-warning@21 {{use of the 'maybe_unused' attribute is a C++17 
extension}}
+// expected-warning@22 {{use of the 'maybe_unused' attribute is a C++17 
extension}}
 #endif


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

r359235 - Skip type units/type uniquing when we know we're only emitting the type once (vtable-based emission when triggered by a strong vtable, with -fno-standalone-debug)

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Apr 25 13:05:47 2019
New Revision: 359235

URL: http://llvm.org/viewvc/llvm-project?rev=359235=rev
Log:
Skip type units/type uniquing when we know we're only emitting the type once 
(vtable-based emission when triggered by a strong vtable, with 
-fno-standalone-debug)

(this would regress size without a corresponding LLVM change that avoids
putting other user defined types inside type units when they aren't in
their own type units - instead emitting declarations inside the type
unit and a definition in the primary CU)

Reviewers: aprantl

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

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-class.cpp
cfe/trunk/test/Modules/ExtDebugInfo.cpp
cfe/trunk/test/Modules/ModuleDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=359235=359234=359235=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Apr 25 13:05:47 2019
@@ -915,6 +915,11 @@ static SmallString<256> getTypeIdentifie
 
   if (!needsTypeIdentifier(TD, CGM, TheCU))
 return Identifier;
+  if (const auto *RD = dyn_cast(TD))
+if (RD->getDefinition())
+  if (RD->isDynamicClass() &&
+  CGM.getVTableLinkage(RD) == llvm::GlobalValue::ExternalLinkage)
+return Identifier;
 
   // TODO: This is using the RTTI name. Is there a better way to get
   // a unique string for a type?

Modified: cfe/trunk/test/CodeGenCXX/debug-info-class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-class.cpp?rev=359235=359234=359235=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-class.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-class.cpp Thu Apr 25 13:05:47 2019
@@ -57,6 +57,11 @@ struct I : virtual H {};
 struct J : I {};
 J j;
 
+struct K {
+  virtual void func() {
+  }
+};
+
 struct A {
   int one;
   static const int HdrSize = 52;
@@ -72,6 +77,8 @@ void f1() {
   E y;
   int i = F::i;
   F::inner z;
+  K k;
+  k.func();
 }
 
 int main(int argc, char **argv) {
@@ -98,7 +105,8 @@ int main(int argc, char **argv) {
 
 // CHECK: [[F:![0-9]*]] = !DICompositeType(tag: DW_TAG_structure_type, name: 
"F"
 // CHECK-SAME: DIFlagFwdDecl
-// CHECK-SAME: identifier: "_ZTS1F"
+// CHECK-NOT: identifier:
+// CHECK-SAME:){{$}}
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "I"
 // CHECK-NOT:  DIFlagFwdDecl
 // CHECK-SAME: ){{$}}
@@ -117,7 +125,8 @@ int main(int argc, char **argv) {
 // CHECK-NOT:  DIFlagFwdDecl
 // CHECK-SAME: elements: [[C_MEM:![0-9]*]]
 // CHECK-SAME: vtableHolder: [[C]]
-// CHECK-SAME: identifier: "_ZTS1C"
+// CHECK-NOT:  identifier:
+// CHECK-SAME: ){{$}}
 // CHECK: [[C_MEM]] = !{[[C_VPTR:![0-9]*]], [[C_S:![0-9]*]], 
[[C_DTOR:![0-9]*]]}
 // CHECK: [[C_VPTR]] = !DIDerivedType(tag: DW_TAG_member, name: "_vptr$C"
 // CHECK-SAME:DIFlagArtificial
@@ -129,10 +138,16 @@ int main(int argc, char **argv) {
 // CHECK: [[D:![0-9]+]] = !DICompositeType(tag: DW_TAG_structure_type, name: 
"D"
 // CHECK-NOT:  size:
 // CHECK-SAME: DIFlagFwdDecl
-// CHECK-SAME: identifier: "_ZTS1D"
+// CHECK-NOT:  identifier:
+// CHECK-SAME: ){{$}}
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "E"
 // CHECK-SAME: DIFlagFwdDecl
-// CHECK-SAME: identifier: "_ZTS1E"
+// CHECK-NOT:  identifier:
+// CHECK-SAME: ){{$}}
+
+// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "K"
+// CHECK-SAME: identifier: "_ZTS1K"
+// CHECK-SAME: ){{$}}
 
 // CHECK: !DISubprogram(name: "func",{{.*}} scope: [[D]]
 // CHECK-SAME:  DISPFlagDefinition
@@ -146,7 +161,8 @@ int main(int argc, char **argv) {
 
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "G"
 // CHECK-SAME: DIFlagFwdDecl
-// CHECK-SAME: identifier: "_ZTS1G"
+// CHECK-NOT:  identifier:
+// CHECK-SAME: ){{$}}
 // CHECK: [[G_INNER_MEM]] = !{[[G_INNER_I:![0-9]*]]}
 // CHECK: [[G_INNER_I]] = !DIDerivedType(tag: DW_TAG_member, name: "j"
 // CHECK-SAME:   baseType: ![[INT]]
@@ -154,5 +170,5 @@ int main(int argc, char **argv) {
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "A"
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "HdrSize"
 //
-// CHECK: ![[EXCEPTLOC]] = 

r359217 - DebugInfo: Fix bitrotted test case

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Apr 25 11:11:48 2019
New Revision: 359217

URL: http://llvm.org/viewvc/llvm-project?rev=359217=rev
Log:
DebugInfo: Fix bitrotted test case

This test was updated with some CHECK suffix variants, but dropped
checking for the unsuffixed 'CHECK'

Modified:
cfe/trunk/test/CodeGenCXX/debug-info-class.cpp

Modified: cfe/trunk/test/CodeGenCXX/debug-info-class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-class.cpp?rev=359217=359216=359217=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-class.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-class.cpp Thu Apr 25 11:11:48 2019
@@ -83,12 +83,12 @@ int main(int argc, char **argv) {
   return 0;
 }
 
-// RUN: %clang_cc1 -triple x86_64-unknown_unknown -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++98 %s -o - | FileCheck 
-check-prefix=CHECK98 %s
-// RUN: %clang_cc1 -triple i686-cygwin -emit-llvm -debug-info-kind=limited 
-fexceptions -std=c++98 %s -o - | FileCheck -check-prefix=CHECK98 %s
-// RUN: %clang_cc1 -triple armv7l-unknown-linux-gnueabihf -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++98 %s -o - | FileCheck 
-check-prefix=CHECK98 %s
-// RUN: %clang_cc1 -triple x86_64-unknown_unknown -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++11 %s -o - | FileCheck 
-check-prefix=CHECK11 %s
-// RUN: %clang_cc1 -triple i686-cygwin -emit-llvm -debug-info-kind=limited 
-fexceptions -std=c++11 %s -o - | FileCheck -check-prefix=CHECK11 %s
-// RUN: %clang_cc1 -triple armv7l-unknown-linux-gnueabihf -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++11 %s -o - | FileCheck 
-check-prefix=CHECK11 %s
+// RUN: %clang_cc1 -triple x86_64-unknown_unknown -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++98 %s -o - | FileCheck 
-check-prefix=CHECK98 -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple i686-cygwin -emit-llvm -debug-info-kind=limited 
-fexceptions -std=c++98 %s -o - | FileCheck -check-prefix=CHECK98 
-check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple armv7l-unknown-linux-gnueabihf -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++98 %s -o - | FileCheck 
-check-prefix=CHECK98 -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple x86_64-unknown_unknown -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++11 %s -o - | FileCheck 
-check-prefix=CHECK11 -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple i686-cygwin -emit-llvm -debug-info-kind=limited 
-fexceptions -std=c++11 %s -o - | FileCheck -check-prefix=CHECK11 
-check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple armv7l-unknown-linux-gnueabihf -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++11 %s -o - | FileCheck 
-check-prefix=CHECK11 -check-prefix=CHECK %s
 
 // CHECK98: invoke {{.+}} @_ZN1BD1Ev(%class.B* %b)
 // CHECK98-NEXT: unwind label %{{.+}}, !dbg ![[EXCEPTLOC:.*]]
@@ -135,10 +135,9 @@ int main(int argc, char **argv) {
 // CHECK-SAME: identifier: "_ZTS1E"
 
 // CHECK: !DISubprogram(name: "func",{{.*}} scope: [[D]]
-// CHECK-SAME:  isDefinition: true
+// CHECK-SAME:  DISPFlagDefinition
 // CHECK-SAME:  declaration: [[D_FUNC_DECL:![0-9]*]]
 // CHECK: [[D_FUNC_DECL]] = !DISubprogram(name: "func",{{.*}} scope: [[D]]
-// CHECK-SAME:isDefinition: false
 
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "inner",{{.*}} 
line: 50
 // CHECK-NOT: DIFlagFwdDecl


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

r358796 - Modules: Adopt template parameters for variable templates to set their decl context correctly

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Apr 19 16:04:05 2019
New Revision: 358796

URL: http://llvm.org/viewvc/llvm-project?rev=358796=rev
Log:
Modules: Adopt template parameters for variable templates to set their decl 
context correctly

Exposed by a related bug about visibility of default arguments of nested
templates - without the correct decl context, default template
parameters of variable templates nested in classes would have incorrect
visibility computed.

Modified:
cfe/trunk/lib/AST/DeclTemplate.cpp
cfe/trunk/test/Modules/nested-template-default-arg-redecl.cpp

Modified: cfe/trunk/lib/AST/DeclTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclTemplate.cpp?rev=358796=358795=358796=diff
==
--- cfe/trunk/lib/AST/DeclTemplate.cpp (original)
+++ cfe/trunk/lib/AST/DeclTemplate.cpp Fri Apr 19 16:04:05 2019
@@ -956,6 +956,7 @@ VarTemplateDecl *VarTemplateDecl::Create
  SourceLocation L, DeclarationName 
Name,
  TemplateParameterList *Params,
  VarDecl *Decl) {
+  AdoptTemplateParameterList(Params, DC);
   return new (C, DC) VarTemplateDecl(C, DC, L, Name, Params, Decl);
 }
 

Modified: cfe/trunk/test/Modules/nested-template-default-arg-redecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/nested-template-default-arg-redecl.cpp?rev=358796=358795=358796=diff
==
--- cfe/trunk/test/Modules/nested-template-default-arg-redecl.cpp (original)
+++ cfe/trunk/test/Modules/nested-template-default-arg-redecl.cpp Fri Apr 19 
16:04:05 2019
@@ -1,18 +1,16 @@
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -x c++ -fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t \
 // RUN: -I %S/Inputs/nested-template-default-arg-redecl -std=c++14 \
-// RUN: -fmodules-local-submodule-visibility -verify %s
+// RUN: -fmodules-local-submodule-visibility -w -verify %s
+
+// expected-no-diagnostics
+
 #include "alias2.h"
 #include "var2.h"
 #include "strct2.h"
 #include "func2.h"
 
-// FIXME: Variable templates lexical decl context appears to be the translation
-// unit, which is incorrect. Fixing this will hopefully address the following
-// error/bug:
-
-// expected-note@Inputs/nested-template-default-arg-redecl/var.h:4 {{default 
argument declared here}}
-auto var = _outer::var<>; // expected-error {{default argument of 'var' 
must be imported from module 'VAR1' before it is required}}
+auto var = _outer::var<>;
 auto func = _outer::func<>;
 strct_outer::strct<> *strct;
 alias_outer::alias<> *alias;


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

r358795 - Modules: Search for a visible definition of the decl context when computing visibility of a default template parameter

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Apr 19 16:02:30 2019
New Revision: 358795

URL: http://llvm.org/viewvc/llvm-project?rev=358795=rev
Log:
Modules: Search for a visible definition of the decl context when computing 
visibility of a default template parameter

The code is/was already correct for the case where a parameter is a
parameter of its enclosing lexical DeclContext (functions and classes).
But for other templates (alias and variable templates) they don't create
their own scope to be members of - in those cases, they parameter should
be considered visible if any definition of the lexical decl context is
visible.

[this should cleanup the failure on the libstdc++ modules buildbot]
[this doesn't actually fix the variable template case for a
secondary/compounding reason (its lexical decl context is incorrectly
considered to be the translation unit)]

Test covers all 4 kinds of templates with default args, including a
regression test for the still broken variable template case.

Reviewers: rsmith

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

Added:
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias1.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias2.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/func.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/func1.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/func2.h

cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/module.modulemap
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/strct.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/strct1.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/strct2.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/var.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/var1.h
cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/var2.h
cfe/trunk/test/Modules/nested-template-default-arg-redecl.cpp
Modified:
cfe/trunk/lib/Sema/SemaLookup.cpp

Modified: cfe/trunk/lib/Sema/SemaLookup.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLookup.cpp?rev=358795=358794=358795=diff
==
--- cfe/trunk/lib/Sema/SemaLookup.cpp (original)
+++ cfe/trunk/lib/Sema/SemaLookup.cpp Fri Apr 19 16:02:30 2019
@@ -1543,8 +1543,21 @@ bool LookupResult::isVisibleSlow(Sema 
 // and in C we must not because each declaration of a function gets its own
 // set of declarations for tags in prototype scope.
 bool VisibleWithinParent;
-if (D->isTemplateParameter() || isa(D) ||
-(isa(DC) && !SemaRef.getLangOpts().CPlusPlus))
+if (D->isTemplateParameter()) {
+  bool SearchDefinitions = true;
+  if (const auto *DCD = dyn_cast(DC)) {
+if (const auto *TD = DCD->getDescribedTemplate()) {
+  TemplateParameterList *TPL = TD->getTemplateParameters();
+  auto Index = getDepthAndIndex(D).second;
+  SearchDefinitions = Index >= TPL->size() || TPL->getParam(Index) != 
D;
+}
+  }
+  if (SearchDefinitions)
+VisibleWithinParent = 
SemaRef.hasVisibleDefinition(cast(DC));
+  else
+VisibleWithinParent = isVisible(SemaRef, cast(DC));
+} else if (isa(D) ||
+   (isa(DC) && !SemaRef.getLangOpts().CPlusPlus))
   VisibleWithinParent = isVisible(SemaRef, cast(DC));
 else if (D->isModulePrivate()) {
   // A module-private declaration is only visible if an enclosing lexical

Added: cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias.h?rev=358795=auto
==
--- cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias.h 
(added)
+++ cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias.h 
Fri Apr 19 16:02:30 2019
@@ -0,0 +1,7 @@
+#ifndef ALIAS_H
+#define ALIAS_H
+struct alias_outer {
+  template 
+  using alias = int;
+};
+#endif

Added: cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias1.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias1.h?rev=358795=auto
==
--- cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias1.h 
(added)
+++ cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias1.h 
Fri Apr 19 16:02:30 2019
@@ -0,0 +1 @@
+#include "alias.h"

Added: cfe/trunk/test/Modules/Inputs/nested-template-default-arg-redecl/alias2.h
URL: 

r358464 - DebugInfo: Default to standalone debug when tuning for LLDB

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Apr 15 17:16:29 2019
New Revision: 358464

URL: http://llvm.org/viewvc/llvm-project?rev=358464=rev
Log:
DebugInfo: Default to standalone debug when tuning for LLDB

LLDB can't currently handle Clang's default (limit/no-standalone) DWARF,
so platforms that default to LLDB (Darwin) or anyone else manually
requesting LLDB tuning, should also get standalone DWARF.

That doesn't mean a user can't explicitly enable (because they have
other reasons to prefer standalone DWARF (such as that they're only
building half their application with debug info enabled, and half
without - or because they're tuning for GDB, but want to be able to use
it under LLDB too (this is the default on FreeBSD))) or disable (testing
LLDB fixes/improvements that handle no-standalone mode, building C code,
perhaps, which wouldn't have the LLDB<>no-standalone conflict, etc) the
feature regardless of the tuning.

Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/debug-options.c

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=358464=358463=358464=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Apr 15 17:16:29 2019
@@ -3295,9 +3295,10 @@ static void RenderDebugOptions(const Too
   // figure out if we need to "upgrade" it to standalone debug info.
   // We parse these two '-f' options whether or not they will be used,
   // to claim them even if you wrote "-fstandalone-debug -gline-tables-only"
-  bool NeedFullDebug = Args.hasFlag(options::OPT_fstandalone_debug,
-options::OPT_fno_standalone_debug,
-TC.GetDefaultStandaloneDebug());
+  bool NeedFullDebug = Args.hasFlag(
+  options::OPT_fstandalone_debug, options::OPT_fno_standalone_debug,
+  DebuggerTuning == llvm::DebuggerKind::LLDB ||
+  TC.GetDefaultStandaloneDebug());
   if (const Arg *A = Args.getLastArg(options::OPT_fstandalone_debug))
 (void)checkDebugInfoOption(A, Args, D, TC);
   if (DebugInfoKind == codegenoptions::LimitedDebugInfo && NeedFullDebug)

Modified: cfe/trunk/test/Driver/debug-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=358464=358463=358464=diff
==
--- cfe/trunk/test/Driver/debug-options.c (original)
+++ cfe/trunk/test/Driver/debug-options.c Mon Apr 15 17:16:29 2019
@@ -3,26 +3,26 @@
 
 // Linux.
 // RUN: %clang -### -c -g %s -target x86_64-linux-gnu 2>&1 \
-// RUN: | FileCheck -check-prefix=G -check-prefix=G_GDB %s
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_GDB %s
 // RUN: %clang -### -c -g2 %s -target x86_64-linux-gnu 2>&1 \
-// RUN: | FileCheck -check-prefix=G %s
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_GDB %s
 // RUN: %clang -### -c -g3 %s -target x86_64-linux-gnu 2>&1 \
-// RUN: | FileCheck -check-prefix=G %s
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_GDB %s
 // RUN: %clang -### -c -ggdb %s -target x86_64-linux-gnu 2>&1 \
-// RUN: | FileCheck -check-prefix=G -check-prefix=G_GDB %s
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_GDB %s
 // RUN: %clang -### -c -ggdb1 %s -target x86_64-linux-gnu 2>&1 \
 // RUN: | FileCheck -check-prefix=GLTO_ONLY -check-prefix=G_GDB %s
 // RUN: %clang -### -c -ggdb3 %s -target x86_64-linux-gnu 2>&1 \
-// RUN: | FileCheck -check-prefix=G %s
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_GDB %s
 // RUN: %clang -### -c -glldb %s -target x86_64-linux-gnu 2>&1 \
-// RUN: | FileCheck -check-prefix=G -check-prefix=G_LLDB %s
+// RUN: | FileCheck -check-prefix=G_STANDALONE 
-check-prefix=G_LLDB %s
 // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \
-// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_SCE %s
 
 // Android.
 // Android should always generate DWARF4.
 // RUN: %clang -### -c -g %s -target arm-linux-androideabi 2>&1 \
-// RUN: | FileCheck -check-prefix=G -check-prefix=G_DWARF4 %s
+// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_DWARF4 
%s
 
 // Darwin.
 // RUN: %clang -### -c -g %s -target x86_64-apple-darwin14 2>&1 \
@@ -231,9 +231,6 @@
 // RUN: %clang -### -target %itanium_abi_triple -gmodules 
-gline-directives-only %s 2>&1 \
 // RUN:| FileCheck -check-prefix=GLIO_ONLY %s
 //
-// G: "-cc1"
-// G: "-debug-info-kind=limited"
-//
 // NOG_PS4: "-cc1"
 // NOG_PS4-NOT "-dwarf-version=
 // NOG_PS4: "-generate-arange-section"
@@ -277,6 +274,8 @@
 //
 // 

Re: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if it's not trivial

[David Blaikie via cfe-commits]

Hi Aaron,

I don't see any mention of this in D44406 - so it might have been good to
have a separate review for this (or included this in the review of D44406,
which I think is possible with the monorepo).

Specifically - this change is missing test coverage (there should be a
clang test that goes from C++ source code to LLVM IR & demonstrates the
flag being emitted into the IR, etc).

Also - what's the reason the non-triviality can't be implied by the absence
of the trivial flag? (or the other way around) - the flags seem redundant
with one another.

On Mon, Feb 25, 2019 at 8:02 PM Aaron Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: asmith
> Date: Mon Feb 25 19:49:05 2019
> New Revision: 354843
>
> URL: http://llvm.org/viewvc/llvm-project?rev=354843=rev
> Log:
> [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if it's not trivial
>
> This goes with https://reviews.llvm.org/D44406
>
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=354843=354842=354843=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Feb 25 19:49:05 2019
> @@ -3031,6 +3031,8 @@ llvm::DICompositeType *CGDebugInfo::Crea
>  // Record if a C++ record is trivial type.
>  if (CXXRD->isTrivial())
>Flags |= llvm::DINode::FlagTrivial;
> +else
> +  Flags |= llvm::DINode::FlagNonTrivial;
>}
>
>llvm::DICompositeType *RealDecl =
> DBuilder.createReplaceableCompositeType(
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r350856 - Split -Wdelete-non-virtual-dtor into two groups

[David Blaikie via cfe-commits]

Might be handy to summarize the changes from the previous reverted version
of this patch (& mention the original commit revision and revert revision)
- in the commit message is ideal, but in a reply to the commit after the
fact will do in a pinch

On Fri, Jan 11, 2019 at 4:06 AM Erik Pilkington via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: epilk
> Date: Thu Jan 10 10:03:07 2019
> New Revision: 350856
>
> URL: http://llvm.org/viewvc/llvm-project?rev=350856=rev
> Log:
> Split -Wdelete-non-virtual-dtor into two groups
>
> This group controls two diagnostics: deleting an abstract class with
> a non-virtual dtor, which is a guaranteed crash, and deleting a
> non-abstract polymorphic class with a non-virtual dtor, which is just
> suspicious.
>
> rdar://40380564
>
> Differential revision: https://reviews.llvm.org/D56405
>
> Added:
> cfe/trunk/test/SemaCXX/delete-non-virtual-dtor.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=350856=350855=350856=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Thu Jan 10 10:03:07
> 2019
> @@ -104,7 +104,11 @@ def UndefinedFuncTemplate : DiagGroup<"u
>  def MissingNoEscape : DiagGroup<"missing-noescape">;
>
>  def DeleteIncomplete : DiagGroup<"delete-incomplete">;
> -def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
> +def DeleteNonAbstractNonVirtualDtor :
> DiagGroup<"delete-non-abstract-non-virtual-dtor">;
> +def DeleteAbstractNonVirtualDtor :
> DiagGroup<"delete-abstract-non-virtual-dtor">;
> +def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor",
> + [DeleteNonAbstractNonVirtualDtor,
> +  DeleteAbstractNonVirtualDtor]>;
>  def AbstractFinalClass : DiagGroup<"abstract-final-class">;
>
>  def CXX11CompatDeprecatedWritableStr :
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=350856=350855=350856=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jan 10
> 10:03:07 2019
> @@ -6455,12 +6455,12 @@ def warn_non_virtual_dtor : Warning<
>  def warn_delete_non_virtual_dtor : Warning<
>"%select{delete|destructor}0 called on non-final %1 that has "
>"virtual functions but non-virtual destructor">,
> -  InGroup, DefaultIgnore, ShowInSystemHeader;
> +  InGroup, DefaultIgnore,
> ShowInSystemHeader;
>  def note_delete_non_virtual : Note<
>"qualify call to silence this warning">;
>  def warn_delete_abstract_non_virtual_dtor : Warning<
>"%select{delete|destructor}0 called on %1 that is abstract but has "
> -  "non-virtual destructor">, InGroup,
> ShowInSystemHeader;
> +  "non-virtual destructor">, InGroup,
> ShowInSystemHeader;
>  def warn_overloaded_virtual : Warning<
>"%q0 hides overloaded virtual %select{function|functions}1">,
>InGroup, DefaultIgnore;
>
> Added: cfe/trunk/test/SemaCXX/delete-non-virtual-dtor.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/delete-non-virtual-dtor.cpp?rev=350856=auto
>
> ==
> --- cfe/trunk/test/SemaCXX/delete-non-virtual-dtor.cpp (added)
> +++ cfe/trunk/test/SemaCXX/delete-non-virtual-dtor.cpp Thu Jan 10 10:03:07
> 2019
> @@ -0,0 +1,30 @@
> +// RUN: %clang_cc1 %s -verify -DDIAG1
> +// RUN: %clang_cc1 %s -verify -DDIAG1 -DDIAG2 -Wdelete-non-virtual-dtor
> +// RUN: %clang_cc1 %s -verify -DDIAG1 -Wmost
> -Wno-delete-non-abstract-non-virtual-dtor
> +// RUN: %clang_cc1 %s -verify -DDIAG2 -Wmost
> -Wno-delete-abstract-non-virtual-dtor
> +// RUN: %clang_cc1 %s -verify -Wmost
> -Wno-delete-non-virtual-dtor
> +
> +#ifndef DIAG1
> +#ifndef DIAG2
> +// expected-no-diagnostics
> +#endif
> +#endif
> +
> +struct S1 {
> +  ~S1() {}
> +  virtual void abs() = 0;
> +};
> +
> +void f1(S1 *s1) { delete s1; }
> +#ifdef DIAG1
> +// expected-warning@-2 {{delete called on 'S1' that is abstract but has
> non-virtual destructor}}
> +#endif
> +
> +struct S2 {
> +  ~S2() {}
> +  virtual void real() {}
> +};
> +void f2(S2 *s2) { delete s2; }
> +#ifdef DIAG2
> +// expected-warning@-2 {{delete called on non-final 'S2' that has
> virtual functions but non-virtual destructor}}
> +#endif
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> 

Re: r350143 - Add vtable anchor to classes.

[David Blaikie via cfe-commits]

While I realize it's in the coding standard - is there any particular other
motivation for this? (Given you've been doing layering cleanup - I'm
wondering fi this is an interesting workaround for some layering problems,
for instance?)

On Sat, Dec 29, 2018 at 1:05 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Fri Dec 28 18:02:30 2018
> New Revision: 350143
>
> URL: http://llvm.org/viewvc/llvm-project?rev=350143=rev
> Log:
> Add vtable anchor to classes.
>
> Modified:
> cfe/trunk/include/clang/AST/DeclCXX.h
> cfe/trunk/include/clang/AST/DeclTemplate.h
> cfe/trunk/include/clang/Lex/ModuleMap.h
> cfe/trunk/lib/AST/DeclCXX.cpp
> cfe/trunk/lib/AST/DeclTemplate.cpp
> cfe/trunk/lib/Lex/ModuleMap.cpp
>
> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=350143=350142=350143=diff
>
> ==
> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
> +++ cfe/trunk/include/clang/AST/DeclCXX.h Fri Dec 28 18:02:30 2018
> @@ -3918,6 +3918,7 @@ class MSPropertyDecl : public Declarator
>: DeclaratorDecl(MSProperty, DC, L, N, T, TInfo, StartL),
>  GetterId(Getter), SetterId(Setter) {}
>
> +  void anchor() override;
>  public:
>friend class ASTDeclReader;
>
>
> Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=350143=350142=350143=diff
>
> ==
> --- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
> +++ cfe/trunk/include/clang/AST/DeclTemplate.h Fri Dec 28 18:02:30 2018
> @@ -751,6 +751,7 @@ class RedeclarableTemplateDecl : public
>  return getMostRecentDecl();
>}
>
> +  void anchor() override;
>  protected:
>template  struct SpecEntryTraits {
>  using DeclType = EntryType;
>
> Modified: cfe/trunk/include/clang/Lex/ModuleMap.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/ModuleMap.h?rev=350143=350142=350143=diff
>
> ==
> --- cfe/trunk/include/clang/Lex/ModuleMap.h (original)
> +++ cfe/trunk/include/clang/Lex/ModuleMap.h Fri Dec 28 18:02:30 2018
> @@ -45,6 +45,8 @@ class SourceManager;
>  /// A mechanism to observe the actions of the module map parser as it
>  /// reads module map files.
>  class ModuleMapCallbacks {
> +  virtual void anchor();
> +
>  public:
>virtual ~ModuleMapCallbacks() = default;
>
>
> Modified: cfe/trunk/lib/AST/DeclCXX.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=350143=350142=350143=diff
>
> ==
> --- cfe/trunk/lib/AST/DeclCXX.cpp (original)
> +++ cfe/trunk/lib/AST/DeclCXX.cpp Fri Dec 28 18:02:30 2018
> @@ -2910,6 +2910,8 @@ void DecompositionDecl::printName(llvm::
>os << ']';
>  }
>
> +void MSPropertyDecl::anchor() {}
> +
>  MSPropertyDecl *MSPropertyDecl::Create(ASTContext , DeclContext *DC,
> SourceLocation L, DeclarationName
> N,
> QualType T, TypeSourceInfo *TInfo,
>
> Modified: cfe/trunk/lib/AST/DeclTemplate.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclTemplate.cpp?rev=350143=350142=350143=diff
>
> ==
> --- cfe/trunk/lib/AST/DeclTemplate.cpp (original)
> +++ cfe/trunk/lib/AST/DeclTemplate.cpp Fri Dec 28 18:02:30 2018
> @@ -149,6 +149,8 @@ void *allocateDefaultArgStorageChain(con
>  // RedeclarableTemplateDecl Implementation
>
>  
> //===--===//
>
> +void RedeclarableTemplateDecl::anchor() {}
> +
>  RedeclarableTemplateDecl::CommonBase
> *RedeclarableTemplateDecl::getCommonPtr() const {
>if (Common)
>  return Common;
>
> Modified: cfe/trunk/lib/Lex/ModuleMap.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/ModuleMap.cpp?rev=350143=350142=350143=diff
>
> ==
> --- cfe/trunk/lib/Lex/ModuleMap.cpp (original)
> +++ cfe/trunk/lib/Lex/ModuleMap.cpp Fri Dec 28 18:02:30 2018
> @@ -54,6 +54,8 @@
>
>  using namespace clang;
>
> +void ModuleMapCallbacks::anchor() {}
> +
>  void ModuleMap::resolveLinkAsDependencies(Module *Mod) {
>auto PendingLinkAs = PendingLinkAsModule.find(Mod->Name);
>if (PendingLinkAs != PendingLinkAsModule.end()) {
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list

r349669 - PR40096: Forwards-compatible with C++20 rule regarding aggregates not having user-declared ctors

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Dec 19 11:33:35 2018
New Revision: 349669

URL: http://llvm.org/viewvc/llvm-project?rev=349669=rev
Log:
PR40096: Forwards-compatible with C++20 rule regarding aggregates not having 
user-declared ctors

Looks like these were in place to make these types move-only. That's
generally not a feature that the type should prescribe (unless it's an
inherent limitation) - instead leaving it up to the users of a type.

Modified:
cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp
cfe/trunk/tools/clang-refactor/TestSupport.h

Modified: cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp?rev=349669=349668=349669=diff
==
--- cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp (original)
+++ cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp Wed Dec 19 11:33:35 2018
@@ -250,8 +250,6 @@ static bool hasAnyDirectChildrenWithKind
 
 namespace {
 struct SelectedNodeWithParents {
-  SelectedNodeWithParents(SelectedNodeWithParents &&) = default;
-  SelectedNodeWithParents =(SelectedNodeWithParents &&) = default;
   SelectedASTNode::ReferenceType Node;
   llvm::SmallVector Parents;
 

Modified: cfe/trunk/tools/clang-refactor/TestSupport.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-refactor/TestSupport.h?rev=349669=349668=349669=diff
==
--- cfe/trunk/tools/clang-refactor/TestSupport.h (original)
+++ cfe/trunk/tools/clang-refactor/TestSupport.h Wed Dec 19 11:33:35 2018
@@ -59,9 +59,6 @@ struct TestSelectionRangesInFile {
   };
   std::vector GroupedRanges;
 
-  TestSelectionRangesInFile(TestSelectionRangesInFile &&) = default;
-  TestSelectionRangesInFile =(TestSelectionRangesInFile &&) = default;
-
   bool foreachRange(const SourceManager ,
 llvm::function_ref Callback) const;
 


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

Re: r346789 - DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.

[David Blaikie via cfe-commits]

(tiny factoid: turns out gold's 64 bit gdb-index support is also broken in
a different, more subtle way... - so best folks don't use this flag except
with lld, it seems, if you're using gdb-index)

On Tue, Nov 13, 2018 at 12:10 PM David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dblaikie
> Date: Tue Nov 13 12:08:13 2018
> New Revision: 346789
>
> URL: http://llvm.org/viewvc/llvm-project?rev=346789=rev
> Log:
> DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier
> use.
>
> Summary:
> This saves a lot of relocations in optimized object files (at the cost
> of some cost/increase in linked executable bytes), but gold's 32 bit
> gdb-index support has a bug (
> https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't
> switch to this unconditionally. (& even if it weren't for that bug, one
> might argue that some users would want to optimize in one direction or
> the other - prioritizing object size or linked executable size)
>
> Differential Revision: https://reviews.llvm.org/D54243
>
> Added:
> cfe/trunk/test/CodeGen/debug-info-ranges-base-address.c
> Modified:
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/test/Driver/debug-options.c
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=346789=346788=346789=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Tue Nov 13 12:08:13 2018
> @@ -1780,6 +1780,10 @@ def fdebug_types_section: Flag <["-"], "
>Flags<[CC1Option]>, HelpText<"Place debug types in their own section
> (ELF Only)">;
>  def fno_debug_types_section: Flag<["-"], "fno-debug-types-section">,
> Group,
>Flags<[CC1Option]>;
> +def fdebug_ranges_base_address: Flag <["-"],
> "fdebug-ranges-base-address">, Group,
> +  Flags<[CC1Option]>, HelpText<"Use DWARF base address selection entries
> in debug_ranges">;
> +def fno_debug_ranges_base_address: Flag <["-"],
> "fno-debug-ranges-base-address">, Group,
> +  Flags<[CC1Option]>;
>  def fsplit_dwarf_inlining: Flag <["-"], "fsplit-dwarf-inlining">,
> Group,
>Flags<[CC1Option]>, HelpText<"Provide minimal debug info in the
> object/executable to facilitate online symbolication/stack traces in the
> absence of .dwo/.dwp files when using Split DWARF">;
>  def fno_split_dwarf_inlining: Flag<["-"], "fno-split-dwarf-inlining">,
> Group,
>
> Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=346789=346788=346789=diff
>
> ==
> --- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
> +++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Tue Nov 13
> 12:08:13 2018
> @@ -331,6 +331,9 @@ CODEGENOPT(PreserveVec3Type, 1, 0)
>  /// Whether to emit .debug_gnu_pubnames section instead of
> .debug_pubnames.
>  CODEGENOPT(DebugNameTable, 2, 0)
>
> +/// Whether to use DWARF base address specifiers in .debug_ranges.
> +CODEGENOPT(DebugRangesBaseAddress, 1, 0)
> +
>  CODEGENOPT(NoPLT, 1, 0)
>
>  /// Whether to embed source in DWARF debug line section.
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=346789=346788=346789=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Nov 13 12:08:13 2018
> @@ -586,7 +586,8 @@ void CGDebugInfo::CreateCompileUnit() {
>CGM.getTarget().getTriple().isNVPTX()
>? llvm::DICompileUnit::DebugNameTableKind::None
>: static_cast(
> -CGOpts.DebugNameTable));
> +CGOpts.DebugNameTable),
> +  CGOpts.DebugRangesBaseAddress);
>  }
>
>  llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) {
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/li

Re: r348685 - Move diagnostic enums into Basic.

[David Blaikie via cfe-commits]

Hey Richard,

Thanks for cleaning up some of the layering here!

I /think/ I vaguely recall having a conversation with Richard Smith about a
different direction to fix the layering of the diagnostics system - but it
was/is more involved. Ah, here, apparently I sent out a WIP patch & must've
got engaged in other things: https://reviews.llvm.org/D41357 - not sure if
this is a better/workable/useful way forward, or whether we should go with
sinking the specific diagnostics into the Diagnostics library as you've
done/started doing here (I don't have much context in my head right now, so
I forget exactly what's involved in fully pushing them all down into
Diagnostics).

Just some thoughts/directions/ideas,
- Dave

On Fri, Dec 7, 2018 at 9:07 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Fri Dec  7 21:05:03 2018
> New Revision: 348685
>
> URL: http://llvm.org/viewvc/llvm-project?rev=348685=rev
> Log:
> Move diagnostic enums into Basic.
>
> Move enums from */*Diagnostic.h to Basic/Diagnostic*.h.
> Basic/AllDiagnostics.h
> needs all the enums and moving the sources to Basic prevents a
> Basic->*->Basic
> dependency loop.  This also allows each Basic/Diagnostics*Kinds.td to have
> a
> header at Basic/Diagnostic*.h (except for Common).  The old headers are
> kept in place since other packages are still using them.
>
> Added:
> cfe/trunk/include/clang/Basic/DiagnosticAST.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/AST/ASTDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticAnalysis.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Analysis/AnalysisDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticComment.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/AST/CommentDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticCrossTU.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/CrossTU/CrossTUDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticDriver.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Driver/DriverDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticFrontend.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Frontend/FrontendDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticLex.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Lex/LexDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticParse.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Parse/ParseDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticRefactoring.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Tooling/Refactoring/RefactoringDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticSema.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Sema/SemaDiagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticSerialization.h
>   - copied, changed from r348541,
> cfe/trunk/include/clang/Serialization/SerializationDiagnostic.h
> Modified:
> cfe/trunk/include/clang/AST/ASTDiagnostic.h
> cfe/trunk/include/clang/AST/CommentDiagnostic.h
> cfe/trunk/include/clang/Analysis/AnalysisDiagnostic.h
> cfe/trunk/include/clang/Basic/AllDiagnostics.h
> cfe/trunk/include/clang/CrossTU/CrossTUDiagnostic.h
> cfe/trunk/include/clang/Driver/DriverDiagnostic.h
> cfe/trunk/include/clang/Frontend/FrontendDiagnostic.h
> cfe/trunk/include/clang/Lex/LexDiagnostic.h
> cfe/trunk/include/clang/Parse/ParseDiagnostic.h
> cfe/trunk/include/clang/Sema/SemaDiagnostic.h
> cfe/trunk/include/clang/Serialization/SerializationDiagnostic.h
> cfe/trunk/include/clang/Tooling/Refactoring/RefactoringDiagnostic.h
>
> Modified: cfe/trunk/include/clang/AST/ASTDiagnostic.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTDiagnostic.h?rev=348685=348684=348685=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTDiagnostic.h (original)
> +++ cfe/trunk/include/clang/AST/ASTDiagnostic.h Fri Dec  7 21:05:03 2018
> @@ -11,19 +11,9 @@
>  #define LLVM_CLANG_AST_ASTDIAGNOSTIC_H
>
>  #include "clang/Basic/Diagnostic.h"
> +#include "clang/Basic/DiagnosticAST.h"
>
>  namespace clang {
> -  namespace diag {
> -enum {
> -#define DIAG(ENUM,FLAGS,DEFAULT_MAPPING,DESC,GROUP,\
> - SFINAE,NOWERROR,SHOWINSYSHEADER,CATEGORY) ENUM,
> -#define ASTSTART
> -#include "clang/Basic/DiagnosticASTKinds.inc"
> -#undef DIAG
> -  NUM_BUILTIN_AST_DIAGNOSTICS
> -};
> -  }  // end namespace diag
> -
>/// DiagnosticsEngine argument formatting function for diagnostics that
>/// involve AST nodes.
>///
>
> Modified: cfe/trunk/include/clang/AST/CommentDiagnostic.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/CommentDiagnostic.h?rev=348685=348684=348685=diff
>
> 

Re: [PATCH] D55377: Allow forwarding -fdebug-compilation-dir to cc1as

[David Blaikie via cfe-commits]

Would it be worth considering whether -fdebug-compilation-dir and
-fdebug-prefix-map could be unified, perhaps by having a placeholder that
could be used in -fdebug-prefix-map for the current directory?

I guess they're low-maintenance enough that it's probably not, but figured
I'd ask.

On Thu, Dec 6, 2018 at 10:34 AM Nico Weber via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> thakis created this revision.
> thakis added a reviewer: rnk.
>
> The flag -fdebug-compilation-dir is useful to make generated .o files
> independent of the path of the build directory, without making the compile
> command-line dependent on the path of the build directory, like
> -fdebug-prefix-map requires. This change makes it so that the driver can
> forward the flag to -cc1as, like it already can for -cc1. We might want to
> consider making -fdebug-compilation-dir a driver flag in a follow-up.
>
> (Since -fdebug-compilation-dir defaults to PWD, it's already possible to
> get this effect by setting PWD, but explicit compiler flags are better than
> env vars, because e.g. ninja tracks command lines and reruns commands that
> change.)
>
> Somewhat related to PR14625.
>
>
> https://reviews.llvm.org/D55377
>
> Files:
>   lib/Driver/ToolChains/Clang.cpp
>   test/Driver/integrated-as.s
>
>
> Index: test/Driver/integrated-as.s
> ===
> --- test/Driver/integrated-as.s
> +++ test/Driver/integrated-as.s
> @@ -50,3 +50,9 @@
>
>  // RUN: %clang -### -target x86_64--- -x assembler -c -fPIC
> -integrated-as %s 2>&1 | FileCheck --check-prefix=PIC %s
>  // PIC: "-mrelocation-model" "pic"
> +
> +// RUN: %clang -### -target x86_64--- -c -integrated-as %s
> -Wa,-fdebug-compilation-dir,. 2>&1 | FileCheck --check-prefix=WA_DEBUGDIR %s
> +// WA_DEBUGDIR: "-fdebug-compilation-dir" "."
> +
> +// RUN: %clang -### -target x86_64--- -c -integrated-as %s -Xassembler
> -fdebug-compilation-dir -Xassembler . 2>&1 | FileCheck
> --check-prefix=XA_DEBUGDIR %s
> +// XA_DEBUGDIR: "-fdebug-compilation-dir" "."
> Index: lib/Driver/ToolChains/Clang.cpp
> ===
> --- lib/Driver/ToolChains/Clang.cpp
> +++ lib/Driver/ToolChains/Clang.cpp
> @@ -2152,6 +2152,9 @@
>}
>CmdArgs.push_back(Value.data());
>TakeNextArg = true;
> +  } else if (Value == "-fdebug-compilation-dir") {
> +CmdArgs.push_back("-fdebug-compilation-dir");
> +TakeNextArg = true;
>} else {
>  D.Diag(diag::err_drv_unsupported_option_argument)
>  << A->getOption().getName() << Value;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r348131 - [AST] Fix an uninitialized bug in the bits of FunctionDecl

[David Blaikie via cfe-commits]

Ah, thanks for the explanation! No worries about pre-commit review or
anything - this is what post-commit review is :) Only note for the future
is that it might be worth mentioning in the body of the commit message
(title/first line was fine) so it's clear why this "extra" work is being
done.

Thanks!
- Dave

On Tue, Dec 4, 2018 at 7:54 AM Bruno Ricci  wrote:

> There is two reasons for this change:
>
> 1.) The first one is that the bit FunctionDeclBits.IsCopyDeductionCandidate
> is only used by CXXDeductionGuideDecl and so there is no getter/setter
> for it in FunctionDecl, and it would not make sense to add one.
> This is a legacy of when these bits where stored in FunctionDecl
> itself.
>
> 2.) The second one is that some of these setter do a little bit more than
> initializing the appropriate bit. For example setInlineSpecified sets
> both
> FunctionDeclBits.IsInlineSpecified and FunctionDeclBits.IsInline, but
> a quick
> reading of the body of the constructor of FunctionDecl would lead
> someone to
> believe that FunctionDeclBits.IsInline is not initialized.
>
> However these are not strong reasons, and I can revert it to use the
> setters
> instead if preferred. My apologies if it would have been preferable to
> review
> it first. It seemed obvious to me and I was familiar with this piece of
> code
> since I did the change a few month ago, but I am still trying to fine tune
> this decision process.
>
> Cheers,
>
> Bruno
>
> On 03/12/2018 22:01, David Blaikie wrote:
> > Why the change from using setter functions to direct assignment?
> >
> > On Mon, Dec 3, 2018 at 5:06 AM Bruno Ricci via cfe-commits <
> cfe-commits@lists.llvm.org > wrote:
> >
> > Author: brunoricci
> > Date: Mon Dec  3 05:04:10 2018
> > New Revision: 348131
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=348131=rev
> > Log:
> > [AST] Fix an uninitialized bug in the bits of FunctionDecl
> >
> > FunctionDeclBits.IsCopyDeductionCandidate was not initialized.
> > This caused a warning with valgrind.
> >
> >
> > Modified:
> > cfe/trunk/lib/AST/Decl.cpp
> >
> > Modified: cfe/trunk/lib/AST/Decl.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=348131=348130=348131=diff
> >
>  
> ==
> > --- cfe/trunk/lib/AST/Decl.cpp (original)
> > +++ cfe/trunk/lib/AST/Decl.cpp Mon Dec  3 05:04:10 2018
> > @@ -2653,27 +2653,29 @@ FunctionDecl::FunctionDecl(Kind DK, ASTC
> >DeclContext(DK), redeclarable_base(C), ODRHash(0),
> >EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
> >assert(T.isNull() || T->isFunctionType());
> > -  setStorageClass(S);
> > -  setInlineSpecified(isInlineSpecified);
> > -  setExplicitSpecified(false);
> > -  setVirtualAsWritten(false);
> > -  setPure(false);
> > -  setHasInheritedPrototype(false);
> > -  setHasWrittenPrototype(true);
> > -  setDeletedAsWritten(false);
> > -  setTrivial(false);
> > -  setTrivialForCall(false);
> > -  setDefaulted(false);
> > -  setExplicitlyDefaulted(false);
> > -  setHasImplicitReturnZero(false);
> > -  setLateTemplateParsed(false);
> > -  setConstexpr(isConstexprSpecified);
> > -  setInstantiationIsPending(false);
> > -  setUsesSEHTry(false);
> > -  setHasSkippedBody(false);
> > -  setWillHaveBody(false);
> > -  setIsMultiVersion(false);
> > -  setHasODRHash(false);
> > +  FunctionDeclBits.SClass = S;
> > +  FunctionDeclBits.IsInline = isInlineSpecified;
> > +  FunctionDeclBits.IsInlineSpecified = isInlineSpecified;
> > +  FunctionDeclBits.IsExplicitSpecified = false;
> > +  FunctionDeclBits.IsVirtualAsWritten = false;
> > +  FunctionDeclBits.IsPure = false;
> > +  FunctionDeclBits.HasInheritedPrototype = false;
> > +  FunctionDeclBits.HasWrittenPrototype = true;
> > +  FunctionDeclBits.IsDeleted = false;
> > +  FunctionDeclBits.IsTrivial = false;
> > +  FunctionDeclBits.IsTrivialForCall = false;
> > +  FunctionDeclBits.IsDefaulted = false;
> > +  FunctionDeclBits.IsExplicitlyDefaulted = false;
> > +  FunctionDeclBits.HasImplicitReturnZero = false;
> > +  FunctionDeclBits.IsLateTemplateParsed = false;
> > +  FunctionDeclBits.IsConstexpr = isConstexprSpecified;
> > +  FunctionDeclBits.InstantiationIsPending = false;
> > +  FunctionDeclBits.UsesSEHTry = false;
> > +  FunctionDeclBits.HasSkippedBody = false;
> > +  FunctionDeclBits.WillHaveBody = false;
> > +  FunctionDeclBits.IsMultiVersion = false;
> > +  FunctionDeclBits.IsCopyDeductionCandidate = false;
> > +  FunctionDeclBits.HasODRHash = false;
> >  }
> >
> >  void FunctionDecl::getNameForDiagnostic(
> >
> >
> > ___
> > cfe-commits 

Re: r348131 - [AST] Fix an uninitialized bug in the bits of FunctionDecl

[David Blaikie via cfe-commits]

Why the change from using setter functions to direct assignment?

On Mon, Dec 3, 2018 at 5:06 AM Bruno Ricci via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: brunoricci
> Date: Mon Dec  3 05:04:10 2018
> New Revision: 348131
>
> URL: http://llvm.org/viewvc/llvm-project?rev=348131=rev
> Log:
> [AST] Fix an uninitialized bug in the bits of FunctionDecl
>
> FunctionDeclBits.IsCopyDeductionCandidate was not initialized.
> This caused a warning with valgrind.
>
>
> Modified:
> cfe/trunk/lib/AST/Decl.cpp
>
> Modified: cfe/trunk/lib/AST/Decl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=348131=348130=348131=diff
>
> ==
> --- cfe/trunk/lib/AST/Decl.cpp (original)
> +++ cfe/trunk/lib/AST/Decl.cpp Mon Dec  3 05:04:10 2018
> @@ -2653,27 +2653,29 @@ FunctionDecl::FunctionDecl(Kind DK, ASTC
>DeclContext(DK), redeclarable_base(C), ODRHash(0),
>EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
>assert(T.isNull() || T->isFunctionType());
> -  setStorageClass(S);
> -  setInlineSpecified(isInlineSpecified);
> -  setExplicitSpecified(false);
> -  setVirtualAsWritten(false);
> -  setPure(false);
> -  setHasInheritedPrototype(false);
> -  setHasWrittenPrototype(true);
> -  setDeletedAsWritten(false);
> -  setTrivial(false);
> -  setTrivialForCall(false);
> -  setDefaulted(false);
> -  setExplicitlyDefaulted(false);
> -  setHasImplicitReturnZero(false);
> -  setLateTemplateParsed(false);
> -  setConstexpr(isConstexprSpecified);
> -  setInstantiationIsPending(false);
> -  setUsesSEHTry(false);
> -  setHasSkippedBody(false);
> -  setWillHaveBody(false);
> -  setIsMultiVersion(false);
> -  setHasODRHash(false);
> +  FunctionDeclBits.SClass = S;
> +  FunctionDeclBits.IsInline = isInlineSpecified;
> +  FunctionDeclBits.IsInlineSpecified = isInlineSpecified;
> +  FunctionDeclBits.IsExplicitSpecified = false;
> +  FunctionDeclBits.IsVirtualAsWritten = false;
> +  FunctionDeclBits.IsPure = false;
> +  FunctionDeclBits.HasInheritedPrototype = false;
> +  FunctionDeclBits.HasWrittenPrototype = true;
> +  FunctionDeclBits.IsDeleted = false;
> +  FunctionDeclBits.IsTrivial = false;
> +  FunctionDeclBits.IsTrivialForCall = false;
> +  FunctionDeclBits.IsDefaulted = false;
> +  FunctionDeclBits.IsExplicitlyDefaulted = false;
> +  FunctionDeclBits.HasImplicitReturnZero = false;
> +  FunctionDeclBits.IsLateTemplateParsed = false;
> +  FunctionDeclBits.IsConstexpr = isConstexprSpecified;
> +  FunctionDeclBits.InstantiationIsPending = false;
> +  FunctionDeclBits.UsesSEHTry = false;
> +  FunctionDeclBits.HasSkippedBody = false;
> +  FunctionDeclBits.WillHaveBody = false;
> +  FunctionDeclBits.IsMultiVersion = false;
> +  FunctionDeclBits.IsCopyDeductionCandidate = false;
> +  FunctionDeclBits.HasODRHash = false;
>  }
>
>  void FunctionDecl::getNameForDiagnostic(
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r347588 - Revert "[clang][slh] add attribute for speculative load hardening"

[David Blaikie via cfe-commits]

Also, including the SVN revision (llvm's util/git-svn/git-svnrevert script
can help with this) is helpful for other folks following along who may not
be using git.

On Mon, Nov 26, 2018 at 12:19 PM Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Mon, Nov 26, 2018 at 3:13 PM Zola Bridges via cfe-commits
>  wrote:
> >
> > Author: zbrid
> > Date: Mon Nov 26 12:11:18 2018
> > New Revision: 347588
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=347588=rev
> > Log:
> > Revert "[clang][slh] add attribute for speculative load hardening"
> >
> > This reverts commit 801eaf91221ba6dd6996b29ff82659ad6359e885.
>
> Next time you revert something, can you add an explanation as to why
> it was reverted into the commit message? It helps when doing code
> archaeology.
>
> Thanks!
>
> ~Aaron
>
> >
> > Removed:
> > cfe/trunk/test/CodeGen/attr-speculative-load-hardening.cpp
> > cfe/trunk/test/CodeGen/attr-speculative-load-hardening.m
> > cfe/trunk/test/SemaCXX/attr-speculative-load-hardening.cpp
> > Modified:
> > cfe/trunk/include/clang/Basic/Attr.td
> > cfe/trunk/include/clang/Basic/AttrDocs.td
> > cfe/trunk/lib/CodeGen/CGCall.cpp
> > cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> >
> > Modified: cfe/trunk/include/clang/Basic/Attr.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=347588=347587=347588=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/Attr.td (original)
> > +++ cfe/trunk/include/clang/Basic/Attr.td Mon Nov 26 12:11:18 2018
> > @@ -3091,9 +3091,3 @@ def AlwaysDestroy : InheritableAttr {
> >let Subjects = SubjectList<[Var]>;
> >let Documentation = [AlwaysDestroyDocs];
> >  }
> > -
> > -def SpeculativeLoadHardening : InheritableAttr {
> > -  let Spellings = [Clang<"speculative_load_hardening">];
> > -  let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
> > -  let Documentation = [SpeculativeLoadHardeningDocs];
> > -}
> >
> > Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=347588=347587=347588=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> > +++ cfe/trunk/include/clang/Basic/AttrDocs.td Mon Nov 26 12:11:18 2018
> > @@ -3629,27 +3629,3 @@ GNU inline semantics are the default beh
> >  ``-std=c89``, ``-std=c94``, or ``-fgnu89-inline``.
> >}];
> >  }
> > -
> > -def SpeculativeLoadHardeningDocs : Documentation {
> > -  let Category = DocCatFunction;
> > -  let Content = [{
> > -  This attribute can be applied to a function declaration in order to
> indicate
> > -  that `Speculative Load Hardening <
> https://llvm.org/docs/SpeculativeLoadHardening.html>`_
> > -  should be enabled for the function body. This can also be applied to
> a method
> > -  in Objective C.
> > -
> > -  Speculative Load Hardening is a best-effort mitigation against
> > -  information leak attacks that make use of control flow
> > -  miss-speculation - specifically miss-speculation of whether a branch
> > -  is taken or not. Typically vulnerabilities enabling such attacks are
> > -  classified as "Spectre variant #1". Notably, this does not attempt to
> > -  mitigate against miss-speculation of branch target, classified as
> > -  "Spectre variant #2" vulnerabilities.
> > -
> > -  When inlining, the attribute is sticky. Inlining a function that
> > -  carries this attribute will cause the caller to gain the
> > -  attribute. This is intended to provide a maximally conservative model
> > -  where the code in a function annotated with this attribute will always
> > -  (even after inlining) end up hardened.
> > -  }];
> > -}
> >
> > Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=347588=347587=347588=diff
> >
> ==
> > --- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Nov 26 12:11:18 2018
> > @@ -1791,8 +1791,6 @@ void CodeGenModule::ConstructDefaultFnAt
> >  if (CodeGenOpts.Backchain)
> >FuncAttrs.addAttribute("backchain");
> >
> > -// FIXME: The interaction of this attribute with the SLH command
> line flag
> > -// has not been determined.
> >  if (CodeGenOpts.SpeculativeLoadHardening)
> >FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);
> >}
> > @@ -1856,8 +1854,6 @@ void CodeGenModule::ConstructAttributeLi
> >FuncAttrs.addAttribute(llvm::Attribute::NoDuplicate);
> >  if (TargetDecl->hasAttr())
> >FuncAttrs.addAttribute(llvm::Attribute::Convergent);
> > -if (TargetDecl->hasAttr())
> > -  FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);
> >
> >  if (const FunctionDecl 

Re: r347035 - [clang] - Simplify tools::SplitDebugName.

[David Blaikie via cfe-commits]

Just copying some of the information given through Phab (
https://reviews.llvm.org/rL347035 ) - this patch was reverted in r347676.
Would be great to get that fixed/recommitted!

On Fri, Nov 16, 2018 at 12:01 AM George Rimar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: grimar
> Date: Thu Nov 15 23:59:24 2018
> New Revision: 347035
>
> URL: http://llvm.org/viewvc/llvm-project?rev=347035=rev
> Log:
> [clang] - Simplify tools::SplitDebugName.
>
> This should be NFC change.
>
> SplitDebugName recently started to accept the `Output` that
> can be used to simplify the logic a bit, also it
> seems that code in SplitDebugName that uses
> OPT_fdebug_compilation_dir is simply dead.
>
> Differential revision: https://reviews.llvm.org/D54576
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
> cfe/trunk/lib/Driver/ToolChains/CommonArgs.h
> cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
> cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=347035=347034=347035=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Thu Nov 15 23:59:24 2018
> @@ -3936,7 +3936,7 @@ void Clang::ConstructJob(Compilation ,
>const char *SplitDWARFOut;
>if (SplitDWARF) {
>  CmdArgs.push_back("-split-dwarf-file");
> -SplitDWARFOut = SplitDebugName(Args, Input, Output);
> +SplitDWARFOut = SplitDebugName(Args, Output);
>  CmdArgs.push_back(SplitDWARFOut);
>}
>
> @@ -5902,7 +5902,7 @@ void ClangAs::ConstructJob(Compilation &
>if ((getDebugFissionKind(D, Args, A) == DwarfFissionKind::Split) &&
>(T.isOSLinux() || T.isOSFuchsia())) {
>  CmdArgs.push_back("-split-dwarf-file");
> -CmdArgs.push_back(SplitDebugName(Args, Input, Output));
> +CmdArgs.push_back(SplitDebugName(Args, Output));
>}
>
>assert(Input.isFilename() && "Invalid input.");
>
> Modified: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp?rev=347035=347034=347035=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp Thu Nov 15 23:59:24 2018
> @@ -808,26 +808,15 @@ bool tools::areOptimizationsEnabled(cons
>return false;
>  }
>
> -const char *tools::SplitDebugName(const ArgList , const InputInfo
> ,
> +const char *tools::SplitDebugName(const ArgList ,
>const InputInfo ) {
>if (Arg *A = Args.getLastArg(options::OPT_gsplit_dwarf_EQ))
>  if (StringRef(A->getValue()) == "single")
>return Args.MakeArgString(Output.getFilename());
>
> -  Arg *FinalOutput = Args.getLastArg(options::OPT_o);
> -  if (FinalOutput && Args.hasArg(options::OPT_c)) {
> -SmallString<128> T(FinalOutput->getValue());
> -llvm::sys::path::replace_extension(T, "dwo");
> -return Args.MakeArgString(T);
> -  } else {
> -// Use the compilation dir.
> -SmallString<128> T(
> -Args.getLastArgValue(options::OPT_fdebug_compilation_dir));
> -SmallString<128> F(llvm::sys::path::stem(Input.getBaseInput()));
> -llvm::sys::path::replace_extension(F, "dwo");
> -T += F;
> -return Args.MakeArgString(F);
> -  }
> +  SmallString<128> T(Output.getFilename());
> +  llvm::sys::path::replace_extension(T, "dwo");
> +  return Args.MakeArgString(T);
>  }
>
>  void tools::SplitDebugInfo(const ToolChain , Compilation , const
> Tool ,
>
> Modified: cfe/trunk/lib/Driver/ToolChains/CommonArgs.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CommonArgs.h?rev=347035=347034=347035=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/CommonArgs.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.h Thu Nov 15 23:59:24 2018
> @@ -63,7 +63,7 @@ void AddHIPLinkerScript(const ToolChain
>  const Tool );
>
>  const char *SplitDebugName(const llvm::opt::ArgList ,
> -   const InputInfo , const InputInfo
> );
> +   const InputInfo );
>
>  void SplitDebugInfo(const ToolChain , Compilation , const Tool ,
>  const JobAction , const llvm::opt::ArgList ,
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=347035=347034=347035=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Thu Nov 15 23:59:24 

r347141 - Sink BuryPointer from Clang into LLVM for reuse there

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Sat Nov 17 10:04:13 2018
New Revision: 347141

URL: http://llvm.org/viewvc/llvm-project?rev=347141=rev
Log:
Sink BuryPointer from Clang into LLVM for reuse there

Modified:
cfe/trunk/include/clang/Frontend/CompilerInstance.h
cfe/trunk/include/clang/Frontend/Utils.h
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/FrontendAction.cpp
cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp
cfe/trunk/tools/driver/cc1_main.cpp

Modified: cfe/trunk/include/clang/Frontend/CompilerInstance.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CompilerInstance.h?rev=347141=347140=347141=diff
==
--- cfe/trunk/include/clang/Frontend/CompilerInstance.h (original)
+++ cfe/trunk/include/clang/Frontend/CompilerInstance.h Sat Nov 17 10:04:13 2018
@@ -22,6 +22,7 @@
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/BuryPointer.h"
 #include 
 #include 
 #include 
@@ -411,7 +412,7 @@ public:
   }
 
   void resetAndLeakFileManager() {
-BuryPointer(FileMgr.get());
+llvm::BuryPointer(FileMgr.get());
 FileMgr.resetWithoutRelease();
   }
 
@@ -431,7 +432,7 @@ public:
   }
 
   void resetAndLeakSourceManager() {
-BuryPointer(SourceMgr.get());
+llvm::BuryPointer(SourceMgr.get());
 SourceMgr.resetWithoutRelease();
   }
 
@@ -453,7 +454,7 @@ public:
   std::shared_ptr getPreprocessorPtr() { return PP; }
 
   void resetAndLeakPreprocessor() {
-BuryPointer(new std::shared_ptr(PP));
+llvm::BuryPointer(new std::shared_ptr(PP));
   }
 
   /// Replace the current preprocessor.
@@ -471,7 +472,7 @@ public:
   }
 
   void resetAndLeakASTContext() {
-BuryPointer(Context.get());
+llvm::BuryPointer(Context.get());
 Context.resetWithoutRelease();
   }
 

Modified: cfe/trunk/include/clang/Frontend/Utils.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/Utils.h?rev=347141=347140=347141=diff
==
--- cfe/trunk/include/clang/Frontend/Utils.h (original)
+++ cfe/trunk/include/clang/Frontend/Utils.h Sat Nov 17 10:04:13 2018
@@ -226,14 +226,6 @@ inline uint64_t getLastArgUInt64Value(co
   return getLastArgUInt64Value(Args, Id, Default, );
 }
 
-// When Clang->getFrontendOpts().DisableFree is set we don't delete some of the
-// global objects, but we don't want LeakDetectors to complain, so we bury them
-// in a globally visible array.
-void BuryPointer(const void *Ptr);
-template  void BuryPointer(std::unique_ptr Ptr) {
-  BuryPointer(Ptr.release());
-}
-
 // Frontend timing utils
 
 /// If the user specifies the -ftime-report argument on an Clang command line

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=347141=347140=347141=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Sat Nov 17 10:04:13 2018
@@ -37,6 +37,7 @@
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/SubtargetFeature.h"
 #include "llvm/Passes/PassBuilder.h"
+#include "llvm/Support/BuryPointer.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/PrettyStackTrace.h"

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=347141=347140=347141=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Sat Nov 17 10:04:13 2018
@@ -38,6 +38,7 @@
 #include "clang/Serialization/ASTReader.h"
 #include "clang/Serialization/GlobalModuleIndex.h"
 #include "llvm/ADT/Statistic.h"
+#include "llvm/Support/BuryPointer.h"
 #include "llvm/Support/CrashRecoveryContext.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/FileSystem.h"
@@ -2132,7 +2133,7 @@ CompilerInstance::lookupMissingImports(S
 
   return false;
 }
-void CompilerInstance::resetAndLeakSema() { BuryPointer(takeSema()); }
+void CompilerInstance::resetAndLeakSema() { llvm::BuryPointer(takeSema()); }
 
 void CompilerInstance::setExternalSemaSource(
 IntrusiveRefCntPtr ESS) {

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=347141=347140=347141=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Sat Nov 17 10:04:13 2018
@@ -3299,21 +3299,6 @@ 

r346929 - NFC cleanup: Prefer make_unique over reset(new T())

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Nov 14 19:04:23 2018
New Revision: 346929

URL: http://llvm.org/viewvc/llvm-project?rev=346929=rev
Log:
NFC cleanup: Prefer make_unique over reset(new T())

Modified:
cfe/trunk/lib/Parse/ParsePragma.cpp

Modified: cfe/trunk/lib/Parse/ParsePragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParsePragma.cpp?rev=346929=346928=346929=diff
==
--- cfe/trunk/lib/Parse/ParsePragma.cpp (original)
+++ cfe/trunk/lib/Parse/ParsePragma.cpp Wed Nov 14 19:04:23 2018
@@ -261,119 +261,122 @@ struct PragmaAttributeHandler : public P
 }  // end namespace
 
 void Parser::initializePragmaHandlers() {
-  AlignHandler.reset(new PragmaAlignHandler());
+  AlignHandler = llvm::make_unique();
   PP.AddPragmaHandler(AlignHandler.get());
 
-  GCCVisibilityHandler.reset(new PragmaGCCVisibilityHandler());
+  GCCVisibilityHandler = llvm::make_unique();
   PP.AddPragmaHandler("GCC", GCCVisibilityHandler.get());
 
-  OptionsHandler.reset(new PragmaOptionsHandler());
+  OptionsHandler = llvm::make_unique();
   PP.AddPragmaHandler(OptionsHandler.get());
 
-  PackHandler.reset(new PragmaPackHandler());
+  PackHandler = llvm::make_unique();
   PP.AddPragmaHandler(PackHandler.get());
 
-  MSStructHandler.reset(new PragmaMSStructHandler());
+  MSStructHandler = llvm::make_unique();
   PP.AddPragmaHandler(MSStructHandler.get());
 
-  UnusedHandler.reset(new PragmaUnusedHandler());
+  UnusedHandler = llvm::make_unique();
   PP.AddPragmaHandler(UnusedHandler.get());
 
-  WeakHandler.reset(new PragmaWeakHandler());
+  WeakHandler = llvm::make_unique();
   PP.AddPragmaHandler(WeakHandler.get());
 
-  RedefineExtnameHandler.reset(new PragmaRedefineExtnameHandler());
+  RedefineExtnameHandler = llvm::make_unique();
   PP.AddPragmaHandler(RedefineExtnameHandler.get());
 
-  FPContractHandler.reset(new PragmaFPContractHandler());
+  FPContractHandler = llvm::make_unique();
   PP.AddPragmaHandler("STDC", FPContractHandler.get());
 
-  STDCFENVHandler.reset(new PragmaSTDC_FENV_ACCESSHandler());
+  STDCFENVHandler = llvm::make_unique();
   PP.AddPragmaHandler("STDC", STDCFENVHandler.get());
 
-  STDCCXLIMITHandler.reset(new PragmaSTDC_CX_LIMITED_RANGEHandler());
+  STDCCXLIMITHandler = llvm::make_unique();
   PP.AddPragmaHandler("STDC", STDCCXLIMITHandler.get());
 
-  STDCUnknownHandler.reset(new PragmaSTDC_UnknownHandler());
+  STDCUnknownHandler = llvm::make_unique();
   PP.AddPragmaHandler("STDC", STDCUnknownHandler.get());
 
-  PCSectionHandler.reset(new PragmaClangSectionHandler(Actions));
+  PCSectionHandler = llvm::make_unique(Actions);
   PP.AddPragmaHandler("clang", PCSectionHandler.get());
 
   if (getLangOpts().OpenCL) {
-OpenCLExtensionHandler.reset(new PragmaOpenCLExtensionHandler());
+OpenCLExtensionHandler = llvm::make_unique();
 PP.AddPragmaHandler("OPENCL", OpenCLExtensionHandler.get());
 
 PP.AddPragmaHandler("OPENCL", FPContractHandler.get());
   }
   if (getLangOpts().OpenMP)
-OpenMPHandler.reset(new PragmaOpenMPHandler());
+OpenMPHandler = llvm::make_unique();
   else
-OpenMPHandler.reset(new PragmaNoOpenMPHandler());
+OpenMPHandler = llvm::make_unique();
   PP.AddPragmaHandler(OpenMPHandler.get());
 
   if (getLangOpts().MicrosoftExt ||
   getTargetInfo().getTriple().isOSBinFormatELF()) {
-MSCommentHandler.reset(new PragmaCommentHandler(Actions));
+MSCommentHandler = llvm::make_unique(Actions);
 PP.AddPragmaHandler(MSCommentHandler.get());
   }
 
   if (getLangOpts().MicrosoftExt) {
-MSDetectMismatchHandler.reset(new PragmaDetectMismatchHandler(Actions));
+MSDetectMismatchHandler =
+llvm::make_unique(Actions);
 PP.AddPragmaHandler(MSDetectMismatchHandler.get());
-MSPointersToMembers.reset(new PragmaMSPointersToMembers());
+MSPointersToMembers = llvm::make_unique();
 PP.AddPragmaHandler(MSPointersToMembers.get());
-MSVtorDisp.reset(new PragmaMSVtorDisp());
+MSVtorDisp = llvm::make_unique();
 PP.AddPragmaHandler(MSVtorDisp.get());
-MSInitSeg.reset(new PragmaMSPragma("init_seg"));
+MSInitSeg = llvm::make_unique("init_seg");
 PP.AddPragmaHandler(MSInitSeg.get());
-MSDataSeg.reset(new PragmaMSPragma("data_seg"));
+MSDataSeg = llvm::make_unique("data_seg");
 PP.AddPragmaHandler(MSDataSeg.get());
-MSBSSSeg.reset(new PragmaMSPragma("bss_seg"));
+MSBSSSeg = llvm::make_unique("bss_seg");
 PP.AddPragmaHandler(MSBSSSeg.get());
-MSConstSeg.reset(new PragmaMSPragma("const_seg"));
+MSConstSeg = llvm::make_unique("const_seg");
 PP.AddPragmaHandler(MSConstSeg.get());
-MSCodeSeg.reset(new PragmaMSPragma("code_seg"));
+MSCodeSeg = llvm::make_unique("code_seg");
 PP.AddPragmaHandler(MSCodeSeg.get());
-MSSection.reset(new PragmaMSPragma("section"));
+MSSection = llvm::make_unique("section");
 PP.AddPragmaHandler(MSSection.get());
-MSRuntimeChecks.reset(new 

r346926 - Stmt bits: Make ExprBits relative to StmtBits

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Nov 14 19:04:18 2018
New Revision: 346926

URL: http://llvm.org/viewvc/llvm-project?rev=346926=rev
Log:
Stmt bits: Make ExprBits relative to StmtBits

Seems like it makes it a bit easier to read/validate/update in the
future.

Modified:
cfe/trunk/include/clang/AST/Stmt.h

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=346926=346925=346926=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Wed Nov 14 19:04:18 2018
@@ -312,7 +312,7 @@ protected:
 unsigned InstantiationDependent : 1;
 unsigned ContainsUnexpandedParameterPack : 1;
   };
-  enum { NumExprBits = 17 };
+  enum { NumExprBits = NumStmtBits + 9 };
 
   class PredefinedExprBitfields {
 friend class ASTStmtReader;


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

r346927 - Rewrite-imports on crash: Simplify handling

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Nov 14 19:04:19 2018
New Revision: 346927

URL: http://llvm.org/viewvc/llvm-project?rev=346927=rev
Log:
Rewrite-imports on crash: Simplify handling

-frewrite-imports already implies -frewrite-includes (it piggy-backs
on/extends the implementation) so there's no need to conditionally pass
-frewrite-includes when already using -frewrite-imports (& especially I
don't think these would want to be different between crash reporting and
not crash reporting)

Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=346927=346926=346927=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Wed Nov 14 19:04:19 2018
@@ -4916,7 +4916,7 @@ void Clang::ConstructJob(Compilation ,
   // nice to enable this when doing a crashdump for modules as well.
   if (Args.hasFlag(options::OPT_frewrite_includes,
options::OPT_fno_rewrite_includes, false) ||
-  (C.isForDiagnostics() && (RewriteImports || !HaveModules)))
+  (C.isForDiagnostics() && !HaveModules))
 CmdArgs.push_back("-frewrite-includes");
 
   // Only allow -traditional or -traditional-cpp outside in preprocessing 
modes.


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

r346928 - Fix combining pragma __debug dump & parser_crash with -E

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Nov 14 19:04:21 2018
New Revision: 346928

URL: http://llvm.org/viewvc/llvm-project?rev=346928=rev
Log:
Fix combining pragma __debug dump & parser_crash with -E

Previously these would be transformed into annotation tokens and the
preprocessor would then assume they were real tokens with source
locations and assert/UB.

Other pragmas that produce annotation tokens aren't a problem because
they aren't handled if the parser isn't hooked up - ParsePragma.cpp
registers those handlers & isn't run for pure preprocessing. So they're
treated as unknown pragmas & printed verbatim by the preprocessor.

Perhaps these pragmas should be treated the same way? But they got mixed
in with other __debug pragmas that do need to be handled during
preprocessing.

The third __debug pragma that produces an annotation token is 'captured'
- which had its own fix for this issue - by not inserting the annotation
token in the first place if it detected that it was in preprocessing
mode. I've removed that fix (from Lex/Pragma.cpp) in favor of the more
general one in Frontend/PrintPreprocessedOutput.cpp.

Added:
cfe/trunk/test/Preprocessor/pragma.c
Modified:
cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
cfe/trunk/lib/Lex/Pragma.cpp

Modified: cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=346928=346927=346928=diff
==
--- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp (original)
+++ cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp Wed Nov 14 19:04:21 2018
@@ -750,6 +750,11 @@ static void PrintPreprocessedTokens(Prep
   reinterpret_cast(Tok.getAnnotationValue()));
   PP.Lex(Tok);
   continue;
+} else if (Tok.isAnnotation()) {
+  // Ignore annotation tokens created by pragmas - the pragmas themselves
+  // will be reproduced in the preprocessed output.
+  PP.Lex(Tok);
+  continue;
 } else if (IdentifierInfo *II = Tok.getIdentifierInfo()) {
   OS << II->getName();
 } else if (Tok.isLiteral() && !Tok.needsCleaning() &&

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=346928=346927=346928=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Wed Nov 14 19:04:21 2018
@@ -1130,10 +1130,6 @@ struct PragmaDebugHandler : public Pragm
   }
 
   void HandleCaptured(Preprocessor ) {
-// Skip if emitting preprocessed output.
-if (PP.isPreprocessedOutput())
-  return;
-
 Token Tok;
 PP.LexUnexpandedToken(Tok);
 

Added: cfe/trunk/test/Preprocessor/pragma.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/pragma.c?rev=346928=auto
==
--- cfe/trunk/test/Preprocessor/pragma.c (added)
+++ cfe/trunk/test/Preprocessor/pragma.c Wed Nov 14 19:04:21 2018
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -E %s | FileCheck %s
+
+#pragma clang __debug parser_crash
+#pragma clang __debug dump Test
+
+// CHECK: #pragma clang __debug parser_crash
+// FIXME: The dump parameter is dropped.
+// CHECK: #pragma clang __debug dump{{$}}


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

r346789 - DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Nov 13 12:08:13 2018
New Revision: 346789

URL: http://llvm.org/viewvc/llvm-project?rev=346789=rev
Log:
DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.

Summary:
This saves a lot of relocations in optimized object files (at the cost
of some cost/increase in linked executable bytes), but gold's 32 bit
gdb-index support has a bug (
https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't
switch to this unconditionally. (& even if it weren't for that bug, one
might argue that some users would want to optimize in one direction or
the other - prioritizing object size or linked executable size)

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

Added:
cfe/trunk/test/CodeGen/debug-info-ranges-base-address.c
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/debug-options.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=346789=346788=346789=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Nov 13 12:08:13 2018
@@ -1780,6 +1780,10 @@ def fdebug_types_section: Flag <["-"], "
   Flags<[CC1Option]>, HelpText<"Place debug types in their own section (ELF 
Only)">;
 def fno_debug_types_section: Flag<["-"], "fno-debug-types-section">, 
Group,
   Flags<[CC1Option]>;
+def fdebug_ranges_base_address: Flag <["-"], "fdebug-ranges-base-address">, 
Group,
+  Flags<[CC1Option]>, HelpText<"Use DWARF base address selection entries in 
debug_ranges">;
+def fno_debug_ranges_base_address: Flag <["-"], 
"fno-debug-ranges-base-address">, Group,
+  Flags<[CC1Option]>;
 def fsplit_dwarf_inlining: Flag <["-"], "fsplit-dwarf-inlining">, 
Group,
   Flags<[CC1Option]>, HelpText<"Provide minimal debug info in the 
object/executable to facilitate online symbolication/stack traces in the 
absence of .dwo/.dwp files when using Split DWARF">;
 def fno_split_dwarf_inlining: Flag<["-"], "fno-split-dwarf-inlining">, 
Group,

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=346789=346788=346789=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Tue Nov 13 12:08:13 2018
@@ -331,6 +331,9 @@ CODEGENOPT(PreserveVec3Type, 1, 0)
 /// Whether to emit .debug_gnu_pubnames section instead of .debug_pubnames.
 CODEGENOPT(DebugNameTable, 2, 0)
 
+/// Whether to use DWARF base address specifiers in .debug_ranges.
+CODEGENOPT(DebugRangesBaseAddress, 1, 0)
+
 CODEGENOPT(NoPLT, 1, 0)
 
 /// Whether to embed source in DWARF debug line section.

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=346789=346788=346789=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Nov 13 12:08:13 2018
@@ -586,7 +586,8 @@ void CGDebugInfo::CreateCompileUnit() {
   CGM.getTarget().getTriple().isNVPTX()
   ? llvm::DICompileUnit::DebugNameTableKind::None
   : static_cast(
-CGOpts.DebugNameTable));
+CGOpts.DebugNameTable),
+  CGOpts.DebugRangesBaseAddress);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) {

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=346789=346788=346789=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Tue Nov 13 12:08:13 2018
@@ -3188,6 +3188,11 @@ static void RenderDebugOptions(const Too
 ? "-gpubnames"
 : "-ggnu-pubnames");
 
+  if (Args.hasFlag(options::OPT_fdebug_ranges_base_address,
+   options::OPT_fno_debug_ranges_base_address, false)) {
+CmdArgs.push_back("-fdebug-ranges-base-address");
+  }
+
   // -gdwarf-aranges turns on the emission of the aranges section in the
   // backend.
   // Always enabled for SCE tuning.

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=346789=346788=346789=diff
==
--- 

Re: r346266 - Don't use std::next() on an input iterator; NFC.

[David Blaikie via cfe-commits]

Thanks!

On Mon, Nov 12, 2018 at 2:14 PM Aaron Ballman 
wrote:

> On Mon, Nov 12, 2018 at 1:30 PM David Blaikie  wrote:
> >
> > The previous code didn't have a conditional for Iter != End - was that a
> bug? Should there be a test case for that bug?
> >
> > If that's not an actual change in behavior, could it be an assert
> instead of a condition?
>
> I think an assertion would make the most sense. I can't devise a way
> where there wouldn't be at least a root path and a file name, so
> skipping over the root component should always be okay. I'll fix that
> up.
>
> ~Aaron
>
> >
> > On Tue, Nov 6, 2018 at 1:14 PM Aaron Ballman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >>
> >> Author: aaronballman
> >> Date: Tue Nov  6 13:12:44 2018
> >> New Revision: 346266
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=346266=rev
> >> Log:
> >> Don't use std::next() on an input iterator; NFC.
> >>
> >> Instead, advance the old-fashioned way, as std::next() cannot be used
> on an input iterator until C++17.
> >>
> >> Modified:
> >> cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
> >>
> >> Modified: cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
> >> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp?rev=346266=346265=346266=diff
> >>
> ==
> >> --- cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp (original)
> >> +++ cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp Tue Nov  6
> 13:12:44 2018
> >> @@ -82,25 +82,27 @@ static std::string fileNameToURI(StringR
> >>  Ret += Twine("/" + Root).str();
> >>}
> >>
> >> -  // Add the rest of the path components, encoding any reserved
> characters.
> >> -  std::for_each(std::next(sys::path::begin(Filename)),
> sys::path::end(Filename),
> >> -[](StringRef Component) {
> >> -  // For reasons unknown to me, we may get a backslash
> with
> >> -  // Windows native paths for the initial backslash
> following
> >> -  // the drive component, which we need to ignore as a
> URI path
> >> -  // part.
> >> -  if (Component == "\\")
> >> -return;
> >> +  auto Iter = sys::path::begin(Filename), End =
> sys::path::end(Filename);
> >> +  if (Iter != End) {
> >> +// Add the rest of the path components, encoding any reserved
> characters;
> >> +// we skip past the first path component, as it was handled it
> above.
> >> +std::for_each(++Iter, End, [](StringRef Component) {
> >> +  // For reasons unknown to me, we may get a backslash with
> Windows native
> >> +  // paths for the initial backslash following the drive
> component, which
> >> +  // we need to ignore as a URI path part.
> >> +  if (Component == "\\")
> >> +return;
> >>
> >> -  // Add the separator between the previous path part
> and the
> >> -  // one being currently processed.
> >> -  Ret += "/";
> >> +  // Add the separator between the previous path part and the one
> being
> >> +  // currently processed.
> >> +  Ret += "/";
> >>
> >> -  // URI encode the part.
> >> -  for (char C : Component) {
> >> -Ret += percentEncodeURICharacter(C);
> >> -  }
> >> -});
> >> +  // URI encode the part.
> >> +  for (char C : Component) {
> >> +Ret += percentEncodeURICharacter(C);
> >> +  }
> >> +});
> >> +  }
> >>
> >>return Ret.str().str();
> >>  }
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r346266 - Don't use std::next() on an input iterator; NFC.

[David Blaikie via cfe-commits]

The previous code didn't have a conditional for Iter != End - was that a
bug? Should there be a test case for that bug?

If that's not an actual change in behavior, could it be an assert instead
of a condition?

On Tue, Nov 6, 2018 at 1:14 PM Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: aaronballman
> Date: Tue Nov  6 13:12:44 2018
> New Revision: 346266
>
> URL: http://llvm.org/viewvc/llvm-project?rev=346266=rev
> Log:
> Don't use std::next() on an input iterator; NFC.
>
> Instead, advance the old-fashioned way, as std::next() cannot be used on
> an input iterator until C++17.
>
> Modified:
> cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp?rev=346266=346265=346266=diff
>
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp Tue Nov  6
> 13:12:44 2018
> @@ -82,25 +82,27 @@ static std::string fileNameToURI(StringR
>  Ret += Twine("/" + Root).str();
>}
>
> -  // Add the rest of the path components, encoding any reserved
> characters.
> -  std::for_each(std::next(sys::path::begin(Filename)),
> sys::path::end(Filename),
> -[](StringRef Component) {
> -  // For reasons unknown to me, we may get a backslash
> with
> -  // Windows native paths for the initial backslash
> following
> -  // the drive component, which we need to ignore as a
> URI path
> -  // part.
> -  if (Component == "\\")
> -return;
> +  auto Iter = sys::path::begin(Filename), End = sys::path::end(Filename);
> +  if (Iter != End) {
> +// Add the rest of the path components, encoding any reserved
> characters;
> +// we skip past the first path component, as it was handled it above.
> +std::for_each(++Iter, End, [](StringRef Component) {
> +  // For reasons unknown to me, we may get a backslash with Windows
> native
> +  // paths for the initial backslash following the drive component,
> which
> +  // we need to ignore as a URI path part.
> +  if (Component == "\\")
> +return;
>
> -  // Add the separator between the previous path part and
> the
> -  // one being currently processed.
> -  Ret += "/";
> +  // Add the separator between the previous path part and the one
> being
> +  // currently processed.
> +  Ret += "/";
>
> -  // URI encode the part.
> -  for (char C : Component) {
> -Ret += percentEncodeURICharacter(C);
> -  }
> -});
> +  // URI encode the part.
> +  for (char C : Component) {
> +Ret += percentEncodeURICharacter(C);
> +  }
> +});
> +  }
>
>return Ret.str().str();
>  }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r346439 - [Frontend/Modules] Show diagnostics on prebuilt module configuration mismatch too

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Nov  8 12:47:30 2018
New Revision: 346439

URL: http://llvm.org/viewvc/llvm-project?rev=346439=rev
Log:
[Frontend/Modules] Show diagnostics on prebuilt module configuration mismatch 
too

The current version only emits  the below error for a module (attempted to be 
loaded) from the `prebuilt-module-path`:

```
error: module file blabla.pcm cannot be loaded due to a configuration mismatch 
with the current compilation [-Wmodule-file-config-mismatch]
```

With this change, if the prebuilt module is used, we allow the proper 
diagnostic behind the configuration mismatch to be shown.

```
error: POSIX thread support was disabled in PCH file but is currently enabled
error: module file blabla.pcm cannot be loaded due to a configuration mismatch 
with the current compilation [-Wmodule-file-config-mismatch]
```

(A few lines later an error is emitted anyways, so there is no reason not to 
complain for configuration mismatches if a config mismatch is found and kills 
the build.)

Reviewed By: dblaikie

Tags: #clang

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

Added:
cfe/trunk/test/Modules/mismatch-diagnostics.cpp
Modified:
cfe/trunk/lib/Frontend/CompilerInstance.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=346439=346438=346439=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Thu Nov  8 12:47:30 2018
@@ -1727,7 +1727,9 @@ CompilerInstance::loadModule(SourceLocat
 // module cache, we don't know how to rebuild modules.
 unsigned ARRFlags = Source == ModuleCache ?
 ASTReader::ARR_OutOfDate | ASTReader::ARR_Missing :
-ASTReader::ARR_ConfigurationMismatch;
+Source == PrebuiltModulePath ?
+0 :
+ASTReader::ARR_ConfigurationMismatch;
 switch (ModuleManager->ReadAST(ModuleFileName,
Source == PrebuiltModulePath
? serialization::MK_PrebuiltModule

Added: cfe/trunk/test/Modules/mismatch-diagnostics.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/mismatch-diagnostics.cpp?rev=346439=auto
==
--- cfe/trunk/test/Modules/mismatch-diagnostics.cpp (added)
+++ cfe/trunk/test/Modules/mismatch-diagnostics.cpp Thu Nov  8 12:47:30 2018
@@ -0,0 +1,22 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t/prebuilt_modules
+//
+// RUN: %clang_cc1 -triple %itanium_abi_triple  \
+// RUN: -fmodules-ts -fprebuilt-module-path=%t/prebuilt-modules \
+// RUN: -emit-module-interface -pthread -DBUILD_MODULE  \
+// RUN: %s -o %t/prebuilt_modules/mismatching_module.pcm
+//
+// RUN: not %clang_cc1 -triple %itanium_abi_triple -fmodules-ts \
+// RUN: -fprebuilt-module-path=%t/prebuilt_modules -DCHECK_MISMATCH \
+// RUN: %s 2>&1 | FileCheck %s
+
+#ifdef BUILD_MODULE
+export module mismatching_module;
+#endif
+
+#ifdef CHECK_MISMATCH
+import mismatching_module;
+// CHECK: error: POSIX thread support was enabled in PCH file but is currently 
disabled
+// CHECK-NEXT: module file {{.*}}/mismatching_module.pcm cannot be loaded due 
to a configuration mismatch with the current compilation
+#endif
+


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

Re: r342827 - Fix modules build with shared library.

[David Blaikie via cfe-commits]

Shuai - have you had a chance to look at this?

On Mon, Oct 22, 2018 at 4:43 PM Richard Smith  wrote:

> On Mon, 22 Oct 2018 at 14:57, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Richard - any further thoughts here (re: layering/dependencies, etc)?
>> Would love to get the layering oddity fixed rather than having it get more
>> embedded over time.
>>
>
> Here's the intended current directory layout and layering as I understand
> it:
>
>  * include/clang/Analysis and lib/Analysis are the parts of the static
> analysis engine that are depended on by both Sema and StaticAnalyzer, and
> include common functionality / infrastructure
>  * include/clang/Analysis/Analyses and lib/Analysis/Analyses are the
> specific Sema analyses (that don't depend on the static analyzer);
> StaticAnalyzer should not need to depend on this
>  * the StaticAnalyzer library should contain all the pieces that are
> specific to the static analyzer
>  * Sema should not depend on Tooling, but it's fine for StaticAnalyzer to
> depend on Tooling
>
> Compared to where we are today, there are two differences:
>
> 1) The implementations of the headers in include/clang/Analysis are in
> lib/Analysis, not in lib/Analysis/Analyses
> 2) ExprMutationAnalyzer is in lib/Analysis despite not being part of the
> common infrastructure depended on by Sema and StaticAnalyzer
>
> For point 1, we should change the lib/Analysis directory layout to match
> the headers.
> For point 2, we should find a home for this ExprMutationAnalyzer code that
> makes sense. Given that the intent is to use it from the static analyzer,
> that seems like a reasonable home for it, but libTooling would also make
> some sense (perhaps a new subdirectory Tooling/Analysis), since it's only
> performing AST matching, not a flow-sensitive / path-sensitive static
> analysis.
>
> On Tue, Oct 2, 2018 at 2:44 PM Shuai Wang via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Mon, Oct 1, 2018 at 4:58 PM Richard Smith 
>>> wrote:
>>>
>>>> On Mon, 1 Oct 2018 at 16:10, George Karpenkov via cfe-commits <
>>>> cfe-commits@lists.llvm.org> wrote:
>>>>
>>>>> Hi Richard,
>>>>>
>>>>> On Oct 1, 2018, at 2:50 PM, Richard Smith via cfe-commits <
>>>>> cfe-commits@lists.llvm.org> wrote:
>>>>>
>>>>> This looks like the wrong fix to me, but I don't really know enough
>>>>> about what's being done with ExprMutationAnalyzer to have an opinion on
>>>>> what the right fix is.
>>>>>
>>>>> Shuai, what is the goal here? Why is this code being moved to
>>>>> Analysis/?
>>>>>
>>>>>
>>>>> I’ve asked for this possibility, as I wanted to use it from the Clang
>>>>> static analyzer.
>>>>>
>>>>> Do you intend to call it from the compiler frontend at some point? I
>>>>> can see a code review for the move itself, but no discussion of a plan or
>>>>> overall direction being followed here. Did I miss it?
>>>>>
>>>>> We have historically decided to not use the tooling interfaces
>>>>> (ASTMatcher, ParentMap, etc) from the frontend,
>>>>>
>>>>>
>>>>> Clang analyzer uses ASTMatcher all over the place.
>>>>>
>>>>> because they're generally a poor fit for our goals (we aim for a
>>>>> largely-single-pass compilation with good locality, and the AST matchers
>>>>> make different design choices)
>>>>>
>>>>>
>>>>> That’s totally good for the analyzer though, right?
>>>>>
>>>>
>>>> Yes, that all seems fine for the static analyzer.
>>>>
>>>>
>>>>> In any case, in future it might make sense to move the analyzer out of
>>>>> Clang proper.
>>>>> But for know the only way to use clang-tidy utilities from the
>>>>> analyzer is to move them into Clang.
>>>>>
>>>>
>>>> Right. I think we should try to maintain the idea that all the Clang
>>>> Static Analyzer-specific things are in lib/StaticAnalyzer, and lib/Analysis
>>>> only contains things depended on by the frontend. (That is: the things a
>>>> clang binary would use if we didn't link in the static analyzer)
>>>>
>>>> Given the above, I think the best approach would be to move this code
>>>> out of lib/Analysis an

Re: r345591 - [CodeGen] Disable the machine verifier on a ThinLTO test

[David Blaikie via cfe-commits]

If ThinLTO doesn't pass the machine verifier - should it maybe be turned
off at the thinlto level in general, rather than for this specific test?

On Tue, Oct 30, 2018 at 5:20 AM Francis Visoiu Mistrih via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: thegameg
> Date: Tue Oct 30 05:18:33 2018
> New Revision: 345591
>
> URL: http://llvm.org/viewvc/llvm-project?rev=345591=rev
> Log:
> [CodeGen] Disable the machine verifier on a ThinLTO test
>
> This allows us to turn the machine verifier on by default on X86.
>
> Modified:
> cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll
>
> Modified: cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll?rev=345591=345590=345591=diff
>
> ==
> --- cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll (original)
> +++ cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll Tue Oct 30
> 05:18:33 2018
> @@ -6,7 +6,9 @@
>
>  ; RUN: opt -thinlto-bc -o %t.o %s
>
> +; FIXME: Fix machine verifier issues and remove -verify-machineinstrs=0.
> PR39436.
>  ; RUN: llvm-lto2 run -thinlto-distributed-indexes %t.o \
> +; RUN:   -verify-machineinstrs=0 \
>  ; RUN:   -o %t2.index \
>  ; RUN:   -r=%t.o,test,px \
>  ; RUN:   -r=%t.o,_ZN1A1nEi,p \
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r345695 - Change "struct" to "class" to avoid warnings

[David Blaikie via cfe-commits]

Could you link to/quote the warnings - might be helpful to understanding
what's being addressed here

On Tue, Oct 30, 2018 at 10:00 PM Bill Wendling via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: void
> Date: Tue Oct 30 21:58:34 2018
> New Revision: 345695
>
> URL: http://llvm.org/viewvc/llvm-project?rev=345695=rev
> Log:
> Change "struct" to "class" to avoid warnings
>
> Modified:
> cfe/trunk/include/clang/AST/Expr.h
>
> Modified: cfe/trunk/include/clang/AST/Expr.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Expr.h?rev=345695=345694=345695=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Expr.h (original)
> +++ cfe/trunk/include/clang/AST/Expr.h Tue Oct 30 21:58:34 2018
> @@ -900,7 +900,8 @@ public:
>  };
>
>  /// ConstantExpr - An expression that occurs in a constant context.
> -struct ConstantExpr : public FullExpr {
> +class ConstantExpr : public FullExpr {
> +public:
>ConstantExpr(Expr *subexpr)
>  : FullExpr(ConstantExprClass, subexpr) {}
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r345109 - Debug Info (-gmodules): emit full types for non-anchored template specializations

[David Blaikie via cfe-commits]

Fair enough - pity we couldn't readily have a single implementation or at
least semantics for modular debug info between implicit and explicit modes
(I mean, my fault in part for building a separate/new system when I did
modular codegen anyway) but hopefully we'll move to explicit modules across
the board in the future anyway & standardize there.

Thanks for the context!

On Mon, Oct 29, 2018 at 12:32 PM Adrian Prantl  wrote:

>
>
> > On Oct 29, 2018, at 11:26 AM, David Blaikie  wrote:
> >
> > Is this a workaround for now with the intent to fix this to allow such
> implicit specializations to have their debug info modularized? I believe
> this does work correctly in modular debug info with expliict modules, would
> probably be sort of nice to have these things be consistent/similar?
>
> It started as a workaround, but I reached the conclusion that it's not
> worthwhile pursuing a more space-efficient solution. Note that all this
> patch does is emit plain old non-modular debug info for non-explicit
> template specializations, so it is definitely safe & conservative. This
> increases the size of the clang module cache in a build of clang by 4MiB
> out of 1GiB total.
>
> As you can read in my thread with Richard, it isn't possible in Clang to
> determine the clang module that contains the complete definition of a
> template specialization inside of a namespace for indirectly imported
> modules (such as in my testcase). That means that a consumer would have to
> look in every Clang module for complete types; not just in the transitive
> closure of imports of the .pcm that has the forward declaration. This
> lookup is expensive and difficult to implement in LLDB, so I decided not to
> pursue this further.
>
> -- adrian
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r344957 - Give Multiversion-inline functions linkonce linkage

[David Blaikie via cfe-commits]

On Mon, Oct 29, 2018 at 11:46 AM Keane, Erich  wrote:

>
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Monday, October 29, 2018 11:41 AM
> *To:* Keane, Erich 
> *Cc:* Eric Christopher ; cfe-commits@lists.llvm.org
>
>
> *Subject:* Re: r344957 - Give Multiversion-inline functions linkonce
> linkage
>
>
>
>
>
> On Mon, Oct 29, 2018 at 11:30 AM Keane, Erich 
> wrote:
>
> GCC actually doesn’t support function multiversioning in C mode, so this
> fix is part of our extension to support C with multiversioning.
>
>
> Ah, what's the motivation for that?
>
> *[Keane, Erich] Basically, I identified no good reason to not support it.
> GCC’s motivation is lost to time as far as I can tell.  This
> multiversioning is super useful in my employer’s math/intrinsic libraries
> (MKL uses this feature extensively), so enabling it in C seemed like a
> positive improvement.  We’ve made some other behavioral changes to make
> ‘target’ work more sanely to suppress some of the worst bugs (becoming MV
> after usage) as well as make it work better with Clang’s
> emit-functionality.*
>
>
>
>
>   I perhaps wonder if this is part of the reason GCC only supports it in
> C++ mode...
>
>
> Yeah... could be.
>
> I mean I suppose using linkonce isn't making multiversioning any worse in
> C than it already is in C++ inline functions (which is where it's pretty
> easy to misuse, as I understand it - two files, one compiled with a CPU
> feature, one without, linkonce functions get linked together & the linker
> picks one - then code built without the feature calls code that uses the
> feature - but, I mean, that can happen even witohut multiversioning, if you
> compile some source files with a feature and some without) - I guess the
> main risk would be if it confuses users by making multiversioned C inline
> functions end up behaving too differently from non-multiversioned ones...
>
> *[Keane, Erich] I suspect that multiversioning is such a sharp edged
> feature, that a change like this makes it a touch more sane.  Since the
> individual versions are independently mangled, you don’t have to worry
> about merging different versions.  The only real issue comes from merging
> the resolver functions if the visible list of declarations is different,
> but we treat that as an ODR violation.*
>
>
>
Rightio - thanks for all the context (:


>
> - Dave
>
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Monday, October 29, 2018 11:25 AM
> *To:* Keane, Erich ; Eric Christopher <
> echri...@gmail.com>
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: r344957 - Give Multiversion-inline functions linkonce
> linkage
>
>
>
> Does this match GCC's approach here?
>
> (I ask this sort of as throwaway/conversation starter - because the
> linkage/behavior around multiversion functions and their inlining is full
> of sharp corners/risks of code moving out of the areas appropriately
> restricted based on the cpu features)
>
> On Mon, Oct 22, 2018 at 2:22 PM Erich Keane via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: erichkeane
> Date: Mon Oct 22 14:20:45 2018
> New Revision: 344957
>
> URL: http://llvm.org/viewvc/llvm-project?rev=344957=rev
> Log:
> Give Multiversion-inline functions linkonce linkage
>
> Since multiversion variant functions can be inline, in C they become
> available-externally linkage.  This ends up causing the variants to not
> be emitted, and not available to the linker.
>
> The solution is to make sure that multiversion functions are always
> emitted by marking them linkonce.
>
> Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75
>
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/test/CodeGen/attr-target-mv.c
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=344957=344956=344957=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Oct 22 14:20:45 2018
> @@ -3669,6 +3669,10 @@ llvm::GlobalValue::LinkageTypes CodeGenM
>return llvm::GlobalVariable::WeakAnyLinkage;
>}
>
> +  if (const auto *FD = D->getAsFunction())
> +if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
> +  return llvm::GlobalVariable::LinkOnceAnyLinkage;
> +
>// We are guaranteed to have a strong definition somewhere else,
>// so we can use available_externally linkage.
>if (Linkage == GVA_AvailableExternally)
>
> Modified: cfe/trunk/test/CodeGen/attr-target-mv.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target-mv.c?rev=344957=344956=344957=diff
>
> ==
> --- cfe/trunk/test/CodeGen/attr-target-mv.c (original)
> +++ cfe/trunk/test/CodeGen/attr-target-mv.c Mon Oct 22 14:20:45 2018
> @@ -88,19 +88,19 @@ void bar4() {

Re: r344957 - Give Multiversion-inline functions linkonce linkage

[David Blaikie via cfe-commits]

On Mon, Oct 29, 2018 at 11:30 AM Keane, Erich  wrote:

> GCC actually doesn’t support function multiversioning in C mode, so this
> fix is part of our extension to support C with multiversioning.
>

Ah, what's the motivation for that?


>   I perhaps wonder if this is part of the reason GCC only supports it in
> C++ mode...
>

Yeah... could be.

I mean I suppose using linkonce isn't making multiversioning any worse in C
than it already is in C++ inline functions (which is where it's pretty easy
to misuse, as I understand it - two files, one compiled with a CPU feature,
one without, linkonce functions get linked together & the linker picks one
- then code built without the feature calls code that uses the feature -
but, I mean, that can happen even witohut multiversioning, if you compile
some source files with a feature and some without) - I guess the main risk
would be if it confuses users by making multiversioned C inline functions
end up behaving too differently from non-multiversioned ones...

- Dave


>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Monday, October 29, 2018 11:25 AM
> *To:* Keane, Erich ; Eric Christopher <
> echri...@gmail.com>
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: r344957 - Give Multiversion-inline functions linkonce
> linkage
>
>
>
> Does this match GCC's approach here?
>
> (I ask this sort of as throwaway/conversation starter - because the
> linkage/behavior around multiversion functions and their inlining is full
> of sharp corners/risks of code moving out of the areas appropriately
> restricted based on the cpu features)
>
> On Mon, Oct 22, 2018 at 2:22 PM Erich Keane via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: erichkeane
> Date: Mon Oct 22 14:20:45 2018
> New Revision: 344957
>
> URL: http://llvm.org/viewvc/llvm-project?rev=344957=rev
> Log:
> Give Multiversion-inline functions linkonce linkage
>
> Since multiversion variant functions can be inline, in C they become
> available-externally linkage.  This ends up causing the variants to not
> be emitted, and not available to the linker.
>
> The solution is to make sure that multiversion functions are always
> emitted by marking them linkonce.
>
> Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75
>
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/test/CodeGen/attr-target-mv.c
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=344957=344956=344957=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Oct 22 14:20:45 2018
> @@ -3669,6 +3669,10 @@ llvm::GlobalValue::LinkageTypes CodeGenM
>return llvm::GlobalVariable::WeakAnyLinkage;
>}
>
> +  if (const auto *FD = D->getAsFunction())
> +if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
> +  return llvm::GlobalVariable::LinkOnceAnyLinkage;
> +
>// We are guaranteed to have a strong definition somewhere else,
>// so we can use available_externally linkage.
>if (Linkage == GVA_AvailableExternally)
>
> Modified: cfe/trunk/test/CodeGen/attr-target-mv.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target-mv.c?rev=344957=344956=344957=diff
>
> ==
> --- cfe/trunk/test/CodeGen/attr-target-mv.c (original)
> +++ cfe/trunk/test/CodeGen/attr-target-mv.c Mon Oct 22 14:20:45 2018
> @@ -88,19 +88,19 @@ void bar4() {
>
>  // CHECK: declare i32 @foo.arch_sandybridge()
>
> -// CHECK: define available_externally i32 @foo_inline.sse4.2()
> +// CHECK: define linkonce i32 @foo_inline.sse4.2()
>  // CHECK: ret i32 0
>
>  // CHECK: declare i32 @foo_inline.arch_sandybridge()
>  //
> -// CHECK: define available_externally i32 @foo_inline.arch_ivybridge()
> +// CHECK: define linkonce i32 @foo_inline.arch_ivybridge()
>  // CHECK: ret i32 1
> -// CHECK: define available_externally i32 @foo_inline()
> +// CHECK: define linkonce i32 @foo_inline()
>  // CHECK: ret i32 2
>
> -// CHECK: define available_externally void @foo_decls()
> -// CHECK: define available_externally void @foo_decls.sse4.2()
> +// CHECK: define linkonce void @foo_decls()
> +// CHECK: define linkonce void @foo_decls.sse4.2()
>
> -// CHECK: define available_externally void @foo_multi.avx_sse4.2()
> -// CHECK: define available_externally void @foo_multi.fma4_sse4.2()
> -// CHECK: define available_externally void
> @foo_multi.arch_ivybridge_fma4_sse4.2()
> +// CHECK: define linkonce void @foo_multi.avx_sse4.2()
> +// CHECK: define linkonce void @foo_multi.fma4_sse4.2()
> +// CHECK: define linkonce void @foo_multi.arch_ivybridge_fma4_sse4.2()
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> 

Re: r345109 - Debug Info (-gmodules): emit full types for non-anchored template specializations

[David Blaikie via cfe-commits]

Is this a workaround for now with the intent to fix this to allow such
implicit specializations to have their debug info modularized? I believe
this does work correctly in modular debug info with expliict modules, would
probably be sort of nice to have these things be consistent/similar?

On Tue, Oct 23, 2018 at 5:08 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Tue Oct 23 17:06:02 2018
> New Revision: 345109
>
> URL: http://llvm.org/viewvc/llvm-project?rev=345109=rev
> Log:
> Debug Info (-gmodules): emit full types for non-anchored template
> specializations
>
> Before this patch, clang would emit a (module-)forward declaration for
> template instantiations that are not anchored by an explicit template
> instantiation, but still are guaranteed to be available in an imported
> module. Unfortunately detecting the owning module doesn't reliably
> work when local submodule visibility is enabled and the template is
> inside a cross-module namespace.
>
> This make clang debuggable again with -gmodules and LSV enabled.
>
> rdar://problem/41552377
>
> Added:
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/A/
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/A/ADT.h
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/B/
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/B/B.h
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/C/
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/C/C.h
> cfe/trunk/test/Modules/Inputs/lsv-debuginfo/module.modulemap
> cfe/trunk/test/Modules/lsv-debuginfo.cpp   (with props)
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/test/Modules/ExtDebugInfo.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=345109=345108=345109=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Oct 23 17:06:02 2018
> @@ -1955,8 +1955,17 @@ static bool isDefinedInClangModule(const
>if (auto *CXXDecl = dyn_cast(RD)) {
>  if (!CXXDecl->isCompleteDefinition())
>return false;
> +// Check wether RD is a template.
>  auto TemplateKind = CXXDecl->getTemplateSpecializationKind();
>  if (TemplateKind != TSK_Undeclared) {
> +  // Unfortunately getOwningModule() isn't accurate enough to find the
> +  // owning module of a ClassTemplateSpecializationDecl that is
> inside a
> +  // namespace spanning multiple modules.
> +  bool Explicit = false;
> +  if (auto *TD = dyn_cast(CXXDecl))
> +Explicit = TD->isExplicitInstantiationOrSpecialization();
> +  if (!Explicit && CXXDecl->getEnclosingNamespaceContext())
> +return false;
>// This is a template, check the origin of the first member.
>if (CXXDecl->field_begin() == CXXDecl->field_end())
>  return TemplateKind == TSK_ExplicitInstantiationDeclaration;
>
> Modified: cfe/trunk/test/Modules/ExtDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ExtDebugInfo.cpp?rev=345109=345108=345109=diff
>
> ==
> --- cfe/trunk/test/Modules/ExtDebugInfo.cpp (original)
> +++ cfe/trunk/test/Modules/ExtDebugInfo.cpp Tue Oct 23 17:06:02 2018
> @@ -83,11 +83,11 @@ void foo() {
>  // CHECK: ![[NS]] = !DINamespace(name: "DebugCXX", scope: ![[MOD:[0-9]+]])
>  // CHECK: ![[MOD]] = !DIModule(scope: null, name: {{.*}}DebugCXX
>
> -// This type is anchored in the module by an explicit template
> instantiation.
> +// This type is not anchored in the module by an explicit template
> instantiation.
>  // CHECK: !DICompositeType(tag: DW_TAG_class_type,
>  // CHECK-SAME: name: "Template
> >",
>  // CHECK-SAME: scope: ![[NS]],
> -// CHECK-SAME: flags: DIFlagFwdDecl,
> +// CHECK-SAME: elements:
>  // CHECK-SAME: identifier:
> "_ZTSN8DebugCXX8TemplateIlNS_6traitsIl")
>
>  // This type is anchored in the module by an explicit template
> instantiation.
>
> Added: cfe/trunk/test/Modules/Inputs/lsv-debuginfo/A/ADT.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/lsv-debuginfo/A/ADT.h?rev=345109=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/lsv-debuginfo/A/ADT.h (added)
> +++ cfe/trunk/test/Modules/Inputs/lsv-debuginfo/A/ADT.h Tue Oct 23
> 17:06:02 2018
> @@ -0,0 +1,45 @@
> +#ifndef ADT
> +#define ADT
> +
> +#ifdef WITH_NAMESPACE
> +namespace llvm {
> +#endif
> +template 
> +struct AlignedCharArray {
> +  alignas(Alignment) char buffer[Size];
> +};
> +
> +template 
> +class AlignerImpl {
> +  T1 t1;
> +};
> +
> +template 
> +union SizerImpl {
> +  char arr1[sizeof(T1)];
> +};
> +
> +template 
> +struct 

Re: r344957 - Give Multiversion-inline functions linkonce linkage

[David Blaikie via cfe-commits]

Does this match GCC's approach here?

(I ask this sort of as throwaway/conversation starter - because the
linkage/behavior around multiversion functions and their inlining is full
of sharp corners/risks of code moving out of the areas appropriately
restricted based on the cpu features)

On Mon, Oct 22, 2018 at 2:22 PM Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Mon Oct 22 14:20:45 2018
> New Revision: 344957
>
> URL: http://llvm.org/viewvc/llvm-project?rev=344957=rev
> Log:
> Give Multiversion-inline functions linkonce linkage
>
> Since multiversion variant functions can be inline, in C they become
> available-externally linkage.  This ends up causing the variants to not
> be emitted, and not available to the linker.
>
> The solution is to make sure that multiversion functions are always
> emitted by marking them linkonce.
>
> Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75
>
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/test/CodeGen/attr-target-mv.c
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=344957=344956=344957=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Oct 22 14:20:45 2018
> @@ -3669,6 +3669,10 @@ llvm::GlobalValue::LinkageTypes CodeGenM
>return llvm::GlobalVariable::WeakAnyLinkage;
>}
>
> +  if (const auto *FD = D->getAsFunction())
> +if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
> +  return llvm::GlobalVariable::LinkOnceAnyLinkage;
> +
>// We are guaranteed to have a strong definition somewhere else,
>// so we can use available_externally linkage.
>if (Linkage == GVA_AvailableExternally)
>
> Modified: cfe/trunk/test/CodeGen/attr-target-mv.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target-mv.c?rev=344957=344956=344957=diff
>
> ==
> --- cfe/trunk/test/CodeGen/attr-target-mv.c (original)
> +++ cfe/trunk/test/CodeGen/attr-target-mv.c Mon Oct 22 14:20:45 2018
> @@ -88,19 +88,19 @@ void bar4() {
>
>  // CHECK: declare i32 @foo.arch_sandybridge()
>
> -// CHECK: define available_externally i32 @foo_inline.sse4.2()
> +// CHECK: define linkonce i32 @foo_inline.sse4.2()
>  // CHECK: ret i32 0
>
>  // CHECK: declare i32 @foo_inline.arch_sandybridge()
>  //
> -// CHECK: define available_externally i32 @foo_inline.arch_ivybridge()
> +// CHECK: define linkonce i32 @foo_inline.arch_ivybridge()
>  // CHECK: ret i32 1
> -// CHECK: define available_externally i32 @foo_inline()
> +// CHECK: define linkonce i32 @foo_inline()
>  // CHECK: ret i32 2
>
> -// CHECK: define available_externally void @foo_decls()
> -// CHECK: define available_externally void @foo_decls.sse4.2()
> +// CHECK: define linkonce void @foo_decls()
> +// CHECK: define linkonce void @foo_decls.sse4.2()
>
> -// CHECK: define available_externally void @foo_multi.avx_sse4.2()
> -// CHECK: define available_externally void @foo_multi.fma4_sse4.2()
> -// CHECK: define available_externally void
> @foo_multi.arch_ivybridge_fma4_sse4.2()
> +// CHECK: define linkonce void @foo_multi.avx_sse4.2()
> +// CHECK: define linkonce void @foo_multi.fma4_sse4.2()
> +// CHECK: define linkonce void @foo_multi.arch_ivybridge_fma4_sse4.2()
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r342827 - Fix modules build with shared library.

[David Blaikie via cfe-commits]

Richard - any further thoughts here (re: layering/dependencies, etc)? Would
love to get the layering oddity fixed rather than having it get more
embedded over time.

On Tue, Oct 2, 2018 at 2:44 PM Shuai Wang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Mon, Oct 1, 2018 at 4:58 PM Richard Smith 
> wrote:
>
>> On Mon, 1 Oct 2018 at 16:10, George Karpenkov via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> On Oct 1, 2018, at 2:50 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>> This looks like the wrong fix to me, but I don't really know enough
>>> about what's being done with ExprMutationAnalyzer to have an opinion on
>>> what the right fix is.
>>>
>>> Shuai, what is the goal here? Why is this code being moved to Analysis/?
>>>
>>>
>>> I’ve asked for this possibility, as I wanted to use it from the Clang
>>> static analyzer.
>>>
>>> Do you intend to call it from the compiler frontend at some point? I can
>>> see a code review for the move itself, but no discussion of a plan or
>>> overall direction being followed here. Did I miss it?
>>>
>>> We have historically decided to not use the tooling interfaces
>>> (ASTMatcher, ParentMap, etc) from the frontend,
>>>
>>>
>>> Clang analyzer uses ASTMatcher all over the place.
>>>
>>> because they're generally a poor fit for our goals (we aim for a
>>> largely-single-pass compilation with good locality, and the AST matchers
>>> make different design choices)
>>>
>>>
>>> That’s totally good for the analyzer though, right?
>>>
>>
>> Yes, that all seems fine for the static analyzer.
>>
>>
>>> In any case, in future it might make sense to move the analyzer out of
>>> Clang proper.
>>> But for know the only way to use clang-tidy utilities from the analyzer
>>> is to move them into Clang.
>>>
>>
>> Right. I think we should try to maintain the idea that all the Clang
>> Static Analyzer-specific things are in lib/StaticAnalyzer, and lib/Analysis
>> only contains things depended on by the frontend. (That is: the things a
>> clang binary would use if we didn't link in the static analyzer)
>>
>> Given the above, I think the best approach would be to move this code out
>> of lib/Analysis and into somewhere in lib/StaticAnalyzer. There shouldn't
>> be any problem with clang-tidy using it from there, since it already
>> depends on the static analyzer.
>>
> I'm happy to do the move.
> Could you (or someone) help point out where exactly I should move it to
> though?
>
>> . If you want to change that, we'll need to discuss that decision.
>>>
>>> If the idea is to move this code into clang proper so that it can be
>>> used by various different tooling clients, we'd need to discuss the right
>>> place for it. Perhaps lib/Tooling/Analysis would make sense?
>>>
>>>
>>> On Mon, 1 Oct 2018 at 13:13, David Blaikie via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> I can't really reproduce this - when I try to build clang/llvm with
>>>> LLVM_ENABLE_MODULES in CMake I'm still seeing an error I reported March on
>>>> a cfe-dev thread - something to do with unique_ptr instantiations for
>>>> MappedBlockStream in the PDB parsing code.
>>>>
>>>> So, I'm wondering what error you hit, Eric/where/how, etc...
>>>>
>>>> On Sun, Sep 30, 2018 at 10:23 AM Eric Fiselier  wrote:
>>>>
>>>>> +rsmith (actually this time)
>>>>>
>>>>> On Sun, Sep 30, 2018 at 12:09 PM Eric Fiselier  wrote:
>>>>>
>>>>>> +rsmith
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Sorry, I'm not actually sure why this fix is correct.I stole both the
>>>>>> fix and the comment from a similar one on L150 of the module map left by
>>>>>> Richard Smith.
>>>>>>
>>>>>> /Eric
>>>>>>
>>>>>> On Tue, Sep 25, 2018 at 8:36 PM Shuai Wang 
>>>>>> wrote:
>>>>>>
>>>>>>> I'd like to understand this better as well, in particular what would
>>>>>>> be a proper fix?
>>>>>>>
>>>>>>> On Tue, Sep 25, 2018 at 2:15 PM David Blaikie

Re: [PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

[David Blaikie via cfe-commits]

On Fri, Oct 19, 2018 at 3:56 PM Adrian Prantl via Phabricator via
llvm-commits  wrote:

> aprantl added a comment.
>
> I have a vague recollection that this column info hack was added to
> disambiguate two types defined on the same line (which is something that
> happened more often than one would think because of macro expansion). Did
> you do the git archeology to ensure that the original reason for doing it
> this way has been resolved? FWIW, I'm fine with doing this change for the
> Darwin platforms because column info is turned on by default, so this
> shouldn't affect us.
>

It was (I think) duplicate calls (rather than types) - so that inlining
(which previously didn't produce a unique'd inlinedAt location (because we
didn't have the "unique" metadata feature)) didn't collapse the
instructions from the two inlined calls into one.


>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D38061
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r342827 - Fix modules build with shared library.

[David Blaikie via cfe-commits]

I can't really reproduce this - when I try to build clang/llvm with
LLVM_ENABLE_MODULES in CMake I'm still seeing an error I reported March on
a cfe-dev thread - something to do with unique_ptr instantiations for
MappedBlockStream in the PDB parsing code.

So, I'm wondering what error you hit, Eric/where/how, etc...

On Sun, Sep 30, 2018 at 10:23 AM Eric Fiselier  wrote:

> +rsmith (actually this time)
>
> On Sun, Sep 30, 2018 at 12:09 PM Eric Fiselier  wrote:
>
>> +rsmith
>>
>> Hi All,
>>
>> Sorry, I'm not actually sure why this fix is correct.I stole both the fix
>> and the comment from a similar one on L150 of the module map left by
>> Richard Smith.
>>
>> /Eric
>>
>> On Tue, Sep 25, 2018 at 8:36 PM Shuai Wang  wrote:
>>
>>> I'd like to understand this better as well, in particular what would be
>>> a proper fix?
>>>
>>> On Tue, Sep 25, 2018 at 2:15 PM David Blaikie 
>>> wrote:
>>>
 +Shuai Wang

 On Tue, Sep 25, 2018 at 2:14 PM David Blaikie 
 wrote:

> Hey Eric - thanks for the fix - but could you explain the issue here
> in a bit more detail, as I'm a bit confused (& really interested in
> understanding any layering problems in LLVM - and fixing them/making sure
> they're fixed/holding the line/etc)
>
> What do you mean by "pull all of the AST matchers library into clang"
> - how does including a header ever add a link dependency?
>
> - Dave
>
>
> On Sat, Sep 22, 2018 at 5:49 PM Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ericwf
>> Date: Sat Sep 22 17:48:05 2018
>> New Revision: 342827
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=342827=rev
>> Log:
>> Fix modules build with shared library.
>>
>> r341994 caused clangAnalysis to pull all of the AST matchers
>> library into clang. Due to inline key functions in the headers,
>> importing the AST matchers library gives a link dependency on the
>> AST matchers (and thus the AST), which clang should not
>> have.
>>
>> This patch works around the issues by excluding the offending
>> libclangAnalysis header in the modulemap.
>>
>> Modified:
>> cfe/trunk/include/clang/module.modulemap
>>
>> Modified: cfe/trunk/include/clang/module.modulemap
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/module.modulemap?rev=342827=342826=342827=diff
>>
>> ==
>> --- cfe/trunk/include/clang/module.modulemap (original)
>> +++ cfe/trunk/include/clang/module.modulemap Sat Sep 22 17:48:05 2018
>> @@ -5,6 +5,12 @@ module Clang_Analysis {
>>textual header "Analysis/Analyses/ThreadSafetyOps.def"
>>
>>module * { export * }
>> +
>> +  // FIXME: Exclude these headers to avoid pulling all of the AST
>> matchers
>> +  // library into clang. Due to inline key functions in the headers,
>> +  // importing the AST matchers library gives a link dependency on
>> the AST
>> +  // matchers (and thus the AST), which clang-format should not have.
>> +  exclude header "Analysis/Analyses/ExprMutationAnalyzer.h"
>>  }
>>
>>  module Clang_AST {
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r343279 - [cxx2a] P0624R2: Lambdas with no capture-default are

[David Blaikie via cfe-commits]

Excellent, excellent - thanks!

On Mon, Oct 1, 2018 at 10:22 AM Richard Smith  wrote:

> On Mon, 1 Oct 2018, 09:55 David Blaikie via cfe-commits, <
> cfe-commits@lists.llvm.org> wrote:
>
>> Awesome - should/does this mean stateless lambdas can be used in
>> uninitialized contexts?
>>
>> std::set> })> s;
>>
>> Would be kind of neat/handy (so you didn't have to pass in the comparator
>> on construction, etc)
>>
>
> Not quite: that also needs p0315r4, but that's coming in C++20 too.
>
> On Thu, Sep 27, 2018 at 3:48 PM Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Thu Sep 27 15:47:04 2018
>>> New Revision: 343279
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=343279=rev
>>> Log:
>>> [cxx2a] P0624R2: Lambdas with no capture-default are
>>> default-constructible and assignable.
>>>
>>> Added:
>>> cfe/trunk/test/SemaCXX/cxx2a-lambda-default-ctor-assign.cpp
>>> Modified:
>>> cfe/trunk/include/clang/AST/DeclCXX.h
>>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>> cfe/trunk/lib/AST/DeclCXX.cpp
>>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>>> cfe/trunk/lib/Sema/SemaExpr.cpp
>>> cfe/trunk/test/SemaCXX/cxx17-compat.cpp
>>> cfe/trunk/www/cxx_status.html
>>>
>>> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=343279=343278=343279=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
>>> +++ cfe/trunk/include/clang/AST/DeclCXX.h Thu Sep 27 15:47:04 2018
>>> @@ -974,10 +974,7 @@ public:
>>>bool needsImplicitDefaultConstructor() const {
>>>  return !data().UserDeclaredConstructor &&
>>> !(data().DeclaredSpecialMembers & SMF_DefaultConstructor) &&
>>> -   // C++14 [expr.prim.lambda]p20:
>>> -   //   The closure type associated with a lambda-expression
>>> has no
>>> -   //   default constructor.
>>> -   !isLambda();
>>> +   (!isLambda() || lambdaIsDefaultConstructibleAndAssignable());
>>>}
>>>
>>>/// Determine whether this class has any user-declared constructors.
>>> @@ -1167,10 +1164,7 @@ public:
>>> !hasUserDeclaredCopyAssignment() &&
>>> !hasUserDeclaredMoveConstructor() &&
>>> !hasUserDeclaredDestructor() &&
>>> -   // C++1z [expr.prim.lambda]p21: "the closure type has a
>>> deleted copy
>>> -   // assignment operator". The intent is that this counts as a
>>> user
>>> -   // declared copy assignment, but we do not model it that way.
>>> -   !isLambda();
>>> +   (!isLambda() || lambdaIsDefaultConstructibleAndAssignable());
>>>}
>>>
>>>/// Determine whether we need to eagerly declare a move assignment
>>> @@ -1210,6 +1204,10 @@ public:
>>>/// a template).
>>>bool isGenericLambda() const;
>>>
>>> +  /// Determine whether this lambda should have an implicit default
>>> constructor
>>> +  /// and copy and move assignment operators.
>>> +  bool lambdaIsDefaultConstructibleAndAssignable() const;
>>> +
>>>/// Retrieve the lambda call operator of the closure type
>>>/// if this is a closure type.
>>>CXXMethodDecl *getLambdaCallOperator() const;
>>>
>>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=343279=343278=343279=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Sep 27
>>> 15:47:04 2018
>>> @@ -6633,6 +6633,11 @@ let CategoryName = "Lambda Issue" in {
>>>  InGroup, DefaultIgnore;
>>>def note_deprecated_this_capture : Note<
>>>  "add an explicit capture of 'this' to capture '*this' by
>>> reference">;
>>> +
>>> +  // C++2a default constructible / assigna