Re: [PATCH] D44883: [Sema] Extend -Wself-assign with -Wself-assign-overloaded to warn on overloaded self-assignment (classes)

[David Blaikie via cfe-commits]

Historically Clang's policy on warnings was, I think, much more
conservative than it seems to be today. There was a strong desire not to
implement off-by-default warnings, and to have warnings with an
exceptionally low false-positive rate - maybe the user-defined operator
detection was either assumed to, or demonstrated to, have a sufficiently
high false positive rate to not meet that high bar.

(as for the flag splitting - that was sometimes done if the new variant of
a flag had enough bug-finding power that an existing codebase using the
existing flag behavior would need significant cleanup - by having the new
functionality under another flag name, existing codebases upgrading to a
newer compiler wouldn't be forced to either do all that cleanup up-front or
disable the flag & risk regressions... )

On Mon, Mar 26, 2018 at 3:08 PM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D44883#1048689, @rjmccall wrote:
>
> > I tracked Chandler down, and he doesn't remember why user-defined
> operators are excluded.
>
>
> Ok then. Unless reviewers think it would be best to have separate diag
> groups for "builtin" and "user-provided" binary operators,
> i'll just extend the `-Wself-assign` / `-Wself-assign-field` /
> `-Wself-move` (i wonder, does it work both the fields and usual variables,
> or not).
>
> (That means, stage2 self-hosting testing will be needed...)
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D44883
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r328380 - Change for an LLVM header file move

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Mar 23 15:16:59 2018
New Revision: 328380

URL: http://llvm.org/viewvc/llvm-project?rev=328380&view=rev
Log:
Change for an LLVM header file move

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=328380&r1=328379&r2=328380&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Fri Mar 23 15:16:59 2018
@@ -46,13 +46,13 @@
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/Target/TargetOptions.h"
 #include "llvm/Transforms/Coroutines.h"
-#include "llvm/Transforms/GCOVProfiler.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/IPO/AlwaysInliner.h"
 #include "llvm/Transforms/IPO/PassManagerBuilder.h"
 #include "llvm/Transforms/IPO/ThinLTOBitcodeWriter.h"
 #include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Instrumentation/BoundsChecking.h"
+#include "llvm/Transforms/Instrumentation/GCOVProfiler.h"
 #include "llvm/Transforms/ObjCARC.h"
 #include "llvm/Transforms/Scalar.h"
 #include "llvm/Transforms/Scalar/GVN.h"


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

Re: [PATCH] D44826: Add -Wunused-using, a warning that finds unused using declarations.

[David Blaikie via cfe-commits]

While implementing the warning is great (wonder if there's any codebase
that isn't -Wunused-using clean, that we could use to compare Clang and
GCC's behavior broadly - make sure it's catching the same cases (or
justify/investigate differences)) - and using it to motivate the debug info
is an improvement to the debug info - it won't quite address all the wasted
debug info, unfortunately :/

Consider this:

namespace a {
  struct b;
};
namespace x {
  using a::b;
  inline void f(b*) {
  }
}

Now the using declaration is used, but if 'f' is never called in this
translation unit, it's a bit weird to produce debug info for the using decl
and could still substantially bloat debug info. (indeed most of the bloat
that the using decl/directive debug info is producing is probably from
directives that are used, but not in a way that's relevant to a certain
translation unit)

I've not looked at the change yet, but if it's particularly
expensive/complicated to wire up the debug info side, it might not be worth
it given it's probably not a significant savings & somewhat of a dead-end
compared to what would be needed for a more complete fix. But I guess it's
probably not expensive/complicated, so probably some fine low hanging fruit
to pick until a more complete fix/improvement is implemented.

On Fri, Mar 23, 2018 at 8:22 AM Carlos Alberto Enciso via Phabricator <
revi...@reviews.llvm.org> wrote:

> CarlosAlbertoEnciso added a comment.
>
> In https://reviews.llvm.org/D44826#1046671, @erichkeane wrote:
>
> > My opinion matters less than @rsmith or @dblaikie on the review, but it
> seems to me that Typedef and Using are SO similar that the implementations
> should just be combined.  You'd likely have to change a couple of types
> along the way to be more generic, but the implementations are essentially a
> copy/paste of eachother.
>
>
> That is a very valid point and it simplifies quite a lot the patch.
>
> If the other reviewers do not have any objection, I will combine both
> implementations and update the uploaded patch.
>
> Thanks,
> Carlos
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D44826
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[David Blaikie via cfe-commits]

The only data we have is that where .o files go, .dwo files go beside them.
How to generalize this to other situations isn't really obvious to me -
even for a.out (do you put all the .dwo files next to a.out? in the same
directory? if the names collide, where then? etc).

Interestingly GCC for "g++ foo.cpp" puts the foo.dwo file right where it
would go by default (next to foo.cpp, even though there's no foo.o).  Oh,
LLVM does that too. Huh. I'm not sure that's a terribly helpful default to
extrapolate to ThinLTO for, though.



On Thu, Mar 22, 2018 at 1:57 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson added a comment.
>
> In https://reviews.llvm.org/D44788#1046093, @dblaikie wrote:
>
> > In implicit ThinLTO, the object files are only temporary.
> >
> > Sort of similar to using -gsplit-dwarf when compiling straight to an
> >  executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where
> >  should the .dwo files go then? If they go where the .o files go, then
> >  they'll be in /tmp/ and get deleted either when the ocmpiler ends after
> it
> >  runs the linker, or perhaps at some uncertain point in the future when
> the
> >  temp space is reclaimed.
>
>
> I think that the .dwo files generally go where the user-specified final
> output goes.  So in your example they would go where a.out goes, not where
> the intermediate/temporary .o files go.
> Being able to override that is fine, but being required to specify a
> directory in order to get fission in the first place is not.
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D44788
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[David Blaikie via cfe-commits]

In implicit ThinLTO, the object files are only temporary.

Sort of similar to using -gsplit-dwarf when compiling straight to an
executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where
should the .dwo files go then? If they go where the .o files go, then
they'll be in /tmp/ and get deleted either when the ocmpiler ends after it
runs the linker, or perhaps at some uncertain point in the future when the
temp space is reclaimed.
(granted, I'm not suggesting we support that actual case - it's not
terribly common for anyone who'd actually need -gsplit-dwarf - but the
implicit ThinLTO case looks quite similar for demonstration purposes)


On Thu, Mar 22, 2018 at 1:22 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson added a comment.
>
> I don't think requiring a new option is a great user interface.  In
> existing use cases the location of the .dwo file matches the location of
> the output file.  Why is this one different?
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D44788
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r328166 - Fix for LLVM change (Transforms/Utils/Local.h -> Analysis/Utils/Local.h)

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Mar 21 15:34:27 2018
New Revision: 328166

URL: http://llvm.org/viewvc/llvm-project?rev=328166&view=rev
Log:
Fix for LLVM change (Transforms/Utils/Local.h -> Analysis/Utils/Local.h)

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=328166&r1=328165&r2=328166&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Wed Mar 21 15:34:27 2018
@@ -29,15 +29,15 @@
 #include "clang/CodeGen/SwiftCallingConv.h"
 #include "clang/Frontend/CodeGenOptions.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/Analysis/Utils/Local.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/IR/Attributes.h"
-#include "llvm/IR/CallingConv.h"
 #include "llvm/IR/CallSite.h"
+#include "llvm/IR/CallingConv.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/InlineAsm.h"
-#include "llvm/IR/Intrinsics.h"
 #include "llvm/IR/IntrinsicInst.h"
-#include "llvm/Transforms/Utils/Local.h"
+#include "llvm/IR/Intrinsics.h"
 using namespace clang;
 using namespace CodeGen;
 


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

Re: r326324 - [analyzer] Fix a compiler warning

[David Blaikie via cfe-commits]

Might be useful in the future to use a more specific commit message such as
"add missing override" (or "add missing override to address
-Wmissing-override warning"), etc.

On Wed, Feb 28, 2018 at 6:03 AM Gabor Horvath via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: xazax
> Date: Wed Feb 28 06:01:48 2018
> New Revision: 326324
>
> URL: http://llvm.org/viewvc/llvm-project?rev=326324&view=rev
> Log:
> [analyzer] Fix a compiler warning
>
> Modified:
> cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
>
> Modified:
> cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h?rev=326324&r1=326323&r2=326324&view=diff
>
> ==
> --- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
> (original)
> +++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
> Wed Feb 28 06:01:48 2018
> @@ -155,7 +155,8 @@ public:
>
>BugReporter& getBugReporter() { return BR; }
>
> -  cross_tu::CrossTranslationUnitContext *getCrossTranslationUnitContext()
> {
> +  cross_tu::CrossTranslationUnitContext *
> +  getCrossTranslationUnitContext() override {
>  return &CTU;
>}
>
>
>
> ___
> 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

r325692 - Remove use of the 'gmlt' term from the -fsplit-dwarf-inlining flag description to make it more readily legible

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Feb 21 08:00:50 2018
New Revision: 325692

URL: http://llvm.org/viewvc/llvm-project?rev=325692&view=rev
Log:
Remove use of the 'gmlt' term from the -fsplit-dwarf-inlining flag description 
to make it more readily legible

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

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=325692&r1=325691&r2=325692&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed Feb 21 08:00:50 2018
@@ -1631,7 +1631,7 @@ def fdebug_types_section: Flag <["-"], "
 def fno_debug_types_section: Flag<["-"], "fno-debug-types-section">, 
Group,
   Flags<[CC1Option]>;
 def fsplit_dwarf_inlining: Flag <["-"], "fsplit-dwarf-inlining">, 
Group,
-  Flags<[CC1Option]>, HelpText<"Provide gmlt-like debug info in the 
object/executable to facilitate online symbolication/stack traces in the 
absence of .dwo/.dwp files when using Split DWARF">;
+  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_prefix_map_EQ


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

r325594 - PR36442: Correct description of -fsplit-dwarf-inlining

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Feb 20 08:35:08 2018
New Revision: 325594

URL: http://llvm.org/viewvc/llvm-project?rev=325594&view=rev
Log:
PR36442: Correct description of -fsplit-dwarf-inlining

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

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=325594&r1=325593&r2=325594&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Feb 20 08:35:08 2018
@@ -1631,7 +1631,7 @@ def fdebug_types_section: Flag <["-"], "
 def fno_debug_types_section: Flag<["-"], "fno-debug-types-section">, 
Group,
   Flags<[CC1Option]>;
 def fsplit_dwarf_inlining: Flag <["-"], "fsplit-dwarf-inlining">, 
Group,
-  Flags<[CC1Option]>, HelpText<"Place debug types in their own section (ELF 
Only)">;
+  Flags<[CC1Option]>, HelpText<"Provide gmlt-like 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_prefix_map_EQ


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

Re: [PATCH] D43259: Implement function attribute artificial

[David Blaikie via cfe-commits]

Maybe - though that'd actually make for larger debug info & not be much
use.

With nodebug+always_inline (which is how the intrinsics are provided) the
function call dissolves into the raw instruction it's meant to represent.
The debug info describes that instruction as if it had been written at the
point of the call.

With this artificial+always_inline a description of inlining would be
provided (DWARF's inlining description is a bit heavy/verbose) & the
debugger would step over it, rather than into it.

For longer functions (inlined or outlined), marking as artificial makes
sense, I think, but /probably/ not for those places already using
nodebug+always_inline.

On Tue, Feb 13, 2018 at 3:18 PM Reid Kleckner via Phabricator <
revi...@reviews.llvm.org> wrote:

> rnk accepted this revision.
> rnk added subscribers: probinson, aprantl, dblaikie.
> rnk added a comment.
> This revision is now accepted and ready to land.
>
> lgtm
>
> ---
>
> Clang's builtin headers use `__attribute__((__nodebug__))` for this
> purpose. Do you think we should follow this up by using artificial instead?
> It seems like it would be a representational improvement. @aprantl
> @probinson @dblaikie
>
>
>
> 
> Comment at: test/Sema/artificial.c:3
> +
> +void __attribute__((artificial)) bar() {} // expected-warning
> {{'artificial' attribute only applies to inline functions}}
> 
> I think it's worth adding the `foo` function from the CodeGen test here to
> show we don't generate warnings when the function is inline specified.
>
>
> https://reviews.llvm.org/D43259
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

Ah.. hrm :/

On Mon, Feb 12, 2018 at 6:03 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 4:01 PM, David Blaikie  wrote:
>
>> ah, sweet :)
>>
>> On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier  wrote:
>>
>>> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie 
>>> wrote:
>>>


 On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie 
> wrote:
>
>>
>>
>> On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Wed Feb  7 10:36:51 2018
>>> New Revision: 324498
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
>>> Log:
>>> [Driver] Add option to manually control discarding value names in
>>> LLVM IR.
>>>
>>> Summary:
>>> Currently, assertion-disabled Clang builds emit value names when
>>> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
>>> easily overridable. In order to get IR output containing names from a
>>> release build of Clang, the user must manually construct the CC1 
>>> invocation
>>> w/o the `-discard-value-names` option. This is less than ideal.
>>>
>>> For example, Godbolt uses a release build of Clang, and so when
>>> asked to emit LLVM IR the result lacks names, making it harder to read.
>>> Manually invoking CC1 on Compiler Explorer is not feasible.
>>>
>>
>> It wouldn't necessarily have to invoke CC1, it could use "-Xclang
>> -discard-value-names".
>>
>
> If you were using an assertion build, and wanted to disable value
> names, then yes -- that would work. However it's the opposite case that is
> of interest:
> When you're using a non-assertion build and want to keep value names.
> In that case invoking CC1 directly is required; otherwise the driver would
> pass
> "-discard-value-names".
>

 Ah, thanks for explaining!


>
>
>>
>>
>>>
>>> This patch adds the driver options `-fdiscard-value-names` and
>>> `-fno-discard-value-names` which allow the user to override the default
>>> behavior. If neither is specified, the old behavior remains.
>>>
>>> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>>>
>>> Reviewed By: aaron.ballman
>>>
>>> Subscribers: bogner, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D42887
>>>
>>> Modified:
>>> cfe/trunk/docs/UsersManual.rst
>>> cfe/trunk/include/clang/Driver/Options.td
>>> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>> cfe/trunk/test/Driver/clang_f_opts.c
>>>
>>> Modified: cfe/trunk/docs/UsersManual.rst
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/docs/UsersManual.rst (original)
>>> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
>>> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>>>must come first.)
>>>
>>>
>>> +Controlling LLVM IR Output
>>> +--
>>> +
>>> +Controlling Value Names in LLVM IR
>>> +^^
>>> +
>>> +Emitting value names in LLVM IR increases the size and verbosity of
>>> the IR.
>>> +By default, value names are only emitted in assertion-enabled
>>> builds of Clang.
>>> +However, when reading IR it can be useful to re-enable the emission
>>> of value
>>> +names to improve readability.
>>> +
>>> +.. option:: -fdiscard-value-names
>>> +
>>> +  Discard value names when generating LLVM IR.
>>> +
>>> +.. option:: -fno-discard-value-names
>>> +
>>> +  Do not discard value names when generating LLVM IR. This option
>>> can be used
>>> +  to re-enable names for release builds of Clang.
>>> +
>>> +
>>>  Comment Parsing Options
>>>  ---
>>>
>>>
>>> Modified: cfe/trunk/include/clang/Driver/Options.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Driver/Options.td (original)
>>> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51
>>> 2018
>>> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>>>  HelpText<"Print a template comparison tree for differing
>>> templates">;
>>>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>>>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
>>> +def fdiscard_value_names : Flag<["-"], "fdiscard-v

Re: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

ah, sweet :)

On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie  wrote:
>
>>
>>
>> On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier  wrote:
>>
>>> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie 
>>> wrote:
>>>


 On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Wed Feb  7 10:36:51 2018
> New Revision: 324498
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
> Log:
> [Driver] Add option to manually control discarding value names in LLVM
> IR.
>
> Summary:
> Currently, assertion-disabled Clang builds emit value names when
> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
> easily overridable. In order to get IR output containing names from a
> release build of Clang, the user must manually construct the CC1 
> invocation
> w/o the `-discard-value-names` option. This is less than ideal.
>
> For example, Godbolt uses a release build of Clang, and so when asked
> to emit LLVM IR the result lacks names, making it harder to read. Manually
> invoking CC1 on Compiler Explorer is not feasible.
>

 It wouldn't necessarily have to invoke CC1, it could use "-Xclang
 -discard-value-names".

>>>
>>> If you were using an assertion build, and wanted to disable value names,
>>> then yes -- that would work. However it's the opposite case that is of
>>> interest:
>>> When you're using a non-assertion build and want to keep value names. In
>>> that case invoking CC1 directly is required; otherwise the driver would pass
>>> "-discard-value-names".
>>>
>>
>> Ah, thanks for explaining!
>>
>>
>>>
>>>


>
> This patch adds the driver options `-fdiscard-value-names` and
> `-fno-discard-value-names` which allow the user to override the default
> behavior. If neither is specified, the old behavior remains.
>
> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>
> Reviewed By: aaron.ballman
>
> Subscribers: bogner, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D42887
>
> Modified:
> cfe/trunk/docs/UsersManual.rst
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/test/Driver/clang_f_opts.c
>
> Modified: cfe/trunk/docs/UsersManual.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>must come first.)
>
>
> +Controlling LLVM IR Output
> +--
> +
> +Controlling Value Names in LLVM IR
> +^^
> +
> +Emitting value names in LLVM IR increases the size and verbosity of
> the IR.
> +By default, value names are only emitted in assertion-enabled builds
> of Clang.
> +However, when reading IR it can be useful to re-enable the emission
> of value
> +names to improve readability.
> +
> +.. option:: -fdiscard-value-names
> +
> +  Discard value names when generating LLVM IR.
> +
> +.. option:: -fno-discard-value-names
> +
> +  Do not discard value names when generating LLVM IR. This option can
> be used
> +  to re-enable names for release builds of Clang.
> +
> +
>  Comment Parsing Options
>  ---
>
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51 2018
> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>  HelpText<"Print a template comparison tree for differing
> templates">;
>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
> +def fdiscard_value_names : Flag<["-"], "fdiscard-value-names">,
> Group,
> +  HelpText<"Discard value names in LLVM IR">, Flags<[DriverOption]>;
> +def fno_discard_value_names : Flag<["-"], "fno-discard-value-names">,
> Group,
> +  HelpText<"Do not discard value names in LLVM IR">,
> Flags<[DriverOption]>;
>  def fdollars_in_identifiers : Flag<["-"], "fdollars-in-identifiers">,
> Group,
>HelpText<"Allow '$' in ident

Re: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie  wrote:
>
>>
>>
>> On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Wed Feb  7 10:36:51 2018
>>> New Revision: 324498
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
>>> Log:
>>> [Driver] Add option to manually control discarding value names in LLVM
>>> IR.
>>>
>>> Summary:
>>> Currently, assertion-disabled Clang builds emit value names when
>>> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
>>> easily overridable. In order to get IR output containing names from a
>>> release build of Clang, the user must manually construct the CC1 invocation
>>> w/o the `-discard-value-names` option. This is less than ideal.
>>>
>>> For example, Godbolt uses a release build of Clang, and so when asked to
>>> emit LLVM IR the result lacks names, making it harder to read. Manually
>>> invoking CC1 on Compiler Explorer is not feasible.
>>>
>>
>> It wouldn't necessarily have to invoke CC1, it could use "-Xclang
>> -discard-value-names".
>>
>
> If you were using an assertion build, and wanted to disable value names,
> then yes -- that would work. However it's the opposite case that is of
> interest:
> When you're using a non-assertion build and want to keep value names. In
> that case invoking CC1 directly is required; otherwise the driver would pass
> "-discard-value-names".
>

Ah, thanks for explaining!


>
>
>>
>>
>>>
>>> This patch adds the driver options `-fdiscard-value-names` and
>>> `-fno-discard-value-names` which allow the user to override the default
>>> behavior. If neither is specified, the old behavior remains.
>>>
>>> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>>>
>>> Reviewed By: aaron.ballman
>>>
>>> Subscribers: bogner, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D42887
>>>
>>> Modified:
>>> cfe/trunk/docs/UsersManual.rst
>>> cfe/trunk/include/clang/Driver/Options.td
>>> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>> cfe/trunk/test/Driver/clang_f_opts.c
>>>
>>> Modified: cfe/trunk/docs/UsersManual.rst
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/docs/UsersManual.rst (original)
>>> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
>>> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>>>must come first.)
>>>
>>>
>>> +Controlling LLVM IR Output
>>> +--
>>> +
>>> +Controlling Value Names in LLVM IR
>>> +^^
>>> +
>>> +Emitting value names in LLVM IR increases the size and verbosity of the
>>> IR.
>>> +By default, value names are only emitted in assertion-enabled builds of
>>> Clang.
>>> +However, when reading IR it can be useful to re-enable the emission of
>>> value
>>> +names to improve readability.
>>> +
>>> +.. option:: -fdiscard-value-names
>>> +
>>> +  Discard value names when generating LLVM IR.
>>> +
>>> +.. option:: -fno-discard-value-names
>>> +
>>> +  Do not discard value names when generating LLVM IR. This option can
>>> be used
>>> +  to re-enable names for release builds of Clang.
>>> +
>>> +
>>>  Comment Parsing Options
>>>  ---
>>>
>>>
>>> Modified: cfe/trunk/include/clang/Driver/Options.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Driver/Options.td (original)
>>> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51 2018
>>> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>>>  HelpText<"Print a template comparison tree for differing
>>> templates">;
>>>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>>>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
>>> +def fdiscard_value_names : Flag<["-"], "fdiscard-value-names">,
>>> Group,
>>> +  HelpText<"Discard value names in LLVM IR">, Flags<[DriverOption]>;
>>> +def fno_discard_value_names : Flag<["-"], "fno-discard-value-names">,
>>> Group,
>>> +  HelpText<"Do not discard value names in LLVM IR">,
>>> Flags<[DriverOption]>;
>>>  def fdollars_in_identifiers : Flag<["-"], "fdollars-in-identifiers">,
>>> Group,
>>>HelpText<"Allow '$' in identifiers">, Flags<[CC1Option]>;
>>>  def fdwarf2_cfi_asm : Flag<["-"], "fdwarf2-cfi-asm">,
>>> Group;
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Driver

Re: r324433 - [NFC] Change odd cast-through-unknown behavior to an Optional

[David Blaikie via cfe-commits]

FWIW, you can write "*M" rather than M.getValue() if you reckon that's
neater.

And you could roll the declaration/initialization of M into the 'if'
condition - but I can understand why you might prefer not to, given it's a
many-line statement, etc.

On Tue, Feb 6, 2018 at 4:39 PM Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Tue Feb  6 16:37:19 2018
> New Revision: 324433
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324433&view=rev
> Log:
> [NFC] Change odd cast-through-unknown behavior to an Optional
>
> This bit of code in the driver uses '~0U' as a sentinel value.
> The result is an odd mishmash of casts just to work.  This replaces
> it with an optional,  which is a little less crazy looking.
> --ehis line, and those below, will be ignored--
>
> Mlib/Driver/Driver.cpp
>
> Modified:
> cfe/trunk/lib/Driver/Driver.cpp
>
> Modified: cfe/trunk/lib/Driver/Driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=324433&r1=324432&r2=324433&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/Driver.cpp (original)
> +++ cfe/trunk/lib/Driver/Driver.cpp Tue Feb  6 16:37:19 2018
> @@ -148,15 +148,15 @@ void Driver::setDriverModeFromOption(Str
>  return;
>StringRef Value = Opt.drop_front(OptName.size());
>
> -  const unsigned M = llvm::StringSwitch(Value)
> - .Case("gcc", GCCMode)
> - .Case("g++", GXXMode)
> - .Case("cpp", CPPMode)
> - .Case("cl", CLMode)
> - .Default(~0U);
> +  auto M = llvm::StringSwitch>(Value)
> +   .Case("gcc", GCCMode)
> +   .Case("g++", GXXMode)
> +   .Case("cpp", CPPMode)
> +   .Case("cl", CLMode)
> +   .Default(None);
>
> -  if (M != ~0U)
> -Mode = static_cast(M);
> +  if (M)
> +Mode = M.getValue();
>else
>  Diag(diag::err_drv_unsupported_option_argument) << OptName << 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: [PATCH] D43128: Introduce an API for LLDB to compute the default module cache path

[David Blaikie via cfe-commits]

Unit test?

On Fri, Feb 9, 2018 at 10:45 AM Phabricator via Phabricator via
llvm-commits  wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL324761: Introduce an API for LLDB to compute the
> default module cache path (authored by adrian, committed by ).
> Herald added a subscriber: llvm-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D43128?vs=133631&id=133650#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D43128
>
> Files:
>   cfe/trunk/include/clang/Driver/Driver.h
>   cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>
>
> Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> ===
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> @@ -2500,6 +2500,13 @@
>  CmdArgs.push_back("-fno-math-builtin");
>  }
>
> +void Driver::getDefaultModuleCachePath(SmallVectorImpl &Result) {
> +  llvm::sys::path::system_temp_directory(/*erasedOnReboot=*/false,
> Result);
> +  llvm::sys::path::append(Result, "org.llvm.clang.");
> +  appendUserToPath(Result);
> +  llvm::sys::path::append(Result, "ModuleCache");
> +}
> +
>  static void RenderModulesOptions(Compilation &C, const Driver &D,
>   const ArgList &Args, const InputInfo
> &Input,
>   const InputInfo &Output,
> @@ -2560,10 +2567,7 @@
>llvm::sys::path::append(Path, "modules");
>  } else if (Path.empty()) {
>// No module path was provided: use the default.
> -  llvm::sys::path::system_temp_directory(/*erasedOnReboot=*/false,
> Path);
> -  llvm::sys::path::append(Path, "org.llvm.clang.");
> -  appendUserToPath(Path);
> -  llvm::sys::path::append(Path, "ModuleCache");
> +  Driver::getDefaultModuleCachePath(Path);
>  }
>
>  const char Arg[] = "-fmodules-cache-path=";
> Index: cfe/trunk/include/clang/Driver/Driver.h
> ===
> --- cfe/trunk/include/clang/Driver/Driver.h
> +++ cfe/trunk/include/clang/Driver/Driver.h
> @@ -572,6 +572,8 @@
>/// no extra characters remaining at the end.
>static bool GetReleaseVersion(StringRef Str,
>  MutableArrayRef Digits);
> +  /// Compute the default -fmodule-cache-path.
> +  static void getDefaultModuleCachePath(SmallVectorImpl &Result);
>  };
>
>  /// \return True if the last defined optimization level is -Ofast.
>
>
> ___
> 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: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Wed Feb  7 10:36:51 2018
> New Revision: 324498
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
> Log:
> [Driver] Add option to manually control discarding value names in LLVM IR.
>
> Summary:
> Currently, assertion-disabled Clang builds emit value names when
> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
> easily overridable. In order to get IR output containing names from a
> release build of Clang, the user must manually construct the CC1 invocation
> w/o the `-discard-value-names` option. This is less than ideal.
>
> For example, Godbolt uses a release build of Clang, and so when asked to
> emit LLVM IR the result lacks names, making it harder to read. Manually
> invoking CC1 on Compiler Explorer is not feasible.
>

It wouldn't necessarily have to invoke CC1, it could use "-Xclang
-discard-value-names".


>
> This patch adds the driver options `-fdiscard-value-names` and
> `-fno-discard-value-names` which allow the user to override the default
> behavior. If neither is specified, the old behavior remains.
>
> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>
> Reviewed By: aaron.ballman
>
> Subscribers: bogner, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D42887
>
> Modified:
> cfe/trunk/docs/UsersManual.rst
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/test/Driver/clang_f_opts.c
>
> Modified: cfe/trunk/docs/UsersManual.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>must come first.)
>
>
> +Controlling LLVM IR Output
> +--
> +
> +Controlling Value Names in LLVM IR
> +^^
> +
> +Emitting value names in LLVM IR increases the size and verbosity of the
> IR.
> +By default, value names are only emitted in assertion-enabled builds of
> Clang.
> +However, when reading IR it can be useful to re-enable the emission of
> value
> +names to improve readability.
> +
> +.. option:: -fdiscard-value-names
> +
> +  Discard value names when generating LLVM IR.
> +
> +.. option:: -fno-discard-value-names
> +
> +  Do not discard value names when generating LLVM IR. This option can be
> used
> +  to re-enable names for release builds of Clang.
> +
> +
>  Comment Parsing Options
>  ---
>
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51 2018
> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>  HelpText<"Print a template comparison tree for differing templates">;
>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
> +def fdiscard_value_names : Flag<["-"], "fdiscard-value-names">,
> Group,
> +  HelpText<"Discard value names in LLVM IR">, Flags<[DriverOption]>;
> +def fno_discard_value_names : Flag<["-"], "fno-discard-value-names">,
> Group,
> +  HelpText<"Do not discard value names in LLVM IR">,
> Flags<[DriverOption]>;
>  def fdollars_in_identifiers : Flag<["-"], "fdollars-in-identifiers">,
> Group,
>HelpText<"Allow '$' in identifiers">, Flags<[CC1Option]>;
>  def fdwarf2_cfi_asm : Flag<["-"], "fdwarf2-cfi-asm">,
> Group;
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Wed Feb  7 10:36:51 2018
> @@ -3266,13 +3266,24 @@ void Clang::ConstructJob(Compilation &C,
>if (!C.isForDiagnostics())
>  CmdArgs.push_back("-disable-free");
>
> -// Disable the verification pass in -asserts builds.
>  #ifdef NDEBUG
> -  CmdArgs.push_back("-disable-llvm-verifier");
> -  // Discard LLVM value names in -asserts builds.
> -  CmdArgs.push_back("-discard-value-names");
> +  const bool IsAssertBuild = false;
> +#else
> +  const bool IsAssertBuild = true;
>  #endif
>
> +  // Disable the verification pass in -asserts builds.
> +  if (!IsAssertBuild)
> +CmdArgs.push_back("disable-llvm-verifier");
> +
> +  // Discard value names in asse

Re: [clang-tools-extra] r323149 - [clangd] Drop ~destructor completions - rarely helpful and work inconsistently

[David Blaikie via cfe-commits]

Fair - maybe just a comment in the test case (and/or the source code that
handles this) saying "hey, let's make sure dtors aren't here - but if/when
there's support for a low priority completion group, these should appear
there" or the like.

On Mon, Jan 29, 2018 at 9:49 AM Sam McCall  wrote:

> On Mon, Jan 29, 2018 at 5:31 PM, David Blaikie  wrote:
>
>> Any chance of making this a really low priority completion?
>>
> (Just for clarity - this is a postfilter in clangd only, we haven't
> changed the behavior of the Sema or libclang APIs)
>
> We certainly have considered downranking such items, maybe it's the right
> thing, but it's not without issues on the UX side:
>  - It's far from the only candidate, other things that people want "at the
> bottom" include inaccessible and unavailable members, injected type names,
> operators... it gets crowded, so you still have to decide how to rank them.
>  - LSP doesn't (currently) have any affordance to "grey out" results and
> show users "this is the last good result, the ones below here are unlikely
> to be useful". So the important end-of-list signal is lost.
> There's also a bit of implementation complexity in having
> second/third/fourth "tiers" of results - it adds invariants to the scoring
> logic that make it harder to understand and modify.
>
> (maybe just leaving in a FIXME or expected-fail check of some kind if it's
>> not practical to implement it right now) For those handful of times when
>> you actually want to do this.
>>
> re: practical to implement, there are a few problems with it, apart from
> being rarely useful:
>  - It completes after "foo.", but not "foo.~F", I guess because the parser
> is in the wrong state
>  - it completes ~basic_string, but not ~string
>
> We do indirectly test that destructor completions are turned off in
> clangd. I don't really know where to add the FIXMEs. I can add XFAIL tests
> to c-index-test I think, is anyone likely to go looking for them?
>
> On Mon, Jan 22, 2018 at 1:06 PM Sam McCall via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: sammccall
>>> Date: Mon Jan 22 13:05:00 2018
>>> New Revision: 323149
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=323149&view=rev
>>> Log:
>>> [clangd] Drop ~destructor completions - rarely helpful and work
>>> inconsistently
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clangd/CodeComplete.cpp
>>> clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
>>>
>>> Modified: clang-tools-extra/trunk/clangd/CodeComplete.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CodeComplete.cpp?rev=323149&r1=323148&r2=323149&view=diff
>>>
>>> ==
>>> --- clang-tools-extra/trunk/clangd/CodeComplete.cpp (original)
>>> +++ clang-tools-extra/trunk/clangd/CodeComplete.cpp Mon Jan 22 13:05:00
>>> 2018
>>> @@ -361,6 +361,10 @@ struct CompletionRecorder : public CodeC
>>>(Result.Availability == CXAvailability_NotAvailable ||
>>> Result.Availability == CXAvailability_NotAccessible))
>>>  continue;
>>> +  // Destructor completion is rarely useful, and works
>>> inconsistently.
>>> +  // (s.^ completes ~string, but s.~st^ is an error).
>>> +  if (dyn_cast_or_null(Result.Declaration))
>>> +continue;
>>>Results.push_back(Result);
>>>  }
>>>}
>>>
>>> Modified: clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp?rev=323149&r1=323148&r2=323149&view=diff
>>>
>>> ==
>>> --- clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
>>> (original)
>>> +++ clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp Mon
>>> Jan 22 13:05:00 2018
>>> @@ -461,7 +461,7 @@ TEST(CompletionTest, NoDuplicates) {
>>>{cls("Adapter")});
>>>
>>>// Make sure there are no duplicate entries of 'Adapter'.
>>> -  EXPECT_THAT(Results.items, ElementsAre(Named("Adapter"),
>>> Named("~Adapter")));
>>> +  EXPECT_THAT(Results.items, ElementsAre(Named("Adapter")));
>>>  }
>>>
>>>  TEST(CompletionTest, ScopedNoIndex) {
>>>
>>>
>>> ___
>>> 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: [clang-tools-extra] r323149 - [clangd] Drop ~destructor completions - rarely helpful and work inconsistently

[David Blaikie via cfe-commits]

Any chance of making this a really low priority completion? (maybe just
leaving in a FIXME or expected-fail check of some kind if it's not
practical to implement it right now) For those handful of times when you
actually want to do this.

On Mon, Jan 22, 2018 at 1:06 PM Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sammccall
> Date: Mon Jan 22 13:05:00 2018
> New Revision: 323149
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323149&view=rev
> Log:
> [clangd] Drop ~destructor completions - rarely helpful and work
> inconsistently
>
> Modified:
> clang-tools-extra/trunk/clangd/CodeComplete.cpp
> clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
>
> Modified: clang-tools-extra/trunk/clangd/CodeComplete.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CodeComplete.cpp?rev=323149&r1=323148&r2=323149&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/CodeComplete.cpp (original)
> +++ clang-tools-extra/trunk/clangd/CodeComplete.cpp Mon Jan 22 13:05:00
> 2018
> @@ -361,6 +361,10 @@ struct CompletionRecorder : public CodeC
>(Result.Availability == CXAvailability_NotAvailable ||
> Result.Availability == CXAvailability_NotAccessible))
>  continue;
> +  // Destructor completion is rarely useful, and works inconsistently.
> +  // (s.^ completes ~string, but s.~st^ is an error).
> +  if (dyn_cast_or_null(Result.Declaration))
> +continue;
>Results.push_back(Result);
>  }
>}
>
> Modified: clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp?rev=323149&r1=323148&r2=323149&view=diff
>
> ==
> --- clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
> (original)
> +++ clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp Mon Jan
> 22 13:05:00 2018
> @@ -461,7 +461,7 @@ TEST(CompletionTest, NoDuplicates) {
>{cls("Adapter")});
>
>// Make sure there are no duplicate entries of 'Adapter'.
> -  EXPECT_THAT(Results.items, ElementsAre(Named("Adapter"),
> Named("~Adapter")));
> +  EXPECT_THAT(Results.items, ElementsAre(Named("Adapter")));
>  }
>
>  TEST(CompletionTest, ScopedNoIndex) {
>
>
> ___
> 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

r323167 - NewPM: Improve/fix GCOV - which needs to run early in the pass pipeline.

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Jan 22 17:25:24 2018
New Revision: 323167

URL: http://llvm.org/viewvc/llvm-project?rev=323167&view=rev
Log:
NewPM: Improve/fix GCOV - which needs to run early in the pass pipeline.

Using a new extension point in the new PM, register GCOV at the start of
the pipeline rather than the end.

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/code-coverage.c

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=323167&r1=323166&r2=323167&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Jan 22 17:25:24 2018
@@ -909,6 +909,9 @@ void EmitAssemblyHelper::EmitAssemblyWit
 bool IsLTO = CodeGenOpts.PrepareForLTO;
 
 if (CodeGenOpts.OptimizationLevel == 0) {
+  if (Optional Options = getGCOVOptions(CodeGenOpts))
+MPM.addPass(GCOVProfilerPass(*Options));
+
   // Build a minimal pipeline based on the semantics required by Clang,
   // which is just that always inlining occurs.
   MPM.addPass(AlwaysInlinerPass());
@@ -932,6 +935,10 @@ void EmitAssemblyHelper::EmitAssemblyWit
 [](FunctionPassManager &FPM, PassBuilder::OptimizationLevel Level) 
{
   FPM.addPass(BoundsCheckingPass());
 });
+  if (Optional Options = getGCOVOptions(CodeGenOpts))
+PB.registerPipelineStartEPCallback([Options](ModulePassManager &MPM) {
+  MPM.addPass(GCOVProfilerPass(*Options));
+});
 
   if (IsThinLTO) {
 MPM = PB.buildThinLTOPreLinkDefaultPipeline(
@@ -945,9 +952,6 @@ void EmitAssemblyHelper::EmitAssemblyWit
CodeGenOpts.DebugPassManager);
   }
 }
-if (Optional Options = getGCOVOptions(CodeGenOpts)) {
-  MPM.addPass(GCOVProfilerPass(*Options));
-}
   }
 
   // FIXME: We still use the legacy pass manager to do code generation. We

Modified: cfe/trunk/test/CodeGen/code-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/code-coverage.c?rev=323167&r1=323166&r2=323167&view=diff
==
--- cfe/trunk/test/CodeGen/code-coverage.c (original)
+++ cfe/trunk/test/CodeGen/code-coverage.c Mon Jan 22 17:25:24 2018
@@ -3,9 +3,15 @@
 // RUN: %clang_cc1 -emit-llvm -disable-red-zone -femit-coverage-data 
-coverage-notes-file=aaa.gcno -coverage-data-file=bbb.gcda -dwarf-column-info 
-debug-info-kind=limited -dwarf-version=4 %s -o - | FileCheck %s --check-prefix 
GCOV_FILE_INFO
 
 // RUN: %clang_cc1 -emit-llvm-bc -o /dev/null -fexperimental-new-pass-manager 
-fdebug-pass-manager -femit-coverage-data %s 2>&1 | FileCheck 
--check-prefix=NEWPM %s
+// RUN: %clang_cc1 -emit-llvm-bc -o /dev/null -fexperimental-new-pass-manager 
-fdebug-pass-manager -femit-coverage-data -O3 %s 2>&1 | FileCheck 
--check-prefix=NEWPM-O3 %s
 
+// NEWPM-NOT: Running pass
 // NEWPM: Running pass: GCOVProfilerPass
 
+// NEWPM-O3-NOT: Running pass
+// NEWPM-O3: Running pass: ForceFunctionAttrsPass
+// NEWPM-O3: Running pass: GCOVProfilerPass
+
 
 int test1(int a) {
   switch (a % 2) {


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

Re: r322065 - Avoid assumption that lit tests are writable (in a couple more places). NFC

[David Blaikie via cfe-commits]

I feel like this sort of change will regress quite quickly - in the sense
that most 'cp' in tests is probably there to put it somewhere writable (in
some cases its to put it in a particular location, not about writability).
Any way we could fix 'cp' in lit to do the right thing here? (I doubt any
test /needs/ cp to propagate the writability bit?)

On Tue, Jan 9, 2018 at 1:34 AM Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sammccall
> Date: Tue Jan  9 01:32:53 2018
> New Revision: 322065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=322065&view=rev
> Log:
> Avoid assumption that lit tests are writable (in a couple more places). NFC
>
> Modified:
> cfe/trunk/test/Modules/modify-module.m
> cfe/trunk/test/PCH/modified-header-crash.c
>
> Modified: cfe/trunk/test/Modules/modify-module.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/modify-module.m?rev=322065&r1=322064&r2=322065&view=diff
>
> ==
> --- cfe/trunk/test/Modules/modify-module.m (original)
> +++ cfe/trunk/test/Modules/modify-module.m Tue Jan  9 01:32:53 2018
> @@ -3,9 +3,9 @@
>
>  // RUN: rm -rf %t
>  // RUN: mkdir -p %t/include
> -// RUN: cp %S/Inputs/Modified/A.h %t/include
> -// RUN: cp %S/Inputs/Modified/B.h %t/include
> -// RUN: cp %S/Inputs/Modified/module.map %t/include
> +// RUN: cat %S/Inputs/Modified/A.h > %t/include/A.h
> +// RUN: cat %S/Inputs/Modified/B.h > %t/include/B.h
> +// RUN: cat %S/Inputs/Modified/module.map > %t/include/module.map
>  // RUN: %clang_cc1 -fdisable-module-hash -fmodules-cache-path=%t/cache
> -fmodules -fimplicit-module-maps -I %t/include %s -verify
>  // RUN: echo '' >> %t/include/B.h
>  // RUN: %clang_cc1 -fdisable-module-hash -fmodules-cache-path=%t/cache
> -fmodules -fimplicit-module-maps -I %t/include %s -verify
>
> Modified: cfe/trunk/test/PCH/modified-header-crash.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/modified-header-crash.c?rev=322065&r1=322064&r2=322065&view=diff
>
> ==
> --- cfe/trunk/test/PCH/modified-header-crash.c (original)
> +++ cfe/trunk/test/PCH/modified-header-crash.c Tue Jan  9 01:32:53 2018
> @@ -1,6 +1,6 @@
>  // Don't crash.
>
> -// RUN: cp %S/modified-header-crash.h %t.h
> +// RUN: cat %S/modified-header-crash.h > %t.h
>  // RUN: %clang_cc1 -DCAKE -x c-header %t.h -emit-pch -o %t
>  // RUN: echo 'int foobar;' >> %t.h
>  // RUN: not %clang_cc1 %s -include-pch %t -fsyntax-only
>
>
> ___
> 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: r322350 - [ODRHash] Don't hash friend functions.

[David Blaikie via cfe-commits]

I'm surprised this problem is unique to friend functions with definitions
inline and the friend declaration site - doesn't a similar issue occur with
member functions of templates that are not instantiated in some (similar)
contexts?

Is there a common solution that could be used for both cases?

On Thu, Jan 11, 2018 at 8:43 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Thu Jan 11 20:42:27 2018
> New Revision: 322350
>
> URL: http://llvm.org/viewvc/llvm-project?rev=322350&view=rev
> Log:
> [ODRHash] Don't hash friend functions.
>
> In certain combinations of templated classes and friend functions, the body
> of friend functions does not get propagated along with function signature.
> Exclude friend functions for hashing to avoid this case.
>
> Added:
> cfe/trunk/test/Modules/Inputs/odr_hash-Friend/
> cfe/trunk/test/Modules/Inputs/odr_hash-Friend/Box.h
> cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M1.h
> cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M2.h
> cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M3.h
> cfe/trunk/test/Modules/Inputs/odr_hash-Friend/module.modulemap
> cfe/trunk/test/Modules/odr_hash-Friend.cpp
> Modified:
> cfe/trunk/lib/AST/ODRHash.cpp
>
> Modified: cfe/trunk/lib/AST/ODRHash.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ODRHash.cpp?rev=322350&r1=322349&r2=322350&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ODRHash.cpp (original)
> +++ cfe/trunk/lib/AST/ODRHash.cpp Thu Jan 11 20:42:27 2018
> @@ -478,6 +478,8 @@ void ODRHash::AddFunctionDecl(const Func
>
>// TODO: Fix hashing for class methods.
>if (isa(Function)) return;
> +  // And friend functions.
> +  if (Function->getFriendObjectKind()) return;
>
>// Skip functions that are specializations or in specialization context.
>const DeclContext *DC = Function;
>
> Added: cfe/trunk/test/Modules/Inputs/odr_hash-Friend/Box.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/odr_hash-Friend/Box.h?rev=322350&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/odr_hash-Friend/Box.h (added)
> +++ cfe/trunk/test/Modules/Inputs/odr_hash-Friend/Box.h Thu Jan 11
> 20:42:27 2018
> @@ -0,0 +1,14 @@
> +template 
> +struct iterator {
> +  void Compare(const iterator &x) { }
> +  friend void Check(iterator) {}
> +};
> +
> +template  struct Box {
> +  iterator I;
> +
> +  void test() {
> +Check(I);
> +I.Compare(I);
> +  }
> +};
>
> Added: cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M1.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M1.h?rev=322350&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M1.h (added)
> +++ cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M1.h Thu Jan 11 20:42:27
> 2018
> @@ -0,0 +1,6 @@
> +#include "Box.h"
> +
> +void Peek() {
> +  Box<> Gift;
> +  Gift.test();
> +}
>
> Added: cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M2.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M2.h?rev=322350&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M2.h (added)
> +++ cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M2.h Thu Jan 11 20:42:27
> 2018
> @@ -0,0 +1,5 @@
> +#include "Box.h"
> +void x() {
> +  Box<> Unused;
> +  //Unused.test();
> +}
>
> Added: cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M3.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M3.h?rev=322350&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M3.h (added)
> +++ cfe/trunk/test/Modules/Inputs/odr_hash-Friend/M3.h Thu Jan 11 20:42:27
> 2018
> @@ -0,0 +1,7 @@
> +#include "Box.h"
> +#include "M2.h"
> +
> +void Party() {
> +  Box<> Present;
> +  Present.test();
> +}
>
> Added: cfe/trunk/test/Modules/Inputs/odr_hash-Friend/module.modulemap
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/odr_hash-Friend/module.modulemap?rev=322350&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/odr_hash-Friend/module.modulemap (added)
> +++ cfe/trunk/test/Modules/Inputs/odr_hash-Friend/module.modulemap Thu Jan
> 11 20:42:27 2018
> @@ -0,0 +1,15 @@
> +module Box {
> +  header "Box.h"
> +}
> +
> +module Module1 {
> +  header "M1.h"
> +}
> +
> +module Module2 {
> +  header "M2.h"
> +}
> +
> +module Module3 {
> +  header "M3.h"
> +}
>
> Added: cfe/trunk/test/Modules/odr_hash-Friend.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/odr_hash-Friend.cpp?rev=322350&view=

Re: r322405 - Disable test for Windows to fix Windows buildbots.

[David Blaikie via cfe-commits]

might be worth having an explanation (probably in both the commit message
and in a comment in the source) about why this test isn't supported on
windows?

On Fri, Jan 12, 2018 at 1:50 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Fri Jan 12 13:49:20 2018
> New Revision: 322405
>
> URL: http://llvm.org/viewvc/llvm-project?rev=322405&view=rev
> Log:
> Disable test for Windows to fix Windows buildbots.
>
> Modified:
> cfe/trunk/test/Modules/odr_hash-Friend.cpp
>
> Modified: cfe/trunk/test/Modules/odr_hash-Friend.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/odr_hash-Friend.cpp?rev=322405&r1=322404&r2=322405&view=diff
>
> ==
> --- cfe/trunk/test/Modules/odr_hash-Friend.cpp (original)
> +++ cfe/trunk/test/Modules/odr_hash-Friend.cpp Fri Jan 12 13:49:20 2018
> @@ -8,6 +8,8 @@
>  // RUN:  -fmodules-cache-path=%t/modules.cache \
>  // RUN:  -std=c++11 -x c++ %s -verify
>
> +// UNSUPPORTED: windows
> +
>  // expected-no-diagnostics
>
>  #include "Box.h"
>
>
> ___
> 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: [PATCH] D41455: [ASTMatchers] Add isNoReturn() match narrower for FunctionDeclarations

[David Blaikie via cfe-commits]

I haven't as yet, no. Sorry - happy if someone else wants to have a go, or
I'll take a closer look soon.

- Dave

On Thu, Jan 11, 2018 at 11:38 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D41455#963752, @aaron.ballman wrote:
>
> > Aside from a documentation nit, this LGTM. However, you should wait to
> commit until after you can safely regenerate the AST matcher documentation.
> The issue there is that dump_ast_matchers.py was not updated after r318304.
> I believe @dblaikie was looking into the Python script, but I'm not certain
> how far he got with it.
>
>
> @dblaikie Hi! Did you get anywhere with the script update?
> As far i'm concerned, all new ASTMatchers are stalled because of this...
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D41455
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r322126 - Wire up GCOV to the new pass manager

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Jan  9 14:03:47 2018
New Revision: 322126

URL: http://llvm.org/viewvc/llvm-project?rev=322126&view=rev
Log:
Wire up GCOV to the new pass manager

GCOV in the old pass manager also strips debug info (if debug info is
disabled/only produced for profiling anyway) after the GCOV pass runs.

I think the strip pass hasn't been ported to the new pass manager, so it
might take me a little while to wire that up.

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/code-coverage.c

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=322126&r1=322125&r2=322126&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Tue Jan  9 14:03:47 2018
@@ -26,6 +26,7 @@
 #include "llvm/Bitcode/BitcodeWriterPass.h"
 #include "llvm/CodeGen/RegAllocRegistry.h"
 #include "llvm/CodeGen/SchedulerRegistry.h"
+#include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/IRPrintingPasses.h"
 #include "llvm/IR/LegacyPassManager.h"
@@ -44,8 +45,8 @@
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/Target/TargetOptions.h"
-#include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/Transforms/Coroutines.h"
+#include "llvm/Transforms/GCOVProfiler.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/IPO/AlwaysInliner.h"
 #include "llvm/Transforms/IPO/PassManagerBuilder.h"
@@ -471,6 +472,23 @@ static void initTargetOptions(llvm::Targ
   Options.MCOptions.IASSearchPaths.push_back(
   Entry.IgnoreSysRoot ? Entry.Path : HSOpts.Sysroot + Entry.Path);
 }
+static Optional getGCOVOptions(const CodeGenOptions &CodeGenOpts) 
{
+  if (CodeGenOpts.DisableGCov)
+return None;
+  if (!CodeGenOpts.EmitGcovArcs && !CodeGenOpts.EmitGcovNotes)
+return None;
+  // Not using 'GCOVOptions::getDefault' allows us to avoid exiting if
+  // LLVM's -default-gcov-version flag is set to something invalid.
+  GCOVOptions Options;
+  Options.EmitNotes = CodeGenOpts.EmitGcovNotes;
+  Options.EmitData = CodeGenOpts.EmitGcovArcs;
+  llvm::copy(CodeGenOpts.CoverageVersion, std::begin(Options.Version));
+  Options.UseCfgChecksum = CodeGenOpts.CoverageExtraChecksum;
+  Options.NoRedZone = CodeGenOpts.DisableRedZone;
+  Options.FunctionNamesInData = !CodeGenOpts.CoverageNoFunctionNamesInData;
+  Options.ExitBlockBeforeBody = CodeGenOpts.CoverageExitBlockBeforeBody;
+  return Options;
+}
 
 void EmitAssemblyHelper::CreatePasses(legacy::PassManager &MPM,
   legacy::FunctionPassManager &FPM) {
@@ -613,20 +631,8 @@ void EmitAssemblyHelper::CreatePasses(le
   if (!CodeGenOpts.RewriteMapFiles.empty())
 addSymbolRewriterPass(CodeGenOpts, &MPM);
 
-  if (!CodeGenOpts.DisableGCov &&
-  (CodeGenOpts.EmitGcovArcs || CodeGenOpts.EmitGcovNotes)) {
-// Not using 'GCOVOptions::getDefault' allows us to avoid exiting if
-// LLVM's -default-gcov-version flag is set to something invalid.
-GCOVOptions Options;
-Options.EmitNotes = CodeGenOpts.EmitGcovNotes;
-Options.EmitData = CodeGenOpts.EmitGcovArcs;
-memcpy(Options.Version, CodeGenOpts.CoverageVersion, 4);
-Options.UseCfgChecksum = CodeGenOpts.CoverageExtraChecksum;
-Options.NoRedZone = CodeGenOpts.DisableRedZone;
-Options.FunctionNamesInData =
-!CodeGenOpts.CoverageNoFunctionNamesInData;
-Options.ExitBlockBeforeBody = CodeGenOpts.CoverageExitBlockBeforeBody;
-MPM.add(createGCOVProfilerPass(Options));
+  if (Optional Options = getGCOVOptions(CodeGenOpts)) {
+MPM.add(createGCOVProfilerPass(*Options));
 if (CodeGenOpts.getDebugInfo() == codegenoptions::NoDebugInfo)
   MPM.add(createStripSymbolsPass(true));
   }
@@ -954,6 +960,9 @@ void EmitAssemblyHelper::EmitAssemblyWit
CodeGenOpts.DebugPassManager);
   }
 }
+if (Optional Options = getGCOVOptions(CodeGenOpts)) {
+  MPM.addPass(GCOVProfilerPass(*Options));
+}
   }
 
   // FIXME: We still use the legacy pass manager to do code generation. We

Modified: cfe/trunk/test/CodeGen/code-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/code-coverage.c?rev=322126&r1=322125&r2=322126&view=diff
==
--- cfe/trunk/test/CodeGen/code-coverage.c (original)
+++ cfe/trunk/test/CodeGen/code-coverage.c Tue Jan  9 14:03:47 2018
@@ -2,7 +2,10 @@
 // RUN: %clang_cc1 -emit-llvm -disable-red-zone -femit-coverage-data 
-coverage-no-function-names-in-data %s -o - | FileCheck %s --check-prefix 
WITHOUTNAMES
 // RUN: %clang_cc1 -emit-llvm -disable-red-zone -femit-coverage-data 
-coverage-notes-file=aaa.gcno -coverage-data-file=bbb.gcda -dwarf-column-info 
-debug-info-kind=limited -dwa

Re: r321845 - Debug Info: Support DW_AT_calling_convention on composite types.

[David Blaikie via cfe-commits]

Excellent :)

On Mon, Jan 8, 2018 at 8:39 AM Adrian Prantl  wrote:

>
> On Jan 8, 2018, at 8:14 AM, David Blaikie  wrote:
>
> Great - are you tracking/planning to implement this for trivial_abi once
> it's in? (was mentioned in the code review, but not sure if it's on your
> plate/plan or not (no worries if it isn't, just keeping these things in
> mind))
>
>
> Yes, this was in fact my primary motivation for the feature. Since the
> code is asking the ABI object, it looks like this might work out of the box
> with the trivial_abi attribute, but I will definitely at least add a
> testcase once it's in.
>
> -- adrian
>
>
> On Thu, Jan 4, 2018 at 5:14 PM Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Thu Jan  4 17:13:52 2018
>> New Revision: 321845
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=321845&view=rev
>> Log:
>> Debug Info: Support DW_AT_calling_convention on composite types.
>> This implements the DWARF 5 feature described at
>> http://www.dwarfstd.org/ShowIssue.php?issue=141215.1
>>
>> This allows a consumer to understand whether a composite data type is
>> trivially copyable and thus should be passed by value instead of by
>> reference. The canonical example is being able to distinguish the
>> following two types:
>>
>>   // S is not trivially copyable because of the explicit destructor.
>>   struct S {
>>  ~S() {}
>>   };
>>
>>   // T is a POD type.
>>   struct T {
>> ~T() = default;
>>   };
>>
>> 
>> Differential Revision: https://reviews.llvm.org/D41039
>>
>> Added:
>> cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.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=321845&r1=321844&r2=321845&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jan  4 17:13:52 2018
>> @@ -2803,9 +2803,18 @@ llvm::DICompositeType *CGDebugInfo::Crea
>>
>>SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
>>
>> +  // Explicitly record the calling convention for C++ records.
>> +  auto Flags = llvm::DINode::FlagZero;
>> +  if (auto CXXRD = dyn_cast(RD)) {
>> +if (CGM.getCXXABI().getRecordArgABI(CXXRD) == CGCXXABI::RAA_Indirect)
>> +  Flags |= llvm::DINode::FlagTypePassByReference;
>> +else
>> +  Flags |= llvm::DINode::FlagTypePassByValue;
>> +  }
>> +
>>llvm::DICompositeType *RealDecl =
>> DBuilder.createReplaceableCompositeType(
>>getTagForRecord(RD), RDName, RDContext, DefUnit, Line, 0, Size,
>> Align,
>> -  llvm::DINode::FlagZero, FullName);
>> +  Flags, FullName);
>>
>>// Elements of composite types usually have back to the type, creating
>>// uniquing cycles.  Distinct nodes are more efficient.
>>
>> Added: cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp?rev=321845&view=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp (added)
>> +++ cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp Thu Jan  4
>> 17:13:52 2018
>> @@ -0,0 +1,48 @@
>> +// RUN: %clang_cc1 -emit-llvm -debug-info-kind=standalone -triple
>> %itanium_abi_triple %s -o - | FileCheck %s
>> +
>> +// Not trivially copyable because of the explicit destructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefDtor",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct RefDtor {
>> +  int i;
>> +  ~RefDtor() {}
>> +} refDtor;
>> +
>> +// Not trivially copyable because of the explicit copy constructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefCopy",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct RefCopy {
>> +  int i;
>> +  RefCopy() = default;
>> +  RefCopy(RefCopy &Copy) {}
>> +} refCopy;
>> +
>> +// Not trivially copyable because of the explicit move constructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefMove",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct RefMove {
>> +  int i;
>> +  RefMove() = default;
>> +  RefMove(RefMove &&Move) {}
>> +} refMove;
>> +
>> +// POD-like type even though it defines a destructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Podlike", {{.*}}flags:
>> DIFlagTypePassByValue
>> +struct Podlike {
>> +  int i;
>> +  Podlike() = default;
>> +  Podlike(Podlike &&Move) = default;
>> +  ~Podlike() = default;
>> +} podlike;
>> +
>> +
>> +// This is a POD type.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Pod",{{.*}}flags:
>> DIFlagTypePassByValue
>> +struct Pod {
>> +  int i;
>> +} pod;
>> +
>> +// This is definitely not a POD type.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Complex",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct Complex {
>> 

Re: r321845 - Debug Info: Support DW_AT_calling_convention on composite types.

[David Blaikie via cfe-commits]

Great - are you tracking/planning to implement this for trivial_abi once
it's in? (was mentioned in the code review, but not sure if it's on your
plate/plan or not (no worries if it isn't, just keeping these things in
mind))

On Thu, Jan 4, 2018 at 5:14 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Thu Jan  4 17:13:52 2018
> New Revision: 321845
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321845&view=rev
> Log:
> Debug Info: Support DW_AT_calling_convention on composite types.
> This implements the DWARF 5 feature described at
> http://www.dwarfstd.org/ShowIssue.php?issue=141215.1
>
> This allows a consumer to understand whether a composite data type is
> trivially copyable and thus should be passed by value instead of by
> reference. The canonical example is being able to distinguish the
> following two types:
>
>   // S is not trivially copyable because of the explicit destructor.
>   struct S {
>  ~S() {}
>   };
>
>   // T is a POD type.
>   struct T {
> ~T() = default;
>   };
>
> 
> Differential Revision: https://reviews.llvm.org/D41039
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.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=321845&r1=321844&r2=321845&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jan  4 17:13:52 2018
> @@ -2803,9 +2803,18 @@ llvm::DICompositeType *CGDebugInfo::Crea
>
>SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
>
> +  // Explicitly record the calling convention for C++ records.
> +  auto Flags = llvm::DINode::FlagZero;
> +  if (auto CXXRD = dyn_cast(RD)) {
> +if (CGM.getCXXABI().getRecordArgABI(CXXRD) == CGCXXABI::RAA_Indirect)
> +  Flags |= llvm::DINode::FlagTypePassByReference;
> +else
> +  Flags |= llvm::DINode::FlagTypePassByValue;
> +  }
> +
>llvm::DICompositeType *RealDecl =
> DBuilder.createReplaceableCompositeType(
>getTagForRecord(RD), RDName, RDContext, DefUnit, Line, 0, Size,
> Align,
> -  llvm::DINode::FlagZero, FullName);
> +  Flags, FullName);
>
>// Elements of composite types usually have back to the type, creating
>// uniquing cycles.  Distinct nodes are more efficient.
>
> Added: cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp?rev=321845&view=auto
>
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp (added)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp Thu Jan  4
> 17:13:52 2018
> @@ -0,0 +1,48 @@
> +// RUN: %clang_cc1 -emit-llvm -debug-info-kind=standalone -triple
> %itanium_abi_triple %s -o - | FileCheck %s
> +
> +// Not trivially copyable because of the explicit destructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefDtor",{{.*}}flags:
> DIFlagTypePassByReference
> +struct RefDtor {
> +  int i;
> +  ~RefDtor() {}
> +} refDtor;
> +
> +// Not trivially copyable because of the explicit copy constructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefCopy",{{.*}}flags:
> DIFlagTypePassByReference
> +struct RefCopy {
> +  int i;
> +  RefCopy() = default;
> +  RefCopy(RefCopy &Copy) {}
> +} refCopy;
> +
> +// Not trivially copyable because of the explicit move constructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefMove",{{.*}}flags:
> DIFlagTypePassByReference
> +struct RefMove {
> +  int i;
> +  RefMove() = default;
> +  RefMove(RefMove &&Move) {}
> +} refMove;
> +
> +// POD-like type even though it defines a destructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Podlike", {{.*}}flags:
> DIFlagTypePassByValue
> +struct Podlike {
> +  int i;
> +  Podlike() = default;
> +  Podlike(Podlike &&Move) = default;
> +  ~Podlike() = default;
> +} podlike;
> +
> +
> +// This is a POD type.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Pod",{{.*}}flags:
> DIFlagTypePassByValue
> +struct Pod {
> +  int i;
> +} pod;
> +
> +// This is definitely not a POD type.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Complex",{{.*}}flags:
> DIFlagTypePassByReference
> +struct Complex {
> +  Complex() {}
> +  Complex(Complex &Copy) : i(Copy.i) {};
> +  int i;
> +} complex;
>
>
> ___
> 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: r321816 - [OPENMP] Add debug info for generated functions.

[David Blaikie via cfe-commits]

Rough guess: That seems like a lot of code changes for relatively little
test changes - are all parts of this change tested? (Might well be - just
lots of layers to plumb things through - but if there's lots of places that
get locations and only a few of those are tested, maybe this could use more
coverage?)

On Thu, Jan 4, 2018 at 11:46 AM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: abataev
> Date: Thu Jan  4 11:45:16 2018
> New Revision: 321816
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321816&view=rev
> Log:
> [OPENMP] Add debug info for generated functions.
>
> Most of the generated functions for the OpenMP were generated with
> disabled debug info. Patch fixes this for better user experience.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
> cfe/trunk/test/OpenMP/target_parallel_debug_codegen.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=321816&r1=321815&r2=321816&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Thu Jan  4 11:45:16 2018
> @@ -1216,7 +1216,8 @@ emitCombinerOrInitializer(CodeGenModule
>CodeGenFunction CGF(CGM);
>// Map "T omp_in;" variable to "*omp_in_parm" value in all expressions.
>// Map "T omp_out;" variable to "*omp_out_parm" value in all
> expressions.
> -  CGF.StartFunction(GlobalDecl(), C.VoidTy, Fn, FnInfo, Args);
> +  CGF.StartFunction(GlobalDecl(), C.VoidTy, Fn, FnInfo, Args,
> In->getLocation(),
> +Out->getLocation());
>CodeGenFunction::OMPPrivateScope Scope(CGF);
>Address AddrIn = CGF.GetAddrOfLocalVar(&OmpInParm);
>Scope.addPrivate(In, [&CGF, AddrIn, PtrTy]() -> Address {
> @@ -2383,7 +2384,8 @@ llvm::Function *CGOpenMPRuntime::emitThr
>// threadprivate copy of the variable VD
>CodeGenFunction CtorCGF(CGM);
>FunctionArgList Args;
> -  ImplicitParamDecl Dst(CGM.getContext(), CGM.getContext().VoidPtrTy,
> +  ImplicitParamDecl Dst(CGM.getContext(), /*DC=*/nullptr, Loc,
> +/*Id=*/nullptr, CGM.getContext().VoidPtrTy,
>  ImplicitParamDecl::Other);
>Args.push_back(&Dst);
>
> @@ -2393,13 +2395,13 @@ llvm::Function *CGOpenMPRuntime::emitThr
>auto Fn = CGM.CreateGlobalInitOrDestructFunction(
>FTy, ".__kmpc_global_ctor_.", FI, Loc);
>CtorCGF.StartFunction(GlobalDecl(), CGM.getContext().VoidPtrTy, Fn,
> FI,
> -Args, SourceLocation());
> +Args, Loc, Loc);
>auto ArgVal = CtorCGF.EmitLoadOfScalar(
>CtorCGF.GetAddrOfLocalVar(&Dst), /*Volatile=*/false,
>CGM.getContext().VoidPtrTy, Dst.getLocation());
>Address Arg = Address(ArgVal, VDAddr.getAlignment());
> -  Arg = CtorCGF.Builder.CreateElementBitCast(Arg,
> -
>  CtorCGF.ConvertTypeForMem(ASTTy));
> +  Arg = CtorCGF.Builder.CreateElementBitCast(
> +  Arg, CtorCGF.ConvertTypeForMem(ASTTy));
>CtorCGF.EmitAnyExprToMem(Init, Arg, Init->getType().getQualifiers(),
> /*IsInitializer=*/true);
>ArgVal = CtorCGF.EmitLoadOfScalar(
> @@ -2414,7 +2416,8 @@ llvm::Function *CGOpenMPRuntime::emitThr
>// of the variable VD
>CodeGenFunction DtorCGF(CGM);
>FunctionArgList Args;
> -  ImplicitParamDecl Dst(CGM.getContext(), CGM.getContext().VoidPtrTy,
> +  ImplicitParamDecl Dst(CGM.getContext(), /*DC=*/nullptr, Loc,
> +/*Id=*/nullptr, CGM.getContext().VoidPtrTy,
>  ImplicitParamDecl::Other);
>Args.push_back(&Dst);
>
> @@ -2425,7 +2428,7 @@ llvm::Function *CGOpenMPRuntime::emitThr
>FTy, ".__kmpc_global_dtor_.", FI, Loc);
>auto NL = ApplyDebugLocation::CreateEmpty(DtorCGF);
>DtorCGF.StartFunction(GlobalDecl(), CGM.getContext().VoidTy, Fn,
> FI, Args,
> -SourceLocation());
> +Loc, Loc);
>// Create a scope with an artificial location for the body of this
> function.
>auto AL = ApplyDebugLocation::CreateArtificial(DtorCGF);
>auto ArgVal = DtorCGF.EmitLoadOfScalar(
> @@ -2469,7 +2472,7 @@ llvm::Function *CGOpenMPRuntime::emitThr
>FunctionArgList ArgList;
>InitCGF.StartFunction(GlobalDecl(), CGM.getContext().VoidTy,
> InitFunction,
>  CGM.getTypes().arrangeNullaryFunction(),
> ArgList,
> -Loc);
> +Loc, Loc);
>emitThreadPrivateVarInit(InitCGF, VDAddr, Ctor, CopyCtor, Dtor,
> Loc);
>   

Re: r321854 - NFC.

[David Blaikie via cfe-commits]

It helps to have the first line of the commit message be roughly
descriptive, since it forms the brief commit summary in version tools and
the subject line in commit email - just "NFC" is a bit unclear. Usually
these sort of commits are described as, say "Suppress -Asserts
unused-variable warning for variable only used in an assert".

On Fri, Jan 5, 2018 at 4:52 AM Evgeny Stupachenko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: evstupac
> Date: Thu Jan  4 18:22:52 2018
> New Revision: 321854
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321854&view=rev
> Log:
> NFC.
> The patch fixes r321395, that cuased
>  -Werror=unused-but-set-variable issue for
>  Diagnosed var on prod build.
>
> From: Evgeny Stupachenko 
>
> Modified:
> cfe/trunk/lib/Serialization/ASTReader.cpp
>
> Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=321854&r1=321853&r2=321854&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTReader.cpp Thu Jan  4 18:22:52 2018
> @@ -10660,6 +10660,7 @@ void ASTReader::diagnoseOdrViolations()
>Diagnosed = true;
>break;
>  }
> +(void)Diagnosed;
>  assert(Diagnosed && "Unable to emit ODR diagnostic.");
>}
>  }
>
>
> ___
> 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: r321997 - Avoid assumption that lit tests are writable. NFC

[David Blaikie via cfe-commits]

I'm sure it's something obvious I don't understand here, but maybe someone
else doesn't either & could benefit from it:

What exactly does this change do? In what important way is "cp X Y"
different from "cat X > Y"?

On Mon, Jan 8, 2018 at 7:06 AM Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sammccall
> Date: Mon Jan  8 07:05:01 2018
> New Revision: 321997
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321997&view=rev
> Log:
> Avoid assumption that lit tests are writable. NFC
>
> Modified:
> cfe/trunk/test/ARCMT/releases-driver.m
> cfe/trunk/test/ARCMT/releases-driver.m.result
> cfe/trunk/test/ARCMT/with-arc-mode-modify.m
> cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result
> cfe/trunk/test/PCH/verify_pch.m
> cfe/trunk/test/VFS/real-path-found-first.m
>
> Modified: cfe/trunk/test/ARCMT/releases-driver.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/releases-driver.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/releases-driver.m (original)
> +++ cfe/trunk/test/ARCMT/releases-driver.m Mon Jan  8 07:05:01 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fblocks -fsyntax-only -fobjc-arc -x objective-c
> %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -triple x86_64-apple-macosx10.6 -x
> objective-c %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/ARCMT/releases-driver.m.result
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/releases-driver.m.result?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/releases-driver.m.result (original)
> +++ cfe/trunk/test/ARCMT/releases-driver.m.result Mon Jan  8 07:05:01 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fblocks -fsyntax-only -fobjc-arc -x objective-c
> %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -triple x86_64-apple-macosx10.6 -x
> objective-c %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/ARCMT/with-arc-mode-modify.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/with-arc-mode-modify.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/with-arc-mode-modify.m (original)
> +++ cfe/trunk/test/ARCMT/with-arc-mode-modify.m Mon Jan  8 07:05:01 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fsyntax-only -fobjc-arc -x objective-c %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -fsyntax-only -fobjc-arc -x objective-c
> %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result (original)
> +++ cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result Mon Jan  8 07:05:01
> 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fsyntax-only -fobjc-arc -x objective-c %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -fsyntax-only -fobjc-arc -x objective-c
> %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/PCH/verify_pch.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/verify_pch.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/PCH/verify_pch.m (original)
> +++ cfe/trunk/test/PCH/verify_pch.m Mon Jan  8 07:05:01 2018
> @@ -2,7 +2,7 @@
>  // RUN: rm -rf %t
>  // RUN: mkdir -p %t/usr/include
>  // RUN: echo '// empty' > %t/usr/include/sys_header.h
> -// RUN: cp %s %t.h
> +// RUN: cat %s > %t.h
>  //
>  // Precompile
>  // RUN: %clang_cc1 -isystem %t/usr/include -x objective-c-header
> -emit-pch -o %t.pch %t.h
>
> Modified: cfe/trunk/test/VFS/real-path-found-first.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/VFS/real-path-found-first.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/VFS/real-path-found-first.m (original)
> +++ cfe/trunk/test/VFS/real-path-found-first.m Mon Jan  8 07:05:01 2018
> @@ -7,7 +7,7 @@
>  // REQUIRES: shell
>  // RUN: rm -rf %t %t-cache %t.pch
>  // RUN: mkdir -p %t/SomeFramework.framework/Modules
> -// RUN: cp %S/Inputs/some_frame_module.map
> %t/SomeFramework.framework/Modules/module.modulemap
> +// RUN: cat %S/Inputs/some_frame_module.map >
> %t/SomeFramework.framework/Modules/module.modulemap
>  // RUN: sed -e "s:INPUT_DIR:%S/Inputs:g" -e "s:OUT_DIR:%t:g"
>

Re: trivial_abi

[David Blaikie via cfe-commits]

(just a side note: perhaps this conversation would've been more suited to
cfe-dev? I sort of missed it because I only check commits once a week,
unless I'm specifically cc'd on something. All good though :))

On Wed, Jan 3, 2018 at 4:06 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 3 January 2018 at 15:24, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Jan 3, 2018, at 5:53 PM, Richard Smith  wrote:
>> On 3 January 2018 at 14:29, John McCall via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> On Jan 3, 2018, at 5:12 PM, Richard Smith  wrote:
>>>
>>> On 2 January 2018 at 20:55, John McCall via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Jan 2, 2018, at 10:43 PM, Richard Smith 
 wrote:

 On 2 January 2018 at 19:02, John McCall via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

>
> On Jan 2, 2018, at 9:15 PM, Akira Hatanaka 
> wrote:
>
>
>
> On Jan 2, 2018, at 4:56 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On 2 January 2018 at 15:33, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hey, Richard et al.  Akira and I were talking about the right ABI
>> rule for deciding can-pass-in-registers-ness for structs in the presence 
>> of
>> trivial_abi, and I think I like Akira's approach but wanted to get your
>> input.
>>
>> The current definition in Itanium is:
>>
>>   *non-trivial for the purposes of calls*
>>
>> A type is considered non-trivial for the purposes of calls if:
>>
>>- it has a non-trivial copy constructor, move constructor, or
>>destructor, or
>>
>> I'm assuming we're implicitly excluding deleted functions here. (I'd
> prefer to make that explicit; this has been the source of a number of ABI
> mismatches.)
>
>>
>>- all of its copy and move constructors are deleted.
>>
>>
>> I'd suggest modifying this to:
>>
>> A type is considered non-trivial for the purposes of calls if:
>> - if has a copy constructor, move constructor, or destructor which is
>> non-trivial for the purposes of calls, or
>> - all of its copy and move constructors are deleted and it does not
>> have the trivial_abi attribute.
>>
>> A copy/move constructor is considered trivial for the purposes of
>> calls if:
>> - it is user-provided and
>> - the class has the trivial_abi attribute and
>> - a defaulted definition of the constructor would be trivial for the
>> purposes of calls; or
>>
>
> We'd need to say what happens if the function in question cannot
> validly be defaulted for any of the reasons in [dcl.fct.def.default]. Do 
> we
> try to infer whether it's a copy or move constructor, and use the rules 
> for
> a defaulted copy or move constructor? Or do we just say that's never
> trivial for the purposes of calls? Or something else? Eg:
>
> struct [[clang::trivial_abi]] A {
>   A(A && = make());
> };
>
> Here, A::A(A&&) cannot validly be defaulted. Is A trivial for the
> purpose of calls? Likewise:
>
> struct [[clang::trivial_abi]] B {
>   B(...);
> };
> struct C {
>   volatile B b;
> };
>
> Here, C's copy constructor calls B::B(...). Is C trivial for the
> purpose of calls? (OK, Clang crashes on that example today. But still...)
>
> I'd be uncomfortable making the rules in [dcl.fct.def.default] part of
> the ABI; they seem to be changing relatively frequently. Perhaps we could
> say "if the function is a copy constructor ([class.copy.ctor]/1), then
> consider what an implicitly-declared defaulted copy constructor would do;
> if it's a move constructor ([class.copy.ctor]/2), then consider what an
> implicitly-declared defaulted move constructor would do; otherwise, it's
> not trivial for the purpose of calls". That'd mean A is trivial for the
> purpose of calls and C is not, which I think is probably the right answer.
>
> - it is not user-provided and
>> - the class has no virtual functions and no virtual base classes, and
>> - the constructor used to copy/move each direct base class subobject
>> is trivial for the purposes of calls, and
>> - for each non-static data member that is of class type (or array
>> thereof), the constructor selected to copy/move that member is trivial 
>> for
>> the purposes of calls.
>>
>> A destructor is considered trivial for the purposes of calls if:
>> - it is not user-provided or the class has the trivial_abi attribute,
>> and
>> - the destructor is not virtual, and
>> - all of the direct base classes of its class have destructors that
>> are trivial for the purposes of calls, and
>> - for all of the non-static data membe

Re: [PATCH] D41414: [analyzer] Add keyboard j/k navigation to HTML reports

[David Blaikie via cfe-commits]

Sure, this is post-commit review feedback.

vim with dvorak works in the sense that it's not unusable, but it's pretty
awkward (see, for example, discussions like this:
http://vim.wikia.com/wiki/Using_Vim_with_the_Dvorak_keyboard_layout )

On Tue, Jan 2, 2018 at 10:03 AM George Karpenkov 
wrote:

> This patch has already landed — also IIRC e.g. vim on dvorak also uses
> hjkl navigation with no issues.
>
>
> On Dec 25, 2017, at 11:21 AM, David Blaikie  wrote:
>
> any chance this can be implemented based on keyboard layout, so it's good
> for dvorak users as well? (maybe it already is, I don't know - just
> mentioning it in case)
>
> On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via
> cfe-commits  wrote:
>
>> This revision was automatically updated to reflect the committed changes.
>> Closed by commit rC321320: [analyzer] Add Javascript to analyzer HTML
>> output to allow keyboard navigation. (authored by george.karpenkov,
>> committed by ).
>> Herald added a subscriber: cfe-commits.
>>
>> Changed prior to commit:
>>   https://reviews.llvm.org/D41414?vs=127919&id=127954#toc
>>
>> Repository:
>>   rC Clang
>>
>> https://reviews.llvm.org/D41414
>>
>> Files:
>>   lib/Rewrite/HTMLRewrite.cpp
>>   lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
>>
>> ___
>> 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: [PATCH] D41039: Add support for attribute "trivial_abi"

[David Blaikie via cfe-commits]

On Tue, Dec 19, 2017 at 9:43 PM Akira Hatanaka  wrote:

> On Tue, Dec 12, 2017 at 12:12 PM, John McCall  wrote:
>
>> On Tue, Dec 12, 2017 at 1:45 PM, David Blaikie 
>> wrote:
>>
>>> On Mon, Dec 11, 2017 at 5:38 PM John McCall  wrote:
>>>
 On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie 
 wrote:

> On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> rjmccall added a comment.
>>
>> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote:
>>
>> > I had a discussion with Duncan today and he pointed out that
>> perhaps we shouldn't allow users to annotate a struct with "trivial_abi" 
>> if
>> one of its subobjects is non-trivial and is not annotated with
>> "trivial_abi" since that gives users too much power.
>> >
>> > Should we error out or drop "trivial_abi" from struct Outer when
>> the following code is compiled?
>> >
>> >   struct Inner1 {
>> > ~Inner1(); // non-trivial
>> > int x;
>> >   };
>> >
>> >   struct __attribute__((trivial_abi)) Outer {
>> > ~Outer();
>> > Inner1 x;
>> >   };
>> >
>> >
>> > The current patch doesn't error out or drop the attribute, but the
>> patch would probably be much simpler if we didn't allow it.
>>
>>
>> I think it makes sense to emit an error if there is provably a
>> non-trivial-ABI component.  However, for class temploids I think that
>> diagnostic should only fire on the definition, not on instantiations; for
>> example:
>>
>>   template  struct __attribute__((trivial_abi)) holder {
>>  T value;
>>  ~holder() {}
>>   };
>>   holder hs; // this instantiation should be legal
>> despite the fact that holder cannot be trivial-ABI.
>>
>> But we should still be able to emit the diagnostic in template
>> definitions, e.g.:
>>
>>   template  struct __attribute__((trivial_abi)) named_holder
>> {
>>  std::string name; // there are no instantiations of this
>> template that could ever be trivial-ABI
>>  T value;
>>  ~named_holder() {}
>>   };
>>
>> The wording should be something akin to the standard template rule
>> that a template is ill-formed if it has no valid instantiations, no
>> diagnostic required.
>>
>> I would definitely like to open the conversation about the name of
>> the attribute.  I don't think we've used "abi" in an existing attribute
>> name; usually it's more descriptive.  And "trivial" is a weighty word in
>> the standard.  I'm not sure I have a great counter-proposal off the top 
>> of
>> my head, though.
>>
>
> Agreed on both counts (would love a better name, don't have any
> stand-out candidates off the top of my head).
>
> I feel like a more descriptive term about the property of the object
> would make me happier - something like "address_independent_identity"
> (s/identity/value/?) though, yeah, that's not spectacular by any stretch.
>

 Incidentally, your comments are not showing up on Phabricator for some
 reason.

>>>
>>> Yeah, Phab doesn't do a great job looking on the mailing list for
>>> interesting replies - I forget, maybe it only catches bottom post or top
>>> post but not infix replies or something...
>>>
>>
>> Well, fortunately the mailing list is also archived. :)
>>
>>
>>> The term "trivially movable" suggests itself, with two caveats:
   - What we're talking about is trivial *destructive* movability, i.e.
 that the combination of moving the value to a new object and not destroying
 the old object can be done trivially, which is not quite the same as
 trivial movability in the normal C++ sense, which I guess could be a
 property that someone theoretically might care about (if the type is
 trivially destructed, but it isn't copyable for semantic reasons?).
   - Trivial destructive movability is a really common property, and
 it's something that a compiler would really like to optimize based on even
 in cases where trivial_abi can't be adopted for binary-compatibility
 reasons.  Stealing the term for the stronger property that the type is
 trivially destructively movable *and its ABI should reflect that in a
 specific way* would be unfortunate.

>>>
>>> Fair point.
>>>
>>>
 "trivially_movable" is a long attribute anyway, and
 "trivially_destructively_movable" is even worse.

 Maybe that second point is telling us that this isn't purely
 descriptive — it's inherently talking about the ABI, not just the semantics
 of the type.  I might be talking myself into accepting trivial_abi if we
 don't end up with a better suggestion.

>>>
>>> *nod* I think if you want to slice this that way (ensuring there's space
>>> to support describing a similar property for use only 

Re: [PATCH] D41414: [analyzer] Add keyboard j/k navigation to HTML reports

[David Blaikie via cfe-commits]

any chance this can be implemented based on keyboard layout, so it's good
for dvorak users as well? (maybe it already is, I don't know - just
mentioning it in case)

On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via
cfe-commits  wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rC321320: [analyzer] Add Javascript to analyzer HTML
> output to allow keyboard navigation. (authored by george.karpenkov,
> committed by ).
> Herald added a subscriber: cfe-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D41414?vs=127919&id=127954#toc
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D41414
>
> Files:
>   lib/Rewrite/HTMLRewrite.cpp
>   lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
>
> ___
> 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: r321319 - [ODRHash] Canonicalize Decl's before processing.

[David Blaikie via cfe-commits]

Test case?

On Thu, Dec 21, 2017 at 2:39 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Thu Dec 21 14:38:29 2017
> New Revision: 321319
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321319&view=rev
> Log:
> [ODRHash] Canonicalize Decl's before processing.
>
> Canonicalizing the Decl before processing it as part of the hash should
> reduce
> issues with non-canonical types showing up as mismatches.
>
> Modified:
> cfe/trunk/lib/AST/ODRHash.cpp
>
> Modified: cfe/trunk/lib/AST/ODRHash.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ODRHash.cpp?rev=321319&r1=321318&r2=321319&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ODRHash.cpp (original)
> +++ cfe/trunk/lib/AST/ODRHash.cpp Thu Dec 21 14:38:29 2017
> @@ -468,6 +468,7 @@ void ODRHash::AddCXXRecordDecl(const CXX
>
>  void ODRHash::AddDecl(const Decl *D) {
>assert(D && "Expecting non-null pointer.");
> +  D = D->getCanonicalDecl();
>auto Result = DeclMap.insert(std::make_pair(D, DeclMap.size()));
>ID.AddInteger(Result.first->second);
>// On first encounter of a Decl pointer, process it.  Every time
> afterwards,
>
>
> ___
> 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: [clang-tools-extra] r321192 - [clangd] Remove an unused lambda capture.

[David Blaikie via cfe-commits]

Generally I'd encourage you/anyone to use [&] for any lambda that doesn't
escape its scope - avoids any issues like this & doesn't really hinder
readability imho.

On Wed, Dec 20, 2017 at 9:23 AM Eric Liu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ioeric
> Date: Wed Dec 20 09:22:56 2017
> New Revision: 321192
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321192&view=rev
> Log:
> [clangd] Remove an unused lambda capture.
>
> Modified:
> clang-tools-extra/trunk/unittests/clangd/Annotations.cpp
>
> Modified: clang-tools-extra/trunk/unittests/clangd/Annotations.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/Annotations.cpp?rev=321192&r1=321191&r2=321192&view=diff
>
> ==
> --- clang-tools-extra/trunk/unittests/clangd/Annotations.cpp (original)
> +++ clang-tools-extra/trunk/unittests/clangd/Annotations.cpp Wed Dec 20
> 09:22:56 2017
> @@ -24,7 +24,7 @@ static void require(bool Assertion, cons
>
>  Annotations::Annotations(StringRef Text) {
>auto Here = [this] { return offsetToPosition(Code, Code.size()); };
> -  auto Require = [this, Text](bool Assertion, const char *Msg) {
> +  auto Require = [Text](bool Assertion, const char *Msg) {
>  require(Assertion, Msg, Text);
>};
>Optional Name;
>
>
> ___
> 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: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

On Tue, Dec 19, 2017 at 1:50 PM Robinson, Paul 
wrote:

> On the lldb-dev thread I thought this was a reasonable idea
> (DW_AT_linkage_name on types) but given the use-case, probably best to
> confine it to classes with vtables?  If there's a broader use-case it
> wasn't clear from the other thread;
>

Yeah, that's the only one I know of from these conversations.


> there it was reported that LLDB really only uses the mangled name for
> tracking down the type description associated with a vtable (which of
> course has a mangled name giving the type).
>

GDB seems to use it for this too - no idea if it has other uses for exact
matching of demangled symbol names with type names in DWARF.


> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Tuesday, December 19, 2017 1:36 PM
> *To:* Anton Gorenkov; Robinson, Paul; Adrian Prantl
> *Cc:* xgsa; mlek...@skidmore.edu;
> reviews+d39622+public+b0839896b45cd...@reviews.llvm.org;
> cfe-commits@lists.llvm.org; shen...@google.com
> *Subject:* Re: [PATCH] D39622: Fix type name generation in DWARF for
> template instantiations with enum types and template specializations
>
>
>
> Not much - I've put them on this part of the thread specifically to raise
> attention.
>
> If it doesn't get visibility here, maybe a cfe-dev thread would be good.
>
>
> On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov  wrote:
>
> Sorry, I am quite new to the process. It seems, Adrian and Paul are in the
> reviewers/subscribers list to the original review (
> https://reviews.llvm.org/D39622). Should I do something else?
>
> 19.12.2017 23:06, David Blaikie wrote:
>
> Yep, could be worth having a conversation with the GDB folks and/or at
> least poke the other LLVM debug info folks (Adrian and Paul - Paul's pretty
> interesting since he works with/on another (not LLDB nor GDB) debugger
> which would have to think about this
> functionality/feature/issue/data/limitation)
>
>
>
> On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov  wrote:
>
> There was a discussion in lldb-dev mailing list on this topic and I
> suppose a reliable solution was suggested [1]. It is to generate
> DW_AT_linkage_name for vtable DIE of a class and provide an additional
> accelerator table. I am going to try to implement this approach (it will
> require some work on both clang and lldb sides), but I'd like also to
> understand if I should discard or complete the current patch. Certainly,
> I'd prefer to complete it if it could be applied (I suppose, at least
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:25, David Blaikie via cfe-commits wrote:
> >
> >
> > On Fri, Dec 15, 2017 at 8:09 AM xgsa  > <mailto:x...@yandex.ua>> wrote:
> >
> > David, thank you for the detailed answer and corner cases.
> > Just to clarify: everywhere in my mail where I mentioned
> > "debugger", I meant LLDB, but not GDB (except, where I mentioned
> > GDB explicitly). Currently, I have no plans to work on GDB,
> > however I would like to make the clang+LLDB pair working in such
> > cases.
> >
> >
> > *nod* My concern is making sure, if possible, we figure out a design
> > that seems viable long-term/in general. (& if we figure out what that
> > design is, but decide it's not achievable immediately, we can make
> > deliberate tradeoffs, document the long term goal & what the short
> > term solutions cost relative to that goal, etc)
> >
> > Thus, I have described your idea in the lldb-dev mailing list [1].
> > Still, I have some concerns about the performance of such
> > semantically aware matching. Currently, with acceleration tables
> > (e.g. apple_types etc) the matching is as fast as lookup in hash
> > map and hash map is loade almost without postprocessing.
> > Semantically aware matching will require either processing during
> > statup or almost linear lookup.
> >
> >
> > Yep, I agree - that seems like a reasonable concern. I wonder whether
> > it'd be reasonable to put accelerator table entries containing the
> > base name of the template to ease such lookup?
> >
> >  Still, should this topic be raised in cde-dev or are all the
> > interested people already here?
> >
> >
> > Yeah, might be worth moving this to a thread there. Though we probably
> > have all the right people

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

Not much - I've put them on this part of the thread specifically to raise
attention.

If it doesn't get visibility here, maybe a cfe-dev thread would be good.



On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov  wrote:

> Sorry, I am quite new to the process. It seems, Adrian and Paul are in the
> reviewers/subscribers list to the original review (
> https://reviews.llvm.org/D39622). Should I do something else?
> 19.12.2017 23:06, David Blaikie wrote:
>
> Yep, could be worth having a conversation with the GDB folks and/or at
> least poke the other LLVM debug info folks (Adrian and Paul - Paul's pretty
> interesting since he works with/on another (not LLDB nor GDB) debugger
> which would have to think about this
> functionality/feature/issue/data/limitation)
>
> On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov  wrote:
>
>> There was a discussion in lldb-dev mailing list on this topic and I
>> suppose a reliable solution was suggested [1]. It is to generate
>> DW_AT_linkage_name for vtable DIE of a class and provide an additional
>> accelerator table. I am going to try to implement this approach (it will
>> require some work on both clang and lldb sides), but I'd like also to
>> understand if I should discard or complete the current patch. Certainly,
>> I'd prefer to complete it if it could be applied (I suppose, at least
>> tests should be added), because even with long term solution implemented
>> in clang/lldb, gdb still won't resolve dynamic types properly for the
>> described cases.
>>
>> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>>
>> 15.12.2017 21:25, David Blaikie via cfe-commits wrote:
>> >
>> >
>> > On Fri, Dec 15, 2017 at 8:09 AM xgsa > > <mailto:x...@yandex.ua>> wrote:
>> >
>> > David, thank you for the detailed answer and corner cases.
>> > Just to clarify: everywhere in my mail where I mentioned
>> > "debugger", I meant LLDB, but not GDB (except, where I mentioned
>> > GDB explicitly). Currently, I have no plans to work on GDB,
>> > however I would like to make the clang+LLDB pair working in such
>> > cases.
>> >
>> >
>> > *nod* My concern is making sure, if possible, we figure out a design
>> > that seems viable long-term/in general. (& if we figure out what that
>> > design is, but decide it's not achievable immediately, we can make
>> > deliberate tradeoffs, document the long term goal & what the short
>> > term solutions cost relative to that goal, etc)
>> >
>> > Thus, I have described your idea in the lldb-dev mailing list [1].
>> > Still, I have some concerns about the performance of such
>> > semantically aware matching. Currently, with acceleration tables
>> > (e.g. apple_types etc) the matching is as fast as lookup in hash
>> > map and hash map is loade almost without postprocessing.
>> > Semantically aware matching will require either processing during
>> > statup or almost linear lookup.
>> >
>> >
>> > Yep, I agree - that seems like a reasonable concern. I wonder whether
>> > it'd be reasonable to put accelerator table entries containing the
>> > base name of the template to ease such lookup?
>> >
>> >  Still, should this topic be raised in cde-dev or are all the
>> > interested people already here?
>> >
>> >
>> > Yeah, might be worth moving this to a thread there. Though we probably
>> > have all the right people here, it's a better spot for the
>> > conversation even for spectators, history (finding this later when we
>> > have similar questions, etc), etc.
>> >
>> > [1] -
>> > http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html
>> > 14.12.2017, 22:40, "David Blaikie" > > <mailto:dblai...@gmail.com>>:
>> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
>> >> mailto:revi...@reviews.llvm.org>>
>> wrote:
>> >>
>> >> xgsa added a comment.
>> >>
>> >> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>> >>
>> >> > Philosophically, mangled names and DWARF information serve
>> >> different purposes, and I don't think you will find one true
>> >> solution where both of them can yield the same name that
>> >> everyone will be happy with.  Mangled

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

Yep, could be worth having a conversation with the GDB folks and/or at
least poke the other LLVM debug info folks (Adrian and Paul - Paul's pretty
interesting since he works with/on another (not LLDB nor GDB) debugger
which would have to think about this
functionality/feature/issue/data/limitation)

On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov  wrote:

> There was a discussion in lldb-dev mailing list on this topic and I
> suppose a reliable solution was suggested [1]. It is to generate
> DW_AT_linkage_name for vtable DIE of a class and provide an additional
> accelerator table. I am going to try to implement this approach (it will
> require some work on both clang and lldb sides), but I'd like also to
> understand if I should discard or complete the current patch. Certainly,
> I'd prefer to complete it if it could be applied (I suppose, at least
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:25, David Blaikie via cfe-commits wrote:
> >
> >
> > On Fri, Dec 15, 2017 at 8:09 AM xgsa  > <mailto:x...@yandex.ua>> wrote:
> >
> > David, thank you for the detailed answer and corner cases.
> > Just to clarify: everywhere in my mail where I mentioned
> > "debugger", I meant LLDB, but not GDB (except, where I mentioned
> > GDB explicitly). Currently, I have no plans to work on GDB,
> > however I would like to make the clang+LLDB pair working in such
> > cases.
> >
> >
> > *nod* My concern is making sure, if possible, we figure out a design
> > that seems viable long-term/in general. (& if we figure out what that
> > design is, but decide it's not achievable immediately, we can make
> > deliberate tradeoffs, document the long term goal & what the short
> > term solutions cost relative to that goal, etc)
> >
> > Thus, I have described your idea in the lldb-dev mailing list [1].
> > Still, I have some concerns about the performance of such
> > semantically aware matching. Currently, with acceleration tables
> > (e.g. apple_types etc) the matching is as fast as lookup in hash
> > map and hash map is loade almost without postprocessing.
> > Semantically aware matching will require either processing during
> > statup or almost linear lookup.
> >
> >
> > Yep, I agree - that seems like a reasonable concern. I wonder whether
> > it'd be reasonable to put accelerator table entries containing the
> > base name of the template to ease such lookup?
> >
> >  Still, should this topic be raised in cde-dev or are all the
> > interested people already here?
> >
> >
> > Yeah, might be worth moving this to a thread there. Though we probably
> > have all the right people here, it's a better spot for the
> > conversation even for spectators, history (finding this later when we
> > have similar questions, etc), etc.
> >
> > [1] -
> > http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html
> > 14.12.2017, 22:40, "David Blaikie"  > <mailto:dblai...@gmail.com>>:
> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
> >> mailto:revi...@reviews.llvm.org>> wrote:
> >>
> >> xgsa added a comment.
> >>
> >> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
> >>
> >> > Philosophically, mangled names and DWARF information serve
> >> different purposes, and I don't think you will find one true
> >> solution where both of them can yield the same name that
> >> everyone will be happy with.  Mangled names exist to provide
> >> unique and reproducible identifiers for the "same" entity
> >> across compilation units.  They are carefully specified (for
> >> example) to allow a linker to associate a reference in one
> >> object file to a definition in a different object file, and
> >> be guaranteed that the association is correct.  A demangled
> >> name is a necessarily context-free translation of the mangled
> >> name into something that has a closer relationship to how a
> >> human would think of or write the name of the thing, but
> >> isn't necessarily the only way to write the name of the thing.
> >> >
> 

Re: [clang-tools-extra] r320591 - [clangd] Fix bool conversion operator of UniqueFunction

[David Blaikie via cfe-commits]

This operator bool should probably be explicit (as most/all of them should
be - and most of them in LLVM are) - to avoid undue implicit conversion to
other int types.

On Wed, Dec 13, 2017 at 7:43 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ibiryukov
> Date: Wed Dec 13 07:42:59 2017
> New Revision: 320591
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320591&view=rev
> Log:
> [clangd] Fix bool conversion operator of UniqueFunction
>
> Usages of it were giving compiler errors because of the missing
> explicit conversion.
>
> Modified:
> clang-tools-extra/trunk/clangd/Function.h
>
> Modified: clang-tools-extra/trunk/clangd/Function.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Function.h?rev=320591&r1=320590&r2=320591&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/Function.h (original)
> +++ clang-tools-extra/trunk/clangd/Function.h Wed Dec 13 07:42:59 2017
> @@ -49,7 +49,7 @@ public:
>  FunctionCallImpl std::decay::type>>(
>  std::forward(Func))) {}
>
> -  operator bool() { return CallablePtr; }
> +  operator bool() { return bool(CallablePtr); }
>
>Ret operator()(Args... As) {
>  assert(CallablePtr);
>
>
> ___
> 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: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

On Fri, Dec 15, 2017 at 8:09 AM xgsa  wrote:

> David, thank you for the detailed answer and corner cases.
>
> Just to clarify: everywhere in my mail where I mentioned "debugger", I
> meant LLDB, but not GDB (except, where I mentioned GDB explicitly).
> Currently, I have no plans to work on GDB, however I would like to make the
> clang+LLDB pair working in such cases.
>

*nod* My concern is making sure, if possible, we figure out a design that
seems viable long-term/in general. (& if we figure out what that design is,
but decide it's not achievable immediately, we can make deliberate
tradeoffs, document the long term goal & what the short term solutions cost
relative to that goal, etc)


> Thus, I have described your idea in the lldb-dev mailing list [1]. Still,
> I have some concerns about the performance of such semantically aware
> matching. Currently, with acceleration tables (e.g. apple_types etc) the
> matching is as fast as lookup in hash map and hash map is loade almost
> without postprocessing. Semantically aware matching will require either
> processing during statup or almost linear lookup.
>

Yep, I agree - that seems like a reasonable concern. I wonder whether it'd
be reasonable to put accelerator table entries containing the base name of
the template to ease such lookup?


>  Still, should this topic be raised in cde-dev or are all the interested
> people already here?
>

Yeah, might be worth moving this to a thread there. Though we probably have
all the right people here, it's a better spot for the conversation even for
spectators, history (finding this later when we have similar questions,
etc), etc.


>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html
>
> 14.12.2017, 22:40, "David Blaikie" :
>
>
> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>
> > Philosophically, mangled names and DWARF information serve different
> purposes, and I don't think you will find one true solution where both of
> them can yield the same name that everyone will be happy with.  Mangled
> names exist to provide unique and reproducible identifiers for the "same"
> entity across compilation units.  They are carefully specified (for
> example) to allow a linker to associate a reference in one object file to a
> definition in a different object file, and be guaranteed that the
> association is correct.  A demangled name is a necessarily context-free
> translation of the mangled name into something that has a closer
> relationship to how a human would think of or write the name of the thing,
> but isn't necessarily the only way to write the name of the thing.
> >
> > DWARF names are (deliberately not carefully specified) strings that
> ought to bear some relationship to how source code would name the thing,
> but you probably don't want to attach semantic significance to those
> names.  This is rather emphatically true for names containing template
> parameters.  Typedefs (and their recent offspring, 'using' aliases) are
> your sworn enemy here.  Enums, as you have found, are also a problem.
> >
> > Basically, the type of an entity does not have a unique name, and trying
> to coerce different representations of the type into having the same unique
> name is a losing battle.
>
>
> I'm actually going back and forth on this ^. It seems to me, regardless of
> mangled names, etc, it'd be good if LLVM used the same name for a type in
> DWARF across different translation units. And, to a large extent, we do
> (the case of typedefs in template parameters doesn't seem to present a
> problem for the current implementation - the underlying type is used),
> enums being one place where we don't - and we don't actually make it that
> much closer to the source/based on what the user wrote.
>
> Even if the user had: "enum X { Y = 0, Z = 0; } ... template
> struct foo; ... foo" LLVM still describes that type as "foo". Also
> if you have "enum X: int; ... foo<(X)0>" you get "foo<0>" whereas in
> another translation unit with a definition of X you'd get "foo".
>
> So for consistency there, I kind of think maybe a change like this isn't
> bad.
>
> But of course the specific way a template name is written may easily still
> vary between compilers, so relying on it being exactly the same might not
> be a great idea anyway...
>
>
> Thank you for clarification, Paul! Nevertheless, I suppose, showing actual
> type of a dynamic variable is very important for the projects, where RTTI
> is used. Moreover, it works properly in gcc+gdb pair, so I am extremely
> interested in fixing it in clang+lldb.
>
> I understand that the suggested solution possibly does not cover all the
> cases, but it improves the situation and actually covers all the cases
> found by me (I have just rechecked -- typedefs/usings seems to work fine
> when displaying the real type of variable). If more cases are found

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
revi...@reviews.llvm.org> wrote:

> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>
> > Philosophically, mangled names and DWARF information serve different
> purposes, and I don't think you will find one true solution where both of
> them can yield the same name that everyone will be happy with.  Mangled
> names exist to provide unique and reproducible identifiers for the "same"
> entity across compilation units.  They are carefully specified (for
> example) to allow a linker to associate a reference in one object file to a
> definition in a different object file, and be guaranteed that the
> association is correct.  A demangled name is a necessarily context-free
> translation of the mangled name into something that has a closer
> relationship to how a human would think of or write the name of the thing,
> but isn't necessarily the only way to write the name of the thing.
> >
> > DWARF names are (deliberately not carefully specified) strings that
> ought to bear some relationship to how source code would name the thing,
> but you probably don't want to attach semantic significance to those
> names.  This is rather emphatically true for names containing template
> parameters.  Typedefs (and their recent offspring, 'using' aliases) are
> your sworn enemy here.  Enums, as you have found, are also a problem.
> >
> > Basically, the type of an entity does not have a unique name, and trying
> to coerce different representations of the type into having the same unique
> name is a losing battle.
>

I'm actually going back and forth on this ^. It seems to me, regardless of
mangled names, etc, it'd be good if LLVM used the same name for a type in
DWARF across different translation units. And, to a large extent, we do
(the case of typedefs in template parameters doesn't seem to present a
problem for the current implementation - the underlying type is used),
enums being one place where we don't - and we don't actually make it that
much closer to the source/based on what the user wrote.

Even if the user had: "enum X { Y = 0, Z = 0; } ... template struct
foo; ... foo" LLVM still describes that type as "foo". Also if you
have "enum X: int; ... foo<(X)0>" you get "foo<0>" whereas in another
translation unit with a definition of X you'd get "foo".

So for consistency there, I kind of think maybe a change like this isn't
bad.

But of course the specific way a template name is written may easily still
vary between compilers, so relying on it being exactly the same might not
be a great idea anyway...


> Thank you for clarification, Paul! Nevertheless, I suppose, showing actual
> type of a dynamic variable is very important for the projects, where RTTI
> is used. Moreover, it works properly in gcc+gdb pair, so I am extremely
> interested in fixing it in clang+lldb.
>
> I understand that the suggested solution possibly does not cover all the
> cases, but it improves the situation and actually covers all the cases
> found by me (I have just rechecked -- typedefs/usings seems to work fine
> when displaying the real type of variable). If more cases are found in
> future, they could be fixed similarly too. Moreover, the debuggers already
> rely on the fact that the type name looks the same in RTTI and DWARF, and I
> suppose they have no choice, because there is no other source of
> information for them (or am I missing something?).


I think they would have a choice, actually - let's walk through it...

It sounds like you're thinking of two other possibilities:

1) "I suppose, we cannot extend RTTI with the debug type name (is it
correct?)" - yeah, that's probably correct, extending the RTTI format
probably isn't desirable and we'd still need a singular/canonical DWARF
name which we don't seem to have (& the RTTI might go in another object
file that may not have debug info, or debug info generated by a different
compiler with a different type printing format, etc... )

2) Extending DWARF to include the mangled name
Sort of possible, DW_AT_linkage_name on a DW_AT_class could be used for
this just fine - no DWARF extension required.

But an alternative would be to have debuggers use a more semantically aware
matching here. The debugger does have enough information in the DWARF to
semantically match "foo<(X)0>" with "foo". enum X is in the DWARF,
and the enumerator Y is present with its value 0.

Another case of Clang's DWARF type printing differing from a common
demangling, is an unsigned parameter. template foo; foo<0> -
common demangling for this is "foo<0u>" but Clang will happily render the
type as "foo<0>" - this one seems less easy to justify changing than the
enum case (the enum case, given the declared-but-not-defined enum example,
seems more compelling to try to have clang give a consistent name to the
type (which, while not complete (differing compilers could still use
different printings), seems somewhat desirable)) because i

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

[David Blaikie via cfe-commits]

On Mon, Dec 11, 2017 at 5:38 PM John McCall  wrote:

> On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie  wrote:
>
>> On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> rjmccall added a comment.
>>>
>>> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote:
>>>
>>> > I had a discussion with Duncan today and he pointed out that perhaps
>>> we shouldn't allow users to annotate a struct with "trivial_abi" if one of
>>> its subobjects is non-trivial and is not annotated with "trivial_abi" since
>>> that gives users too much power.
>>> >
>>> > Should we error out or drop "trivial_abi" from struct Outer when the
>>> following code is compiled?
>>> >
>>> >   struct Inner1 {
>>> > ~Inner1(); // non-trivial
>>> > int x;
>>> >   };
>>> >
>>> >   struct __attribute__((trivial_abi)) Outer {
>>> > ~Outer();
>>> > Inner1 x;
>>> >   };
>>> >
>>> >
>>> > The current patch doesn't error out or drop the attribute, but the
>>> patch would probably be much simpler if we didn't allow it.
>>>
>>>
>>> I think it makes sense to emit an error if there is provably a
>>> non-trivial-ABI component.  However, for class temploids I think that
>>> diagnostic should only fire on the definition, not on instantiations; for
>>> example:
>>>
>>>   template  struct __attribute__((trivial_abi)) holder {
>>>  T value;
>>>  ~holder() {}
>>>   };
>>>   holder hs; // this instantiation should be legal despite
>>> the fact that holder cannot be trivial-ABI.
>>>
>>> But we should still be able to emit the diagnostic in template
>>> definitions, e.g.:
>>>
>>>   template  struct __attribute__((trivial_abi)) named_holder {
>>>  std::string name; // there are no instantiations of this template
>>> that could ever be trivial-ABI
>>>  T value;
>>>  ~named_holder() {}
>>>   };
>>>
>>> The wording should be something akin to the standard template rule that
>>> a template is ill-formed if it has no valid instantiations, no diagnostic
>>> required.
>>>
>>> I would definitely like to open the conversation about the name of the
>>> attribute.  I don't think we've used "abi" in an existing attribute name;
>>> usually it's more descriptive.  And "trivial" is a weighty word in the
>>> standard.  I'm not sure I have a great counter-proposal off the top of my
>>> head, though.
>>>
>>
>> Agreed on both counts (would love a better name, don't have any stand-out
>> candidates off the top of my head).
>>
>> I feel like a more descriptive term about the property of the object
>> would make me happier - something like "address_independent_identity"
>> (s/identity/value/?) though, yeah, that's not spectacular by any stretch.
>>
>
> Incidentally, your comments are not showing up on Phabricator for some
> reason.
>

Yeah, Phab doesn't do a great job looking on the mailing list for
interesting replies - I forget, maybe it only catches bottom post or top
post but not infix replies or something...


>
> The term "trivially movable" suggests itself, with two caveats:
>   - What we're talking about is trivial *destructive* movability, i.e.
> that the combination of moving the value to a new object and not destroying
> the old object can be done trivially, which is not quite the same as
> trivial movability in the normal C++ sense, which I guess could be a
> property that someone theoretically might care about (if the type is
> trivially destructed, but it isn't copyable for semantic reasons?).
>   - Trivial destructive movability is a really common property, and it's
> something that a compiler would really like to optimize based on even in
> cases where trivial_abi can't be adopted for binary-compatibility reasons.
> Stealing the term for the stronger property that the type is trivially
> destructively movable *and its ABI should reflect that in a specific way*
> would be unfortunate.
>

Fair point.


> "trivially_movable" is a long attribute anyway, and
> "trivially_destructively_movable" is even worse.
>
> Maybe that second point is telling us that this isn't purely descriptive —
> it's inherently talking about the ABI, not just the semantics of the type.
> I might be talking myself into accepting trivial_abi if we don't end up
> with a better suggestion.
>

*nod* I think if you want to slice this that way (ensuring there's space to
support describing a similar property for use only in non-ABI-breaking
contexts as well) it seems like ABI is the term to use somewhere in the
name.


> Random thing that occurred to me: is it actually reasonable to enforce
> trivial_abi correctness in a non-template context?  Templates aren't the
> only case where a user could reasonably want to add trivial_abi and just
> have it be suppressed if it's wrong.  Imagine if some stdlib made
> std::string trivial_abi; someone might reasonably want to make my
> named_holder example above trivial_abi as well, with the expectation that
> it would only have an effect on targets where std::string was trivial_abi.
> A

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

[David Blaikie via cfe-commits]

On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
revi...@reviews.llvm.org> wrote:

> rjmccall added a comment.
>
> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote:
>
> > I had a discussion with Duncan today and he pointed out that perhaps we
> shouldn't allow users to annotate a struct with "trivial_abi" if one of its
> subobjects is non-trivial and is not annotated with "trivial_abi" since
> that gives users too much power.
> >
> > Should we error out or drop "trivial_abi" from struct Outer when the
> following code is compiled?
> >
> >   struct Inner1 {
> > ~Inner1(); // non-trivial
> > int x;
> >   };
> >
> >   struct __attribute__((trivial_abi)) Outer {
> > ~Outer();
> > Inner1 x;
> >   };
> >
> >
> > The current patch doesn't error out or drop the attribute, but the patch
> would probably be much simpler if we didn't allow it.
>
>
> I think it makes sense to emit an error if there is provably a
> non-trivial-ABI component.  However, for class temploids I think that
> diagnostic should only fire on the definition, not on instantiations; for
> example:
>
>   template  struct __attribute__((trivial_abi)) holder {
>  T value;
>  ~holder() {}
>   };
>   holder hs; // this instantiation should be legal despite
> the fact that holder cannot be trivial-ABI.
>
> But we should still be able to emit the diagnostic in template
> definitions, e.g.:
>
>   template  struct __attribute__((trivial_abi)) named_holder {
>  std::string name; // there are no instantiations of this template
> that could ever be trivial-ABI
>  T value;
>  ~named_holder() {}
>   };
>
> The wording should be something akin to the standard template rule that a
> template is ill-formed if it has no valid instantiations, no diagnostic
> required.
>
> I would definitely like to open the conversation about the name of the
> attribute.  I don't think we've used "abi" in an existing attribute name;
> usually it's more descriptive.  And "trivial" is a weighty word in the
> standard.  I'm not sure I have a great counter-proposal off the top of my
> head, though.
>

Agreed on both counts (would love a better name, don't have any stand-out
candidates off the top of my head).

I feel like a more descriptive term about the property of the object would
make me happier - something like "address_independent_identity"
(s/identity/value/?) though, yeah, that's not spectacular by any stretch.


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

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

[David Blaikie via cfe-commits]

My bet would be: warn and ignore it, but probably Richard's & John might
have stronger thoughts/justifications/etc.

On Mon, Dec 11, 2017 at 1:38 PM Akira Hatanaka via Phabricator <
revi...@reviews.llvm.org> wrote:

> ahatanak added a comment.
>
> I had a discussion with Duncan today and he pointed out that perhaps we
> shouldn't allow users to annotate a struct with "trivial_abi" if one of its
> subobjects is non-trivial and is not annotated with "trivial_abi" since
> that gives users too much power.
>
> Should we error out or drop "trivial_abi" from struct Outer when the
> following code is compiled?
>
>   struct Inner1 {
> ~Inner1(); // non-trivial
> int x;
>   };
>
>   struct __attribute__((trivial_abi)) Outer {
> ~Outer();
> Inner1 x;
>   };
>
> The current patch doesn't error out or drop the attribute, but the patch
> would probably be much simpler if we didn't allow it.
>
>
> https://reviews.llvm.org/D41039
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D40838: [OpenCL] Fix layering violation by getOpenCLTypeAddrSpace

[David Blaikie via cfe-commits]

Thanks!

On Wed, Dec 6, 2017 at 2:12 AM Sven van Haastregt via Phabricator <
revi...@reviews.llvm.org> wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rC319883: [OpenCL] Fix layering violation by
> getOpenCLTypeAddrSpace (authored by svenvh).
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D40838
>
> Files:
>   include/clang/AST/ASTContext.h
>   include/clang/Basic/TargetInfo.h
>   lib/AST/ASTContext.cpp
>   lib/Basic/TargetInfo.cpp
>   lib/Basic/Targets/AMDGPU.h
>   lib/CodeGen/CGOpenCLRuntime.cpp
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33989: [OpenCL] Allow targets to select address space per type

[David Blaikie via cfe-commits]

Ping - I have a pretty clear workaround internally, but still would be
happy to remove any workarounds given the opportunity.

As for layering. For now the issue is that libAST depends on libBasic, and
libraries can't have circular dependencies. Modular builds (well,
especially modular codegen, but even not) can observe some of this/are
broken by this.

So the change as-is isn't acceptable. For now I think it'd be best to fix
the layering as it stands (add enums that can be passed down to Basic as
needed, for example (I haven't looked closely)) & if you believe Basic and
AST should be rolled together - maybe that's worthy of a discussion on
cfe-dev.

On Fri, Nov 17, 2017 at 9:56 AM Anastasia Stulova via Phabricator via
cfe-commits  wrote:

> Anastasia added a comment.
>
> Perhaps, I don't understand the concept of layered design in this
> particular case. But I just find it annoying that we need to re-implement
> the entire OpenCL AST Type structure in Basic. And even if we don't have
> dependencies on the files physically we still logically  bound to the AST
> representation in Basics and just entirely mirror it there.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D33989
>
>
>
> ___
> 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

r318719 - FormatInternal.h: Add missing includes.

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Nov 20 17:09:17 2017
New Revision: 318719

URL: http://llvm.org/viewvc/llvm-project?rev=318719&view=rev
Log:
FormatInternal.h: Add missing includes.

Modified:
cfe/trunk/lib/Format/FormatInternal.h

Modified: cfe/trunk/lib/Format/FormatInternal.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatInternal.h?rev=318719&r1=318718&r2=318719&view=diff
==
--- cfe/trunk/lib/Format/FormatInternal.h (original)
+++ cfe/trunk/lib/Format/FormatInternal.h Mon Nov 20 17:09:17 2017
@@ -16,6 +16,10 @@
 #ifndef LLVM_CLANG_LIB_FORMAT_FORMATINTERNAL_H
 #define LLVM_CLANG_LIB_FORMAT_FORMATINTERNAL_H
 
+#include "BreakableToken.h"
+#include "clang/Tooling/Core/Lookup.h"
+#include 
+
 namespace clang {
 namespace format {
 namespace internal {


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

r318720 - ASTMatchers{, Macros}.h: Add some extra macros to use for decl/def of matchers

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Nov 20 17:09:18 2017
New Revision: 318720

URL: http://llvm.org/viewvc/llvm-project?rev=318720&view=rev
Log:
ASTMatchers{,Macros}.h: Add some extra macros to use for decl/def of matchers

Fix ODR violations caused by using internal linkage variables in
non-internal inline functions. (also removes duplicate definitions, etc)

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchersMacros.h
cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=318720&r1=318719&r2=318720&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Mon Nov 20 17:09:18 2017
@@ -4803,9 +4803,9 @@ AST_MATCHER(Type, realFloatingPointType)
 ///   matches "int b[7]"
 ///
 /// Usable as: Matcher, Matcher
-AST_TYPELOC_TRAVERSE_MATCHER(hasElementType, getElement,
- AST_POLYMORPHIC_SUPPORTED_TYPES(ArrayType,
- ComplexType));
+AST_TYPELOC_TRAVERSE_MATCHER_DECL(hasElementType, getElement,
+  AST_POLYMORPHIC_SUPPORTED_TYPES(ArrayType,
+  
ComplexType));
 
 /// \brief Matches C arrays with a specified constant size.
 ///
@@ -4921,8 +4921,8 @@ extern const AstTypeMatcher
 ///  matches "_Atomic(int) i"
 ///
 /// Usable as: Matcher
-AST_TYPELOC_TRAVERSE_MATCHER(hasValueType, getValue,
- AST_POLYMORPHIC_SUPPORTED_TYPES(AtomicType));
+AST_TYPELOC_TRAVERSE_MATCHER_DECL(hasValueType, getValue,
+  AST_POLYMORPHIC_SUPPORTED_TYPES(AtomicType));
 
 /// \brief Matches types nodes representing C++11 auto types.
 ///
@@ -5115,11 +5115,10 @@ extern const AstTypeMatcher, Matcher,
 ///   Matcher, Matcher
-AST_TYPELOC_TRAVERSE_MATCHER(pointee, getPointee,
- AST_POLYMORPHIC_SUPPORTED_TYPES(BlockPointerType,
- MemberPointerType,
- PointerType,
- ReferenceType));
+AST_TYPELOC_TRAVERSE_MATCHER_DECL(
+pointee, getPointee,
+AST_POLYMORPHIC_SUPPORTED_TYPES(BlockPointerType, MemberPointerType,
+PointerType, ReferenceType));
 
 /// \brief Matches typedef types.
 ///

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersMacros.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersMacros.h?rev=318720&r1=318719&r2=318720&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchersMacros.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersMacros.h Mon Nov 20 17:09:18 
2017
@@ -367,6 +367,27 @@
 // FIXME: add a matcher for TypeLoc derived classes using its custom casting
 // API (no longer dyn_cast) if/when we need such matching
 
+#define AST_TYPE_TRAVERSE_MATCHER_DECL(MatcherName, FunctionName,  
\
+   ReturnTypesF)   
\
+  namespace internal { 
\
+  template  struct TypeMatcher##MatcherName##Getter {  
\
+static QualType (T::*value())() const { return &T::FunctionName; } 
\
+  };   
\
+  }
\
+  extern const ::clang::ast_matchers::internal::   
\
+  TypeTraversePolymorphicMatcher<  
\
+  QualType,
\
+  ::clang::ast_matchers::internal::TypeMatcher##MatcherName##Getter,   
\
+  ::clang::ast_matchers::internal::TypeTraverseMatcher,
\
+  ReturnTypesF>::Func MatcherName
+
+#define AST_TYPE_TRAVERSE_MATCHER_DEF(MatcherName, ReturnTypesF)   
\
+  const ::clang::ast_matchers::internal::TypeTraversePolymorphicMatcher<   
\
+  QualType,
\
+  ::clang::ast_matchers::internal::TypeMatcher##MatcherName##Getter,   
\
+  ::clang::ast_matchers::internal::TypeTraverseMatcher,
\
+  ReturnTypesF>::Func MatcherName
+
 /// \brief AST_TYPE_TRAVERSE_MATCHER(MatcherName, FunctionName) defines
 /// the matcher \c MatcherName that can be used to traverse from one \c Type
 /// to another.
@@ -386,6 +407,30 @@

r318491 - Update for layering fix in LLVM CodeGen<>Target

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Nov 16 17:07:20 2017
New Revision: 318491

URL: http://llvm.org/viewvc/llvm-project?rev=318491&view=rev
Log:
Update for layering fix in LLVM CodeGen<>Target

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=318491&r1=318490&r2=318491&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Thu Nov 16 17:07:20 2017
@@ -44,7 +44,7 @@
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/Target/TargetOptions.h"
-#include "llvm/Target/TargetSubtargetInfo.h"
+#include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/Transforms/Coroutines.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/IPO/AlwaysInliner.h"


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

Re: [PATCH] D33989: [OpenCL] Allow targets to select address space per type

[David Blaikie via cfe-commits]

Ping on this layering violation. A simple way to demonstrate this is to
move the definition of clang::Type::getTypeClass out of line: This results
in an unresolved symbol due to incorrect/broken dependencies.

Richard? Anyone else? Ideas on how to address this layering violation?

Anastasia: Could you explain more what you mean by "A large logical
dependency" - which bits of code expose/demonstrate that dependency? (I
know very little about this code, I came across the layering violation
while trying to build more of Clang & LLVM with modular code generation)

On Thu, Oct 12, 2017 at 6:51 AM Anastasia Stulova via Phabricator via
cfe-commits  wrote:

> Anastasia added inline comments.
>
>
> 
> Comment at: cfe/trunk/lib/Basic/TargetInfo.cpp:351
>
> +LangAS::ID TargetInfo::getOpenCLTypeAddrSpace(const Type *T) const {
> +  auto BT = dyn_cast(T);
> 
> chapuni wrote:
> > Excuse me for old commit, I think it might be layering violation.
> > Could we avoid using AST/Type here?
> One of the problems is that even if we could write another layer of enums
> to map OpenCL specific AST types into the TargetInfo representation it
> doesn't really help creating a layered structure between AST and Basic
> libs.  They seem to have a large logical dependence despite not including
> the library headers physically. So modification in AST would require
> modifications in Basic anyway resulting in overhead of changing 2 places
> instead of 1. So I am wondering if there is any better approach here e.g.
> revisiting the library dependencies or what classes they should contain?
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D33989
>
>
>
> ___
> 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

r318304 - ASTMatchers.h: Fix ODR violations by avoiding internal linkage variables in headers

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Nov 15 08:52:12 2017
New Revision: 318304

URL: http://llvm.org/viewvc/llvm-project?rev=318304&view=rev
Log:
ASTMatchers.h: Fix ODR violations by avoiding internal linkage variables in 
headers

Internal linkage variables ODR referenced from inline functions create
ODR violations (the same inline function ends up having different
definitions in each TU, since it references different variables - rather
than one definition).

This also happens to break modular code generation - so this is the last
fix to allow clang to compile with modular code generation.

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=318304&r1=318303&r2=318304&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Wed Nov 15 08:52:12 2017
@@ -178,7 +178,7 @@ inline internal::TrueMatcher anything()
 /// \endcode
 /// decl(hasDeclContext(translationUnitDecl()))
 ///   matches "int X", but not "int Y".
-const internal::VariadicDynCastAllOfMatcher
+extern const internal::VariadicDynCastAllOfMatcher
 translationUnitDecl;
 
 /// \brief Matches typedef declarations.
@@ -190,7 +190,8 @@ const internal::VariadicDynCastAllOfMatc
 /// \endcode
 /// typedefDecl()
 ///   matches "typedef int X", but not "using Y = int"
-const internal::VariadicDynCastAllOfMatcher typedefDecl;
+extern const internal::VariadicDynCastAllOfMatcher
+typedefDecl;
 
 /// \brief Matches typedef name declarations.
 ///
@@ -201,7 +202,7 @@ const internal::VariadicDynCastAllOfMatc
 /// \endcode
 /// typedefNameDecl()
 ///   matches "typedef int X" and "using Y = int"
-const internal::VariadicDynCastAllOfMatcher
+extern const internal::VariadicDynCastAllOfMatcher
 typedefNameDecl;
 
 /// \brief Matches type alias declarations.
@@ -213,7 +214,8 @@ const internal::VariadicDynCastAllOfMatc
 /// \endcode
 /// typeAliasDecl()
 ///   matches "using Y = int", but not "typedef int X"
-const internal::VariadicDynCastAllOfMatcher typeAliasDecl;
+extern const internal::VariadicDynCastAllOfMatcher
+typeAliasDecl;
 
 /// \brief Matches type alias template declarations.
 ///
@@ -222,7 +224,7 @@ const internal::VariadicDynCastAllOfMatc
 ///   template 
 ///   using Y = X;
 /// \endcode
-const internal::VariadicDynCastAllOfMatcher
+extern const internal::VariadicDynCastAllOfMatcher
 typeAliasTemplateDecl;
 
 /// \brief Matches AST nodes that were expanded within the main-file.
@@ -313,7 +315,7 @@ AST_POLYMORPHIC_MATCHER_P(isExpansionInF
 /// friend X;
 ///   };
 /// \endcode
-const internal::VariadicAllOfMatcher decl;
+extern const internal::VariadicAllOfMatcher decl;
 
 /// \brief Matches a declaration of a linkage specification.
 ///
@@ -323,7 +325,7 @@ const internal::VariadicAllOfMatcher
+extern const internal::VariadicDynCastAllOfMatcher
 linkageSpecDecl;
 
 /// \brief Matches a declaration of anything that could have a name.
@@ -337,7 +339,7 @@ const internal::VariadicDynCastAllOfMatc
 /// } U;
 ///   };
 /// \endcode
-const internal::VariadicDynCastAllOfMatcher namedDecl;
+extern const internal::VariadicDynCastAllOfMatcher namedDecl;
 
 /// \brief Matches a declaration of label.
 ///
@@ -348,7 +350,7 @@ const internal::VariadicDynCastAllOfMatc
 /// \endcode
 /// labelDecl()
 ///   matches 'FOO:'
-const internal::VariadicDynCastAllOfMatcher labelDecl;
+extern const internal::VariadicDynCastAllOfMatcher labelDecl;
 
 /// \brief Matches a declaration of a namespace.
 ///
@@ -359,7 +361,8 @@ const internal::VariadicDynCastAllOfMatc
 /// \endcode
 /// namespaceDecl()
 ///   matches "namespace {}" and "namespace test {}"
-const internal::VariadicDynCastAllOfMatcher namespaceDecl;
+extern const internal::VariadicDynCastAllOfMatcher
+namespaceDecl;
 
 /// \brief Matches a declaration of a namespace alias.
 ///
@@ -370,7 +373,7 @@ const internal::VariadicDynCastAllOfMatc
 /// \endcode
 /// namespaceAliasDecl()
 ///   matches "namespace alias" but not "namespace test"
-const internal::VariadicDynCastAllOfMatcher
+extern const internal::VariadicDynCastAllOfMatcher
 namespaceAliasDecl;
 
 /// \brief Matches class, struct, and union declarations.
@@ -382,9 +385,7 @@ const internal::VariadicDynCastAllOfMatc
 ///   struct S {};
 ///   union U {};
 /// \endcode
-const internal::VariadicDynCastAllOfMatcher<
-  Decl,
-  RecordDecl> recordDecl;
+extern const internal::VariadicDynCastAllOfMatcher 
recordDecl;
 
 /// \brief Matches C++ class declarations.
 ///
@@ -393,9 +394,8 @@ const internal::VariadicDynCastAllOfMatc
 ///   class X;
 ///   template class Z {};
 /// \endcode
-const internal::VariadicDynCastAllOfMatcher<
-  Decl,
-  CXXRecordDecl> cxxRecordDecl;
+exter

Re: [PATCH] D39622: Fix type debug information generation for enum-based template specialization

[David Blaikie via cfe-commits]

On Sun, Nov 12, 2017 at 12:53 PM Anton via Phabricator <
revi...@reviews.llvm.org> wrote:

> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#919579, @aprantl wrote:
>
> > For clarification: what is the "symbols table" you are referring to in
> the description?
>
>
> I meant the data dumped with "nm -an ./test".
>
> By the way, I haven't abandoned the patch, I have found one more case when
> my fix doesn't work and I am working on improvement. Nevertheless, it would
> be helpful to get answers to the questions in this review (about changing
> the "Indentation" field and about the test).
>

I'm confused then - nm's output uses a demangler, the file doesn't actually
have either "Impl" or "Impl<(TagType)0>" in it.

It's probably not OK/possible to ensure the type always matches lldb's
demangled form. Other produces might have another idea of what its
demangled form looks like.


>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D39622
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39622: Fix type debug information generation for enum-based template specialization

[David Blaikie via cfe-commits]

Ping \/

On Fri, Nov 3, 2017 at 4:22 PM David Blaikie  wrote:

> When you say "symbols table" - what are you referring to?
>
> On Fri, Nov 3, 2017 at 4:20 PM Adrian Prantl via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> aprantl added a comment.
>>
>> Can you add a testcase?
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D39622
>>
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39622: Fix type debug information generation for enum-based template specialization

[David Blaikie via cfe-commits]

When you say "symbols table" - what are you referring to?

On Fri, Nov 3, 2017 at 4:20 PM Adrian Prantl via Phabricator <
revi...@reviews.llvm.org> wrote:

> aprantl added a comment.
>
> Can you add a testcase?
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D39622
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r317279 - Modular Codegen: Don't home always_inline functions

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Nov  2 15:28:50 2017
New Revision: 317279

URL: http://llvm.org/viewvc/llvm-project?rev=317279&view=rev
Log:
Modular Codegen: Don't home always_inline functions

Since they'll likely (not always - if the address is taken, etc) be
inlined away, even at -O0, separately provided weak definitions are
likely to be unused so skip all of that.

Modified:
cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
cfe/trunk/test/Modules/Inputs/codegen/foo.h
cfe/trunk/test/Modules/Inputs/codegen/use.cpp
cfe/trunk/test/Modules/codegen.test

Modified: cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterDecl.cpp?rev=317279&r1=317278&r2=317279&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriterDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriterDecl.cpp Thu Nov  2 15:28:50 2017
@@ -2270,9 +2270,11 @@ void ASTRecordWriter::AddFunctionDefinit
 if (Writer->Context->getLangOpts().ModulesCodegen) {
   // Under -fmodules-codegen, codegen is performed for all non-internal,
   // non-always_inline functions.
-  if (!Linkage)
-Linkage = Writer->Context->GetGVALinkageForFunction(FD);
-  ModulesCodegen = *Linkage != GVA_Internal;
+  if (!FD->hasAttr()) {
+if (!Linkage)
+  Linkage = Writer->Context->GetGVALinkageForFunction(FD);
+ModulesCodegen = *Linkage != GVA_Internal;
+  }
 }
   }
   Record->push_back(ModulesCodegen);

Modified: cfe/trunk/test/Modules/Inputs/codegen/foo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/codegen/foo.h?rev=317279&r1=317278&r2=317279&view=diff
==
--- cfe/trunk/test/Modules/Inputs/codegen/foo.h (original)
+++ cfe/trunk/test/Modules/Inputs/codegen/foo.h Thu Nov  2 15:28:50 2017
@@ -29,4 +29,7 @@ inline void inst_decl() {
   inst();
 }
 
+__attribute__((always_inline)) inline void always_inl() {
+}
+
 asm("narf");

Modified: cfe/trunk/test/Modules/Inputs/codegen/use.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/codegen/use.cpp?rev=317279&r1=317278&r2=317279&view=diff
==
--- cfe/trunk/test/Modules/Inputs/codegen/use.cpp (original)
+++ cfe/trunk/test/Modules/Inputs/codegen/use.cpp Thu Nov  2 15:28:50 2017
@@ -6,3 +6,6 @@ void non_modular_use_of_implicit_dtor()
 void use_of_instantiated_declaration_without_definition() {
   inst();
 }
+void call_always_inline() {
+  always_inl();
+}

Modified: cfe/trunk/test/Modules/codegen.test
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/codegen.test?rev=317279&r1=317278&r2=317279&view=diff
==
--- cfe/trunk/test/Modules/codegen.test (original)
+++ cfe/trunk/test/Modules/codegen.test Thu Nov  2 15:28:50 2017
@@ -4,7 +4,7 @@ REQUIRES: x86-registered-target
 RUN: %clang_cc1 -triple=x86_64-linux-gnu -fmodules-codegen -fmodules-debuginfo 
-x c++ -fmodules -emit-module -fmodule-name=foo %S/Inputs/codegen/foo.modulemap 
-o %t/foo.pcm
 
 RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -debug-info-kind=limited 
-o - %t/foo.pcm | FileCheck --check-prefix=FOO --check-prefix=BOTH %s
-RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -debug-info-kind=limited 
-o - -fmodules -fmodule-file=%t/foo.pcm %S/Inputs/codegen/use.cpp | FileCheck 
--check-prefix=BOTH --check-prefix=USE %s
+RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -debug-info-kind=limited 
-o - -fmodules -disable-llvm-passes -fmodule-file=%t/foo.pcm 
%S/Inputs/codegen/use.cpp | FileCheck --check-prefix=BOTH --check-prefix=USE %s
 
 For want of any better definition, inline asm goes "everywhere" the same as it
 if it were in a header (with the disadvantage that the inline asm will be
@@ -23,6 +23,7 @@ USE: module asm "narf"
 FOO: $_Z2f1PKcz = comdat any
 FOO: $_ZN13implicit_dtorD1Ev = comdat any
 USE: $_Z4instIiEvv = comdat any
+USE: $_Z10always_inlv = comdat any
 FOO: $_ZN13implicit_dtorD2Ev = comdat any
 FOO: define weak_odr void @_Z2f1PKcz(i8* %fmt, ...) #{{[0-9]+}} comdat
 FOO:   call void @llvm.va_start(i8* %{{[a-zA-Z0-9]*}})
@@ -38,6 +39,7 @@ FOO: define weak_odr void @_ZN13implicit
 
 USE: define linkonce_odr void @_ZN20uninst_implicit_dtorD1Ev
 USE: define linkonce_odr void @_Z4instIiEvv
+USE: define linkonce_odr void @_Z10always_inlv
 USE: define linkonce_odr void @_ZN20uninst_implicit_dtorD2Ev
 
 Modular debug info puts the definition of a class defined in a module in that


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

r317274 - Modular Codegen: Don't home/modularize static functions in headers

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Nov  2 14:55:40 2017
New Revision: 317274

URL: http://llvm.org/viewvc/llvm-project?rev=317274&view=rev
Log:
Modular Codegen: Don't home/modularize static functions in headers

Consistent with various workarounds in the backwards compatible modules
that allow static functions in headers to exist, be deduplicated to some
degree, and not generally fail right out of the gate... do the same with
modular codegen as there are enough cases (including in libstdc++ and in
LLVM itself - though I cleaned up the easy ones) that it's worth
supporting as a migration/backcompat step.

Simply create a separate, internal linkage function in each object that
needs it. If an available_externally/modularized function references a
static function, but the modularized function is eventually dropped and
not inlined, the static function will be dropped as unreferenced.

Modified:
cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
cfe/trunk/test/Modules/codegen-opt.test

Modified: cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterDecl.cpp?rev=317274&r1=317273&r2=317274&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriterDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriterDecl.cpp Thu Nov  2 14:55:40 2017
@@ -2258,15 +2258,22 @@ void ASTRecordWriter::AddFunctionDefinit
   assert(FD->doesThisDeclarationHaveABody());
   bool ModulesCodegen = false;
   if (Writer->WritingModule && !FD->isDependentContext()) {
-// Under -fmodules-codegen, codegen is performed for all defined functions.
-// When building a C++ Modules TS module interface unit, a strong 
definition
-// in the module interface is provided by the compilation of that module
-// interface unit, not by its users. (Inline functions are still emitted
-// in module users.)
-ModulesCodegen =
-Writer->Context->getLangOpts().ModulesCodegen ||
-(Writer->WritingModule->Kind == Module::ModuleInterfaceUnit &&
- Writer->Context->GetGVALinkageForFunction(FD) == GVA_StrongExternal);
+Optional Linkage;
+if (Writer->WritingModule->Kind == Module::ModuleInterfaceUnit) {
+  // When building a C++ Modules TS module interface unit, a strong
+  // definition in the module interface is provided by the compilation of
+  // that module interface unit, not by its users. (Inline functions are
+  // still emitted in module users.)
+  Linkage = Writer->Context->GetGVALinkageForFunction(FD);
+  ModulesCodegen = *Linkage == GVA_StrongExternal;
+}
+if (Writer->Context->getLangOpts().ModulesCodegen) {
+  // Under -fmodules-codegen, codegen is performed for all non-internal,
+  // non-always_inline functions.
+  if (!Linkage)
+Linkage = Writer->Context->GetGVALinkageForFunction(FD);
+  ModulesCodegen = *Linkage != GVA_Internal;
+}
   }
   Record->push_back(ModulesCodegen);
   if (ModulesCodegen)

Modified: cfe/trunk/test/Modules/codegen-opt.test
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/codegen-opt.test?rev=317274&r1=317273&r2=317274&view=diff
==
--- cfe/trunk/test/Modules/codegen-opt.test (original)
+++ cfe/trunk/test/Modules/codegen-opt.test Thu Nov  2 14:55:40 2017
@@ -25,7 +25,13 @@ FOO-NOT: {{define|declare}}
 FOO: declare void @_Z2f1Ri(i32*
 FOO-NOT: {{define|declare}}
 
-FIXME: this internal function should be weak_odr, comdat, and with a new 
mangling
+Internal functions are not modularly code generated - they are
+internal wherever they're used. This might not be ideal, but
+continues to workaround/support some oddities that backwards
+compatible modules have seen and supported in the wild.  To remove
+the duplication here, the internal functions would need to be
+promoted to weak_odr, placed in comdat and given a new mangling -
+this would be needed for the C++ Modules TS anyway.
 FOO: define internal void @_ZL2f2v() #{{[0-9]+}}
 FOO-NOT: {{define|declare}}
 
@@ -45,7 +51,7 @@ BAR-OPT: define available_externally voi
 BAR-CMN-NOT: {{define|declare}}
 BAR-OPT: declare void @_Z2f1Ri(i32*
 BAR-OPT-NOT: {{define|declare}}
-BAR-OPT: define available_externally void @_ZL2f2v()
+BAR-OPT: define internal void @_ZL2f2v()
 BAR-OPT-NOT: {{define|declare}}
 
 
@@ -61,5 +67,5 @@ USE-OPT: define available_externally voi
 USE-OPT-NOT: {{define|declare}}
 USE-OPT: declare void @_Z2f1Ri(i32*
 USE-OPT-NOT: {{define|declare}}
-USE-OPT: define available_externally void @_ZL2f2v()
+USE-OPT: define internal void @_ZL2f2v()
 USE-OPT-NOT: {{define|declare}}


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

Re: [PATCH] D39208: [Analyzer] Do not use static storage to for implementations created in BodyFarm.cpp

[David Blaikie via cfe-commits]

On Mon, Oct 23, 2017 at 5:01 PM George Karpenkov via Phabricator via
cfe-commits  wrote:

> george.karpenkov added a comment.
>
> @dcoughlin the context I was thinking about is that if everyone
> consistently runs `clang-format` (if we want that), then we never would
> have discussion.
> The alternative is that every run of `clang-format` would be followed by
> manually reverting changes which were introduced by mistake (in this case,
> because the file was moved).
>

clang-format has script (git-clang-format) for formatting only a diff, use
that or something like it so you're not reformatting unrelated lines. If
you're changing so much of the file, or it's so malformatted that local
format updates are going to be really inconsistent, reformat the entire
file in a standalone commit first, then submit your semantic changes
separately.

(also there's a way to setup clang-format to "format changed lines on-save"
in vim, which is what I use - now I basically don't think about formatting
:) )


>
>
> https://reviews.llvm.org/D39208
>
>
>
> ___
> 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: r316536 - [Analyzer] Store BodyFarm in std::unique_ptr

[David Blaikie via cfe-commits]

Could this be a value rather than indirected through a unique_ptr? Simply:

  BodyFarm BdyFrm;

& initialized in the ctors init list?

On Tue, Oct 24, 2017 at 4:53 PM George Karpenkov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: george.karpenkov
> Date: Tue Oct 24 16:53:19 2017
> New Revision: 316536
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316536&view=rev
> Log:
> [Analyzer] Store BodyFarm in std::unique_ptr
>
> Differential Revision: https://reviews.llvm.org/D39220
>
> Modified:
> cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
> cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
>
> Modified: cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h?rev=316536&r1=316535&r2=316536&view=diff
>
> ==
> --- cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h (original)
> +++ cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h Tue Oct 24
> 16:53:19 2017
> @@ -421,7 +421,7 @@ class AnalysisDeclContextManager {
>
>/// Pointer to a factory for creating and caching implementations for
> common
>/// methods during the analysis.
> -  BodyFarm *BdyFrm = nullptr;
> +  std::unique_ptr BdyFrm;
>
>/// Flag to indicate whether or not bodies should be synthesized
>/// for well-known functions.
> @@ -438,8 +438,6 @@ public:
>   bool addCXXNewAllocator = true,
>   CodeInjector *injector = nullptr);
>
> -  ~AnalysisDeclContextManager();
> -
>AnalysisDeclContext *getContext(const Decl *D);
>
>bool getUseUnoptimizedCFG() const {
>
> Modified: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp?rev=316536&r1=316535&r2=316536&view=diff
>
> ==
> --- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp (original)
> +++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp Tue Oct 24 16:53:19 2017
> @@ -306,8 +306,8 @@ AnalysisDeclContext *AnalysisDeclContext
>
>  BodyFarm *AnalysisDeclContextManager::getBodyFarm() {
>if (!BdyFrm)
> -BdyFrm = new BodyFarm(ASTCtx, Injector.get());
> -  return BdyFrm;
> +BdyFrm = llvm::make_unique(ASTCtx, Injector.get());
> +  return BdyFrm.get();
>  }
>
>  const StackFrameContext *
> @@ -603,11 +603,6 @@ AnalysisDeclContext::~AnalysisDeclContex
>}
>  }
>
> -AnalysisDeclContextManager::~AnalysisDeclContextManager() {
> -  if (BdyFrm)
> -delete BdyFrm;
> -}
> -
>  LocationContext::~LocationContext() {}
>
>  LocationContextManager::~LocationContextManager() {
>
>
> ___
> 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: r316403 - [Analyzer] Fix for the memory leak: fix typo in if-statement.

[David Blaikie via cfe-commits]

I realize this was changed in a follow-up commit anyway, but for future
reference: There's no need (& best to avoid - simpler to read, avoids bugs
like this, etc) to conditionalize delete like this. Delete is a no-op on
null pointers anyway, so this dtor should just contain an unconditional
"delete BdyFrm;"

On Mon, Oct 23, 2017 at 6:09 PM George Karpenkov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: george.karpenkov
> Date: Mon Oct 23 18:09:43 2017
> New Revision: 316403
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316403&view=rev
> Log:
> [Analyzer] Fix for the memory leak: fix typo in if-statement.
>
> Modified:
> cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
>
> Modified: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp?rev=316403&r1=316402&r2=316403&view=diff
>
> ==
> --- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp (original)
> +++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp Mon Oct 23 18:09:43 2017
> @@ -604,7 +604,7 @@ AnalysisDeclContext::~AnalysisDeclContex
>  }
>
>  AnalysisDeclContextManager::~AnalysisDeclContextManager() {
> -  if (!BdyFrm)
> +  if (BdyFrm)
>  delete BdyFrm;
>  }
>
>
>
> ___
> 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

r316793 - Sanitizers.h: Modularize/Fix ODR violations by making inline functions non-static

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Oct 27 13:40:45 2017
New Revision: 316793

URL: http://llvm.org/viewvc/llvm-project?rev=316793&view=rev
Log:
Sanitizers.h: Modularize/Fix ODR violations by making inline functions 
non-static

Modified:
cfe/trunk/include/clang/Basic/Sanitizers.h

Modified: cfe/trunk/include/clang/Basic/Sanitizers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Sanitizers.h?rev=316793&r1=316792&r2=316793&view=diff
==
--- cfe/trunk/include/clang/Basic/Sanitizers.h (original)
+++ cfe/trunk/include/clang/Basic/Sanitizers.h Fri Oct 27 13:40:45 2017
@@ -80,7 +80,7 @@ SanitizerMask parseSanitizerValue(String
 SanitizerMask expandSanitizerGroups(SanitizerMask Kinds);
 
 /// Return the sanitizers which do not affect preprocessing.
-static inline SanitizerMask getPPTransparentSanitizers() {
+inline SanitizerMask getPPTransparentSanitizers() {
   return SanitizerKind::CFI | SanitizerKind::Integer |
  SanitizerKind::Nullability | SanitizerKind::Undefined;
 }


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

r316792 - CharInfo.h: Modularize/fix ODR violations by making inline functions in header not static

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Oct 27 13:40:45 2017
New Revision: 316792

URL: http://llvm.org/viewvc/llvm-project?rev=316792&view=rev
Log:
CharInfo.h: Modularize/fix ODR violations by making inline functions in header 
not static

Modified:
cfe/trunk/include/clang/Basic/CharInfo.h

Modified: cfe/trunk/include/clang/Basic/CharInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CharInfo.h?rev=316792&r1=316791&r2=316792&view=diff
==
--- cfe/trunk/include/clang/Basic/CharInfo.h (original)
+++ cfe/trunk/include/clang/Basic/CharInfo.h Fri Oct 27 13:40:45 2017
@@ -40,14 +40,14 @@ namespace charinfo {
 } // end namespace charinfo
 
 /// Returns true if this is an ASCII character.
-LLVM_READNONE static inline bool isASCII(char c) {
+LLVM_READNONE inline bool isASCII(char c) {
   return static_cast(c) <= 127;
 }
 
 /// Returns true if this is a valid first character of a C identifier,
 /// which is [a-zA-Z_].
-LLVM_READONLY static inline bool isIdentifierHead(unsigned char c,
-  bool AllowDollar = false) {
+LLVM_READONLY inline bool isIdentifierHead(unsigned char c,
+   bool AllowDollar = false) {
   using namespace charinfo;
   if (InfoTable[c] & (CHAR_UPPER|CHAR_LOWER|CHAR_UNDER))
 return true;
@@ -56,8 +56,8 @@ LLVM_READONLY static inline bool isIdent
 
 /// Returns true if this is a body character of a C identifier,
 /// which is [a-zA-Z0-9_].
-LLVM_READONLY static inline bool isIdentifierBody(unsigned char c,
-  bool AllowDollar = false) {
+LLVM_READONLY inline bool isIdentifierBody(unsigned char c,
+   bool AllowDollar = false) {
   using namespace charinfo;
   if (InfoTable[c] & (CHAR_UPPER|CHAR_LOWER|CHAR_DIGIT|CHAR_UNDER))
 return true;
@@ -68,7 +68,7 @@ LLVM_READONLY static inline bool isIdent
 /// ' ', '\\t', '\\f', '\\v'.
 ///
 /// Note that this returns false for '\\0'.
-LLVM_READONLY static inline bool isHorizontalWhitespace(unsigned char c) {
+LLVM_READONLY inline bool isHorizontalWhitespace(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & (CHAR_HORZ_WS|CHAR_SPACE)) != 0;
 }
@@ -76,7 +76,7 @@ LLVM_READONLY static inline bool isHoriz
 /// Returns true if this character is vertical ASCII whitespace: '\\n', '\\r'.
 ///
 /// Note that this returns false for '\\0'.
-LLVM_READONLY static inline bool isVerticalWhitespace(unsigned char c) {
+LLVM_READONLY inline bool isVerticalWhitespace(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & CHAR_VERT_WS) != 0;
 }
@@ -85,43 +85,43 @@ LLVM_READONLY static inline bool isVerti
 /// ' ', '\\t', '\\f', '\\v', '\\n', '\\r'.
 ///
 /// Note that this returns false for '\\0'.
-LLVM_READONLY static inline bool isWhitespace(unsigned char c) {
+LLVM_READONLY inline bool isWhitespace(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & (CHAR_HORZ_WS|CHAR_VERT_WS|CHAR_SPACE)) != 0;
 }
 
 /// Return true if this character is an ASCII digit: [0-9]
-LLVM_READONLY static inline bool isDigit(unsigned char c) {
+LLVM_READONLY inline bool isDigit(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & CHAR_DIGIT) != 0;
 }
 
 /// Return true if this character is a lowercase ASCII letter: [a-z]
-LLVM_READONLY static inline bool isLowercase(unsigned char c) {
+LLVM_READONLY inline bool isLowercase(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & CHAR_LOWER) != 0;
 }
 
 /// Return true if this character is an uppercase ASCII letter: [A-Z]
-LLVM_READONLY static inline bool isUppercase(unsigned char c) {
+LLVM_READONLY inline bool isUppercase(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & CHAR_UPPER) != 0;
 }
 
 /// Return true if this character is an ASCII letter: [a-zA-Z]
-LLVM_READONLY static inline bool isLetter(unsigned char c) {
+LLVM_READONLY inline bool isLetter(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & (CHAR_UPPER|CHAR_LOWER)) != 0;
 }
 
 /// Return true if this character is an ASCII letter or digit: [a-zA-Z0-9]
-LLVM_READONLY static inline bool isAlphanumeric(unsigned char c) {
+LLVM_READONLY inline bool isAlphanumeric(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & (CHAR_DIGIT|CHAR_UPPER|CHAR_LOWER)) != 0;
 }
 
 /// Return true if this character is an ASCII hex digit: [0-9a-fA-F]
-LLVM_READONLY static inline bool isHexDigit(unsigned char c) {
+LLVM_READONLY inline bool isHexDigit(unsigned char c) {
   using namespace charinfo;
   return (InfoTable[c] & (CHAR_DIGIT|CHAR_XLETTER)) != 0;
 }
@@ -129,7 +129,7 @@ LLVM_READONLY static inline bool isHexDi
 /// Return true if this character is an ASCII punctuation character.
 ///
 /// Note that '_' is both a punctuation character and an identifier character!
-LL

r316791 - ASTContext.h: Modularize/fix ODR violations by removing 'static' from inline functions in headers

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Oct 27 13:40:44 2017
New Revision: 316791

URL: http://llvm.org/viewvc/llvm-project?rev=316791&view=rev
Log:
ASTContext.h: Modularize/fix ODR violations by removing 'static' from inline 
functions in headers

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

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=316791&r1=316790&r2=316791&view=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Oct 27 13:40:44 2017
@@ -2779,13 +2779,13 @@ public:
 };
 
 /// \brief Utility function for constructing a nullary selector.
-static inline Selector GetNullarySelector(StringRef name, ASTContext& Ctx) {
+inline Selector GetNullarySelector(StringRef name, ASTContext &Ctx) {
   IdentifierInfo* II = &Ctx.Idents.get(name);
   return Ctx.Selectors.getSelector(0, &II);
 }
 
 /// \brief Utility function for constructing an unary selector.
-static inline Selector GetUnarySelector(StringRef name, ASTContext& Ctx) {
+inline Selector GetUnarySelector(StringRef name, ASTContext &Ctx) {
   IdentifierInfo* II = &Ctx.Idents.get(name);
   return Ctx.Selectors.getSelector(1, &II);
 }


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

r316794 - StaticAnalyzer: Modularize/fix ODR violations making functions inline but non-static in headers

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Fri Oct 27 13:40:46 2017
New Revision: 316794

URL: http://llvm.org/viewvc/llvm-project?rev=316794&view=rev
Log:
StaticAnalyzer: Modularize/fix ODR violations making functions inline but 
non-static in headers

Also move these out of the llvm namespace & rely on ADL as is
appropriate for these op<< overloads.

Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h?rev=316794&r1=316793&r2=316794&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h Fri 
Oct 27 13:40:46 2017
@@ -1412,21 +1412,18 @@ public:
   bool hasTrait(SymbolRef Sym, InvalidationKinds IK) const;
   bool hasTrait(const MemRegion *MR, InvalidationKinds IK) const;
 };
-  
-} // end GR namespace
-
-} // end clang namespace
 
 
//===--===//
 // Pretty-printing regions.
 
//===--===//
-
-namespace llvm {
-static inline raw_ostream &operator<<(raw_ostream &os,
-  const clang::ento::MemRegion* R) {
+inline raw_ostream &operator<<(raw_ostream &os,
+   const clang::ento::MemRegion *R) {
   R->dumpToStream(os);
   return os;
 }
-} // end llvm namespace
+
+} // namespace ento
+
+} // namespace clang
 
 #endif

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h?rev=316794&r1=316793&r2=316794&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h Fri Oct 
27 13:40:46 2017
@@ -198,6 +198,10 @@ public:
   }
 };
 
+inline raw_ostream &operator<<(raw_ostream &os, clang::ento::SVal V) {
+  V.dumpToStream(os);
+  return os;
+}
 
 class UndefinedVal : public SVal {
 public:
@@ -622,11 +626,6 @@ private:
 } // end clang namespace
 
 namespace llvm {
-static inline raw_ostream &operator<<(raw_ostream &os,
-clang::ento::SVal V) {
-  V.dumpToStream(os);
-  return os;
-}
 
 template  struct isPodLike;
 template <> struct isPodLike {

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h?rev=316794&r1=316793&r2=316794&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h Fri Oct 
27 13:40:46 2017
@@ -98,6 +98,12 @@ public:
   virtual const MemRegion *getOriginRegion() const { return nullptr; }
 };
 
+inline raw_ostream &operator<<(raw_ostream &os,
+   const clang::ento::SymExpr *SE) {
+  SE->dumpToStream(os);
+  return os;
+}
+
 typedef const SymExpr *SymbolRef;
 typedef SmallVector SymbolRefSmallVectorTy;
 

Modified: 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h?rev=316794&r1=316793&r2=316794&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h 
Fri Oct 27 13:40:46 2017
@@ -633,11 +633,4 @@ public:
 
 } // end clang namespace
 
-namespace llvm {
-static inline raw_ostream &operator<<(raw_ostream &os,
-  const clang::ento::SymExpr *SE) {
-  SE->dumpToStream(os);
-  return os;
-}
-} // end llvm namespace
 #endif


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

Re: [PATCH] D39069: CodeGen: Fix missing debug loc due to alloca

[David Blaikie via cfe-commits]

What John said, but also a narrower test would be good - checking that the
appropriate call instruction gets a debug location, rather than checking
that a bunch of inlining doesn't cause the assertion/verifier failure,
would be good. (Clang tests should, as much as possible, not rely on or run
the LLVM optimization passes - but check the IR coming directly from Clang
before any of that)

On Wed, Oct 18, 2017 at 2:15 PM Yaxun Liu via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> yaxunl created this revision.
>
> Builder save/restores insertion pointer when emitting addr space cast
> for alloca, but does not save/restore debug loc, which causes verifier
> failure for certain call instructions.
>
> This patch fixes that.
>
>
> https://reviews.llvm.org/D39069
>
> Files:
>   lib/CodeGen/CGExpr.cpp
>   test/CodeGenOpenCL/func-call-dbg-loc.cl
>
>
> Index: test/CodeGenOpenCL/func-call-dbg-loc.cl
> ===
> --- /dev/null
> +++ test/CodeGenOpenCL/func-call-dbg-loc.cl
> @@ -0,0 +1,34 @@
> +// RUN: %clang_cc1 -triple amdgcn---amdgizcl -debug-info-kind=limited
> -dwarf-version=2 -debugger-tuning=gdb -O0 -emit-llvm -o - %s | FileCheck %s
> +// Checks the file compiles without verifier error: inlinable function
> call in a function with debug info must have a !dbg location.
> +
> +typedef struct
> +{
> +float m_max;
> +} Struct;
> +
> +typedef struct
> +{
> +Struct m_volume;
> +} Node;
> +
> +
> +Struct buzz(Node node)
> +{
> +return node.m_volume;
> +}
> +
> +__attribute__((always_inline))
> +float bar(Struct aabb)
> +{
> +return 0.0f;
> +}
> +
> +__attribute__((used))
> +void foo()
> +{
> +Node node;
> +// CHECK: store float 0.00e+00, float addrspace(5)* %f, align 4,
> !dbg !{{[0-9]+}}
> +float f = bar(buzz(node));
> +}
> +
> +
> Index: lib/CodeGen/CGExpr.cpp
> ===
> --- lib/CodeGen/CGExpr.cpp
> +++ lib/CodeGen/CGExpr.cpp
> @@ -75,11 +75,13 @@
>if (CastToDefaultAddrSpace && getASTAllocaAddressSpace() !=
> LangAS::Default) {
>  auto DestAddrSpace =
> getContext().getTargetAddressSpace(LangAS::Default);
>  auto CurIP = Builder.saveIP();
> +auto DbgLoc = Builder.getCurrentDebugLocation();
>  Builder.SetInsertPoint(AllocaInsertPt);
>  V = getTargetHooks().performAddrSpaceCast(
>  *this, V, getASTAllocaAddressSpace(), LangAS::Default,
>  Ty->getPointerTo(DestAddrSpace), /*non-null*/ true);
>  Builder.restoreIP(CurIP);
> +Builder.SetCurrentDebugLocation(DbgLoc);
>}
>
>return Address(V, Align);
>
>
> ___
> 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: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

[David Blaikie via cfe-commits]

Generally it's preferably to avoid adding dead code (partly for this reason
- it's hard to track when it gets used and ensure it's appropriately
tested) could the member function's body be replaced with llvm_unreachable
for now, then?

On Mon, Oct 16, 2017 at 10:27 AM Alex L  wrote:

> At the moment this method override is not used by the clang-refactor tool,
> so I don't think I can add a test for it.
>
> On 16 October 2017 at 10:11, David Blaikie  wrote:
>
>> Is there a test that could be added to cover this new code?
>>
>> On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Fri Oct 13 14:15:25 2017
>>> New Revision: 315755
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=315755&view=rev
>>> Log:
>>> Fix -Woverloaded-virtual warning in clang-refactor
>>>
>>> Modified:
>>> cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>>>
>>> Modified: cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-refactor/ClangRefactor.cpp?rev=315755&r1=315754&r2=315755&view=diff
>>>
>>> ==
>>> --- cfe/trunk/tools/clang-refactor/ClangRefactor.cpp (original)
>>> +++ cfe/trunk/tools/clang-refactor/ClangRefactor.cpp Fri Oct 13 14:15:25
>>> 2017
>>> @@ -314,6 +314,10 @@ public:
>>>  SourceChanges.insert(SourceChanges.begin(), Changes.begin(),
>>> Changes.end());
>>>}
>>>
>>> +  void handle(SymbolOccurrences Occurrences) override {
>>> +RefactoringResultConsumer::handle(std::move(Occurrences));
>>> +  }
>>> +
>>>const AtomicChanges &getSourceChanges() const { return SourceChanges;
>>> }
>>>
>>>  private:
>>>
>>>
>>> ___
>>> 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: [clang-tools-extra] r315323 - [clangd] Added forgotten return in UniqueFunction.

[David Blaikie via cfe-commits]

Is there missing test coverage for this?

On Tue, Oct 10, 2017 at 9:12 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ibiryukov
> Date: Tue Oct 10 09:12:47 2017
> New Revision: 315323
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315323&view=rev
> Log:
> [clangd] Added forgotten return in UniqueFunction.
>
> This hasn't bitten us because we only used functions returning
> 'void'.
>
> Modified:
> clang-tools-extra/trunk/clangd/Function.h
>
> Modified: clang-tools-extra/trunk/clangd/Function.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Function.h?rev=315323&r1=315322&r2=315323&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/Function.h (original)
> +++ clang-tools-extra/trunk/clangd/Function.h Tue Oct 10 09:12:47 2017
> @@ -46,7 +46,7 @@ public:
>
>Ret operator()(Args... As) {
>  assert(CallablePtr);
> -CallablePtr->Call(std::forward(As)...);
> +return CallablePtr->Call(std::forward(As)...);
>}
>
>  private:
>
>
> ___
> 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: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

[David Blaikie via cfe-commits]

Is there a test that could be added to cover this new code?

On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Fri Oct 13 14:15:25 2017
> New Revision: 315755
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315755&view=rev
> Log:
> Fix -Woverloaded-virtual warning in clang-refactor
>
> Modified:
> cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>
> Modified: cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-refactor/ClangRefactor.cpp?rev=315755&r1=315754&r2=315755&view=diff
>
> ==
> --- cfe/trunk/tools/clang-refactor/ClangRefactor.cpp (original)
> +++ cfe/trunk/tools/clang-refactor/ClangRefactor.cpp Fri Oct 13 14:15:25
> 2017
> @@ -314,6 +314,10 @@ public:
>  SourceChanges.insert(SourceChanges.begin(), Changes.begin(),
> Changes.end());
>}
>
> +  void handle(SymbolOccurrences Occurrences) override {
> +RefactoringResultConsumer::handle(std::move(Occurrences));
> +  }
> +
>const AtomicChanges &getSourceChanges() const { return SourceChanges; }
>
>  private:
>
>
> ___
> 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: [libcxx] r315874 - Silence clang's -Wtautological-constant-compare in last_write_time.pass.cpp

[David Blaikie via cfe-commits]

Would it be better/possible to improve the warning to not have this false
positive, rather than suppressing it?

On Sun, Oct 15, 2017 at 1:12 PM Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: lebedevri
> Date: Sun Oct 15 13:12:42 2017
> New Revision: 315874
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315874&view=rev
> Log:
> Silence clang's -Wtautological-constant-compare in last_write_time.pass.cpp
>
> Previously this broke the builders, when D38101 was committed.
> Silence the warning so that it can be re-landed.
>
> Modified:
>
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
>
> Modified:
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp?rev=315874&r1=315873&r2=315874&view=diff
>
> ==
> ---
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> (original)
> +++
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> Sun Oct 15 13:12:42 2017
> @@ -88,6 +88,13 @@ bool TestSupportsNegativeTimes() {
>  return !ec && new_write_time <= -5;
>  }
>
> +// In some configurations, the comparison is tautological and the test is
> valid.
> +// We disable the warning so that we can actually test it regardless.
> +#if defined(__clang__)
> +#pragma clang diagnostic push
> +#pragma clang diagnostic ignored "-Wtautological-constant-compare"
> +#endif
> +
>  bool TestSupportsMaxTime() {
>  using namespace std::chrono;
>  using Lim = std::numeric_limits;
> @@ -106,11 +113,22 @@ bool TestSupportsMaxTime() {
>  return !ec && new_write_time > max_sec - 1;
>  }
>
> +#if defined(__clang__)
> +#pragma clang diagnostic pop
> +#endif
> +
>  static const bool SupportsNegativeTimes = TestSupportsNegativeTimes();
>  static const bool SupportsMaxTime = TestSupportsMaxTime();
>
>  } // end namespace
>
> +// In some configurations, the comparison is tautological and the test is
> valid.
> +// We disable the warning so that we can actually test it regardless.
> +#if defined(__clang__)
> +#pragma clang diagnostic push
> +#pragma clang diagnostic ignored "-Wtautological-constant-compare"
> +#endif
> +
>  // Check if a time point is representable on a given filesystem. Check
> that:
>  // (A) 'tp' is representable as a time_t
>  // (B) 'tp' is non-negative or the filesystem supports negative times.
> @@ -127,6 +145,10 @@ inline bool TimeIsRepresentableByFilesys
>  return true;
>  }
>
> +#if defined(__clang__)
> +#pragma clang diagnostic pop
> +#endif
> +
>  TEST_SUITE(exists_test_suite)
>
>  TEST_CASE(signature_test)
>
>
> ___
> 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: [PATCH] D38464: [clangd] less boilerplate in RPC dispatch

[David Blaikie via cfe-commits]

I mention it only out of interest of deduplication of functionality/code
within the LLVM project as a whole. Be nice not to maintain two things if
one would suffice.

On Thu, Oct 12, 2017 at 6:21 AM Sam McCall  wrote:

> Interesting - this is pretty primitive, and still fairly tightly coupled
> to JSON-RPC.
> I can't easily tell from the code how the ORC RPC functionality - would it
> be easy to use with JSON-RPC, does it make sense to use serialization only,
> does it have opinions about threading models? And really, what would we
> expect to gain vs using the current more naive code (it looks more
> complicated, probably having more complex requirements).
>
> On Mon, Oct 9, 2017 at 11:16 PM, David Blaikie  wrote:
>
>> hey Lang (& folks here) any chance there's some overlap between the RPC
>> functionality here and the RPC functionality in ORC that could be
>> deduplicated/refactored?
>>
>> On Fri, Oct 6, 2017 at 5:30 AM Ilya Biryukov via Phabricator via
>> cfe-commits  wrote:
>>
>>> ilya-biryukov accepted this revision.
>>> ilya-biryukov added a comment.
>>> This revision is now accepted and ready to land.
>>>
>>> LGTM.
>>> Note there's a new LSP method handler added upstream
>>> (`textDocument/signatureHelp`), we should add it to this change before
>>> submitting.
>>>
>>>
>>>
>>> 
>>> Comment at: clangd/ClangdLSPServer.h:47
>>>// Implement ProtocolCallbacks.
>>> -  void onInitialize(StringRef ID, InitializeParams IP,
>>> -JSONOutput &Out) override;
>>> -  void onShutdown(JSONOutput &Out) override;
>>> -  void onDocumentDidOpen(DidOpenTextDocumentParams Params,
>>> - JSONOutput &Out) override;
>>> -  void onDocumentDidChange(DidChangeTextDocumentParams Params,
>>> -   JSONOutput &Out) override;
>>> -  void onDocumentDidClose(DidCloseTextDocumentParams Params,
>>> -  JSONOutput &Out) override;
>>> -  void onDocumentOnTypeFormatting(DocumentOnTypeFormattingParams Params,
>>> -  StringRef ID, JSONOutput &Out)
>>> override;
>>> -  void onDocumentRangeFormatting(DocumentRangeFormattingParams Params,
>>> - StringRef ID, JSONOutput &Out)
>>> override;
>>> -  void onDocumentFormatting(DocumentFormattingParams Params, StringRef
>>> ID,
>>> -JSONOutput &Out) override;
>>> -  void onCodeAction(CodeActionParams Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> -  void onCompletion(TextDocumentPositionParams Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> -  void onGoToDefinition(TextDocumentPositionParams Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> -  void onSwitchSourceHeader(TextDocumentIdentifier Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> +  void onInitialize(Ctx &C, InitializeParams &Params) override;
>>> +  void onShutdown(Ctx &C, NoParams &Params) override;
>>> 
>>> sammccall wrote:
>>> > ilya-biryukov wrote:
>>> > > ilya-biryukov wrote:
>>> > > > Maybe there's a way to have a typed return value instead of `Ctx`?
>>> > > > This would give an interface that's harder to misuse: one can't
>>> forget to call `reply` or call it twice.
>>> > > >
>>> > > > Here's on design that comes to mind.
>>> > > > Notification handlers could have `void` return, normal requests
>>> can return `Optional` or `Optional` (with result json).
>>> > > > `Optional` is be used to indicate whether error occurred while
>>> processing the request.
>>> > > >
>>> > > After putting more thought into it, `Ctx`-based API seems to have an
>>> advantage: it will allow us to easily implement async responses.
>>> > > E.g., we can run code completion on a background thread and continue
>>> processing other requests. When completion is ready, we will simply call
>>> `Ctx.reply` to return results to the language client.
>>> > >
>>> > > To make that possible, can we allow moving `RequestContext` and pass
>>> it by-value instead of by-ref?
>>> > Yeah I thought about returning a value... it certainly reads more
>>> nicely, but I don't think we're ready to do a good job in this patch:
>>> >  - return value should be an object ready to be serialized (rather
>>> than a JSON string) - I don't want to bring that in scope here, but it
>>> might affect the details of the API
>>> >  - there's several cases we know about (return object, no reply, error
>>> reply) and some we're not sure about (async as you mention - any multiple
>>> responses)? I think this needs some design, and I don't yet know the
>>> project well enough to drive it.
>>> >
>>> > I've switched to passing Ctx by value as you suggest (though it's
>>> certainly cheap enough to copy, too).
>>> Yeah, copy is also fine there performance-wise.
>>>
>>> I do think move-only interface fits slightly better. We can check a
>>> whole bunch of invariants if 

Re: [PATCH] D38464: [clangd] less boilerplate in RPC dispatch

[David Blaikie via cfe-commits]

hey Lang (& folks here) any chance there's some overlap between the RPC
functionality here and the RPC functionality in ORC that could be
deduplicated/refactored?

On Fri, Oct 6, 2017 at 5:30 AM Ilya Biryukov via Phabricator via
cfe-commits  wrote:

> ilya-biryukov accepted this revision.
> ilya-biryukov added a comment.
> This revision is now accepted and ready to land.
>
> LGTM.
> Note there's a new LSP method handler added upstream
> (`textDocument/signatureHelp`), we should add it to this change before
> submitting.
>
>
>
> 
> Comment at: clangd/ClangdLSPServer.h:47
>// Implement ProtocolCallbacks.
> -  void onInitialize(StringRef ID, InitializeParams IP,
> -JSONOutput &Out) override;
> -  void onShutdown(JSONOutput &Out) override;
> -  void onDocumentDidOpen(DidOpenTextDocumentParams Params,
> - JSONOutput &Out) override;
> -  void onDocumentDidChange(DidChangeTextDocumentParams Params,
> -   JSONOutput &Out) override;
> -  void onDocumentDidClose(DidCloseTextDocumentParams Params,
> -  JSONOutput &Out) override;
> -  void onDocumentOnTypeFormatting(DocumentOnTypeFormattingParams Params,
> -  StringRef ID, JSONOutput &Out) override;
> -  void onDocumentRangeFormatting(DocumentRangeFormattingParams Params,
> - StringRef ID, JSONOutput &Out) override;
> -  void onDocumentFormatting(DocumentFormattingParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onCodeAction(CodeActionParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onCompletion(TextDocumentPositionParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onGoToDefinition(TextDocumentPositionParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onSwitchSourceHeader(TextDocumentIdentifier Params, StringRef ID,
> -JSONOutput &Out) override;
> +  void onInitialize(Ctx &C, InitializeParams &Params) override;
> +  void onShutdown(Ctx &C, NoParams &Params) override;
> 
> sammccall wrote:
> > ilya-biryukov wrote:
> > > ilya-biryukov wrote:
> > > > Maybe there's a way to have a typed return value instead of `Ctx`?
> > > > This would give an interface that's harder to misuse: one can't
> forget to call `reply` or call it twice.
> > > >
> > > > Here's on design that comes to mind.
> > > > Notification handlers could have `void` return, normal requests can
> return `Optional` or `Optional` (with result json).
> > > > `Optional` is be used to indicate whether error occurred while
> processing the request.
> > > >
> > > After putting more thought into it, `Ctx`-based API seems to have an
> advantage: it will allow us to easily implement async responses.
> > > E.g., we can run code completion on a background thread and continue
> processing other requests. When completion is ready, we will simply call
> `Ctx.reply` to return results to the language client.
> > >
> > > To make that possible, can we allow moving `RequestContext` and pass
> it by-value instead of by-ref?
> > Yeah I thought about returning a value... it certainly reads more
> nicely, but I don't think we're ready to do a good job in this patch:
> >  - return value should be an object ready to be serialized (rather than
> a JSON string) - I don't want to bring that in scope here, but it might
> affect the details of the API
> >  - there's several cases we know about (return object, no reply, error
> reply) and some we're not sure about (async as you mention - any multiple
> responses)? I think this needs some design, and I don't yet know the
> project well enough to drive it.
> >
> > I've switched to passing Ctx by value as you suggest (though it's
> certainly cheap enough to copy, too).
> Yeah, copy is also fine there performance-wise.
>
> I do think move-only interface fits slightly better. We can check a whole
> bunch of invariants if `Ctx` is move-only (i.e., that request wasn't
> dropped without response or `reply` was not called twice).
>
>
> 
> Comment at: clangd/ClangdLSPServer.h:48
> +  void onInitialize(Ctx &C, InitializeParams &Params) override;
> +  void onShutdown(Ctx &C, NoParams &Params) override;
> +  void onDocumentDidOpen(Ctx &C, DidOpenTextDocumentParams &Params)
> override;
> 
> sammccall wrote:
> > ilya-biryukov wrote:
> > > Maybe there's a way to get rid of `NoParams`?
> > > E.g. by adding a overload to `HandlerRegisterer`?
> > Even if there was, I think I prefer the regularity (changed this to
> ShutdownParams - oops!).
> >
> > Otherwise the signature's dependent on some combination of {current LSP,
> whether we actually implement the options, whether we've defined any
> extensions}. It's harder to remember, means changing lots of places when
> these factors change, and complica

Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

[David Blaikie via cfe-commits]

On Wed, Sep 27, 2017 at 1:58 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson added a reviewer: rnk.
> probinson added a comment.
>
> +rnk for the CodeView question.
>
>
>
> 
> Comment at: include/clang/Frontend/CodeGenOptions.def:222
>  ///< of inline stack frames without
> .dwo files.
> +CODEGENOPT(DebugFwdTemplateParams, 1, 0) ///< Whether to emit complete
> + ///< template parameter
> descriptions in
> 
> dblaikie wrote:
> > Maybe 'Decl' rather than 'Fwd'.
> Well, in a sense they are all declarations, and 'Fwd' is a clearer
> statement of the distinction this flag is trying to make.  Unless you feel
> strongly I'd prefer to leave it as is.
>

Fair enough.


> 
> Comment at: lib/CodeGen/CGDebugInfo.cpp:836
>llvm::DINode::FlagFwdDecl, FullName);
> +  if (CGM.getCodeGenOpts().DebugFwdTemplateParams)
> +if (auto *TSpecial = dyn_cast(RD))
> 
> It just occurred to me... should CodeView care about this?
>

Not sure

Reid?


>
>
> 
> Comment at: test/CodeGenCXX/debug-info-fwd-template-param.cpp:7
> +template class A;
> +A *p;
> +
> 
> dblaikie wrote:
> > Any particular reason for const int, rather than int?
> It was the illustrative example of the difference between the demangler
> ("int const") and clang ("const int") that the debugger guys tripped over,
> and so was in the source I started with when creating this test.  I think
> you are correct, it is not important to have it.
>

*nod* I understand that it's part of the original issue, but doesn't seem
needed/relevant here.  Thanks! :)


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

Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

[David Blaikie via cfe-commits]

On Wed, Sep 27, 2017 at 11:50 AM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson added a comment.
>
> In https://reviews.llvm.org/D14358#882445, @dblaikie wrote:
>
> > > I would prefer to eliminate the `` from the instance name as
> well, because our debugger reconstructs a name more to its liking from the
> parameter children.  However, IIUC the name with params is used for
> deduplication in LTO, so that is probably not such a good idea. :-)
> >
> > Though you have this out of tree? How do you cope with LTO there?
>
>
> We discovered that we had to keep them in the name for LTO.
>
> > I've not fully refreshed myself on the previous conversations - but it
> looks like my thought was that this state proposed here is
> weird/inconsistent: The parameters are already in the name, so adding them
> in the DIEs seems redundant. If the parameters weren't in the name then
> this change might make more sense.
>
> Our debugger throws away the params in the name, and relies on the
> children.  The names as rendered in DWARF by Clang are not textually
> consistent with names as rendered by the demangler.  Our debugger uses the
> children to construct names that are consistent with how the demangler
> works.  Then it can match up type names returned by the demangler to type
> names it has constructed.  Assuming I am not misunderstanding our debugger
> guys again, but that's my recollection.
>
> I believe we have talked previously about using a different scheme for
> deduplication that doesn't depend (or not so much) on the names.  If we had
> that, we could eliminate params from the name, and save probably a
> noticeable chunk of space in the string section.  I haven't tried to
> measure that, though.  But we have to have the children in place before we
> can experiment with other deduplication schemes.
>

Fair enough - yeah, I would agree with Adrian that this probably isn't a
driver flag (at least not yet), though. Either only driven by the debugger
tuning (though perhaps we had some position that debugger tuning wouldn't
ever be the only way to access functionality, only change defaults) or
additionally a cc1 flag. Haven't thought about the name.


>
> There is also the pedantic point that DWARF doesn't say these child
> entries are optional, or omitted for forward declarations.  I know gcc
> doesn't (or didn't, anyway; what I have locally is gcc 5.4) but gcc is not
> the arbiter of what constitutes conforming DWARF.
>
>
> https://reviews.llvm.org/D14358
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r314079 - Fix implicit-fallthrough warning by adding missing break

[David Blaikie via cfe-commits]

Is there also missing test coverage here?

On Sun, Sep 24, 2017 at 8:19 AM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rksimon
> Date: Sun Sep 24 08:17:46 2017
> New Revision: 314079
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314079&view=rev
> Log:
> Fix implicit-fallthrough warning by adding missing break
>
> Modified:
> cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp
>
> Modified: cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp?rev=314079&r1=314078&r2=314079&view=diff
>
> ==
> --- cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp (original)
> +++ cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp Sun Sep 24 08:17:46 2017
> @@ -185,6 +185,7 @@ void CrossTranslationUnitContext::emitCr
>case index_error_code::invalid_index_format:
>  Context.getDiagnostics().Report(diag::err_fnmap_parsing)
>  << IE.getFileName() << IE.getLineNum();
> +break;
>case index_error_code::multiple_definitions:
>  Context.getDiagnostics().Report(diag::err_multiple_def_index)
>  << IE.getLineNum();
>
>
> ___
> 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: r312580 - Fix memory leak after r312467. The ModuleMap is the owner of the global module object until it's reparented under a real module.

[David Blaikie via cfe-commits]

On Tue, Sep 5, 2017 at 2:47 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Sep  5 14:46:22 2017
> New Revision: 312580
>
> URL: http://llvm.org/viewvc/llvm-project?rev=312580&view=rev
> Log:
> Fix memory leak after r312467. The ModuleMap is the owner of the global
> module object until it's reparented under a real module.
>
> Modified:
> cfe/trunk/include/clang/Lex/ModuleMap.h
> cfe/trunk/lib/Lex/ModuleMap.cpp
>
> Modified: cfe/trunk/include/clang/Lex/ModuleMap.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/ModuleMap.h?rev=312580&r1=312579&r2=312580&view=diff
>
> ==
> --- cfe/trunk/include/clang/Lex/ModuleMap.h (original)
> +++ cfe/trunk/include/clang/Lex/ModuleMap.h Tue Sep  5 14:46:22 2017
> @@ -82,22 +82,26 @@ class ModuleMap {
>
>/// \brief The directory used for Clang-supplied, builtin include
> headers,
>/// such as "stdint.h".
> -  const DirectoryEntry *BuiltinIncludeDir;
> +  const DirectoryEntry *BuiltinIncludeDir = nullptr;
>
>/// \brief Language options used to parse the module map itself.
>///
>/// These are always simple C language options.
>LangOptions MMapLangOpts;
>
> -  // The module that the main source file is associated with (the module
> -  // named LangOpts::CurrentModule, if we've loaded it).
> -  Module *SourceModule;
> +  /// The module that the main source file is associated with (the module
> +  /// named LangOpts::CurrentModule, if we've loaded it).
> +  Module *SourceModule = nullptr;
> +
> +  /// The global module for the current TU, if we still own it.
> (Ownership is
> +  /// transferred if/when we create an enclosing module.
> +  std::unique_ptr PendingGlobalModule;
>
>/// \brief The top-level modules that are known.
>llvm::StringMap Modules;
>
>/// \brief The number of modules we have created in total.
> -  unsigned NumCreatedModules;
> +  unsigned NumCreatedModules = 0;
>
>  public:
>/// \brief Flags describing the role of a module header.
>
> Modified: cfe/trunk/lib/Lex/ModuleMap.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/ModuleMap.cpp?rev=312580&r1=312579&r2=312580&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/ModuleMap.cpp (original)
> +++ cfe/trunk/lib/Lex/ModuleMap.cpp Tue Sep  5 14:46:22 2017
> @@ -256,8 +256,7 @@ ModuleMap::ModuleMap(SourceManager &Sour
>   const LangOptions &LangOpts, const TargetInfo
> *Target,
>   HeaderSearch &HeaderInfo)
>  : SourceMgr(SourceMgr), Diags(Diags), LangOpts(LangOpts),
> Target(Target),
> -  HeaderInfo(HeaderInfo), BuiltinIncludeDir(nullptr),
> -  SourceModule(nullptr), NumCreatedModules(0) {
> +  HeaderInfo(HeaderInfo) {
>MMapLangOpts.LineComment = true;
>  }
>
> @@ -747,10 +746,12 @@ std::pair ModuleMap::fin
>  }
>
>  Module *ModuleMap::createGlobalModuleForInterfaceUnit(SourceLocation Loc)
> {
> -  auto *Result = new Module("", Loc, nullptr, /*IsFramework*/
> false,
> -/*IsExplicit*/ true, NumCreatedModules++);
> -  Result->Kind = Module::GlobalModuleFragment;
> -  return Result;
> +  assert(!PendingGlobalModule && "created multiple global modules");
> +  PendingGlobalModule.reset(
> +  new Module("", Loc, nullptr, /*IsFramework*/ false,
> + /*IsExplicit*/ true, NumCreatedModules++));
> +  PendingGlobalModule->Kind = Module::GlobalModuleFragment;
> +  return PendingGlobalModule.get();
>  }
>
>  Module *ModuleMap::createModuleForInterfaceUnit(SourceLocation Loc,
> @@ -766,7 +767,10 @@ Module *ModuleMap::createModuleForInterf
>Modules[Name] = SourceModule = Result;
>
>// Reparent the current global module fragment as a submodule of this
> module.
> +  assert(GlobalModule == PendingGlobalModule.get() &&
> + "unexpected global module");
>GlobalModule->setParent(Result);
> +  PendingGlobalModule.release(); // now owned by parent
>

Would it be reasonable to reverse the 'setParent' API (into an addSubmodule
call on the parent - that takes the child/submodule by std::unique_ptr
value) so the hand-off/ownership is more clear/less error prone?


>
>// Mark the main source file as being within the newly-created module
> so that
>// declarations and macros are properly visibility-restricted to it.
>
>
> ___
> 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: [PATCH] D37428: Debug info: Fixed faulty debug locations for attributed statements

[David Blaikie via cfe-commits]

Fine to remove it if it didn't change the test - it just wasn't clear to me
what exactly was being tested at the time so it was more "does this test
still work with/without -disable-llvm-passes".

No worries.

On Tue, Sep 5, 2017 at 10:58 PM Karl-Johan Karlsson via Phabricator <
revi...@reviews.llvm.org> wrote:

> Ka-Ka added inline comments.
>
>
> 
> Comment at: test/CodeGen/debug-info-attributed-stmt.c:1
> +// RUN: %clang_cc1 -triple x86_64-unk-unk -disable-llvm-passes
> -debug-info-kind=limited -emit-llvm %s -o - | FileCheck %s
> +
> 
> echristo wrote:
> > Since we're not optimizing or generating code you should be able to
> remove the -disable-llvm-passes I believe.
> I added the option -disable-llvm-passes as David Blaikie suggested it in
> his original comment:
>
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170904/202982.html
> As I have mainly worked in llvm backends I'm not that familiar with the
> clang -cc1 options. I have no opinion about this. I wait for you and David
> Blaikie to decide if I should remove or keep the option
> -disable-llvm-passes.
>
>
>
> https://reviews.llvm.org/D37428
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D37428: Debug info: Fixed faulty debug locations for attributed statements

[David Blaikie via cfe-commits]

Seems like the test case should/could be simplified a bit, maybe? (could it
be something really simple like "void f(bool b) { #pragma ... while (b) ;
}"?)

Also, is it relying on LLVM optimizations to run (add
"-disable-llvm-passes" to the command line to be sure it isn't, perhaps?)?

On Sun, Sep 3, 2017 at 10:35 AM Karl-Johan Karlsson via Phabricator via
cfe-commits  wrote:

> Ka-Ka created this revision.
> Herald added a subscriber: aprantl.
>
> As no stoppoint was generated the attributed statements got faulty debug
> locations.
>
>
> https://reviews.llvm.org/D37428
>
> Files:
>   lib/CodeGen/CGStmt.cpp
>   test/CodeGen/debug-info-attributed-stmt.c
>
>
> Index: test/CodeGen/debug-info-attributed-stmt.c
> ===
> --- /dev/null
> +++ test/CodeGen/debug-info-attributed-stmt.c
> @@ -0,0 +1,19 @@
> +// RUN: %clang_cc1 -triple x86_64-unk-unk -debug-info-kind=limited
> -emit-llvm %s -o - | FileCheck %s
> +int data[50] = { 0 };
> +
> +void foo()
> +{
> +int i = 0;
> +int x = 7;
> +#pragma nounroll
> +while (i < 50)
> +{
> +data[i] = i;
> +++i;
> +}
> +
> +// CHECK: br label %while.cond, !dbg ![[NUM:[0-9]+]]
> +// CHECK: br i1 %cmp, label %while.body, label %while.end, !dbg ![[NUM]]
> +// CHECK: br label %while.cond, !dbg ![[NUM]], !llvm.loop
> +// CHECK: ![[NUM]] = !DILocation(line: 9, scope: !14)
> +}
> Index: lib/CodeGen/CGStmt.cpp
> ===
> --- lib/CodeGen/CGStmt.cpp
> +++ lib/CodeGen/CGStmt.cpp
> @@ -556,6 +556,10 @@
>
>  void CodeGenFunction::EmitAttributedStmt(const AttributedStmt &S) {
>const Stmt *SubStmt = S.getSubStmt();
> +
> +  // Generate a stoppoint if we are emitting debug info.
> +  EmitStopPoint(SubStmt);
> +
>switch (SubStmt->getStmtClass()) {
>case Stmt::DoStmtClass:
>  EmitDoStmt(cast(*SubStmt), S.getAttrs());
>
>
> ___
> 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

r312268 - Disable clang-format's MemoizationTest as it becomes prohibitive with EXPENSIVE_CHECKS

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Aug 31 11:49:34 2017
New Revision: 312268

URL: http://llvm.org/viewvc/llvm-project?rev=312268&view=rev
Log:
Disable clang-format's MemoizationTest as it becomes prohibitive with 
EXPENSIVE_CHECKS

EXPENSIVE_CHECKS enables libstdc++'s library consistency checks, which
includes checking the container passed to std::priority_queue for its
well-formedness. This makes the clang-format memoization too expensive,
so disable it.

(it's a necessary feature of libstdc++'s consistency checks that it
ruins the required scalability of C++ standard library features - so
these workarounds are to be expected if a test ever tries to test
scalability in some way, like this test does)

Modified:
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=312268&r1=312267&r2=312268&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Aug 31 11:49:34 2017
@@ -3440,6 +3440,10 @@ TEST_F(FormatTest, BreakConstructorIniti
Style);
 }
 
+#ifndef EXPENSIVE_CHECKS
+// Expensive checks enables libstdc++ checking which includes validating the
+// state of ranges used in std::priority_queue - this blows out the
+// runtime/scalability of the function and makes this test unacceptably slow.
 TEST_F(FormatTest, MemoizationTests) {
   // This breaks if the memoization lookup does not take \c Indent and
   // \c LastSpace into account.
@@ -3518,6 +3522,7 @@ TEST_F(FormatTest, MemoizationTests) {
   input += "   a) {}";
   verifyFormat(input, OnePerLine);
 }
+#endif
 
 TEST_F(FormatTest, BreaksAsHighAsPossible) {
   verifyFormat(


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

Re: r310905 - Avoid PointerIntPair of constexpr EvalInfo structs

[David Blaikie via cfe-commits]

On Mon, Aug 28, 2017 at 5:21 PM Reid Kleckner  wrote:

> On Mon, Aug 28, 2017 at 5:02 PM, David Blaikie  wrote:
>
>> Feels like this alignment attribute may be a bit of a death trap, then?
>> Should other uses of the attribute be scrutinized, or could we come up with
>> a portable way to use it safely? (using a different attribute on different
>> compilers - sounded like maybe one form worked with MSVC and a different
>> form worked with GCC? Maybe the attribute could be improved to use those as
>> appropriate?)
>>
>
> I never was able to reproduce the user issue, so I have very little
> information. I have a hard time believing that mingw32 gcc miscompiles all
> alignment attributes. There must have been something funny about our usage
> of it in ExprConstant.cpp that triggered the bug. In the unlikely case that
> we hit it again, hopefully the next user that hits the bug will provide
> more information about what went wrong.
>

Hrm - I really don't like the idea of making changes without really
understanding what's being addressed. :/

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

Re: r310905 - Avoid PointerIntPair of constexpr EvalInfo structs

[David Blaikie via cfe-commits]

Feels like this alignment attribute may be a bit of a death trap, then?
Should other uses of the attribute be scrutinized, or could we come up with
a portable way to use it safely? (using a different attribute on different
compilers - sounded like maybe one form worked with MSVC and a different
form worked with GCC? Maybe the attribute could be improved to use those as
appropriate?)

On Mon, Aug 14, 2017 at 6:18 PM Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rnk
> Date: Mon Aug 14 18:17:47 2017
> New Revision: 310905
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310905&view=rev
> Log:
> Avoid PointerIntPair of constexpr EvalInfo structs
>
> They are stack allocated, so their alignment is not to be trusted.
> 32-bit MSVC only guarantees 4 byte stack alignment, even though alignof
> would tell you otherwise. I tried fixing this with __declspec align, but
> that apparently upsets GCC. Hopefully this version will satisfy all
> compilers.
>
> See PR32018 for some info about the mingw issues.
>
> Should supercede https://reviews.llvm.org/D34873
>
> 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=310905&r1=310904&r2=310905&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
> +++ cfe/trunk/lib/AST/ExprConstant.cpp Mon Aug 14 18:17:47 2017
> @@ -537,7 +537,7 @@ namespace {
>/// rules.  For example, the RHS of (0 && foo()) is not evaluated.  We
> can
>/// evaluate the expression regardless of what the RHS is, but C only
> allows
>/// certain things in certain situations.
> -  struct LLVM_ALIGNAS(/*alignof(uint64_t)*/ 8) EvalInfo {
> +  struct EvalInfo {
>  ASTContext &Ctx;
>
>  /// EvalStatus - Contains information about the evaluation.
> @@ -977,24 +977,22 @@ namespace {
>/// RAII object used to optionally suppress diagnostics and
> side-effects from
>/// a speculative evaluation.
>class SpeculativeEvaluationRAII {
> -/// Pair of EvalInfo, and a bit that stores whether or not we were
> -/// speculatively evaluating when we created this RAII.
> -llvm::PointerIntPair InfoAndOldSpecEval;
> -Expr::EvalStatus Old;
> +EvalInfo *Info;
> +Expr::EvalStatus OldStatus;
> +bool OldIsSpeculativelyEvaluating;
>
>  void moveFromAndCancel(SpeculativeEvaluationRAII &&Other) {
> -  InfoAndOldSpecEval = Other.InfoAndOldSpecEval;
> -  Old = Other.Old;
> -  Other.InfoAndOldSpecEval.setPointer(nullptr);
> +  Info = Other.Info;
> +  OldStatus = Other.OldStatus;
> +  Other.Info = nullptr;
>  }
>
>  void maybeRestoreState() {
> -  EvalInfo *Info = InfoAndOldSpecEval.getPointer();
>if (!Info)
>  return;
>
> -  Info->EvalStatus = Old;
> -  Info->IsSpeculativelyEvaluating = InfoAndOldSpecEval.getInt();
> +  Info->EvalStatus = OldStatus;
> +  Info->IsSpeculativelyEvaluating = OldIsSpeculativelyEvaluating;
>  }
>
>public:
> @@ -1002,8 +1000,8 @@ namespace {
>
>  SpeculativeEvaluationRAII(
>  EvalInfo &Info, SmallVectorImpl *NewDiag =
> nullptr)
> -: InfoAndOldSpecEval(&Info, Info.IsSpeculativelyEvaluating),
> -  Old(Info.EvalStatus) {
> +: Info(&Info), OldStatus(Info.EvalStatus),
> +  OldIsSpeculativelyEvaluating(Info.IsSpeculativelyEvaluating) {
>Info.EvalStatus.Diag = NewDiag;
>Info.IsSpeculativelyEvaluating = true;
>  }
>
>
> ___
> 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: [PATCH] D36860: [Driver] Recognize DevDiv internal builds of MSVC, with a different directory structure

[David Blaikie via cfe-commits]

On Fri, Aug 18, 2017 at 6:59 PM Stephan T. Lavavej via Phabricator via
cfe-commits  wrote:

> STL_MSFT added a comment.
>
> In https://reviews.llvm.org/D36860#846232, @thakis wrote:
>
> > Many driver tests check in a basic representative directory structure
> (e.g. test/Driver/Inputs/basic_freebsd_tree/ and its many siblings).
> >
> > But if you're happy with others breaking this code, I suppose having no
> tests is ok; I imagine most people won't use this code :-)
>
>
> I can't check in copies of `cl.exe` and `link.exe` (the former's version
> is inspected, so it can't just be a dummy file).


Version as in file metadata, or version as in "cl -v" printed output or the
like?

If it's file metadata (such that Clang can discover it without having to
run the binary on a test machine) might be worth making a dummy file with
just the version metadata in it.

But yeah *shrug* your call


> I'm happy without upstream tests for this logic. In the long run, I hope
> that we can eliminate this internal directory structure and make it
> identical to the released directory structure.
>
>
> https://reviews.llvm.org/D36860
>
>
>
> ___
> 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: r311601 - Fix a bug in CGDebugInfo::EmitInlineFunctionStart causing DILocations to be

[David Blaikie via cfe-commits]

*nod* Thanks - let me know if you have trouble simplifying or explaining it
& I'll see if fresh eyes help :)

On Mon, Aug 28, 2017 at 4:46 PM Adrian Prantl  wrote:

> It's possible that this testcase can be golfed some more. I copied it
> almost verbatim from the PR. I'll see what I can do. The important thing is
> that it needs to trigger the situation where the frontend is creating an
> inlined function.
>
> -- adrian
>
> On Aug 28, 2017, at 4:43 PM, David Blaikie  wrote:
>
> Seems like a rather complex test case - could you explain what's going on
> there? (maybe in the form of a comment in the code - what path through all
> those classes is required to tickle this)
>
> On Wed, Aug 23, 2017 at 2:25 PM Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Wed Aug 23 14:24:12 2017
>> New Revision: 311601
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=311601&view=rev
>> Log:
>> Fix a bug in CGDebugInfo::EmitInlineFunctionStart causing DILocations to
>> be
>> parented in function declarations.
>>
>> Fixes PR33997.
>> https://bugs.llvm.org/show_bug.cgi?id=33997
>>
>> Added:
>> cfe/trunk/test/CodeGenCXX/debug-info-inlined.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=311601&r1=311600&r2=311601&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Aug 23 14:24:12 2017
>> @@ -3287,7 +3287,7 @@ void CGDebugInfo::EmitInlineFunctionStar
>>llvm::DISubprogram *SP = nullptr;
>>if (FI != SPCache.end())
>>  SP = dyn_cast_or_null(FI->second);
>> -  if (!SP)
>> +  if (!SP || !SP->isDefinition())
>>  SP = getFunctionStub(GD);
>>FnBeginRegionCount.push_back(LexicalBlockStack.size());
>>LexicalBlockStack.emplace_back(SP);
>>
>> Added: cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp?rev=311601&view=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp (added)
>> +++ cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp Wed Aug 23 14:24:12
>> 2017
>> @@ -0,0 +1,45 @@
>> +// RUN: %clang_cc1 -emit-llvm -triple i686-pc-windows-msvc19.0.24213
>> -gcodeview -debug-info-kind=limited -std=c++14 %s -o - | FileCheck %s
>> +// PR33997.
>> +struct already_AddRefed {
>> +  ~already_AddRefed();
>> +};
>> +struct RefPtr {
>> +  operator int *();
>> +};
>> +struct ServoCssRulesStrong {
>> +  already_AddRefed Consume();
>> +};
>> +struct GroupRule {
>> +  GroupRule(already_AddRefed);
>> +};
>> +class ConditionRule : GroupRule {
>> +  using GroupRule::GroupRule;
>> +};
>> +class CSSMediaRule : ConditionRule {
>> +  using ConditionRule::ConditionRule;
>> +};
>> +class CSSMozDocumentRule : ConditionRule {
>> +  using ConditionRule::ConditionRule;
>> +};
>> +class ServoDocumentRule : CSSMozDocumentRule {
>> +  ServoDocumentRule(RefPtr);
>> +};
>> +class ServoMediaRule : CSSMediaRule {
>> +  ServoMediaRule(RefPtr);
>> +};
>> +ServoCssRulesStrong Servo_MediaRule_GetRules(int *);
>> +ServoCssRulesStrong Servo_DocumentRule_GetRules(int *);
>> +ServoDocumentRule::ServoDocumentRule(RefPtr aRawRule)
>> +:
>> CSSMozDocumentRule(Servo_DocumentRule_GetRules(aRawRule).Consume()) {}
>> +
>> +ServoMediaRule::ServoMediaRule(RefPtr aRawRule)
>> +: CSSMediaRule(Servo_MediaRule_GetRules(aRawRule).Consume()) {}
>> +
>> +// CHECK: define{{.*}}ServoMediaRule
>> +// CHECK-NOT: {{ ret }}
>> +// CHECK: store %class.ConditionRule* %
>> +// CHECK-SAME: %class.ConditionRule** %
>> +// CHECK-SAME: !dbg ![[INL:[0-9]+]]
>> +
>> +// CHECK: ![[INL]] = !DILocation(line: 16, scope: ![[SP:[0-9]+]],
>> inlinedAt:
>> +// CHECK: ![[SP]] = distinct !DISubprogram(name: "GroupRule",
>> {{.*}}isDefinition: true
>>
>>
>> ___
>> 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: r311601 - Fix a bug in CGDebugInfo::EmitInlineFunctionStart causing DILocations to be

[David Blaikie via cfe-commits]

Seems like a rather complex test case - could you explain what's going on
there? (maybe in the form of a comment in the code - what path through all
those classes is required to tickle this)

On Wed, Aug 23, 2017 at 2:25 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Wed Aug 23 14:24:12 2017
> New Revision: 311601
>
> URL: http://llvm.org/viewvc/llvm-project?rev=311601&view=rev
> Log:
> Fix a bug in CGDebugInfo::EmitInlineFunctionStart causing DILocations to be
> parented in function declarations.
>
> Fixes PR33997.
> https://bugs.llvm.org/show_bug.cgi?id=33997
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-inlined.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=311601&r1=311600&r2=311601&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Aug 23 14:24:12 2017
> @@ -3287,7 +3287,7 @@ void CGDebugInfo::EmitInlineFunctionStar
>llvm::DISubprogram *SP = nullptr;
>if (FI != SPCache.end())
>  SP = dyn_cast_or_null(FI->second);
> -  if (!SP)
> +  if (!SP || !SP->isDefinition())
>  SP = getFunctionStub(GD);
>FnBeginRegionCount.push_back(LexicalBlockStack.size());
>LexicalBlockStack.emplace_back(SP);
>
> Added: cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp?rev=311601&view=auto
>
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp (added)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-inlined.cpp Wed Aug 23 14:24:12
> 2017
> @@ -0,0 +1,45 @@
> +// RUN: %clang_cc1 -emit-llvm -triple i686-pc-windows-msvc19.0.24213
> -gcodeview -debug-info-kind=limited -std=c++14 %s -o - | FileCheck %s
> +// PR33997.
> +struct already_AddRefed {
> +  ~already_AddRefed();
> +};
> +struct RefPtr {
> +  operator int *();
> +};
> +struct ServoCssRulesStrong {
> +  already_AddRefed Consume();
> +};
> +struct GroupRule {
> +  GroupRule(already_AddRefed);
> +};
> +class ConditionRule : GroupRule {
> +  using GroupRule::GroupRule;
> +};
> +class CSSMediaRule : ConditionRule {
> +  using ConditionRule::ConditionRule;
> +};
> +class CSSMozDocumentRule : ConditionRule {
> +  using ConditionRule::ConditionRule;
> +};
> +class ServoDocumentRule : CSSMozDocumentRule {
> +  ServoDocumentRule(RefPtr);
> +};
> +class ServoMediaRule : CSSMediaRule {
> +  ServoMediaRule(RefPtr);
> +};
> +ServoCssRulesStrong Servo_MediaRule_GetRules(int *);
> +ServoCssRulesStrong Servo_DocumentRule_GetRules(int *);
> +ServoDocumentRule::ServoDocumentRule(RefPtr aRawRule)
> +: CSSMozDocumentRule(Servo_DocumentRule_GetRules(aRawRule).Consume())
> {}
> +
> +ServoMediaRule::ServoMediaRule(RefPtr aRawRule)
> +: CSSMediaRule(Servo_MediaRule_GetRules(aRawRule).Consume()) {}
> +
> +// CHECK: define{{.*}}ServoMediaRule
> +// CHECK-NOT: {{ ret }}
> +// CHECK: store %class.ConditionRule* %
> +// CHECK-SAME: %class.ConditionRule** %
> +// CHECK-SAME: !dbg ![[INL:[0-9]+]]
> +
> +// CHECK: ![[INL]] = !DILocation(line: 16, scope: ![[SP:[0-9]+]],
> inlinedAt:
> +// CHECK: ![[SP]] = distinct !DISubprogram(name: "GroupRule",
> {{.*}}isDefinition: true
>
>
> ___
> 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: r310379 - Revert "[OPENMP][DEBUG] Set proper address space info if required by target."

[David Blaikie via cfe-commits]

It's helpful to mention why a patch is reverted in the commit message that
reverts. Thought for next time! :)

On Tue, Aug 8, 2017 at 9:46 AM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: abataev
> Date: Tue Aug  8 09:45:36 2017
> New Revision: 310379
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310379&view=rev
> Log:
> Revert "[OPENMP][DEBUG] Set proper address space info if required by
> target."
>
> This reverts commit r310377.
>
> Removed:
> cfe/trunk/test/OpenMP/target_parallel_debug_codegen.cpp
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
> cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/test/OpenMP/nvptx_target_firstprivate_codegen.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=310379&r1=310378&r2=310379&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Tue Aug  8 09:45:36 2017
> @@ -2685,14 +2685,6 @@ def OMPCaptureNoInit : InheritableAttr {
>let Documentation = [Undocumented];
>  }
>
> -def OMPCaptureKind : Attr {
> -  // This attribute has no spellings as it is only ever created
> implicitly.
> -  let Spellings = [];
> -  let SemaHandler = 0;
> -  let Args = [UnsignedArgument<"CaptureKind">];
> -  let Documentation = [Undocumented];
> -}
> -
>  def OMPDeclareSimdDecl : Attr {
>let Spellings = [Pragma<"omp", "declare simd">];
>let Subjects = SubjectList<[Function]>;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=310379&r1=310378&r2=310379&view=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Aug  8 09:45:36 2017
> @@ -8527,11 +8527,6 @@ public:
>/// is performed.
>bool isOpenMPPrivateDecl(ValueDecl *D, unsigned Level);
>
> -  /// Sets OpenMP capture kind (OMPC_private, OMPC_firstprivate, OMPC_map
> etc.)
> -  /// for \p FD based on DSA for the provided corresponding captured
> declaration
> -  /// \p D.
> -  void setOpenMPCaptureKind(FieldDecl *FD, ValueDecl *D, unsigned Level);
> -
>/// \brief Check if the specified variable is captured  by 'target'
> directive.
>/// \param Level Relative level of nested OpenMP construct for that the
> check
>/// is performed.
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h?rev=310379&r1=310378&r2=310379&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h Tue Aug  8 09:45:36 2017
> @@ -1325,32 +1325,6 @@ public:
>virtual void emitDoacrossOrdered(CodeGenFunction &CGF,
> const OMPDependClause *C);
>
> -  /// Translates the native parameter of outlined function if this is
> required
> -  /// for target.
> -  /// \param FD Field decl from captured record for the paramater.
> -  /// \param NativeParam Parameter itself.
> -  virtual const VarDecl *translateParameter(const FieldDecl *FD,
> -const VarDecl *NativeParam)
> const {
> -return NativeParam;
> -  }
> -
> -  typedef llvm::function_ref Address)>
> -  MappingFnType;
> -  /// Maps the native argument to the address of the corresponding
> -  /// target-specific argument.
> -  /// \param FD Field decl from captured record for the paramater.
> -  /// \param NativeParam Parameter itself.
> -  /// \param TargetParam Corresponding target-specific parameter.
> -  /// \param MapFn Function that maps the native parameter to the address
> of the
> -  /// target-specific.
> -  virtual void mapParameterAddress(CodeGenFunction &CGF, const FieldDecl
> *FD,
> -   const VarDecl *NativeParam,
> -   const VarDecl *TargetParam,
> -   const MappingFnType) const {
> -assert(NativeParam == TargetParam &&
> -   "native and target args must be the same");
> -  }
> -
>/// Emits call of the outlined function with the provided arguments,
>/// translating these arguments to correct target-specific arguments.
>virtual void
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp?rev=310379&r1=310378

Re: [PATCH] D36386: [clang] Remove unit test which uses reverse-iterate and fix a PointerLikeTypeTrait specialization

[David Blaikie via cfe-commits]

OK - go ahead and remove the tests then, if the functionality is now
covered by the buildbot+existing tests.

On Wed, Aug 9, 2017 at 12:04 PM Grang, Mandeep Singh 
wrote:

> > Ah, OK. I'm still curious about whether this results in a loss of test
> coverage. Without this test, would the bug it was testing still be caught
> by some test failure in at least one of the forward or reverse iteration
> modes?
>
> Sorry ... I missed that. Yes, the reverse iteration buildbot
> http://lab.llvm.org:8011/builders/reverse-iteration would test these.
> These tests were a stopgap solution anyway while the reverse builtbot was
> being setup.
>
> > I'll just do that (r310506 & r310508) - done! :)
> Thanks!
>
>
> --Mandeep
>
> On 8/9/2017 11:35 AM, David Blaikie wrote:
>
>
>
> On Wed, Aug 9, 2017 at 1:44 AM Grang, Mandeep Singh 
> wrote:
>
>> In D35043 I have removed the llvm tests which use -reverse-iterate. This
>> patch removes the clang tests.
>>
>
> Ah, OK. I'm still curious about whether this results in a loss of test
> coverage. Without this test, would the bug it was testing still be caught
> by some test failure in at least one of the forward or reverse iteration
> modes?
>
>
>> Should I post a later patch to change all "class PointerLikeTypeTraits"
>> to "struct PointerLikeTypeTraits"?
>>
>
> I'll just do that (r310506 & r310508) - done! :)
>
>
>>
>>
>> On 8/7/2017 2:50 PM, David Blaikie wrote:
>>
>>
>>
>> On Mon, Aug 7, 2017 at 12:08 PM Mandeep Singh Grang via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> mgrang added a comment.
>>>
>>> This patch does 3 things:
>>>
>>> 1. Get rid of the unit test objc-modern-metadata-visibility2.mm because
>>> this test check uses flag -reverse-iterate. This flag will be removed in
>>> https://reviews.llvm.org/D35043.
>>>
>>
>> Sure - please commit that separately (probably once D35043 is approved -
>> probably best to include that removal in D35043, or a separate patch that
>> /only/ removes the -reverse-iterate flag (& any tests that use it) as a
>> standalone change?).
>>
>> Does this test need a replacement? If this test is removed and the
>> underlying issue it was testing regresses, will one of the buildbots
>> (reverse or normal) catch the problem?
>>
>>
>>> 2. https://reviews.llvm.org/D35043 gets rid of the empty base
>>> definition for PointerLikeTypeTraits. This results in a compiler warning
>>> because PointerLikeTypeTrait has been defined as struct here while in the
>>> header it is a class. So I have changed struct to class.
>>>
>>
>> I'd probably go the other way - traits classes like this make more sense
>> as structs, I think - it only has public members & no implementation really
>> has any need for supporting private members.
>>
>>
>>> 3. Since I changed struct PointerLikeTypeTrait to class
>>> PointerLikeTypeTrait here, the member functions are no longer public now.
>>> This results in a compiler error. So I explicitly marked them as public
>>> here.
>>>
>>>
>>> https://reviews.llvm.org/D36386
>>>
>>>
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36386: [clang] Remove unit test which uses reverse-iterate and fix a PointerLikeTypeTrait specialization

[David Blaikie via cfe-commits]

On Wed, Aug 9, 2017 at 1:44 AM Grang, Mandeep Singh 
wrote:

> In D35043 I have removed the llvm tests which use -reverse-iterate. This
> patch removes the clang tests.
>

Ah, OK. I'm still curious about whether this results in a loss of test
coverage. Without this test, would the bug it was testing still be caught
by some test failure in at least one of the forward or reverse iteration
modes?


> Should I post a later patch to change all "class PointerLikeTypeTraits" to
> "struct PointerLikeTypeTraits"?
>

I'll just do that (r310506 & r310508) - done! :)


>
>
> On 8/7/2017 2:50 PM, David Blaikie wrote:
>
>
>
> On Mon, Aug 7, 2017 at 12:08 PM Mandeep Singh Grang via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> mgrang added a comment.
>>
>> This patch does 3 things:
>>
>> 1. Get rid of the unit test objc-modern-metadata-visibility2.mm because
>> this test check uses flag -reverse-iterate. This flag will be removed in
>> https://reviews.llvm.org/D35043.
>>
>
> Sure - please commit that separately (probably once D35043 is approved -
> probably best to include that removal in D35043, or a separate patch that
> /only/ removes the -reverse-iterate flag (& any tests that use it) as a
> standalone change?).
>
> Does this test need a replacement? If this test is removed and the
> underlying issue it was testing regresses, will one of the buildbots
> (reverse or normal) catch the problem?
>
>
>> 2. https://reviews.llvm.org/D35043 gets rid of the empty base definition
>> for PointerLikeTypeTraits. This results in a compiler warning because
>> PointerLikeTypeTrait has been defined as struct here while in the header it
>> is a class. So I have changed struct to class.
>>
>
> I'd probably go the other way - traits classes like this make more sense
> as structs, I think - it only has public members & no implementation really
> has any need for supporting private members.
>
>
>> 3. Since I changed struct PointerLikeTypeTrait to class
>> PointerLikeTypeTrait here, the member functions are no longer public now.
>> This results in a compiler error. So I explicitly marked them as public
>> here.
>>
>>
>> https://reviews.llvm.org/D36386
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r310508 - PointerLikeTypeTraits: class->struct to match LLVM change

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Aug  9 11:34:22 2017
New Revision: 310508

URL: http://llvm.org/viewvc/llvm-project?rev=310508&view=rev
Log:
PointerLikeTypeTraits: class->struct to match LLVM change

Modified:
cfe/trunk/include/clang/AST/CanonicalType.h
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/AST/DeclGroup.h
cfe/trunk/include/clang/AST/TemplateName.h
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/IdentifierTable.h
cfe/trunk/include/clang/Basic/SourceLocation.h
cfe/trunk/include/clang/CodeGen/ConstantInitFuture.h
cfe/trunk/include/clang/Sema/Ownership.h

Modified: cfe/trunk/include/clang/AST/CanonicalType.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/CanonicalType.h?rev=310508&r1=310507&r2=310508&view=diff
==
--- cfe/trunk/include/clang/AST/CanonicalType.h (original)
+++ cfe/trunk/include/clang/AST/CanonicalType.h Wed Aug  9 11:34:22 2017
@@ -359,8 +359,7 @@ struct simplify_type< ::clang::CanQual is "basically a pointer".
 template
-class PointerLikeTypeTraits > {
-public:
+struct PointerLikeTypeTraits > {
   static inline void *getAsVoidPointer(clang::CanQual P) {
 return P.getAsOpaquePtr();
   }

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=310508&r1=310507&r2=310508&view=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Wed Aug  9 11:34:22 2017
@@ -73,8 +73,7 @@ public:
 namespace llvm {
   // Provide PointerLikeTypeTraits for non-cvr pointers.
   template<>
-  class PointerLikeTypeTraits< ::clang::AnyFunctionDecl> {
-  public:
+  struct PointerLikeTypeTraits< ::clang::AnyFunctionDecl> {
 static inline void *getAsVoidPointer(::clang::AnyFunctionDecl F) {
   return F.get();
 }

Modified: cfe/trunk/include/clang/AST/DeclGroup.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclGroup.h?rev=310508&r1=310507&r2=310508&view=diff
==
--- cfe/trunk/include/clang/AST/DeclGroup.h (original)
+++ cfe/trunk/include/clang/AST/DeclGroup.h Wed Aug  9 11:34:22 2017
@@ -138,10 +138,9 @@ public:
 namespace llvm {
   // DeclGroupRef is "like a pointer", implement PointerLikeTypeTraits.
   template 
-  class PointerLikeTypeTraits;
+  struct PointerLikeTypeTraits;
   template <>
-  class PointerLikeTypeTraits {
-  public:
+  struct PointerLikeTypeTraits {
 static inline void *getAsVoidPointer(clang::DeclGroupRef P) {
   return P.getAsOpaquePtr();
 }

Modified: cfe/trunk/include/clang/AST/TemplateName.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TemplateName.h?rev=310508&r1=310507&r2=310508&view=diff
==
--- cfe/trunk/include/clang/AST/TemplateName.h (original)
+++ cfe/trunk/include/clang/AST/TemplateName.h Wed Aug  9 11:34:22 2017
@@ -515,8 +515,7 @@ namespace llvm {
 
 /// \brief The clang::TemplateName class is effectively a pointer.
 template<>
-class PointerLikeTypeTraits {
-public:
+struct PointerLikeTypeTraits {
   static inline void *getAsVoidPointer(clang::TemplateName TN) {
 return TN.getAsVoidPointer();
   }

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=310508&r1=310507&r2=310508&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Wed Aug  9 11:34:22 2017
@@ -48,10 +48,9 @@ namespace clang {
 
 namespace llvm {
   template 
-  class PointerLikeTypeTraits;
+  struct PointerLikeTypeTraits;
   template<>
-  class PointerLikeTypeTraits< ::clang::Type*> {
-  public:
+  struct PointerLikeTypeTraits< ::clang::Type*> {
 static inline void *getAsVoidPointer(::clang::Type *P) { return P; }
 static inline ::clang::Type *getFromVoidPointer(void *P) {
   return static_cast< ::clang::Type*>(P);
@@ -59,8 +58,7 @@ namespace llvm {
 enum { NumLowBitsAvailable = clang::TypeAlignmentInBits };
   };
   template<>
-  class PointerLikeTypeTraits< ::clang::ExtQuals*> {
-  public:
+  struct PointerLikeTypeTraits< ::clang::ExtQuals*> {
 static inline void *getAsVoidPointer(::clang::ExtQuals *P) { return P; }
 static inline ::clang::ExtQuals *getFromVoidPointer(void *P) {
   return static_cast< ::clang::ExtQuals*>(P);
@@ -1143,8 +1141,7 @@ template<> struct simplify_type< ::clang
 
 // Teach SmallPtrSet that QualType is "basically a pointer".
 template<>
-class PointerLikeTypeTraits {
-public:
+struct PointerLikeTypeTraits {
   static inline void *getAsVoidPointer(clang::QualType P) {
 return P.ge

Re: [PATCH] D36386: [clang] Remove unit test which uses reverse-iterate and fix a PointerLikeTypeTrait specialization

[David Blaikie via cfe-commits]

On Mon, Aug 7, 2017 at 12:08 PM Mandeep Singh Grang via Phabricator <
revi...@reviews.llvm.org> wrote:

> mgrang added a comment.
>
> This patch does 3 things:
>
> 1. Get rid of the unit test objc-modern-metadata-visibility2.mm because
> this test check uses flag -reverse-iterate. This flag will be removed in
> https://reviews.llvm.org/D35043.
>

Sure - please commit that separately (probably once D35043 is approved -
probably best to include that removal in D35043, or a separate patch that
/only/ removes the -reverse-iterate flag (& any tests that use it) as a
standalone change?).

Does this test need a replacement? If this test is removed and the
underlying issue it was testing regresses, will one of the buildbots
(reverse or normal) catch the problem?


> 2. https://reviews.llvm.org/D35043 gets rid of the empty base definition
> for PointerLikeTypeTraits. This results in a compiler warning because
> PointerLikeTypeTrait has been defined as struct here while in the header it
> is a class. So I have changed struct to class.
>

I'd probably go the other way - traits classes like this make more sense as
structs, I think - it only has public members & no implementation really
has any need for supporting private members.


> 3. Since I changed struct PointerLikeTypeTrait to class
> PointerLikeTypeTrait here, the member functions are no longer public now.
> This results in a compiler error. So I explicitly marked them as public
> here.
>
>
> https://reviews.llvm.org/D36386
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36386: [clang] Remove unit test which uses reverse-iterate and fix a PointerLikeTypeTrait specialization

[David Blaikie via cfe-commits]

Not sure I understand the context for these changes - could you describe
the motivation(s) in more detail?

On Sun, Aug 6, 2017 at 10:39 PM Mandeep Singh Grang via Phabricator <
revi...@reviews.llvm.org> wrote:

> mgrang created this revision.
>
> This patch is in response to https://reviews.llvm.org/D35043 which
> removed -reverse-iterate flag
> and the base definition for PointerLikeTypeTrait.
>
>
> https://reviews.llvm.org/D36386
>
> Files:
>   include/clang/AST/ExternalASTSource.h
>   test/Rewriter/objc-modern-metadata-visibility2.mm
>
>
> Index: test/Rewriter/objc-modern-metadata-visibility2.mm
> ===
> --- test/Rewriter/objc-modern-metadata-visibility2.mm
> +++ /dev/null
> @@ -1,45 +0,0 @@
> -// REQUIRES: abi-breaking-checks
> -// NOTE: This test has been split from objc-modern-metadata-visibility.mm
> in
> -// order to test with -reverse-iterate as this flag is only present with
> -// ABI_BREAKING_CHECKS.
> -
> -// RUN: %clang_cc1 -E %s -o %t.mm -mllvm -reverse-iterate
> -// RUN: %clang_cc1 -x objective-c++ -fblocks -fms-extensions
> -rewrite-objc %t.mm -mllvm -reverse-iterate -o - | FileCheck %s
> -// rdar://11144048
> -
> -@class NSString;
> -
> -@interface NSObject {
> -Class isa;
> -}
> -@end
> -
> -@interface Sub : NSObject {
> -int subIvar;
> -NSString *nsstring;
> -@private
> -id PrivateIvar;
> -}
> -@end
> -
> -@implementation Sub
> -- (id) MyNSString { return subIvar ? PrivateIvar : nsstring; }
> -@end
> -
> -@interface NSString @end
> -@implementation NSString @end
> -
> -// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C"
> __declspec(dllimport) unsigned long OBJC_IVAR_$_Sub$subIvar;
> -// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" unsigned long
> OBJC_IVAR_$_Sub$PrivateIvar;
> -// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C"
> __declspec(dllimport) unsigned long OBJC_IVAR_$_Sub$nsstring;
> -// CHECK: #pragma warning(disable:4273)
> -// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C"
> __declspec(dllexport) unsigned long int OBJC_IVAR_$_Sub$subIvar
> -// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C"
> __declspec(dllexport) unsigned long int OBJC_IVAR_$_Sub$nsstring
> -// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" unsigned long
> int OBJC_IVAR_$_Sub$PrivateIvar
> -// CHECK: extern "C" __declspec(dllimport) struct _class_t
> OBJC_METACLASS_$_NSObject;
> -// CHECK: extern "C" __declspec(dllexport) struct _class_t
> OBJC_METACLASS_$_Sub
> -// CHECK: extern "C" __declspec(dllimport) struct _class_t
> OBJC_CLASS_$_NSObject;
> -// CHECK: extern "C" __declspec(dllexport) struct _class_t
> OBJC_CLASS_$_Sub
> -// CHECK: extern "C" __declspec(dllexport) struct _class_t
> OBJC_CLASS_$_NSString;
> -// CHECK: extern "C" __declspec(dllexport) struct _class_t
> OBJC_METACLASS_$_NSString
> -// CHECK: extern "C" __declspec(dllexport) struct _class_t
> OBJC_CLASS_$_NSString
> Index: include/clang/AST/ExternalASTSource.h
> ===
> --- include/clang/AST/ExternalASTSource.h
> +++ include/clang/AST/ExternalASTSource.h
> @@ -466,9 +466,10 @@
>  namespace llvm {
>  template   void (clang::ExternalASTSource::*Update)(Owner)>
> -struct PointerLikeTypeTraits<
> +class PointerLikeTypeTraits<
>  clang::LazyGenerationalUpdatePtr> {
>typedef clang::LazyGenerationalUpdatePtr Ptr;
> +public:
>static void *getAsVoidPointer(Ptr P) { return P.getOpaqueValue(); }
>static Ptr getFromVoidPointer(void *P) { return
> Ptr::getFromOpaqueValue(P); }
>enum {
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D35746: Make new PM honor -fdebug-info-for-profiling (clang side)

[David Blaikie via cfe-commits]

On Thu, Jul 27, 2017 at 8:30 AM Dehao Chen via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> danielcdh marked an inline comment as done.
> danielcdh added a comment.
>
> Thanks for the review!
>
> In https://reviews.llvm.org/D35746#822498, @chandlerc wrote:
>
> > LGTM with a tiny tweak below.
> >
> > Would be good to add a test that this flag is being honored, either in
> this patch or in a follow-up.
>
>
> I'll add the test in a follow-up patch. Could you help suggest how to add
> a test for this? Shall I just invoke "clang -cc1
> -fexperimental-new-pass-manager" and check if discriminator is generated?
> That seems an integration test.
>

Yeah, things that interact between Clang and LLVM that aren't part of IR
basically slip through the cracks of the nice separation of testing here.
Either they go untested, or are tested in a more 'integration' like test -
though trying to find the minimal thing to examine that's not testing all
the features, etc.

If there's a clang argument that dumps the pass sequence? Or some other
'earlier' observable property like that? (how's the
-fexperimental-new-pass-manager flag tested, for example? maybe it isn't)


>
>
> https://reviews.llvm.org/D35746
>
>
>
> ___
> 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: [PATCH] D35783: Ignore shadowing for declarations coming from within macros.

[David Blaikie via cfe-commits]

On Tue, Jul 25, 2017 at 1:19 AM Roman Lebedev via Phabricator via
cfe-commits  wrote:

> lebedev.ri added a comment.
>
> How does this relate to the gcc behavior?
> I suspect not everyone would want to have this relaxed `-Wshadow` mode.
>

Generally I think the goal hasn't been to allow a clang user to keep their
code GCC warning clean - if a warning has too many false positives, it
can/will be changed in clang, even if it means it misses cases GCC will
flag. (for example -Wreturn-type, which pops up a lot in the LLVM codebase
when it fires on code that's probably unreachable that Clang is nice enough
to assume won't be reached (code after a fully covered switch over enum,
where each case returns))

Though it's not unheard of to bisect the diagnostic space to provide these
variations if suitable - but I wouldn't suggest doing so 'just' for
compatibility with GCC.


> Perhaps it could be hidden under some new flag, which is not going to be
> automatically enabled by `-Weverything`.
>

Nothing is ever not going to be automatically enabled by -Weverything (the
intent is that it's really, always, everything). Or perhaps you meant
-Wall? (which isn't everything & that ship's already sailed, so usually
more nuanced choices are made about what goes in there, etc)


> Like, `-Wshadow-in-macros` which does nothing compared to `-Wshadow`, and
> then `-Wno-shadow-in-macros` which enables this relaxed mode?
>
>
> https://reviews.llvm.org/D35783
>
>
>
> ___
> 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: r309496 - Improve readability of CXX method overrides list

[David Blaikie via cfe-commits]

Test coverage?

On Sun, Jul 30, 2017 at 5:52 AM Lenar Safin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: lll
> Date: Sat Jul 29 13:42:58 2017
> New Revision: 309496
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309496&view=rev
> Log:
> Improve readability of CXX method overrides list
>
> Summary:
> Separate CXX method overrides list entries with commas.
>
> Reviewers: lhames
>
> Reviewed By: lhames
>
> Subscribers: llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D35800
>
>
> Modified:
> cfe/trunk/lib/AST/ASTDumper.cpp
>
> Modified: cfe/trunk/lib/AST/ASTDumper.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=309496&r1=309495&r2=309496&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ASTDumper.cpp (original)
> +++ cfe/trunk/lib/AST/ASTDumper.cpp Sat Jul 29 13:42:58 2017
> @@ -1184,7 +1184,7 @@ void ASTDumper::VisitFunctionDecl(const
>   I != E; ++I)
>dumpCXXCtorInitializer(*I);
>
> -  if (const CXXMethodDecl *MD = dyn_cast(D))
> +  if (const CXXMethodDecl *MD = dyn_cast(D)) {
>  if (MD->size_overridden_methods() != 0) {
>auto dumpOverride =
>  [=](const CXXMethodDecl *D) {
> @@ -1199,11 +1199,14 @@ void ASTDumper::VisitFunctionDecl(const
>  dumpOverride(*FirstOverrideItr);
>  for (const auto *Override :
> llvm::make_range(FirstOverrideItr + 1,
> -MD->end_overridden_methods()))
> +MD->end_overridden_methods())) {
> +  OS << ", ";
>dumpOverride(Override);
> +}
>  OS << " ]";
>});
>  }
> +  }
>
>if (D->doesThisDeclarationHaveABody())
>  dumpStmt(D->getBody());
>
>
> ___
> 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: [libcxxabi] r309349 - [demangler] Fix some overzealous -Wreturn-type errors

[David Blaikie via cfe-commits]

On Thu, Jul 27, 2017 at 6:35 PM Erik Pilkington via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: epilk
> Date: Thu Jul 27 18:35:14 2017
> New Revision: 309349
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309349&view=rev
> Log:
> [demangler] Fix some overzealous -Wreturn-type errors
>

I'm guessing this is GCC's -Wreturn-type after a
fully-covered-all-returning switch?

That's usually addressed by using llvm_unreachable after the switch, rather
than a dead return. (not sure if you've something like llvm_unreachable in
libcxxabi to use?)


>
> Modified:
> libcxxabi/trunk/src/cxa_demangle.cpp
>
> Modified: libcxxabi/trunk/src/cxa_demangle.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp?rev=309349&r1=309348&r2=309349&view=diff
>
> ==
> --- libcxxabi/trunk/src/cxa_demangle.cpp (original)
> +++ libcxxabi/trunk/src/cxa_demangle.cpp Thu Jul 27 18:35:14 2017
> @@ -896,6 +896,7 @@ public:
>  case SpecialSubKind::iostream:
>return StringView("basic_iostream");
>  }
> +return StringView();
>}
>
>void printLeft(OutputStream &S) const override {
> @@ -944,6 +945,7 @@ public:
>  case SpecialSubKind::iostream:
>return StringView("iostream");
>  }
> +return StringView();
>}
>
>void printLeft(OutputStream &S) const override {
>
>
> ___
> 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: [PATCH] D35961: [llvm] Update MachOObjectFile::exports interface

[David Blaikie via cfe-commits]

On Fri, Jul 28, 2017 at 4:01 PM Kevin Enderby  wrote:

> On Jul 28, 2017, at 10:30 AM, David Blaikie  wrote:
>
>
>
> On Fri, Jul 28, 2017 at 10:24 AM Kevin Enderby  wrote:
>
>> On Jul 27, 2017, at 9:50 PM, Saleem Abdulrasool via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>> compnerd added a comment.
>>
>> Does anyone use the overload with the `O` for `exports` with `nullptr`
>> instead of `this`?  If not, we could just inline `this` throughout.
>>
>>
>> This will break lld as it needs the default nullptr.  See r308691.
>>
>> The reason that O was added was so that this check from r308690 could be
>> added.
>>
>
> When O is specified is it always == this, though? That seems to be implied
> by the original post.
>
> If that's the case, then the ability to pass null is really only passing
> the on/off state for the diagnostic? Is that necessary, or would it be good
> to just always produce the Error, even in lld?
>
>
> Without O one can’t use O->getLibraryCount() which is what is needed for
> the test.  I guess one could change the interface if lld really wanted this
> check. But I’d leave that to the lld folks as to what level of error
> checking they want.
>

No worries - looks like Alex explained the disconnect that there were
different functions under discussion. (:


>
>
>
>>
>> +  if (O != nullptr) {
>> +if (State.Other > O->getLibraryCount()) {
>> +  *E = malformedError("bad library ordinal: " +
>> Twine((int)State.Other)
>> +   + " (max " + Twine((int)O->getLibraryCount()) + ") in
>> export "
>> +   "trie data at node: 0x" + utohexstr(offset));
>> +  moveToEnd();
>> +  return;
>> +}
>>
>> This is needed for the test case:
>>
>> +RUN: not llvm-objdump -macho -exports-trie
>> %p/Inputs/macho-trie-bad-library-ordinal 2>&1 | FileCheck -check-prefix
>> BAD_LIBRARY_ORDINAL %s
>> +BAD_LIBRARY_ORDINAL: macho-trie-bad-library-ordinal': truncated or
>> malformed object (bad library ordinal: 69 (max 3) in export trie data at
>> node: 0x33)
>>
>>
>>
>>
>> 
>> Comment at: tools/llvm-nm/llvm-nm.cpp:1230
>>   Error Err = Error::success();
>> -  for (const llvm::object::ExportEntry &Entry : MachO->exports(Err,
>> -
>>   MachO)) {
>> +  for (const llvm::object::ExportEntry &Entry : MachO->exports(Err))
>> {
>> bool found = false;
>> 
>> I think that using `auto` here instead of `llvm::object:ExportEntry` is
>> better for readability.
>>
>>
>> 
>> Comment at: tools/llvm-objdump/MachODump.cpp:9406
>>   Error Err = Error::success();
>> -  for (const llvm::object::ExportEntry &Entry : Obj->exports(Err, Obj)) {
>> +  for (const llvm::object::ExportEntry &Entry : Obj->exports(Err)) {
>> uint64_t Flags = Entry.flags();
>> 
>> Similar.
>>
>>
>> Repository:
>>  rL LLVM
>>
>> https://reviews.llvm.org/D35961
>>
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D35961: [llvm] Update MachOObjectFile::exports interface

[David Blaikie via cfe-commits]

On Fri, Jul 28, 2017 at 10:24 AM Kevin Enderby  wrote:

> On Jul 27, 2017, at 9:50 PM, Saleem Abdulrasool via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> compnerd added a comment.
>
> Does anyone use the overload with the `O` for `exports` with `nullptr`
> instead of `this`?  If not, we could just inline `this` throughout.
>
>
> This will break lld as it needs the default nullptr.  See r308691.
>
> The reason that O was added was so that this check from r308690 could be
> added.
>

When O is specified is it always == this, though? That seems to be implied
by the original post.

If that's the case, then the ability to pass null is really only passing
the on/off state for the diagnostic? Is that necessary, or would it be good
to just always produce the Error, even in lld?


>
> +  if (O != nullptr) {
> +if (State.Other > O->getLibraryCount()) {
> +  *E = malformedError("bad library ordinal: " +
> Twine((int)State.Other)
> +   + " (max " + Twine((int)O->getLibraryCount()) + ") in
> export "
> +   "trie data at node: 0x" + utohexstr(offset));
> +  moveToEnd();
> +  return;
> +}
>
> This is needed for the test case:
>
> +RUN: not llvm-objdump -macho -exports-trie
> %p/Inputs/macho-trie-bad-library-ordinal 2>&1 | FileCheck -check-prefix
> BAD_LIBRARY_ORDINAL %s
> +BAD_LIBRARY_ORDINAL: macho-trie-bad-library-ordinal': truncated or
> malformed object (bad library ordinal: 69 (max 3) in export trie data at
> node: 0x33)
>
>
>
>
> 
> Comment at: tools/llvm-nm/llvm-nm.cpp:1230
>   Error Err = Error::success();
> -  for (const llvm::object::ExportEntry &Entry : MachO->exports(Err,
> -
>   MachO)) {
> +  for (const llvm::object::ExportEntry &Entry : MachO->exports(Err)) {
> bool found = false;
> 
> I think that using `auto` here instead of `llvm::object:ExportEntry` is
> better for readability.
>
>
> 
> Comment at: tools/llvm-objdump/MachODump.cpp:9406
>   Error Err = Error::success();
> -  for (const llvm::object::ExportEntry &Entry : Obj->exports(Err, Obj)) {
> +  for (const llvm::object::ExportEntry &Entry : Obj->exports(Err)) {
> uint64_t Flags = Entry.flags();
> 
> Similar.
>
>
> Repository:
>  rL LLVM
>
> https://reviews.llvm.org/D35961
>
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D35715: Preserve typedef names in debug info for template type parameters

[David Blaikie via cfe-commits]

On Fri, Jul 21, 2017 at 12:57 PM David Blaikie  wrote:

> On Fri, Jul 21, 2017 at 11:34 AM David Majnemer via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> majnemer added a comment.
>>
>> This might be a silly question but why not do this by default?
>>
>
> I'd hazard a guess that GDB wouldn't cope well with this (in terms of
> identifying templates as the same type under this flag - one TU has a
> function that has a parameter type with the name "foo" and the other
> has a type named "foo" (where f is a typedef of int) - going to guess
> GDB doesn't realize those are the same type... )
>

(in fact, the DWARF doesn't necessarily have any mention of 'x' or that
it's a typedef of int... - the DW_TAG_template_type_parameter says the
parameter is int, so it's not not impossible to figure it all out - though
that's predicated on another patch Paul has, to include
DW_TAG_template_type_parameters of template declarations (which Clang
currently doesn't do - saves space, etc))


>
> Also, Paul: This doesn't change the type that's referenced in the
> DW_TAG_template_type_parameter? Would it make sense to actually do this the
> opposite way - use the canonical name for the name, but have the
> DW_TAG_template_type_parameter refer to the typedef? Still means the type
> can vary between different translation units, which seems a bit difficult
> to deal with, but probably harmless in that case?
>
> Would still mean long/unweildy names, though, which I guess is what's
> being avoided/addressed here.
>
>
>>
>>
>> https://reviews.llvm.org/D35715
>>
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D35715: Preserve typedef names in debug info for template type parameters

[David Blaikie via cfe-commits]

On Fri, Jul 21, 2017 at 11:34 AM David Majnemer via Phabricator <
revi...@reviews.llvm.org> wrote:

> majnemer added a comment.
>
> This might be a silly question but why not do this by default?
>

I'd hazard a guess that GDB wouldn't cope well with this (in terms of
identifying templates as the same type under this flag - one TU has a
function that has a parameter type with the name "foo" and the other
has a type named "foo" (where f is a typedef of int) - going to guess
GDB doesn't realize those are the same type... )

Also, Paul: This doesn't change the type that's referenced in the
DW_TAG_template_type_parameter? Would it make sense to actually do this the
opposite way - use the canonical name for the name, but have the
DW_TAG_template_type_parameter refer to the typedef? Still means the type
can vary between different translation units, which seems a bit difficult
to deal with, but probably harmless in that case?

Would still mean long/unweildy names, though, which I guess is what's being
avoided/addressed here.


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

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

[David Blaikie via cfe-commits]

Looks good - does this support available_externally definitions of strong
external linkage functions in the users of a module? (is that tested?)
Should it?

Also should we consider having two flags for modular codegen - one for
correctness (external function definitions), one for linkage size
optimization (inline functions). Given the current data on optimized builds
with inline functions (that it hurts object size to emit
weak+available_externally definitions rather than linkonce_odr because so
many definitions are optimized away entirely, that the bytes for the weak
definition are wasted/unnecessary) - or at least something to keep in
mind/run numbers on in the future for more generic codebases than Google's
protobuf-heavy (& only protobuf modularized) code.

On Wed, Jul 5, 2017 at 5:30 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Wed Jul  5 17:30:00 2017
> New Revision: 307232
>
> URL: http://llvm.org/viewvc/llvm-project?rev=307232&view=rev
> Log:
> [modules ts] Do not emit strong function definitions from the module
> interface unit in every user.
>
> Added:
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cppm
> cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/user.cpp
> Modified:
> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>
> Modified: cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterDecl.cpp?rev=307232&r1=307231&r2=307232&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTWriterDecl.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTWriterDecl.cpp Wed Jul  5 17:30:00 2017
> @@ -2233,8 +2233,18 @@ void ASTRecordWriter::AddFunctionDefinit
>Writer->ClearSwitchCaseIDs();
>
>assert(FD->doesThisDeclarationHaveABody());
> -  bool ModulesCodegen = Writer->Context->getLangOpts().ModulesCodegen &&
> -Writer->WritingModule &&
> !FD->isDependentContext();
> +  bool ModulesCodegen = false;
> +  if (Writer->WritingModule && !FD->isDependentContext()) {
> +// Under -fmodules-codegen, codegen is performed for all defined
> functions.
> +// When building a C++ Modules TS module interface unit, a strong
> definition
> +// in the module interface is provided by the compilation of that
> module
> +// interface unit, not by its users. (Inline functions are still
> emitted
> +// in module users.)
> +ModulesCodegen =
> +Writer->Context->getLangOpts().ModulesCodegen ||
> +(Writer->WritingModule->Kind == Module::ModuleInterfaceUnit &&
> + Writer->Context->GetGVALinkageForFunction(FD) ==
> GVA_StrongExternal);
> +  }
>Record->push_back(ModulesCodegen);
>if (ModulesCodegen)
>  Writer->ModularCodegenDecls.push_back(Writer->GetDeclRef(FD));
>
> Added: cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp?rev=307232&view=auto
>
> ==
> --- cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp (added)
> +++ cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp Wed
> Jul  5 17:30:00 2017
> @@ -0,0 +1,23 @@
> +// RUN: %clang_cc1 -fmodules-ts %S/module.cppm -triple
> %itanium_abi_triple -emit-module-interface -o %t
> +// RUN: %clang_cc1 -fmodules-ts %s -triple %itanium_abi_triple
> -fmodule-file=%t -emit-llvm -o - | FileCheck %s --implicit-check-not=unused
> --implicit-check-not=global_module
> +
> +module Module;
> +
> +void use() {
> +  // CHECK: define linkonce_odr {{.*}}@_Z20used_inline_exportedv
> +  used_inline_exported();
> +  // CHECK: declare {{.*}}@_Z18noninline_exportedv
> +  noninline_exported();
> +
> +  // FIXME: This symbol should not be visible here.
> +  // CHECK: define internal {{.*}}@_ZL26used_static_module_linkagev
> +  used_static_module_linkage();
> +
> +  // FIXME: The module name should be mangled into the name of this
> function.
> +  // CHECK: define linkonce_odr {{.*}}@_Z26used_inline_module_linkagev
> +  used_inline_module_linkage();
> +
> +  // FIXME: The module name should be mangled into the name of this
> function.
> +  // CHECK: declare {{.*}}@_Z24noninline_module_linkagev
> +  noninline_module_linkage();
> +}
>
> Added: cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cppm
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cppm?rev=307232&view=auto
>
> ==
> --- cfe/trunk/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cppm
> (added)
> 

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

Thanks all!

On Wed, Jul 12, 2017 at 7:46 AM Alexander Kornienko 
wrote:

> Done in r307661.
>
> On Mon, Jul 10, 2017 at 2:08 PM, Alexander Kornienko 
> wrote:
>
>> Benjamin has actually fixed the issue by reverting to the old behavior in 
>> r306822.
>> I'll add a test for this behavior anyway.
>>
>> On Mon, Jul 10, 2017 at 11:47 AM, Alexander Kornienko 
>> wrote:
>>
>>> Sorry, missed this thread somehow. So, the behavior itself seems
>>> incorrect. Clang tools should not be trying to find a compilation database
>>> in case the command line has a `--`, but the driver fails to parse it. It
>>> should be a hard failure. We also need a reliable test for this behavior
>>> (with a compile_commands.json being put into a test directory or generated
>>> during a test).
>>>
>>>
>>> On Tue, Jun 27, 2017 at 3:33 AM, David Blaikie 
>>> wrote:
>>>


 On Mon, Jun 26, 2017 at 5:31 AM Serge Pavlov 
 wrote:

> 2017-06-26 4:05 GMT+07:00 David Blaikie :
>
>> Ah, I see now then.
>>
>> I have a symlink from the root of my source directory pointing to the
>> compile_commands.json in my build directory.
>>
>> I have this so that the vim YouCompleteMe plugin (& any other clang
>> tools) can find it, as they usually should, for using tools with the
>> llvm/clang project...
>>
>> Sounds like this test is incompatible with using the tooling
>> infrastructure in the llvm/clang project?
>>
> Any test that relies on compilation database search can fail in such
> case. Maybe the root of the tools test could contain some special
> compile_commands.json so that the search will always end up in definite
> state?
>

 Perhaps - or maybe tools could have a parameter limiting how many
 parent directories to recurse up through? But yeah, dunno what the best
 solution would be.


>
>
>>
>> On Sun, Jun 25, 2017, 10:24 AM Serge Pavlov 
>> wrote:
>>
>>> 2017-06-25 0:52 GMT+07:00 David Blaikie :
>>>


 On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov 
 wrote:

> With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json
> is created in the directory
> /tools/clang/tools/extra/test/clang-tidy/Output,
>

 I'd be really surprised if this is the case - why would
 cmake/ninja/makefiles put the compile commands for the whole LLVM
 project/build in that somewhat random subdirectory?

>>>
>>> I was wrong, these json files were not created by cmake run but
>>> appear during test run. The file created by cmake is in the build root.
>>>
>>>


> but the tests from
> /llvm/tools/clang/tools/extra/test/clang-tidy run in the
> directory /tools/clang/tools/extra/test/clang-tidy, which 
> does
> not contain json files. So the test passes successfully. Ubuntu 16.04,
> cmake 3.5.1.
>

 Ah, perhaps you found a compile_commands for one of the test cases,
 not the one generated by CMake. CMake 3.5.1 doesn't support
 CMAKE_EXPORT_COMPILE_COMMANDS.

 It was added in 3.5.2, according to the documentation:
 https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html


>>>
>>> It was added in 2.8.5 according to documentation (
>>> http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems),
>>> at least the version 3.5.1 creates compilation databases.
>>>
>>> clang-tidy tries to create compilation database from source path,
>>> looking for compile_commands.json in the directory where provided source
>>> file resides and in all its parent directories. If source tree is in a
>>> subdirectory of build tree, then compile_commands.json in the build
>>> directory would be found and the test would fail. Is it your case?
>>>
>>>
> Thanks,
> --Serge
>
> 2017-06-24 9:42 GMT+07:00 David Blaikie :
>
>> Ping (+Manuel, perhaps he's got some ideas about this, given
>> background in the tooling & compilation database work, or could 
>> point this
>> to someone who does?)
>>
>>
>> On Thu, Jun 15, 2017 at 10:40 AM David Blaikie <
>> dblai...@gmail.com> wrote:
>>
>>>
>>> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>>>
>>> If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake
>>> (& have a sufficiently recent cmake), then CMake will generate a
>>> compile_commands.json in the root of the build tree. The test finds 
>>> this &
>>> fails, instead of finding no compilation database & succeeding.
>>>
>>> (to use this, you can then symlink from the root of the source
>>>

Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

[David Blaikie via cfe-commits]

I'm roughly where I was before, I think:

"In any case, it seems like it might make sense for you to upstream your
template naming change and put it under the PS4 debugger tuning option, and
put this change there too, once the motivation for it is in-tree. At that
point, while I'd be curious about the size tradeoff, it'd be essentially
academic."

Basically without the naming change in-tree, there seems to be a lack of
motivation for this change. I'd prefer/recommend/suggest keeping this
change wherever that change is. (so if the naming change is upstreamed
(conditional/behind the PS4 debugger tuning flag) then I agree this
could/should go in similarly)

- Dave

On Tue, Jul 11, 2017 at 10:34 AM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson updated this revision to Diff 106063.
> probinson added a comment.
>
> Refresh to current TOT, and ping.  Funny what you can find in a year-old
> to-do list
>
>
> https://reviews.llvm.org/D14358
>
> Files:
>   lib/CodeGen/CGDebugInfo.cpp
>   test/CodeGenCXX/debug-info-template-fwd-param.cpp
>   test/Modules/ExtDebugInfo.cpp
>
>
> Index: test/Modules/ExtDebugInfo.cpp
> ===
> --- test/Modules/ExtDebugInfo.cpp
> +++ test/Modules/ExtDebugInfo.cpp
> @@ -93,9 +93,13 @@
>  // CHECK-SAME: flags: DIFlagFwdDecl,
>  // CHECK-SAME: identifier:
> "_ZTSN8DebugCXX8TemplateIiNS_6traitsIi")
>
> -// This type isn't, however, even with standalone non-module debug info
> this
> -// type is a forward declaration.
> -// CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type, name:
> "traits",
> +// This type isn't, however, it is a template parameter type and so gets a
> +// forward declaration.
> +// CHECK: !DICompositeType(tag: DW_TAG_structure_type,
> +// CHECK-SAME: name: "traits",
> +// CHECK-SAME: scope: ![[NS]],
> +// CHECK-SAME: flags: DIFlagFwdDecl,
> +// CHECK-SAME: identifier: "_ZTSN8DebugCXX6traitsIiEE")
>
>  // This one isn't.
>  // CHECK: !DICompositeType(tag: DW_TAG_class_type,
> Index: test/CodeGenCXX/debug-info-template-fwd-param.cpp
> ===
> --- test/CodeGenCXX/debug-info-template-fwd-param.cpp
> +++ test/CodeGenCXX/debug-info-template-fwd-param.cpp
> @@ -0,0 +1,25 @@
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin
> -debug-info-kind=limited -emit-llvm -o - | FileCheck %s
> +// A forward declaration of a template should still have template
> parameters.
> +
> +template class A {
> +public:
> +  A(T val);
> +private:
> +  T x;
> +};
> +
> +struct B {
> +  A *p;
> +};
> +
> +B b;
> +
> +// CHECK:  !DICompositeType(tag: DW_TAG_class_type, name: "A int>"
> +// CHECK-SAME: flags: DIFlagFwdDecl
> +// CHECK-SAME: templateParams: [[PARAM_LIST:![0-9]*]]
> +// CHECK:  [[PARAM_LIST]] = !{[[PARAM:![0-9]*]]}
> +// CHECK:  [[PARAM]] = !DITemplateTypeParameter(name: "T",
> +// CHECK-SAME: type: [[CTYPE:![0-9]*]]
> +// CHECK:  [[CTYPE]] = !DIDerivedType(tag: DW_TAG_const_type
> +// CHECK-SAME: baseType: [[BTYPE:![0-9]*]]
> +// CHECK:  [[BTYPE]] = !DIBasicType(name: "int"
> Index: lib/CodeGen/CGDebugInfo.cpp
> ===
> --- lib/CodeGen/CGDebugInfo.cpp
> +++ lib/CodeGen/CGDebugInfo.cpp
> @@ -805,6 +805,10 @@
>llvm::DICompositeType *RetTy = DBuilder.createReplaceableCompositeType(
>getTagForRecord(RD), RDName, Ctx, DefUnit, Line, 0, Size, Align,
>llvm::DINode::FlagFwdDecl, FullName);
> +  if (const ClassTemplateSpecializationDecl *TSpecial =
> +  dyn_cast(RD))
> +DBuilder.replaceArrays(RetTy, llvm::DINodeArray(),
> +   CollectCXXTemplateParams(TSpecial, DefUnit));
>ReplaceMap.emplace_back(
>std::piecewise_construct, std::make_tuple(Ty),
>std::make_tuple(static_cast(RetTy)));
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D34896: Enable the new PM + SamlePGO + ThinLTO testing.

[David Blaikie via cfe-commits]

On Mon, Jul 10, 2017 at 10:58 AM Dehao Chen  wrote:

> This test was originally added in https://reviews.llvm.org/D34721 with
> clang change. It's kind of dup of the previous test
> (-check-prefix=SAMPLEPGO) in terms of testing the clang bits. But we
> want to make sure the new PM has the expected behavior.


Is the new PM behavior tested in LLVM tests?


> I guess it
> would be acceptable to remove one of them, but I'd prefer to remove
> the one with legacy PM. Let me know if you think I should do that.
>

Generally I'd leave it as-is (before this change) (my mental model/approach
is that changing/updating this test is like, for example, changing/adding
another test for C++ lambdas when/after a new implementation of
(fictional/notional) mem2reg was added - generally testing all these
combinations isn't practical, so as long as the pieces of functionality are
tested, that tends to be as far as it goes in the LLVM project (granted
there are a few places that are tricky - like these non-IR, purely
API-based, relationships between Clang & LLVM, where something approaching
an end-to-end test may be appropriate))

Not sure how other folks feel about such things & guess removing the old
test/upgrading it to test the experimental pass manager doesn't make it any
worse than the original test from my perspective. But it still feels like
it's not quite the right philosophy - if adding the test to cover the new
pass manager is important, then losing the coverage on the old scenario is
problematic... - if it isn't, then there's no need to add the new test
coverage at all & the test should remain as it was.

Anyway, whatever you think's best - just my 2c & not sure I'm describing it
so well.

- Dave


>
> Thanks,
> Dehao
>
> On Mon, Jul 10, 2017 at 9:45 AM, David Blaikie  wrote:
> > Does this test any code in Clang? (given the test is being committed
> without
> > any change in Clang, I'm guessing maybe not) - perhaps this test doesn't
> > belong in Clang's test suite?
> >
> > Looks like changes/functionality in LTOPreLinkDefaultPipeline are tested
> in
> > test/Other/new-pm-thinlto-defaults.ll at least?
> >
> > On Fri, Jun 30, 2017 at 10:05 AM Dehao Chen via Phabricator via
> cfe-commits
> >  wrote:
> >>
> >> danielcdh created this revision.
> >> Herald added subscribers: eraman, inglorion, mehdi_amini, sanjoy.
> >>
> >> This patch should be enabled after https://reviews.llvm.org/D34895
> >>
> >>
> >> https://reviews.llvm.org/D34896
> >>
> >> Files:
> >>   test/CodeGen/pgo-sample-thinlto-summary.c
> >>
> >>
> >> Index: test/CodeGen/pgo-sample-thinlto-summary.c
> >> ===
> >> --- test/CodeGen/pgo-sample-thinlto-summary.c
> >> +++ test/CodeGen/pgo-sample-thinlto-summary.c
> >> @@ -1,9 +1,7 @@
> >>  // RUN: %clang_cc1 -O2
> >> -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s
> -emit-llvm
> >> -o - 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
> >>  // RUN: %clang_cc1 -O2
> >> -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s
> -emit-llvm
> >> -flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
> >>  // RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager
> >> -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s
> -emit-llvm
> >> -o - 2>&1 | FileCheck %s -check-prefix=SAMPLEPGO
> >> -// FIXME: Run the following command once LTOPreLinkDefaultPipeline is
> >> -//customized.
> >> -// %clang_cc1 -O2 -fexperimental-new-pass-manager
> >> -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s
> -emit-llvm
> >> -flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
> >> +// RUN: %clang_cc1 -O2 -fexperimental-new-pass-manager
> >> -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s
> -emit-llvm
> >> -flto=thin -o - 2>&1 | FileCheck %s -check-prefix=THINLTO
> >>  // Checks if hot call is inlined by normal compile, but not inlined by
> >>  // thinlto compile.
> >>
> >>
> >>
> >> ___
> >> 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