[PATCH] D69237: Refactor getDeclAtPosition() to use SelectionTree + targetDecl()

[Nathan Ridge via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/XRefs.cpp:139
+// that constructor. FIXME(nridge): this should probably be handled in
+// targetDecl() itself.
+const CXXConstructorDecl *findCalledConstructor(const SelectionTree::Node *N) {

ilya-biryukov wrote:
> sammccall wrote:
> > nridge wrote:
> > > I would appreciate some tips on how we could handle this in 
> > > `targetDecl()`. Please see more specific comments below.
> > My thinking is basically:
> >  - C++ syntax is vague and doesn't give us great ways of referring directly 
> > to constructors.
> >  - there's value to simplicity, and I've found go-to-definition 
> > additionally finding implicit nodes to be confusing as often as useful. I 
> > think on balance and given the constraints of LSP, we should consider 
> > dropping this and having implicit references be returned by find-refs but 
> > not targetable by go-to-def/hover/etc. It's OK for simplicity of 
> > implementation to be a concern here.
> >  - the node that targets the constructor is the CXXConstructExpr. Treating 
> > the VarDecl conditionally as a reference to the constructor, while clever, 
> > seems like a hack. Ideally the fix is to make SelectionTree yield the 
> > CXXConstructExpr, not to change TargetDecl.
> >  - CXXConstructExpr is only sometimes implicit. SelectionTree should return 
> > it for the parens in `Foo()` or `Foo x()`. And ideally for the equals in 
> > `Foo x = {}`, though I think there's no CXXConstructExpr in the AST in that 
> > case :-(
> >  - When the AST modelling is bad (as it seems to be for some aspects 
> > CXXConstructExpr) we should consider accepting some glitches and trying to 
> > improve things in clang if they're important. Hacking around them will lead 
> > to inconsistencies between different clangd features.
> > 
> > The TL;DR is I think I'd be happy to drop this special case and try to make 
> > SelectionTree surface CXXConstructExpr more often, even if it changes some 
> > behavior.
> +1 to the idea of landing this and changing behavior.
> I don't think we're loosing much in terms of functionality and I personally 
> like the new code much more.
FWIW, I do find being able to get from a variable declaration to the invoked 
constructor to be very useful.

If the class has several constructors, there's no other easy way to determine 
which one is being invoked (only other thing I can think of is to perform "find 
references" on each constructor and see which one includes the variable 
declaration as a reference, which is a lot more tedious), and I think that's an 
important thing to be able to do (just like for named functions).

So I'd definitely like to keep this case working. However, I'd be fine with 
only having the parens or braces target the constructor. (That's still slightly 
annoying, as you have to place  the cursor more precisely, and it also may not 
be obvious to users, but at least there's a way to do it.) I'm also fine with 
changing the behaviour for now, and deferring constructor targeting to a 
follow-up, as there are other benefits this patch brings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69237



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

[PATCH] D67031: [Clang][Bundler] Error reporting improvements

[Sergey Dmitriev via Phabricator via cfe-commits]

sdmitriev added inline comments.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:133
   /// returned if there are no more bundles to be read.
-  virtual StringRef ReadBundleStart(MemoryBuffer ) = 0;
+  virtual Expected>
+  ReadBundleStart(MemoryBuffer ) = 0;

ABataev wrote:
> sdmitriev wrote:
> > sdmitriev wrote:
> > > ABataev wrote:
> > > > Do we really need an inner `Optional` here?
> > > The idea was to return `StringRef` with bundle name when we have still 
> > > have bundles and `None` when there are no more bundles in the file (BTW 
> > > comment has to be updated to describe this). But I can restore the old 
> > > convention where empty bundle name means 'no more bundles' in the file. 
> > > In terms of functionality that would be the same, though use of 
> > > `Optional<...>` makes intentions more explicit))
> > I have updated comment to describe the intended behavior.
> > @ABataev do you insist on removing inner `Optional<>` and restoring the 
> > current convention where empty string means the end of bundles in the file?
> The problem here is that `Expected` already handles the state and we have 
> inner `Optional` for the same reason. Can we reuse `Expected` to indicate 
> that there are no more bundles?
Well, `Expected` encodes two possible states (either Error or Value), but we 
need to encode three states - Error, Value or None. I do not have ideas how to 
do it without adding inner `Optional`. If you have, please share.


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

https://reviews.llvm.org/D67031



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

[PATCH] D69250: [ARM][AArch64] Implement __cls and __clsl intrinsics from ACLE

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added inline comments.



Comment at: clang/lib/Headers/arm_acle.h:150
+__clsl(unsigned long __t) {
+#if __SIZEOF_LONG__ == 4
+  return __builtin_arm_cls(__t);

vhscampos wrote:
> compnerd wrote:
> > I don't see a pattern match for the `cls64` on ARM32, would that not fail 
> > to lower?
> Yes. However, for now, I am not enabling support for `cls64` on ARM32 as it 
> is not done yet.
Is the difference not just the parameter type?  I think that implementing it 
should be a trivial change to the existing implementation.  Is there a reason 
that you are not implementing that?



Comment at: clang/lib/Headers/arm_acle.h:155
+#endif
+}
+

vhscampos wrote:
> compnerd wrote:
> > Should we have a `__clsll` extension, otherwise these two are the same in 
> > LLP64?  I'm thinking about the LLP64 environments, where `long` and `long 
> > long` are different (32-bit vs 64-bit).
> ACLE does provide a `long long` version of `cls` called `__clsll`. But since 
> the support for `cls64` on Arm32 is not done yet, I decided not to write 
> support for `__clsll`. If I did, it would work for 64-bit but not for 32-bit.
> 
> Please let me know what you think.
clang supports Windows where `long` is 4-bytes even on 64-bit targets, and this 
means that this doesn't work for that target.  I think that we need to add 
`__clsll` so that 64-bit ARM at least is covered.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69250



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

[PATCH] D51899: Remove extraneous ".a" suffix from baremetal clang_rt.builtins when compiling for baremetal.

[Saleem Abdulrasool via Phabricator via cfe-commits]

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

This is not a linker specific thing - the library name that we are passing is 
misnamed - the parameter should be `-l`  which will become `lib` 
` [`.so` | `.a`].  If we want to guarantee the static library, 
using `-static`, `-nostatic` around the library is more appropriate.


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

https://reviews.llvm.org/D51899



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

[PATCH] D69318: [analyzer] Add SufficientSizeArrayIndexingChecker

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added reviewers: baloghadamsoftware, xazax.hun, rnkovacs, Charusso, 
dcoughlin.
Szelethus added a comment.

In D69318#1718220 , @gamesh411 wrote:

> Please feel free to add more reviewers.


Here you go!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69318



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

[PATCH] D69184: [libTooling] Introduce general combinator for fixed-value `MatchConsumer`s.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

In D69184#1715256 , @gribozavr wrote:

> What are the use cases for non-text values?
>
> I like the name `text` much better... If the name conflict is the issue, I 
> think you could rename it to `toText` -- it would even read more fluently 
> `change(toText("abc"))`, also making it obvious that we are not changing *the 
> text abc*, but we are changing the code to say "abc".


Another example use is: 
https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Tooling/Transformer/RangeSelector.h#L29-L32,
 although I must admit that I hadn't thought of that before this patch.  It's 
just the natural generalization (it's actually the K combinator form SKI fame). 
 So, I haven't thought about other examples -- the primary motivation was just 
the naming.

That said, I'm not sure about `toText` because I consider the "to" as implicit 
in `change`. In fact, it might be a good idea to rename `change` to `changeTo` 
(WDYT?).  What about any of `asText`, `textMsg`, `textMessage`? (I realize the 
unfortunate pun in the last two, but not sure that's worth caring about).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69184



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

[clang] d052a57 - [c++2a] Allow comparison functions to be explicitly defaulted.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2019-10-22T18:16:17-07:00
New Revision: d052a578de58cbbb638cbe2dba05242d1ff443b9

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

LOG: [c++2a] Allow comparison functions to be explicitly defaulted.

This adds some initial syntactic checking that only the appropriate
function signatures can be defaulted. No implicit definitions are
generated yet.

Added: 
clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
clang/test/CXX/class/class.compare/class.eq/p1.cpp
clang/test/CXX/class/class.compare/class.rel/p1.cpp

Modified: 
clang/include/clang/AST/Decl.h
clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/AST/Decl.cpp
clang/lib/Parse/ParseDecl.cpp
clang/lib/Parse/ParseDeclCXX.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/test/CXX/dcl.decl/dcl.fct.def/dcl.fct.def.default/p1.cpp
clang/test/Parser/cxx0x-decl.cpp
clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
clang/test/SemaCXX/cxx17-compat.cpp

Removed: 




diff  --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index ce674e09c44d..b3e7a570fd6d 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -59,6 +59,7 @@ class EnumDecl;
 class Expr;
 class FunctionTemplateDecl;
 class FunctionTemplateSpecializationInfo;
+class FunctionTypeLoc;
 class LabelStmt;
 class MemberSpecializationInfo;
 class Module;
@@ -2362,6 +2363,12 @@ class FunctionDecl : public DeclaratorDecl,
   /// parameters have default arguments (in C++).
   unsigned getMinRequiredArguments() const;
 
+  /// Find the source location information for how the type of this function
+  /// was written. May be absent (for example if the function was declared via
+  /// a typedef) and may contain a 
diff erent type from that of the function
+  /// (for example if the function type was adjusted by an attribute).
+  FunctionTypeLoc getFunctionTypeLoc() const;
+
   QualType getReturnType() const {
 return getType()->castAs()->getReturnType();
   }

diff  --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index 6018c1417789..7a416c282e3d 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -87,7 +87,8 @@ def warn_cxx98_compat_variadic_templates :
   Warning<"variadic templates are incompatible with C++98">,
   InGroup, DefaultIgnore;
 def err_default_special_members : Error<
-  "only special member functions may be defaulted">;
+  "only special member functions %select{|and comparison operators }0"
+  "may be defaulted">;
 def err_deleted_non_function : Error<
   "only functions can have deleted definitions">;
 def err_module_not_found : Error<"module '%0' not found">, DefaultFatal;

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d802a92c42c0..f7b98bb9ea86 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8099,6 +8099,31 @@ def note_vbase_moved_here : Note<
   "%select{%1 is a virtual base class of base class %2 declared here|"
   "virtual base class %1 declared here}0">;
 
+// C++20 defaulted comparisons
+// This corresponds to values of Sema::DefaultedComparisonKind.
+def select_defaulted_comparison_kind : TextSubstitution<
+  "%select{|equality|three-way|equality|relational}0 comparison "
+  "operator">;
+def ext_defaulted_comparison : ExtWarn<
+  "defaulted comparison operators are a C++20 extension">, InGroup;
+def warn_cxx17_compat_defaulted_comparison : Warning<
+  "defaulted comparison operators are incompatible with C++ standards "
+  "before C++20">, InGroup, DefaultIgnore;
+def err_defaulted_comparison_template : Error<
+  "comparison operator template cannot be defaulted">;
+def err_defaulted_comparison_out_of_class : Error<
+  "%sub{select_defaulted_comparison_kind}0 can only be defaulted in a class "
+  "definition">;
+def err_defaulted_comparison_param : Error<
+  "invalid parameter type for defaulted 
%sub{select_defaulted_comparison_kind}0"
+  "%
diff {; found $, expected $|}1,2">;
+def err_defaulted_comparison_non_const : Error<
+  "defaulted member %sub{select_defaulted_comparison_kind}0 must be "
+  "const-qualified">;
+def err_defaulted_comparison_return_type_not_bool : Error<
+  "return type for defaulted %sub{select_defaulted_comparison_kind}0 "
+  "must be 'bool', not %1">;
+
 def ext_implicit_exception_spec_mismatch : ExtWarn<
   "function previously declared with an 

[PATCH] D69292: Proposal to add -Wtautological-compare to -Wall

[Nico Weber via Phabricator via cfe-commits]

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

Abstractly this lgtm. Do you have any data on true / false positive rates?


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

https://reviews.llvm.org/D69292



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

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[pre-merge checks [bot] via Phabricator via cfe-commits]

merge_guards_bot added a comment.

Build result: fail - 59521 tests passed, 1 failed and 805 were skipped.

  failed: LLVM.tools/llvm-ar/mri-utf8.test

Log files: cmake-log.txt 
, 
ninja_check_all-log.txt 
, 
CMakeCache.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241



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

[PATCH] D69221: [clang][darwin] Fix search path logic for C_INCLUDE_DIRS

[Louis Dionne via Phabricator via cfe-commits]

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

Good find! The following drivers (at least) appear to have the same problem:

  clang/lib/Driver/ToolChains/WebAssembly.cpp:236
  clang/lib/Driver/ToolChains/Solaris.cpp:247
  clang/lib/Driver/ToolChains/Linux.cpp:677
  clang/lib/Driver/ToolChains/Hurd.cpp:148
  clang/lib/Driver/ToolChains/Fuchsia.cpp:289
  clang/lib/Driver/ToolChains/Darwin.cpp:1862

This makes me wonder whether `C_INCLUDE_DIRS` is useful at all. Does anybody 
use it? Also, if we keep `C_INCLUDE_DIRS`, it would be nice to add a test for 
this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69221



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

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Okay.  If the optimizer cannot correctly handle a mix of constrained and 
unconstrained FP operations, then the optimizer should protect itself, either 
by refusing to inline across such boundaries or by adding constraints as 
necessary before inlining.  If it does that, I don't think it's particularly 
appropriate for the frontend to warn about the combination of constrained FP 
and supposedly inlining-related attributes (which only really seems true of 
`always_inline`).  We should just mention in the documentation that this isn't 
particularly performant at the moment.

I feel quite confident that we can solve the engineering problem of efficiently 
figuring out that there's a constrained scope somewhere in a function and 
therefore we need constrained intrinsics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69272



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

Re: r374288 - Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)"

[Michael Kruse via cfe-commits]

Am Mo., 21. Okt. 2019 um 23:44 Uhr schrieb Jordan Rupprecht
:
> At any rate, it sounds like this is not a codegen bug at all, but just an 
> over-eager warning?

That interpretation is different from mine. Codgen emits the following
from vectorize(disable)

!4 = !{!"llvm.loop.vectorize.enable", i1 true}

which is is not what I'd expect.

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

Re: r374202 - [ObjC generics] Fix not inheriting type bounds in categories/extensions.

[Hans Wennborg via cfe-commits]

I've gone ahead and reverted in 4c539e8.

On Tue, Oct 22, 2019 at 10:43 AM Hans Wennborg  wrote:
>
> Since it looks suspicious, can we revert your change in the meantime?
> We have a number of instances where this fires, so it's not just one
> place we'd need to work around it.
>
> On Mon, Oct 21, 2019 at 6:39 PM Volodymyr Sapsai  wrote:
> >
> > That error looks strange and confusing to me too. My guess is that my 
> > change exposed some bug with literals. I’ve tried
> >
> >  NSDictionary* videoSettingsDictionary2 = [NSDictionary
> > dictionaryWithObject:@(best_fourcc)
> > forKey:(id)kCVPixelBufferPixelFormatTypeKey];
> >
> > and
> >
> > @interface GenericTest  : NSObject
> > - (void)test:(const KeyType  _Nonnull)key;
> > @end
> >
> > void anotherTest(GenericTest *t) {
> >   [t test:(id)kCVPixelBufferPixelFormatTypeKey];
> > }
> >
> > But they didn’t trigger the error. I need more time to investigate the 
> > issue but in the meantime you can fix the build by casting to the 
> > corresponding constant type, something like
> >
> >   (NSString *)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc)
> >
> > Thanks,
> > Volodymyr
> >
> > > On Oct 21, 2019, at 14:37, Hans Wennborg  wrote:
> > >
> > > Hi Volodymyr,
> > >
> > > This broke the Chrome build in an interesting way. Here's a reduced repro:
> > >
> > >
> > > $ cat /tmp/a.mm
> > > #import 
> > >
> > > void f(int width, int height) {
> > >  FourCharCode best_fourcc = kCMPixelFormat_422YpCbCr8_yuvs;
> > >  NSDictionary* videoSettingsDictionary = @{
> > >(id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
> > >  };
> > > }
> > >
> > > $ build.release/bin/clang++ -isysroot
> > > /work/chromium/src/build/mac_files/xcode_binaries/Contents/Developer/Platforms/MacOSX.platform/Developer/SDK
> > > s/MacOSX10.14.sdk -c /tmp/a.mm
> > >
> > > /tmp/a.mm:6:5: error: cannot initialize a parameter of type
> > > 'KeyType  _Nonnull const' (aka 'const id') with an rvalue
> > > of type 'id'
> > >(id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
> > >^~~~
> > > 1 error generated.
> > >
> > >
> > > To me, the "cannot initialize a parameter of type [nanana] (aka 'const
> > > id') with an rvalue of type 'id'" message looks strange, but I'm not
> > > an Obj-C expert. Is this expected behaviour, and if so how should we
> > > change our code?
> > >
> > > Thanks,
> > > Hans
> > >
> > > On Wed, Oct 9, 2019 at 12:26 PM Volodymyr Sapsai via cfe-commits
> > >  wrote:
> > >>
> > >> Author: vsapsai
> > >> Date: Wed Oct  9 12:29:13 2019
> > >> New Revision: 374202
> > >>
> > >> URL: http://llvm.org/viewvc/llvm-project?rev=374202=rev
> > >> Log:
> > >> [ObjC generics] Fix not inheriting type bounds in categories/extensions.
> > >>
> > >> When a category/extension doesn't repeat a type bound, corresponding
> > >> type parameter is substituted with `id` when used as a type argument. As
> > >> a result, in the added test case it was causing errors like
> > >>
> > >>> type argument 'T' (aka 'id') does not satisfy the bound 
> > >>> ('id') of type parameter 'T'
> > >>
> > >> We are already checking that type parameters should be consistent
> > >> everywhere (see `checkTypeParamListConsistency`) and update
> > >> `ObjCTypeParamDecl` to have correct underlying type. And when we use the
> > >> type parameter as a method return type or a method parameter type, it is
> > >> substituted to the bounded type. But when we use the type parameter as a
> > >> type argument, we check `ObjCTypeParamType` that ignores the updated
> > >> underlying type and remains `id`.
> > >>
> > >> Fix by desugaring `ObjCTypeParamType` to the underlying type, the same
> > >> way we are doing with `TypedefType`.
> > >>
> > >> rdar://problem/54329242
> > >>
> > >> Reviewers: erik.pilkington, ahatanak
> > >>
> > >> Reviewed By: erik.pilkington
> > >>
> > >> Subscribers: jkorous, dexonsmith, ributzka, cfe-commits
> > >>
> > >> Differential Revision: https://reviews.llvm.org/D66696
> > >>
> > >> Modified:
> > >>cfe/trunk/include/clang/AST/Type.h
> > >>cfe/trunk/lib/AST/Type.cpp
> > >>cfe/trunk/test/SemaObjC/parameterized_classes_subst.m
> > >>
> > >> Modified: cfe/trunk/include/clang/AST/Type.h
> > >> URL: 
> > >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=374202=374201=374202=diff
> > >> ==
> > >> --- cfe/trunk/include/clang/AST/Type.h (original)
> > >> +++ cfe/trunk/include/clang/AST/Type.h Wed Oct  9 12:29:13 2019
> > >> @@ -5569,7 +5569,7 @@ class ObjCTypeParamType : public Type,
> > >>
> > >> public:
> > >>   bool isSugared() const { return true; }
> > >> -  QualType desugar() const { return getCanonicalTypeInternal(); }
> > >> +  QualType desugar() const;
> > >>
> > >>   static bool classof(const Type *T) {
> > >> return T->getTypeClass() == ObjCTypeParam;
> > >>
> > >> Modified: cfe/trunk/lib/AST/Type.cpp
> > >> URL: 
> > >> 

[PATCH] D69322: [hip][cuda] Enable extended lambda support on Windows.

[Michael Liao via Phabricator via cfe-commits]

hliao created this revision.
hliao added reviewers: rsmith, rjmccall, tra, yaxunl.
Herald added a reviewer: martong.
Herald added a reviewer: shafik.
Herald added subscribers: cfe-commits, erik.pilkington.
Herald added a project: clang.

- On Windows, extended lambda has extra issues due to the numbering schemes are 
different between the host compilation (Microsoft C++ ABI) and the device 
compilation (Itanium C++ ABI. Additional device side lambda number is required 
per lambda for the host compilation to correctly mangle the device-side lambda 
name.
- A hybrid numbering context `MSHIPNumberingContext` is introduced to number a 
lambda for both host- and device-compilations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69322

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/Mangle.h
  clang/include/clang/AST/MangleNumberingContext.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/CXXABI.h
  clang/lib/AST/ItaniumCXXABI.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftCXXABI.cpp
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGenCUDA/unnamed-types.cu

Index: clang/test/CodeGenCUDA/unnamed-types.cu
===
--- clang/test/CodeGenCUDA/unnamed-types.cu
+++ clang/test/CodeGenCUDA/unnamed-types.cu
@@ -1,12 +1,17 @@
 // RUN: %clang_cc1 -std=c++11 -x hip -triple x86_64-linux-gnu -aux-triple amdgcn-amd-amdhsa -emit-llvm %s -o - | FileCheck %s --check-prefix=HOST
+// RUN: %clang_cc1 -std=c++11 -x hip -triple x86_64-pc-windows-msvc -aux-triple amdgcn-amd-amdhsa -emit-llvm %s -o - | FileCheck %s --check-prefix=MSVC
 // RUN: %clang_cc1 -std=c++11 -x hip -triple amdgcn-amd-amdhsa -fcuda-is-device -emit-llvm %s -o - | FileCheck %s --check-prefix=DEVICE
 
 #include "Inputs/cuda.h"
 
 // HOST: @0 = private unnamed_addr constant [43 x i8] c"_Z2k0IZZ2f1PfENKUlS0_E_clES0_EUlfE_EvS0_T_\00", align 1
+// HOST: @1 = private unnamed_addr constant [60 x i8] c"_Z2k1IZ2f1PfEUlfE_Z2f1S0_EUlffE_Z2f1S0_EUlfE0_EvS0_T_T0_T1_\00", align 1
+// Check that, on MSVC, the same device kernel mangling name is generated.
+// MSVC: @0 = private unnamed_addr constant [43 x i8] c"_Z2k0IZZ2f1PfENKUlS0_E_clES0_EUlfE_EvS0_T_\00", align 1
+// MSVC: @1 = private unnamed_addr constant [60 x i8] c"_Z2k1IZ2f1PfEUlfE_Z2f1S0_EUlffE_Z2f1S0_EUlfE0_EvS0_T_T0_T1_\00", align 1
 
 __device__ float d0(float x) {
-  return [](float x) { return x + 2.f; }(x);
+  return [](float x) { return x + 1.f; }(x);
 }
 
 __device__ float d1(float x) {
@@ -14,11 +19,21 @@
 }
 
 // DEVICE: amdgpu_kernel void @_Z2k0IZZ2f1PfENKUlS0_E_clES0_EUlfE_EvS0_T_(
+// DEVICE: define internal float @_ZZZ2f1PfENKUlS_E_clES_ENKUlfE_clEf(
 template 
 __global__ void k0(float *p, F f) {
   p[0] = f(p[0]) + d0(p[1]) + d1(p[2]);
 }
 
+// DEVICE: amdgpu_kernel void @_Z2k1IZ2f1PfEUlfE_Z2f1S0_EUlffE_Z2f1S0_EUlfE0_EvS0_T_T0_T1_(
+// DEVICE: define internal float @_ZZ2f1PfENKUlfE_clEf(
+// DEVICE: define internal float @_ZZ2f1PfENKUlffE_clEff(
+// DEVICE: define internal float @_ZZ2f1PfENKUlfE0_clEf(
+template 
+__global__ void k1(float *p, F0 f0, F1 f1, F2 f2) {
+  p[0] = f0(p[0]) + f1(p[1], p[2]) + f2(p[3]);
+}
+
 void f0(float *p) {
   [](float *p) {
 *p = 1.f;
@@ -29,11 +44,17 @@
 // linkages are still required to keep the original `internal` linkage.
 
 // HOST: define internal void @_ZZ2f1PfENKUlS_E_clES_(
-// DEVICE: define internal float @_ZZZ2f1PfENKUlS_E_clES_ENKUlfE_clEf(
 void f1(float *p) {
   [](float *p) {
-k0<<<1,1>>>(p, [] __device__ (float x) { return x + 1.f; });
+k0<<<1,1>>>(p, [] __device__ (float x) { return x + 3.f; });
   }(p);
+  k1<<<1,1>>>(p,
+  [] __device__ (float x) { return x + 4.f; },
+  [] __device__ (float x, float y) { return x * y; },
+  [] __device__ (float x) { return x + 5.f; });
 }
 // HOST: @__hip_register_globals
 // HOST: __hipRegisterFunction{{.*}}@_Z2k0IZZ2f1PfENKUlS0_E_clES0_EUlfE_EvS0_T_{{.*}}@0
+// HOST: __hipRegisterFunction{{.*}}@_Z2k1IZ2f1PfEUlfE_Z2f1S0_EUlffE_Z2f1S0_EUlfE0_EvS0_T_T0_T1_{{.*}}@1
+// MSVC: __hipRegisterFunction{{.*}}@"??$k0@V@?0???R1?0??f1@@YAXPEAM@Z@QEBA@0@Z@@@YAXPEAMV@?0???R0?0??f1@@YAX0@Z@QEBA@0@Z@@Z{{.*}}@0
+// MSVC: __hipRegisterFunction{{.*}}@"??$k1@V@?0??f1@@YAXPEAM@Z@V@?0??2@YAX0@Z@V@?0??2@YAX0@Z@@@YAXPEAMV@?0??f1@@YAX0@Z@V@?0??1@YAX0@Z@V@?0??1@YAX0@Z@@Z{{.*}}@1
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -6226,6 +6226,7 @@
 Record->push_back(Lambda.NumExplicitCaptures);
 Record->push_back(Lambda.HasKnownInternalLinkage);
 Record->push_back(Lambda.ManglingNumber);
+Record->push_back(Lambda.DeviceManglingNumber);
 

[clang] 4c539e8 - Revert r374202"[ObjC generics] Fix not inheriting type bounds in categories/extensions."

[Hans Wennborg via cfe-commits]

Author: Hans Wennborg
Date: 2019-10-22T22:39:01+02:00
New Revision: 4c539e8da1b3de38a53ef3f7497f5c45a3243b61

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

LOG: Revert r374202"[ObjC generics] Fix not inheriting type bounds in 
categories/extensions."

This introduced new errors, see below. Reverting until that can be investigated
properly.

  #import 

  void f(int width, int height) {
FourCharCode best_fourcc = kCMPixelFormat_422YpCbCr8_yuvs;
NSDictionary* videoSettingsDictionary = @{
  (id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
};
  }

  $ clang++ -c /tmp/a.mm

  /tmp/a.mm:6:5: error: cannot initialize a parameter of type
  'KeyType  _Nonnull const' (aka 'const id') with an rvalue
  of type 'id'
  (id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
  ^~~~
  1 error generated.

> When a category/extension doesn't repeat a type bound, corresponding
> type parameter is substituted with `id` when used as a type argument. As
> a result, in the added test case it was causing errors like
>
> > type argument 'T' (aka 'id') does not satisfy the bound ('id') 
> > of type parameter 'T'
>
> We are already checking that type parameters should be consistent
> everywhere (see `checkTypeParamListConsistency`) and update
> `ObjCTypeParamDecl` to have correct underlying type. And when we use the
> type parameter as a method return type or a method parameter type, it is
> substituted to the bounded type. But when we use the type parameter as a
> type argument, we check `ObjCTypeParamType` that ignores the updated
> underlying type and remains `id`.
>
> Fix by desugaring `ObjCTypeParamType` to the underlying type, the same
> way we are doing with `TypedefType`.
>
> rdar://problem/54329242
>
> Reviewers: erik.pilkington, ahatanak
>
> Reviewed By: erik.pilkington
>
> Subscribers: jkorous, dexonsmith, ributzka, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D66696

Added: 


Modified: 
clang/include/clang/AST/Type.h
clang/lib/AST/Type.cpp
clang/test/SemaObjC/parameterized_classes_subst.m

Removed: 




diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index c9238e952101..ecbbd73e19fb 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -5569,7 +5569,7 @@ class ObjCTypeParamType : public Type,
 
 public:
   bool isSugared() const { return true; }
-  QualType desugar() const;
+  QualType desugar() const { return getCanonicalTypeInternal(); }
 
   static bool classof(const Type *T) {
 return T->getTypeClass() == ObjCTypeParam;

diff  --git a/clang/lib/AST/Type.cpp b/clang/lib/AST/Type.cpp
index 4d54ea1061ed..4fed5b410b17 100644
--- a/clang/lib/AST/Type.cpp
+++ b/clang/lib/AST/Type.cpp
@@ -663,10 +663,6 @@ ObjCTypeParamType::ObjCTypeParamType(const 
ObjCTypeParamDecl *D,
   initialize(protocols);
 }
 
-QualType ObjCTypeParamType::desugar() const {
-  return getDecl()->getUnderlyingType();
-}
-
 ObjCObjectType::ObjCObjectType(QualType Canonical, QualType Base,
ArrayRef typeArgs,
ArrayRef protocols,

diff  --git a/clang/test/SemaObjC/parameterized_classes_subst.m 
b/clang/test/SemaObjC/parameterized_classes_subst.m
index b6d884760d29..d14a6e9deb40 100644
--- a/clang/test/SemaObjC/parameterized_classes_subst.m
+++ b/clang/test/SemaObjC/parameterized_classes_subst.m
@@ -467,17 +467,3 @@ - (void)mapUsingBlock:(id (^)(id))block {
 - (void)mapUsingBlock2:(id)block { // expected-warning{{conflicting parameter 
types in implementation}}
 }
 @end
-
-// --
-// Use a type parameter as a type argument.
-// --
-// Type bounds in a category/extension are omitted. rdar://problem/54329242
-@interface ParameterizedContainer>
-- (ParameterizedContainer *)inInterface;
-@end
-@interface ParameterizedContainer (Cat)
-- (ParameterizedContainer *)inCategory;
-@end
-@interface ParameterizedContainer ()
-- (ParameterizedContainer *)inExtension;
-@end



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

[clang] 1c98ff4 - Fix name of warn_ignored_hip_only_option

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2019-10-22T16:36:28-04:00
New Revision: 1c98ff49a30b88a2601b92e8702ff2058c4fc226

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

LOG: Fix name of warn_ignored_hip_only_option

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index 40911957d6fe..6018c1417789 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -305,7 +305,7 @@ def err_openclcxx_not_supported : Error<
   "'%0' is not supported in C++ for OpenCL">;
 
 // HIP
-def warn_ignore_hip_only_option : Warning<
+def warn_ignored_hip_only_option : Warning<
   "'%0' is ignored since it is only supported for HIP">,
   InGroup;
 

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 767a0718b24c..f6e6f71b2805 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -2532,7 +2532,7 @@ static void ParseLangArgs(LangOptions , ArgList 
, InputKind IK,
 if (Opts.HIP)
   Opts.GPUAllowDeviceInit = 1;
 else
-  Diags.Report(diag::warn_ignore_hip_only_option)
+  Diags.Report(diag::warn_ignored_hip_only_option)
   << Args.getLastArg(OPT_fgpu_allow_device_init)->getAsString(Args);
   }
   Opts.HIPUseNewLaunchAPI = Args.hasArg(OPT_fhip_new_launch_api);



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

[PATCH] D67185: [RISCV] Add support for -ffixed-xX flags

[Simon Cook via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGaed9d6d64a38: [RISCV] Add support for -ffixed-xX flags 
(authored by simoncook).

Changed prior to commit:
  https://reviews.llvm.org/D67185?vs=223005=226081#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67185

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-fixed-x-register.c
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp
  llvm/lib/Target/RISCV/RISCVRegisterInfo.h
  llvm/lib/Target/RISCV/RISCVSubtarget.cpp
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/reserved-reg-errors.ll
  llvm/test/CodeGen/RISCV/reserved-regs.ll

Index: llvm/test/CodeGen/RISCV/reserved-regs.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/reserved-regs.ll
@@ -0,0 +1,130 @@
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x3 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X3
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x3 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X3
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x4 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X4
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x4 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X4
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x5 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X5
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x5 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X5
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x6 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X6
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x6 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X6
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x7 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X7
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x7 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X7
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x8 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X8
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x8 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X8
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x9 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X9
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x9 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X9
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x10 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X10
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x10 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X10
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x11 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X11
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x11 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X11
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x12 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X12
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x12 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X12
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x13 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X13
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x13 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X13
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x14 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X14
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x14 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X14
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x15 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X15
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x15 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X15
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x16 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X16
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x16 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X16
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x17 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X17
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x17 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X17
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x18 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X18
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x18 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X18
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x19 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X19
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x19 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X19
+; RUN: llc -mtriple=riscv32 -mattr=+reserve-x20 -verify-machineinstrs < %s | FileCheck %s -check-prefix=X20
+; RUN: llc -mtriple=riscv64 -mattr=+reserve-x20 

[clang] aed9d6d - [RISCV] Add support for -ffixed-xX flags

[Simon Cook via cfe-commits]

Author: Simon Cook
Date: 2019-10-22T21:25:01+01:00
New Revision: aed9d6d64a38d155cd09232da5640b5ade069bd9

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

LOG: [RISCV] Add support for -ffixed-xX flags

This adds support for reserving GPRs such that the compiler will not
choose a register for register allocation. The implementation follows
the same design as for AArch64; each reserved register becomes a target
feature and used for getting the reserved registers for a given
MachineFunction. The backend checks that it does not need to write to
any reserved register; if it does a relevant error is generated.

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

Added: 
clang/test/Driver/riscv-fixed-x-register.c
llvm/test/CodeGen/RISCV/reserved-reg-errors.ll
llvm/test/CodeGen/RISCV/reserved-regs.ll

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Arch/RISCV.cpp
llvm/lib/Target/RISCV/RISCV.td
llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
llvm/lib/Target/RISCV/RISCVISelLowering.cpp
llvm/lib/Target/RISCV/RISCVISelLowering.h
llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp
llvm/lib/Target/RISCV/RISCVRegisterInfo.h
llvm/lib/Target/RISCV/RISCVSubtarget.cpp
llvm/lib/Target/RISCV/RISCVSubtarget.h

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 4db7cd844d15..20d7c241a937 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2263,9 +2263,9 @@ def mfix_cortex_a53_835769 : Flag<["-"], 
"mfix-cortex-a53-835769">,
 def mno_fix_cortex_a53_835769 : Flag<["-"], "mno-fix-cortex-a53-835769">,
   Group,
   HelpText<"Don't workaround Cortex-A53 erratum 835769 (AArch64 only)">;
-foreach i = {1-7,9-15,18,20-28} in
-  def ffixed_x#i : Flag<["-"], "ffixed-x"#i>, Group,
-HelpText<"Reserve the "#i#" register (AArch64 only)">;
+foreach i = {1-31} in
+  def ffixed_x#i : Flag<["-"], "ffixed-x"#i>, Group,
+HelpText<"Reserve the "#i#" register (AArch64/RISC-V only)">;
 
 foreach i = {8-15,18} in
   def fcall_saved_x#i : Flag<["-"], "fcall-saved-x"#i>, 
Group,

diff  --git a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp 
b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
index 624788a5874e..a26f723a5073 100644
--- a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -367,6 +367,70 @@ void riscv::getRISCVTargetFeatures(const Driver , const 
llvm::Triple ,
   if (MArch.hasValue() && !getArchFeatures(D, *MArch, Features, Args))
 return;
 
+  // Handle features corresponding to "-ffixed-X" options
+  if (Args.hasArg(options::OPT_ffixed_x1))
+Features.push_back("+reserve-x1");
+  if (Args.hasArg(options::OPT_ffixed_x2))
+Features.push_back("+reserve-x2");
+  if (Args.hasArg(options::OPT_ffixed_x3))
+Features.push_back("+reserve-x3");
+  if (Args.hasArg(options::OPT_ffixed_x4))
+Features.push_back("+reserve-x4");
+  if (Args.hasArg(options::OPT_ffixed_x5))
+Features.push_back("+reserve-x5");
+  if (Args.hasArg(options::OPT_ffixed_x6))
+Features.push_back("+reserve-x6");
+  if (Args.hasArg(options::OPT_ffixed_x7))
+Features.push_back("+reserve-x7");
+  if (Args.hasArg(options::OPT_ffixed_x8))
+Features.push_back("+reserve-x8");
+  if (Args.hasArg(options::OPT_ffixed_x9))
+Features.push_back("+reserve-x9");
+  if (Args.hasArg(options::OPT_ffixed_x10))
+Features.push_back("+reserve-x10");
+  if (Args.hasArg(options::OPT_ffixed_x11))
+Features.push_back("+reserve-x11");
+  if (Args.hasArg(options::OPT_ffixed_x12))
+Features.push_back("+reserve-x12");
+  if (Args.hasArg(options::OPT_ffixed_x13))
+Features.push_back("+reserve-x13");
+  if (Args.hasArg(options::OPT_ffixed_x14))
+Features.push_back("+reserve-x14");
+  if (Args.hasArg(options::OPT_ffixed_x15))
+Features.push_back("+reserve-x15");
+  if (Args.hasArg(options::OPT_ffixed_x16))
+Features.push_back("+reserve-x16");
+  if (Args.hasArg(options::OPT_ffixed_x17))
+Features.push_back("+reserve-x17");
+  if (Args.hasArg(options::OPT_ffixed_x18))
+Features.push_back("+reserve-x18");
+  if (Args.hasArg(options::OPT_ffixed_x19))
+Features.push_back("+reserve-x19");
+  if (Args.hasArg(options::OPT_ffixed_x20))
+Features.push_back("+reserve-x20");
+  if (Args.hasArg(options::OPT_ffixed_x21))
+Features.push_back("+reserve-x21");
+  if (Args.hasArg(options::OPT_ffixed_x22))
+Features.push_back("+reserve-x22");
+  if (Args.hasArg(options::OPT_ffixed_x23))
+Features.push_back("+reserve-x23");
+  if (Args.hasArg(options::OPT_ffixed_x24))
+Features.push_back("+reserve-x24");
+  if (Args.hasArg(options::OPT_ffixed_x25))
+Features.push_back("+reserve-x25");
+  if 

[PATCH] D69268: [HIP] Add option -fgpu-allow-device-init

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rG68f5ca4e19c1: [HIP] Add option -fgpu-allow-device-init 
(authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D69268?vs=226044=226078#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69268

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaCUDA.cpp
  clang/test/CodeGenCUDA/device-init-fun.cu
  clang/test/Frontend/warn-device-init-fun.cu

Index: clang/test/Frontend/warn-device-init-fun.cu
===
--- /dev/null
+++ clang/test/Frontend/warn-device-init-fun.cu
@@ -0,0 +1,8 @@
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang_cc1 -triple nvptx -fcuda-is-device \
+// RUN: -fgpu-allow-device-init \
+// RUN:  %s 2>&1 | FileCheck %s
+
+// CHECK: warning: '-fgpu-allow-device-init' is ignored since it is only supported for HIP
+
Index: clang/test/CodeGenCUDA/device-init-fun.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/device-init-fun.cu
@@ -0,0 +1,19 @@
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -triple amdgcn -fcuda-is-device -std=c++11 \
+// RUN: -fgpu-allow-device-init -x hip \
+// RUN: -fno-threadsafe-statics -emit-llvm -o - %s \
+// RUN: | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// CHECK: define internal amdgpu_kernel void @_GLOBAL__sub_I_device_init_fun.cu() #[[ATTR:[0-9]*]]
+// CHECK: attributes #[[ATTR]] = {{.*}}"device-init"
+
+__device__ void f();
+
+struct A {
+  __device__ A() { f(); }
+};
+
+__device__ A a;
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -492,6 +492,8 @@
   const Expr *Init = VD->getInit();
   if (VD->hasAttr() || VD->hasAttr() ||
   VD->hasAttr()) {
+if (LangOpts.GPUAllowDeviceInit)
+  return;
 assert(!VD->isStaticLocal() || VD->hasAttr());
 bool AllowedInit = false;
 if (const CXXConstructExpr *CE = dyn_cast(Init))
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -2528,6 +2528,13 @@
 Opts.CUDADeviceApproxTranscendentals = 1;
 
   Opts.GPURelocatableDeviceCode = Args.hasArg(OPT_fgpu_rdc);
+  if (Args.hasArg(OPT_fgpu_allow_device_init)) {
+if (Opts.HIP)
+  Opts.GPUAllowDeviceInit = 1;
+else
+  Diags.Report(diag::warn_ignore_hip_only_option)
+  << Args.getLastArg(OPT_fgpu_allow_device_init)->getAsString(Args);
+  }
   Opts.HIPUseNewLaunchAPI = Args.hasArg(OPT_fhip_new_launch_api);
 
   if (Opts.ObjC) {
Index: clang/lib/Driver/ToolChains/HIP.cpp
===
--- clang/lib/Driver/ToolChains/HIP.cpp
+++ clang/lib/Driver/ToolChains/HIP.cpp
@@ -292,6 +292,10 @@
  false))
 CC1Args.push_back("-fgpu-rdc");
 
+  if (DriverArgs.hasFlag(options::OPT_fgpu_allow_device_init,
+ options::OPT_fno_gpu_allow_device_init, false))
+CC1Args.push_back("-fgpu-allow-device-init");
+
   // Default to "hidden" visibility, as object level linking will not be
   // supported for the foreseeable future.
   if (!DriverArgs.hasArg(options::OPT_fvisibility_EQ,
Index: clang/lib/CodeGen/CGDeclCXX.cpp
===
--- clang/lib/CodeGen/CGDeclCXX.cpp
+++ clang/lib/CodeGen/CGDeclCXX.cpp
@@ -437,7 +437,7 @@
   // that are of class type, cannot have a non-empty constructor. All
   // the checks have been done in Sema by now. Whatever initializers
   // are allowed are empty and we just need to ignore them here.
-  if (getLangOpts().CUDA && getLangOpts().CUDAIsDevice &&
+  if (getLangOpts().CUDAIsDevice && !getLangOpts().GPUAllowDeviceInit &&
   (D->hasAttr() || D->hasAttr() ||
D->hasAttr()))
 return;
@@ -608,6 +608,11 @@
 Fn->setCallingConv(llvm::CallingConv::SPIR_KERNEL);
   }
 
+  if (getLangOpts().HIP) {
+Fn->setCallingConv(llvm::CallingConv::AMDGPU_KERNEL);
+Fn->addFnAttr("device-init");
+  }
+
   CXXGlobalInits.clear();
 }
 
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -602,6 +602,9 @@
 def fhip_new_launch_api : Flag<["-"], 

[clang] 68f5ca4 - [HIP] Add option -fgpu-allow-device-init

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2019-10-22T16:06:20-04:00
New Revision: 68f5ca4e19c16f12895a6f0b9fbabc1d86c4b6b0

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

LOG: [HIP] Add option -fgpu-allow-device-init

Add this option to allow device side class type global variables
with non-trivial ctor/dtor. device side init/fini functions will
be emitted, which will be executed by HIP runtime when
the fat binary is loaded/unloaded.

This feature is to facilitate implementation of device side
sanitizer which requires global vars with non-trival ctors.

By default this option is disabled.

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

Added: 
clang/test/CodeGenCUDA/device-init-fun.cu
clang/test/Frontend/warn-device-init-fun.cu

Modified: 
clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/CGDeclCXX.cpp
clang/lib/Driver/ToolChains/HIP.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Sema/SemaCUDA.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index 484cc317f965..40911957d6fe 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -304,6 +304,11 @@ def err_arcmt_nsinvocation_ownership : 
Error<"NSInvocation's %0 is not safe to b
 def err_openclcxx_not_supported : Error<
   "'%0' is not supported in C++ for OpenCL">;
 
+// HIP
+def warn_ignore_hip_only_option : Warning<
+  "'%0' is ignored since it is only supported for HIP">,
+  InGroup;
+
 // OpenMP
 def err_omp_more_one_clause : Error<
   "directive '#pragma omp %0' cannot contain more than one '%1' 
clause%select{| with '%3' name modifier| with 'source' dependence}2">;

diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index 928059539558..11218ccaeee7 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -1077,6 +1077,10 @@ def SerializedDiagnostics : 
DiagGroup<"serialized-diagnostics">;
 // compiling CUDA C/C++ but which is not compatible with the CUDA spec.
 def CudaCompat : DiagGroup<"cuda-compat">;
 
+// A warning group for warnings about features supported by HIP but
+// ignored by CUDA.
+def HIPOnly : DiagGroup<"hip-only">;
+
 // Warnings which cause linking of the runtime libraries like
 // libc and the CRT to be skipped.
 def AVRRtlibLinkingQuirks : DiagGroup<"avr-rtlib-linking-quirks">;

diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index a423654d5e03..eba4f835d661 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -224,6 +224,7 @@ LANGOPT(CUDAAllowVariadicFunctions, 1, 0, "allowing 
variadic functions in CUDA d
 LANGOPT(CUDAHostDeviceConstexpr, 1, 1, "treating unattributed constexpr 
functions as __host__ __device__")
 LANGOPT(CUDADeviceApproxTranscendentals, 1, 0, "using approximate 
transcendental functions")
 LANGOPT(GPURelocatableDeviceCode, 1, 0, "generate relocatable device code")
+LANGOPT(GPUAllowDeviceInit, 1, 0, "allowing device side global init functions 
for HIP")
 
 LANGOPT(SYCLIsDevice  , 1, 0, "Generate code for SYCL device")
 

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 3ce6fcf29f94..4db7cd844d15 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -602,6 +602,9 @@ def fhip_dump_offload_linker_script : Flag<["-"], 
"fhip-dump-offload-linker-scri
 def fhip_new_launch_api : Flag<["-"], "fhip-new-launch-api">,
   Flags<[CC1Option]>, HelpText<"Use new kernel launching API for HIP.">;
 def fno_hip_new_launch_api : Flag<["-"], "fno-hip-new-launch-api">;
+def fgpu_allow_device_init : Flag<["-"], "fgpu-allow-device-init">,
+  Flags<[CC1Option]>, HelpText<"Allow device side init function in HIP">;
+def fno_gpu_allow_device_init : Flag<["-"], "fno-gpu-allow-device-init">;
 def libomptarget_nvptx_path_EQ : Joined<["--"], "libomptarget-nvptx-path=">, 
Group,
   HelpText<"Path to libomptarget-nvptx libraries">;
 def dD : Flag<["-"], "dD">, Group, Flags<[CC1Option]>,

diff  --git a/clang/lib/CodeGen/CGDeclCXX.cpp b/clang/lib/CodeGen/CGDeclCXX.cpp
index bf16b7bec4b1..5b172a3480be 100644
--- a/clang/lib/CodeGen/CGDeclCXX.cpp
+++ b/clang/lib/CodeGen/CGDeclCXX.cpp
@@ -437,7 +437,7 @@ CodeGenModule::EmitCXXGlobalVarDeclInitFunc(const VarDecl 
*D,
   // that are of class type, cannot have a non-empty constructor. All
   // the checks have been done in Sema 

[PATCH] D69318: [analyzer] Add SufficientSizeArrayIndexingChecker

[Endre Fülöp via Phabricator via cfe-commits]

gamesh411 created this revision.
Herald added subscribers: cfe-commits, Charusso, dkrupp, donat.nagy, Szelethus, 
arphaman, mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun, 
whisperity, mgorny.
Herald added a project: clang.
gamesh411 added a reviewer: Szelethus.
gamesh411 added a comment.

Please feel free to add more reviewers.


Checks for indexing situations, where an array is indexed with a
variable of type not sufficiently large to cover the whole range of the
arrays possible index set. This check is uses path-sensitivity in order
to reason about the possible size of the array being checked.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69318

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/SufficientSizeArrayIndexingChecker.cpp
  clang/test/Analysis/sufficient-size-array-indexing-32bit.c
  clang/test/Analysis/sufficient-size-array-indexing-64bit.c

Index: clang/test/Analysis/sufficient-size-array-indexing-64bit.c
===
--- /dev/null
+++ clang/test/Analysis/sufficient-size-array-indexing-64bit.c
@@ -0,0 +1,127 @@
+// RUN: %clang_analyze_cc1 -triple x86_64 -analyzer-checker=core,alpha.cplusplus.SufficientSizeArrayIndexing %s -verify
+
+#include "Inputs/system-header-simulator.h"
+
+const unsigned long long one_byte_signed_max = (1ULL << 7) - 1;
+const unsigned long long two_byte_signed_max = (1ULL << 15) - 1;
+const unsigned long long four_byte_signed_max = (1ULL << 31) - 1;
+
+const unsigned long long one_byte_unsigned_max = (1ULL << 8) - 1;
+const unsigned long long two_byte_unsigned_max = (1ULL << 16) - 1;
+const unsigned long long four_byte_unsigned_max = (1ULL << 32) - 1;
+
+char smaller_than_1byte_signed_range[one_byte_signed_max];
+char exactly_1byte_signed_range[one_byte_signed_max + 1];
+char greater_than_1byte_signed_range[one_byte_signed_max + 2];
+
+char smaller_than_2byte_signed_range[two_byte_signed_max];
+char exactly_2byte_signed_range[two_byte_signed_max + 1];
+char greater_than_2byte_signed_range[two_byte_signed_max + 2];
+
+char smaller_than_4byte_signed_range[four_byte_signed_max];
+char exactly_4byte_signed_range[four_byte_signed_max + 1];
+char greater_than_4byte_signed_range[four_byte_signed_max + 2];
+
+char smaller_than_1byte_unsigned_range[one_byte_unsigned_max];
+char exactly_1byte_unsigned_range[one_byte_unsigned_max + 1];
+char greater_than_1byte_unsigned_range[one_byte_unsigned_max + 2];
+
+char smaller_than_2byte_unsigned_range[two_byte_unsigned_max];
+char exactly_2byte_unsigned_range[two_byte_unsigned_max + 1];
+char greater_than_2byte_unsigned_range[two_byte_unsigned_max + 2];
+
+char smaller_than_4byte_unsigned_range[four_byte_unsigned_max];
+char exactly_4byte_unsigned_range[four_byte_unsigned_max + 1];
+char greater_than_4byte_unsigned_range[four_byte_unsigned_max + 2];
+
+const char one_byte_signed_index = 1;  // sizeof(char) == 1
+const short two_byte_signed_index = 1; // sizeof(short) == 2
+const int four_byte_signed_index = 1;  // sizeof(int) == 4
+
+const unsigned char one_byte_unsigned_index = 1;
+const unsigned short two_byte_unsigned_index = 1;
+const unsigned int four_byte_unsigned_index = 1;
+
+void ignore_literal_indexing() {
+  char a = exactly_4byte_unsigned_range[32]; // nowarning
+}
+
+void ignore_literal_indexing_with_parens() {
+  char a = exactly_4byte_unsigned_range[(32)]; // nowarning
+}
+
+void range_check_one_byte_index() {
+  char r;
+  char *pr = 
+  *pr = smaller_than_1byte_signed_range[one_byte_signed_index]; // nowarning
+  *pr = exactly_1byte_signed_range[one_byte_signed_index];  // nowarning
+  *pr = greater_than_1byte_signed_range[one_byte_signed_index]; // expected-warning{{Indexing array with type 'char' cannot cover the whole range of the array's index set, which may result in memory waste in form of unindexable elements. Consider using a type with greater maximum value}}
+  *pr = smaller_than_1byte_unsigned_range[one_byte_unsigned_index]; // nowarning
+  *pr = exactly_1byte_unsigned_range[one_byte_unsigned_index];  // nowarning
+  *pr = greater_than_1byte_unsigned_range[one_byte_unsigned_index]; // expected-warning{{Indexing array with type 'unsigned char' cannot cover the whole range of the array's index set, which may result in memory waste in form of unindexable elements. Consider using a type with greater maximum value}}
+}
+
+void range_check_two_byte_index() {
+  char r;
+  char *pr = 
+  *pr = smaller_than_2byte_signed_range[two_byte_signed_index]; // nowarning
+  *pr = exactly_2byte_signed_range[two_byte_signed_index];  // nowarning
+  *pr = greater_than_2byte_signed_range[two_byte_signed_index]; // expected-warning{{Indexing array with type 'short' cannot cover the whole range of the array's index set, which may result in memory waste in form of unindexable elements. Consider using a 

[PATCH] D69318: [analyzer] Add SufficientSizeArrayIndexingChecker

[Endre Fülöp via Phabricator via cfe-commits]

gamesh411 added a comment.

Please feel free to add more reviewers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69318



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

[PATCH] D69292: Proposal to add -Wtautological-compare to -Wall

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

xbolva00 added a comment.

Cool!


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

https://reviews.llvm.org/D69292



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

[PATCH] D69316: [OpenMP 5.0] target update list items need not be contiguous (Sema)

[Chi Chun Chen via Phabricator via cfe-commits]

cchen updated this revision to Diff 226067.
cchen added a comment.

Fix summary message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69316

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_map_codegen.cpp
  clang/test/OpenMP/target_map_messages.cpp
  clang/test/OpenMP/target_teams_map_messages.cpp
  clang/test/OpenMP/target_update_ast_print.cpp
  clang/test/OpenMP/target_update_from_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp

Index: clang/test/OpenMP/target_update_to_messages.cpp
===
--- clang/test/OpenMP/target_update_to_messages.cpp
+++ clang/test/OpenMP/target_update_to_messages.cpp
@@ -80,6 +80,7 @@
   T to;
   const T ()[5] = da;
   S7 s7;
+  T ***mptr;
 
 #pragma omp target update to // expected-error {{expected '(' after 'to'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -118,6 +119,9 @@
   {
 #pragma omp target update to(s7.x)
   }
+#pragma omp target update to(mptr[:2][2+2-4:1][0:5+5]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update to(mptr[:1][:2-1][2:4-3]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update to(mptr[:1][:2][0:2]) // expected-error 2 {{only one level of indirection allowed in array section}}
   return 0;
 }
 
@@ -135,6 +139,7 @@
   const int ()[5] = da;
   S7 s7;
   int *m;
+  int ***mptr;
 
 #pragma omp target update to // expected-error {{expected '(' after 'to'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -171,6 +176,9 @@
   {
 #pragma omp target update to(s7.x)
   }
+#pragma omp target update to(mptr[:2][2+2-4:1][0:5+5]) // expected-error {{only one level of indirection allowed in array section}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mptr[:1][:2-1][2:4-3]) // expected-error {{only one level of indirection allowed in array section}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mptr[:1][:2][0:2]) // expected-error {{only one level of indirection allowed in array section}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 
   return tmain(argc)+tmain(argc); // expected-note {{in instantiation of function template specialization 'tmain' requested here}} expected-note {{in instantiation of function template specialization 'tmain' requested here}}
 }
Index: clang/test/OpenMP/target_update_from_messages.cpp
===
--- clang/test/OpenMP/target_update_from_messages.cpp
+++ clang/test/OpenMP/target_update_from_messages.cpp
@@ -80,6 +80,7 @@
   const T ()[5] = da;
   T *m;
   S7 s7;
+  T ***mptr;
 
 #pragma omp target update from // expected-error {{expected '(' after 'from'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -118,6 +119,9 @@
   {
 #pragma omp target update from(s7.x)
   }
+#pragma omp target update from(mptr[:2][2+2-4:1][0:5+5]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update from(mptr[:1][:2-1][2:4-3]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update from(mptr[:1][:2][0:2]) // expected-error 2 {{only one level of indirection allowed in array section}}
 
   return 0;
 }
@@ -136,6 +140,7 @@
   const int ()[5] = da;
   int *m;
   S7 s7;
+  int ***mptr;
 
 #pragma omp target update from // expected-error {{expected '(' after 'from'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from( // expected-error {{expected ')'}} expected-note {{to match this '('}} 

[PATCH] D69316: [OpenMP 5.0] target update list items need not be contiguous (Sema)

[Chi Chun Chen via Phabricator via cfe-commits]

cchen created this revision.
cchen added reviewers: ABataev, sfantao.
Herald added subscribers: cfe-commits, guansong.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.

- Removed a restriction that list items for target update

directive must have contiguous storage.

- A restriction was added for array sections that array of pointers

is still disallowed. (also modify a test case in target_map_codegen
that is not valid anymore in OpenMP 5.0)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69316

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_map_codegen.cpp
  clang/test/OpenMP/target_map_messages.cpp
  clang/test/OpenMP/target_teams_map_messages.cpp
  clang/test/OpenMP/target_update_ast_print.cpp
  clang/test/OpenMP/target_update_from_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp

Index: clang/test/OpenMP/target_update_to_messages.cpp
===
--- clang/test/OpenMP/target_update_to_messages.cpp
+++ clang/test/OpenMP/target_update_to_messages.cpp
@@ -80,6 +80,7 @@
   T to;
   const T ()[5] = da;
   S7 s7;
+  T ***mptr;
 
 #pragma omp target update to // expected-error {{expected '(' after 'to'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -118,6 +119,9 @@
   {
 #pragma omp target update to(s7.x)
   }
+#pragma omp target update to(mptr[:2][2+2-4:1][0:5+5]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update to(mptr[:1][:2-1][2:4-3]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update to(mptr[:1][:2][0:2]) // expected-error 2 {{only one level of indirection allowed in array section}}
   return 0;
 }
 
@@ -135,6 +139,7 @@
   const int ()[5] = da;
   S7 s7;
   int *m;
+  int ***mptr;
 
 #pragma omp target update to // expected-error {{expected '(' after 'to'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -171,6 +176,9 @@
   {
 #pragma omp target update to(s7.x)
   }
+#pragma omp target update to(mptr[:2][2+2-4:1][0:5+5]) // expected-error {{only one level of indirection allowed in array section}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mptr[:1][:2-1][2:4-3]) // expected-error {{only one level of indirection allowed in array section}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mptr[:1][:2][0:2]) // expected-error {{only one level of indirection allowed in array section}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 
   return tmain(argc)+tmain(argc); // expected-note {{in instantiation of function template specialization 'tmain' requested here}} expected-note {{in instantiation of function template specialization 'tmain' requested here}}
 }
Index: clang/test/OpenMP/target_update_from_messages.cpp
===
--- clang/test/OpenMP/target_update_from_messages.cpp
+++ clang/test/OpenMP/target_update_from_messages.cpp
@@ -80,6 +80,7 @@
   const T ()[5] = da;
   T *m;
   S7 s7;
+  T ***mptr;
 
 #pragma omp target update from // expected-error {{expected '(' after 'from'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -118,6 +119,9 @@
   {
 #pragma omp target update from(s7.x)
   }
+#pragma omp target update from(mptr[:2][2+2-4:1][0:5+5]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update from(mptr[:1][:2-1][2:4-3]) // expected-error 2 {{only one level of indirection allowed in array section}}
+#pragma omp target update from(mptr[:1][:2][0:2]) // expected-error 2 {{only one level of indirection allowed in array section}}
 
   return 0;
 }
@@ -136,6 +140,7 @@
   const int ()[5] = da;
   int *m;
   S7 s7;
+  int 

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:890
+  "cannot apply to inline functions, ignoring pragma">,
+   InGroup;
 

sepavloff wrote:
> hfinkel wrote:
> > sepavloff wrote:
> > > hfinkel wrote:
> > > > andrew.w.kaylor wrote:
> > > > > rjmccall wrote:
> > > > > > What's the purpose of this restriction?  Whether `inline` really 
> > > > > > has much to do with inlining depends a lot on the exact language 
> > > > > > settings.  (Also, even if this restriction were okay, the 
> > > > > > diagnostic is quite bad given that there are three separate 
> > > > > > conditions that can lead to it firing.)
> > > > > > 
> > > > > > Also, I thought we were adding instruction-level annotations for 
> > > > > > this kind of thing to LLVM IR.  Was that not in service of 
> > > > > > implementing this pragma?
> > > > > > 
> > > > > > I'm not categorically opposed to taking patches that only partially 
> > > > > > implement a feature, but I do want to feel confident that there's a 
> > > > > > reasonable technical path forward to the full implementation.  In 
> > > > > > this case, it feels like the function-level attribute is a dead end 
> > > > > > technically.
> > > > > I'm guessing this is intended to avoid the optimization problems that 
> > > > > would occur (currently) if a function with strictfp were inlined into 
> > > > > a function without it. I'm just guessing though, so correct me if I'm 
> > > > > wrong.
> > > > > 
> > > > > As I've said elsewhere, I hope this is a temporary problem. It is a 
> > > > > real problem though (as is the fact that the inliner isn't currently 
> > > > > handling this case correctly).
> > > > > 
> > > > > What would you think of a new command line option that caused us to 
> > > > > mark functions with strictfp as noinline? We'd still need an error 
> > > > > somewhat like this, but I feel like that would be more likely to 
> > > > > accomplish what we want on a broad scale.
> > > > We would not want to prevent all inlining, just inlining where the 
> > > > attributes don't match. We should fix his first. I think we just need 
> > > > to add a CompatRule to include/llvm/IR/Attributes.td (or something like 
> > > > that).
> > > As Andrew already said, `noinline` attribute is a mean to limit negative 
> > > performance impact. Of course, to inline or not to inline - such decision 
> > > is made by backend. However it a user requested a function to be inline, 
> > > a warning looks useful.
> > > 
> > > When constrained intrinsics get full support in optimizations, this 
> > > restriction will become unnecessary.
> > > 
> > > Outlining is one of the ways that converts this solution into full pragma 
> > > implementation. Another is implementation of constrained intrinsics 
> > > support in optimization transformations.
> > > 
> > > As for a new command line option that caused us to mark functions with 
> > > strictfp as noinline, it loos a good idea, but we must adapt inliner 
> > > first, so that it can convert ordinary floating operations to constrained 
> > > intrinsics during inlining.
> > > 
> > > In the case of `#pragma STDC FENV_ACCESS` we cannot in general say if 
> > > attributes are compatible so a function can be inlined into another. The 
> > > pragma only says that user modified floating point environment. One 
> > > function may set only rounding mode and another use different exception 
> > > handling, in this case we cannot do inlining. More fine grained pragmas, 
> > > like that proposed in https://reviews.llvm.org/D65997 could enable more 
> > > flexible inlining.
> > > Of course, to inline or not to inline - such decision is made by backend. 
> > > However it a user requested a function to be inline, a warning looks 
> > > useful.
> > 
> > We need to be careful. inline is not just an optimizaiton hint. It also 
> > affects function linkage. Also, when inlining into functions with similar 
> > constraints, there's no problem with the inlining.
> > 
> > > One function may set only rounding mode and another use different 
> > > exception handling, in this case we cannot do inlining.
> > 
> > Can you please explain this? It does not seem like that should block 
> > inlining when both the caller and callee are marked as fenv_access-enabled.
> > We need to be careful. inline is not just an optimizaiton hint. It also 
> > affects function linkage. Also, when inlining into functions with similar 
> > constraints, there's no problem with the inlining.
> This is an argument in favor of the warning on conflicting attributes.
> 
> >> One function may set only rounding mode and another use different 
> >> exception handling, in this case we cannot do inlining.
> >Can you please explain this? It does not seem like that should block 
> >inlining when both the caller and callee are marked as fenv_access-enabled. 
> 
> I was wrong. If a function correctly restores FP state, it can be inlined 
> into 

[PATCH] D68340: Add AIX toolchain and basic linker functionality

[Xiangling Liao via Phabricator via cfe-commits]

Xiangling_L added inline comments.



Comment at: clang/lib/Driver/ToolChains/AIX.cpp:35
+  // Only support 32 and 64 bit
+  if (!IsArch32Bit && !IsArch64Bit)
+llvm_unreachable("Unsupported bit width value");

stevewan wrote:
> jasonliu wrote:
> > Xiangling_L wrote:
> > > Is there any reason to use llvm_unreachable here? I think we should use  
> > > 'assertion' instead here:
> > > 
> > > ```
> > > assert((IsArch32Bit || IsArch64Bit) && "...");
> > > ```
> > IsArch64Bit used only in the assertion could cause warning when the 
> > assertion is turned off. 
> Jason has provided a good point why `llvm_unreachable` was preferred here. 
> Other than that, I believe the two are fairly interchangeable in this 
> particular case. That said, I'm leaning towards keeping `llvm_unreachable`, 
> but definitely add more comment if you have good reasons for using `assert`. 
> Thanks!
Jason is right, I am fine with keeping `llvm_unreachable`.



Comment at: clang/lib/Driver/ToolChains/AIX.cpp:44
+  } else {
+assert(Output.isNothing() && "Invalid output.");
+  }

Glad to know the build without assertion on would not be affected by this. I 
just have slight preference that we don't have this blank block in our product 
code when the assertion is off. Is that better we put this assertion before 
`if` block, and do something like this;

```
assert((Output.isFilename() || Output.isNothing()) && "Invalid output.");

if (Output.isFilename()) {
CmdArgs.push_back("-o");
CmdArgs.push_back(Output.getFilename());
  } 
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68340



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

Re: r374202 - [ObjC generics] Fix not inheriting type bounds in categories/extensions.

[Hans Wennborg via cfe-commits]

Since it looks suspicious, can we revert your change in the meantime?
We have a number of instances where this fires, so it's not just one
place we'd need to work around it.

On Mon, Oct 21, 2019 at 6:39 PM Volodymyr Sapsai  wrote:
>
> That error looks strange and confusing to me too. My guess is that my change 
> exposed some bug with literals. I’ve tried
>
>  NSDictionary* videoSettingsDictionary2 = [NSDictionary
> dictionaryWithObject:@(best_fourcc)
> forKey:(id)kCVPixelBufferPixelFormatTypeKey];
>
> and
>
> @interface GenericTest  : NSObject
> - (void)test:(const KeyType  _Nonnull)key;
> @end
>
> void anotherTest(GenericTest *t) {
>   [t test:(id)kCVPixelBufferPixelFormatTypeKey];
> }
>
> But they didn’t trigger the error. I need more time to investigate the issue 
> but in the meantime you can fix the build by casting to the corresponding 
> constant type, something like
>
>   (NSString *)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc)
>
> Thanks,
> Volodymyr
>
> > On Oct 21, 2019, at 14:37, Hans Wennborg  wrote:
> >
> > Hi Volodymyr,
> >
> > This broke the Chrome build in an interesting way. Here's a reduced repro:
> >
> >
> > $ cat /tmp/a.mm
> > #import 
> >
> > void f(int width, int height) {
> >  FourCharCode best_fourcc = kCMPixelFormat_422YpCbCr8_yuvs;
> >  NSDictionary* videoSettingsDictionary = @{
> >(id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
> >  };
> > }
> >
> > $ build.release/bin/clang++ -isysroot
> > /work/chromium/src/build/mac_files/xcode_binaries/Contents/Developer/Platforms/MacOSX.platform/Developer/SDK
> > s/MacOSX10.14.sdk -c /tmp/a.mm
> >
> > /tmp/a.mm:6:5: error: cannot initialize a parameter of type
> > 'KeyType  _Nonnull const' (aka 'const id') with an rvalue
> > of type 'id'
> >(id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
> >^~~~
> > 1 error generated.
> >
> >
> > To me, the "cannot initialize a parameter of type [nanana] (aka 'const
> > id') with an rvalue of type 'id'" message looks strange, but I'm not
> > an Obj-C expert. Is this expected behaviour, and if so how should we
> > change our code?
> >
> > Thanks,
> > Hans
> >
> > On Wed, Oct 9, 2019 at 12:26 PM Volodymyr Sapsai via cfe-commits
> >  wrote:
> >>
> >> Author: vsapsai
> >> Date: Wed Oct  9 12:29:13 2019
> >> New Revision: 374202
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=374202=rev
> >> Log:
> >> [ObjC generics] Fix not inheriting type bounds in categories/extensions.
> >>
> >> When a category/extension doesn't repeat a type bound, corresponding
> >> type parameter is substituted with `id` when used as a type argument. As
> >> a result, in the added test case it was causing errors like
> >>
> >>> type argument 'T' (aka 'id') does not satisfy the bound ('id') 
> >>> of type parameter 'T'
> >>
> >> We are already checking that type parameters should be consistent
> >> everywhere (see `checkTypeParamListConsistency`) and update
> >> `ObjCTypeParamDecl` to have correct underlying type. And when we use the
> >> type parameter as a method return type or a method parameter type, it is
> >> substituted to the bounded type. But when we use the type parameter as a
> >> type argument, we check `ObjCTypeParamType` that ignores the updated
> >> underlying type and remains `id`.
> >>
> >> Fix by desugaring `ObjCTypeParamType` to the underlying type, the same
> >> way we are doing with `TypedefType`.
> >>
> >> rdar://problem/54329242
> >>
> >> Reviewers: erik.pilkington, ahatanak
> >>
> >> Reviewed By: erik.pilkington
> >>
> >> Subscribers: jkorous, dexonsmith, ributzka, cfe-commits
> >>
> >> Differential Revision: https://reviews.llvm.org/D66696
> >>
> >> Modified:
> >>cfe/trunk/include/clang/AST/Type.h
> >>cfe/trunk/lib/AST/Type.cpp
> >>cfe/trunk/test/SemaObjC/parameterized_classes_subst.m
> >>
> >> Modified: cfe/trunk/include/clang/AST/Type.h
> >> URL: 
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=374202=374201=374202=diff
> >> ==
> >> --- cfe/trunk/include/clang/AST/Type.h (original)
> >> +++ cfe/trunk/include/clang/AST/Type.h Wed Oct  9 12:29:13 2019
> >> @@ -5569,7 +5569,7 @@ class ObjCTypeParamType : public Type,
> >>
> >> public:
> >>   bool isSugared() const { return true; }
> >> -  QualType desugar() const { return getCanonicalTypeInternal(); }
> >> +  QualType desugar() const;
> >>
> >>   static bool classof(const Type *T) {
> >> return T->getTypeClass() == ObjCTypeParam;
> >>
> >> Modified: cfe/trunk/lib/AST/Type.cpp
> >> URL: 
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Type.cpp?rev=374202=374201=374202=diff
> >> ==
> >> --- cfe/trunk/lib/AST/Type.cpp (original)
> >> +++ cfe/trunk/lib/AST/Type.cpp Wed Oct  9 12:29:13 2019
> >> @@ -663,6 +663,10 @@ ObjCTypeParamType::ObjCTypeParamType(con
> >>   

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[Serge Pavlov via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:890
+  "cannot apply to inline functions, ignoring pragma">,
+   InGroup;
 

hfinkel wrote:
> sepavloff wrote:
> > hfinkel wrote:
> > > andrew.w.kaylor wrote:
> > > > rjmccall wrote:
> > > > > What's the purpose of this restriction?  Whether `inline` really has 
> > > > > much to do with inlining depends a lot on the exact language 
> > > > > settings.  (Also, even if this restriction were okay, the diagnostic 
> > > > > is quite bad given that there are three separate conditions that can 
> > > > > lead to it firing.)
> > > > > 
> > > > > Also, I thought we were adding instruction-level annotations for this 
> > > > > kind of thing to LLVM IR.  Was that not in service of implementing 
> > > > > this pragma?
> > > > > 
> > > > > I'm not categorically opposed to taking patches that only partially 
> > > > > implement a feature, but I do want to feel confident that there's a 
> > > > > reasonable technical path forward to the full implementation.  In 
> > > > > this case, it feels like the function-level attribute is a dead end 
> > > > > technically.
> > > > I'm guessing this is intended to avoid the optimization problems that 
> > > > would occur (currently) if a function with strictfp were inlined into a 
> > > > function without it. I'm just guessing though, so correct me if I'm 
> > > > wrong.
> > > > 
> > > > As I've said elsewhere, I hope this is a temporary problem. It is a 
> > > > real problem though (as is the fact that the inliner isn't currently 
> > > > handling this case correctly).
> > > > 
> > > > What would you think of a new command line option that caused us to 
> > > > mark functions with strictfp as noinline? We'd still need an error 
> > > > somewhat like this, but I feel like that would be more likely to 
> > > > accomplish what we want on a broad scale.
> > > We would not want to prevent all inlining, just inlining where the 
> > > attributes don't match. We should fix his first. I think we just need to 
> > > add a CompatRule to include/llvm/IR/Attributes.td (or something like 
> > > that).
> > As Andrew already said, `noinline` attribute is a mean to limit negative 
> > performance impact. Of course, to inline or not to inline - such decision 
> > is made by backend. However it a user requested a function to be inline, a 
> > warning looks useful.
> > 
> > When constrained intrinsics get full support in optimizations, this 
> > restriction will become unnecessary.
> > 
> > Outlining is one of the ways that converts this solution into full pragma 
> > implementation. Another is implementation of constrained intrinsics support 
> > in optimization transformations.
> > 
> > As for a new command line option that caused us to mark functions with 
> > strictfp as noinline, it loos a good idea, but we must adapt inliner first, 
> > so that it can convert ordinary floating operations to constrained 
> > intrinsics during inlining.
> > 
> > In the case of `#pragma STDC FENV_ACCESS` we cannot in general say if 
> > attributes are compatible so a function can be inlined into another. The 
> > pragma only says that user modified floating point environment. One 
> > function may set only rounding mode and another use different exception 
> > handling, in this case we cannot do inlining. More fine grained pragmas, 
> > like that proposed in https://reviews.llvm.org/D65997 could enable more 
> > flexible inlining.
> > Of course, to inline or not to inline - such decision is made by backend. 
> > However it a user requested a function to be inline, a warning looks useful.
> 
> We need to be careful. inline is not just an optimizaiton hint. It also 
> affects function linkage. Also, when inlining into functions with similar 
> constraints, there's no problem with the inlining.
> 
> > One function may set only rounding mode and another use different exception 
> > handling, in this case we cannot do inlining.
> 
> Can you please explain this? It does not seem like that should block inlining 
> when both the caller and callee are marked as fenv_access-enabled.
> We need to be careful. inline is not just an optimizaiton hint. It also 
> affects function linkage. Also, when inlining into functions with similar 
> constraints, there's no problem with the inlining.
This is an argument in favor of the warning on conflicting attributes.

>> One function may set only rounding mode and another use different exception 
>> handling, in this case we cannot do inlining.
>Can you please explain this? It does not seem like that should block inlining 
>when both the caller and callee are marked as fenv_access-enabled. 

I was wrong. If a function correctly restores FP state, it can be inlined into 
another fenv_access-enabled function.


Repository:
  rG LLVM Github Monorepo

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

[PATCH] D67536: [WIP] [clangd] Add support for an inactive regions notification

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

Just a few NITs from my side. I'll let the other review the actual 
implementation




Comment at: clang-tools-extra/clangd/ParsedAST.cpp:217
+  void SourceRangeSkipped(SourceRange Range, SourceLocation EndifLoc) override 
{
+SkippedRanges.push_back(Range);
+  }

Maybe keep only ranges from the main file?



Comment at: clang-tools-extra/clangd/ParsedAST.h:100
 
+  const std::vector () const {
+return SkippedRanges;

NIT: please return `llvm::ArrayRef` instead


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67536



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

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

> I don't see how such warning can help a user. A note about impact of the 
> pragma on performance can be put into documentation. Issuing a warning on 
> every use of the pragma may be annoying.

I definitely agree. Performance may be fine in many cases, and performance may 
not be *relatively* important where the pragma is used. I don't believe that a 
warning should be added for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69272



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

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D69272#1717967 , @kpn wrote:

> Baking into the front end the fact that the backend implementation is not yet 
> complete doesn't strike me as a good idea.


I don't expect that this patch would pass review quickly. But it could be used 
to organize requests what must be done to implement this functionality. Now I 
see that we need to add functionality to inliner. Do you have ideas what else 
should be done to implement this variant of the pragma?

> I think the issue with the inliner not being smart enough yet is an issue for 
> llvm to deal with and not front ends like clang. It would be straightforward 
> enough for llvm to mark functions that have the strictfp attribute so they 
> also are marked noinline. As a temporary measure, of course. This is a case 
> where llvm hasn't caught up with well-formed IR, so it would be llvm's job to 
> work around its own incompleteness.

That's true. But if user specifies `inline` for a function that contains the 
pragma, he requested contradictory attributes. Should compiler emit a warning? 
If yes, this is a job of frontend.

> See D43142  for code to convert all floating 
> point in a function into constrained intrinsics. Updated versions of this 
> code with support for intrinsics that didn't exist at the time also exist. I 
> don't see why this pass couldn't be reworked a bit to be used by the inliner. 
> And it would only be needed when inlining into a strictfp function a function 
> that wasn't strictfp.

I think this patch can help in adaptation of the inliner. The transformation 
must be rewritten as a function or even built into the logic of inliner.

> You mentioned that extending the scope of the #pragma may result in a 
> "performance drop, which is unacceptable in many cases". But the only 
> difference between allowing the #pragma only at the top of a function, and 
> allowing it everywhere the standard allows, is that the user knows about the 
> potential loss of performance. The performance loss happens in both cases. 
> Again, I don't think baking into clang the current state of llvm is a good 
> idea.

A user may be convinced that using the pragma is expensive. He would carefully 
implement the function with the pragma and if the function is small and called 
rarely, performance drop can be minimized. Such solution does not work for all 
cases but for some it is acceptable. If using the pragma in a small region 
results in loss of optimization in entire function, this is counterintuitive 
and in many cases unacceptable.

> A warning from clang that strictfp code doesn't perform very well today is 
> probably a good idea, and it would be ripped out easily when the day comes. 
> The warning would only fire when the #pragma is seen, and that code is small, 
> self-contained, and actually already exists in clang now but with different 
> text.

I don't see how such warning can help a user. A note about impact of the pragma 
on performance can be put into documentation. Issuing a warning on every use of 
the pragma may be annoying.

The main advantage of this restricted variant of the pragma IMHO is the 
possibility to provide implementation which can be developed in reasonable time 
and can be used in production code. Users will file bugs, we will fix them and 
the implementation will progress. If the pragma causes substantial performance 
loss, number of its users will be lower and the development will be slowed down.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69272



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Hal Finkel via Phabricator via cfe-commits]

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

In D63607#1709258 , @peterwaller-arm 
wrote:

> Friendly ping to everybody watching. I'd like to get this in soon if possible.
>
> Hal - do you think this is close to being accepted? Note that I consider this 
> "the beginning" rather than "the end", since there will be more functionality 
> to add piecewise before this is fully functional. In the meantime, since it 
> is new functionality, it should not break anything.


One comment on the test, but otherwise LGTM.




Comment at: clang/test/Driver/flang/flang-not-installed.f90:11
+! shell syntax.
+! UNSUPPORTED: windows
+

I believe that you can write:

  REQUIRES: shell

for this.


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

https://reviews.llvm.org/D63607



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

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:890
+  "cannot apply to inline functions, ignoring pragma">,
+   InGroup;
 

sepavloff wrote:
> hfinkel wrote:
> > andrew.w.kaylor wrote:
> > > rjmccall wrote:
> > > > What's the purpose of this restriction?  Whether `inline` really has 
> > > > much to do with inlining depends a lot on the exact language settings.  
> > > > (Also, even if this restriction were okay, the diagnostic is quite bad 
> > > > given that there are three separate conditions that can lead to it 
> > > > firing.)
> > > > 
> > > > Also, I thought we were adding instruction-level annotations for this 
> > > > kind of thing to LLVM IR.  Was that not in service of implementing this 
> > > > pragma?
> > > > 
> > > > I'm not categorically opposed to taking patches that only partially 
> > > > implement a feature, but I do want to feel confident that there's a 
> > > > reasonable technical path forward to the full implementation.  In this 
> > > > case, it feels like the function-level attribute is a dead end 
> > > > technically.
> > > I'm guessing this is intended to avoid the optimization problems that 
> > > would occur (currently) if a function with strictfp were inlined into a 
> > > function without it. I'm just guessing though, so correct me if I'm wrong.
> > > 
> > > As I've said elsewhere, I hope this is a temporary problem. It is a real 
> > > problem though (as is the fact that the inliner isn't currently handling 
> > > this case correctly).
> > > 
> > > What would you think of a new command line option that caused us to mark 
> > > functions with strictfp as noinline? We'd still need an error somewhat 
> > > like this, but I feel like that would be more likely to accomplish what 
> > > we want on a broad scale.
> > We would not want to prevent all inlining, just inlining where the 
> > attributes don't match. We should fix his first. I think we just need to 
> > add a CompatRule to include/llvm/IR/Attributes.td (or something like that).
> As Andrew already said, `noinline` attribute is a mean to limit negative 
> performance impact. Of course, to inline or not to inline - such decision is 
> made by backend. However it a user requested a function to be inline, a 
> warning looks useful.
> 
> When constrained intrinsics get full support in optimizations, this 
> restriction will become unnecessary.
> 
> Outlining is one of the ways that converts this solution into full pragma 
> implementation. Another is implementation of constrained intrinsics support 
> in optimization transformations.
> 
> As for a new command line option that caused us to mark functions with 
> strictfp as noinline, it loos a good idea, but we must adapt inliner first, 
> so that it can convert ordinary floating operations to constrained intrinsics 
> during inlining.
> 
> In the case of `#pragma STDC FENV_ACCESS` we cannot in general say if 
> attributes are compatible so a function can be inlined into another. The 
> pragma only says that user modified floating point environment. One function 
> may set only rounding mode and another use different exception handling, in 
> this case we cannot do inlining. More fine grained pragmas, like that 
> proposed in https://reviews.llvm.org/D65997 could enable more flexible 
> inlining.
> Of course, to inline or not to inline - such decision is made by backend. 
> However it a user requested a function to be inline, a warning looks useful.

We need to be careful. inline is not just an optimizaiton hint. It also affects 
function linkage. Also, when inlining into functions with similar constraints, 
there's no problem with the inlining.

> One function may set only rounding mode and another use different exception 
> handling, in this case we cannot do inlining.

Can you please explain this? It does not seem like that should block inlining 
when both the caller and callee are marked as fenv_access-enabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69272



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

[PATCH] D67185: [RISCV] Add support for -ffixed-xX flags

[Simon Cook via Phabricator via cfe-commits]

simoncook added a comment.

In D67185#1708177 , @asb wrote:

> In D67185#1707849 , @lenary wrote:
>
> > Note, D68862  is in-progress at the 
> > moment, which is related to this patch.
>
>
> Indeed - Simon, could you please go through that patch and ensure that the 
> implementation here is aligned to it (or indeed, feed back on that patch if 
> you feel they should be doing something differently). Thanks!


It looks like that patch is following the same route we are, using target 
features to implement this, both inspired by AArch64. There were some questions 
about using SubtargetFeatures for these kind of purposes and should these be 
function attributes instead. Given we’re already using features for things like 
relaxation, I’m inclined to stick with target features rather than split these 
between two different methodologies, especially since we have the AArch64 
precedence in this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67185



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

[PATCH] D54214: [RISCV] Set triple based on -march flag

[James Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

In D54214#1718043 , @simoncook wrote:

> Ping, before I rebased this did anyone have any other thoughts on flag 
> precedence?


The precedence seems sensible; it's what MIPS is doing for -mabi vs -target 
just above.




Comment at: clang/lib/Driver/Driver.cpp:541
+  // If target is RISC-V adjust the target triple according to
+  // provided architecture name
+  A = Args.getLastArg(options::OPT_march_EQ);

Missing a full-stop here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D54214



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

[PATCH] D54214: [RISCV] Set triple based on -march flag

[Simon Cook via Phabricator via cfe-commits]

simoncook added a comment.
Herald added a subscriber: pzheng.

Ping, before I rebased this did anyone have any other thoughts on flag 
precedence?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D54214



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

[PATCH] D69268: [HIP] Add option -fgpu-allow-device-init

[Yaxun Liu via Phabricator via cfe-commits]

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



Comment at: include/clang/Basic/DiagnosticCommonKinds.td:308
+// HIP
+def warn_ignore_hip_only_option : Warning<
+  "'%0' is ignored since it is only supported for HIP">,

tra wrote:
> `warn_ignore*d*_hip_only_option` ?
will do when commit. thanks.


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

https://reviews.llvm.org/D69268



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

[PATCH] D69268: [HIP] Add option -fgpu-allow-device-init

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added a comment.

Thank you for adding the warning. One small nit about the name. LGTM otherwise.




Comment at: include/clang/Basic/DiagnosticCommonKinds.td:308
+// HIP
+def warn_ignore_hip_only_option : Warning<
+  "'%0' is ignored since it is only supported for HIP">,

`warn_ignore*d*_hip_only_option` ?


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

https://reviews.llvm.org/D69268



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

[PATCH] D69308: [analyzer] Test cases for the unsupported features for Clang Static Analyzer

[Daniel Krupp via Phabricator via cfe-commits]

dkrupp created this revision.
dkrupp added reviewers: NoQ, Szelethus.
dkrupp added a project: clang.
Herald added subscribers: cfe-commits, Charusso, gamesh411, donat.nagy, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, xazax.hun, 
whisperity.

These test cases demonstrate some of the missing features of the Clang Static 
Analyzer.

In this patch 2 missing C++ features are demonstrated from  
https://clang-analyzer.llvm.org/open_projects.html

1. Handle constructors within new[]
2. Handle constructors for default arguments


Repository:
  rC Clang

https://reviews.llvm.org/D69308

Files:
  
clang/test/Analysis/clangsa_unsupported_features/handle_constructors_for_default_arguments.cpp
  
clang/test/Analysis/clangsa_unsupported_features/handle_constructors_with_new_array.cpp
  clang/www/analyzer/open_projects.html

Index: clang/www/analyzer/open_projects.html
===
--- clang/www/analyzer/open_projects.html
+++ clang/www/analyzer/open_projects.html
@@ -95,6 +95,7 @@
  We should model (potentially some of) such evaluations,
  and the same applies for destructors called from
  operator delete[].
+ See tests cases in https://github.com/llvm/llvm-project/tree/master/clang/test/Analysis/clangsa_unsupported_features/handle_constructors_with_new_array.cpp;>handle_constructors_with_new_array.cpp.
   
 
 
@@ -117,6 +118,7 @@
   Default arguments in C++ are recomputed at every call,
  and are therefore local, and not static, variables.
   
+  See tests cases in https://github.com/llvm/llvm-project/tree/master/clang/test/Analysis/clangsa_unsupported_features/handle_constructors_for_default_arguments.cpp;>handle_constructors_for_default_arguments.cpp.
 
 
 Enhance the modeling of the standard library.
Index: clang/test/Analysis/clangsa_unsupported_features/handle_constructors_with_new_array.cpp
===
--- /dev/null
+++ clang/test/Analysis/clangsa_unsupported_features/handle_constructors_with_new_array.cpp
@@ -0,0 +1,81 @@
+// RUN: %clang_cc1 -fsyntax-only -analyze \
+// RUN:   -analyzer-checker=core,debug.ExprInspection %s -verify
+// REQUIRES: non-existing-system
+
+// These test cases demonstrate lack of Static Analyzer features.
+// Remove REQUIRES line, when the feature gets implemented.
+
+// Handle constructors within new[]
+
+// When an array of objects is allocated using the operator new[],
+// constructors for all elements of the array are called.
+// We should model (potentially some of) such evaluations,
+// and the same applies for destructors called from operator delete[].
+
+void clang_analyzer_eval(bool);
+
+struct init_with_list {
+  int a;
+  init_with_list() : a(1) {}
+};
+
+struct init_in_body {
+  int a;
+  init_in_body() { a = 1; }
+};
+
+struct init_default_member {
+  int a = 1;
+};
+
+void test_automatic() {
+
+  init_with_list a1;
+  init_in_body a2;
+  init_default_member a3;
+
+  clang_analyzer_eval(a1.a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a2.a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a3.a == 1); // expected-warning {{TRUE}}
+}
+
+void test_dynamic() {
+
+  auto *a1 = new init_with_list;
+  auto *a2 = new init_in_body;
+  auto *a3 = new init_default_member;
+
+  clang_analyzer_eval(a1->a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a2->a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a3->a == 1); // expected-warning {{TRUE}}
+
+  delete a1;
+  delete a2;
+  delete a3;
+}
+
+void test_automatic_aggregate() {
+
+  init_with_list a1[1];
+  init_in_body a2[1];
+  init_default_member a3[1];
+
+  clang_analyzer_eval(a1[0].a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a2[0].a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a3[0].a == 1); // expected-warning {{TRUE}}
+}
+
+void test_dynamic_aggregate() {
+
+  auto *a1 = new init_with_list[1];
+  auto *a2 = new init_in_body[1];
+  auto *a3 = new init_default_member[1];
+
+  clang_analyzer_eval(a1[0].a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a2[0].a == 1); // expected-warning {{TRUE}}
+  clang_analyzer_eval(a3[0].a == 1); // expected-warning {{TRUE}}
+
+  delete[] a1;
+  delete[] a2;
+  delete[] a3;
+}
Index: clang/test/Analysis/clangsa_unsupported_features/handle_constructors_for_default_arguments.cpp
===
--- /dev/null
+++ clang/test/Analysis/clangsa_unsupported_features/handle_constructors_for_default_arguments.cpp
@@ -0,0 +1,86 @@
+// RUN: %clang_cc1 -fsyntax-only -analyze \
+// RUN:   -analyzer-checker=core,debug.ExprInspection %s -verify
+// REQUIRES: non-existing-system
+
+// These test cases demonstrate lack of Static Analyzer features.
+// Remove REQUIRES line, when the feature gets implemented.
+
+// Handle constructors for default arguments
+// Default arguments 

[PATCH] D67216: [cfi] Add flag to always generate .debug_frame

[David Candler via Phabricator via cfe-commits]

dcandler added a comment.

I think `-f[no-]force-dwarf-frame` suitably describes the behavior, and looks 
in line with other options. I'll update the patch shortly unless anyone else 
has any other input.


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

https://reviews.llvm.org/D67216



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

[PATCH] D69263: [clangd] Implement cross-file rename.

[Haojian Wu via Phabricator via cfe-commits]

hokein marked an inline comment as done.
hokein added a comment.

Thanks for the comments.

In D69263#1716760 , @ilya-biryukov 
wrote:

> Another important concern is surfacing errors to the users: silently dropping 
> ranges for stale files is definitely not the nicest option, I'm afraid this 
> will lead to non-explainable failure modes and users will be incredibly 
> unhappy...


Agree, I think we should surface this error to users when the index is stale or 
we don't have enough confident to perform the rename.

Thinking more about this -- we have a dynamic index (for all opened files) 
which is overlaid on a static index (which is a background index in open-source 
world), so for all affected files, they are either in

1. an open state -- we can rely on the dynamic index, I think it is safe to 
assume that index always returns up-to-date results;
2. a non-open state -- rely on the background index, however background index 
has more chance to be stale (especially we don't detect file-change events at 
the moment), we could do a range patch heuristically to mitigate this stale 
issue. Failing that, we surface the error to users.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69263



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

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

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

kpn added a comment.

Baking into the front end the fact that the backend implementation is not yet 
complete doesn't strike me as a good idea.

And the metadata arguments to the constrained intrinsics are designed to allow 
for correctly marked constrained intrinsics to be eventually treated pretty 
close to the same as non-constrained math instructions. Once the implementation 
is further along, of course.

I think the issue with the inliner not being smart enough yet is an issue for 
llvm to deal with and not front ends like clang. It would be straightforward 
enough for llvm to mark functions that have the strictfp attribute so they also 
are marked noinline. As a temporary measure, of course. This is a case where 
llvm hasn't caught up with well-formed IR, so it would be llvm's job to work 
around its own incompleteness.

See D43142  for code to convert all floating 
point in a function into constrained intrinsics. Updated versions of this code 
with support for intrinsics that didn't exist at the time also exist. I don't 
see why this pass couldn't be reworked a bit to be used by the inliner. And it 
would only be needed when inlining into a strictfp function a function that 
wasn't strictfp.

You mentioned that extending the scope of the #pragma may result in a 
"performance drop, which is unacceptable in many cases". But the only 
difference between allowing the #pragma only at the top of a function, and 
allowing it everywhere the standard allows, is that the user knows about the 
potential loss of performance. The performance loss happens in both cases. 
Again, I don't think baking into clang the current state of llvm is a good idea.

A warning from clang that strictfp code doesn't perform very well today is 
probably a good idea, and it would be ripped out easily when the day comes. The 
warning would only fire when the #pragma is seen, and that code is small, 
self-contained, and actually already exists in clang now but with different 
text.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69272



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

[PATCH] D69298: [clangd] Define out-of-line initial apply logic

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 226046.
kadircet added a comment.

- Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69298

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -1562,6 +1562,21 @@
 })cpp");
 }
 
+TEST_F(DefineOutlineTest, ApplyTest) {
+  FileName = "Test.hpp";
+
+  // No implementation file.
+  EXPECT_EQ(apply("void fo^o() { return; }"),
+"fail: Couldn't find a suitable implementation file.");
+
+  llvm::StringMap EditedFiles;
+  ExtraFiles["Test.cpp"] = "";
+  EXPECT_EQ(apply("void fo^o() { return; }", ), "void foo() ;");
+  EXPECT_THAT(EditedFiles,
+  testing::ElementsAre(FileWithContents(testPath("Test.cpp"),
+"void foo() { return; }")));
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
@@ -9,12 +9,18 @@
 #include "HeaderSourceSwitch.h"
 #include "Path.h"
 #include "Selection.h"
+#include "SourceCode.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/Stmt.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Driver/Types.h"
+#include "clang/Tooling/Core/Replacement.h"
 #include "llvm/ADT/Optional.h"
-#include "llvm/Support/Path.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
 
 namespace clang {
 namespace clangd {
@@ -39,6 +45,29 @@
   return nullptr;
 }
 
+llvm::Optional getSourceFile(llvm::StringRef FileName,
+   const Tweak::Selection ) {
+  if (auto Source = getCorrespondingHeaderOrSource(
+  FileName,
+  ().getFileManager().getVirtualFileSystem()))
+return *Source;
+  return getCorrespondingHeaderOrSource(FileName, Sel.AST, Sel.Index);
+}
+
+// Creates a modified version of function definition that can be inserted at a
+// different location. Contains both function signature and body.
+llvm::Optional moveFunctionDef(const FunctionDecl *FD) {
+  auto  = FD->getASTContext().getSourceManager();
+  auto CharRange = toHalfOpenFileRange(SM, FD->getASTContext().getLangOpts(),
+   FD->getSourceRange());
+  if (!CharRange)
+return llvm::None;
+
+  // FIXME: Qualify return type.
+  // FIXME: Qualify function name depending on the target context.
+  return toSourceCode(SM, *CharRange);
+}
+
 /// Moves definition of a function/method to an appropriate implementation file.
 ///
 /// Before:
@@ -84,8 +113,66 @@
   }
 
   Expected apply(const Selection ) override {
-return llvm::createStringError(llvm::inconvertibleErrorCode(),
-   "Not implemented yet");
+const SourceManager  = Sel.AST.getSourceManager();
+llvm::StringRef FileName = SM.getFilename(Sel.Cursor);
+
+auto SourceFile = getSourceFile(FileName, Sel);
+if (!SourceFile)
+  return llvm::createStringError(
+  llvm::inconvertibleErrorCode(),
+  "Couldn't find a suitable implementation file.");
+
+auto  =
+Sel.AST.getSourceManager().getFileManager().getVirtualFileSystem();
+auto Buffer = FS.getBufferForFile(*SourceFile);
+// FIXME: Maybe we should consider creating the implementation file if it
+// doesn't exist?
+if (!Buffer)
+  return llvm::createStringError(Buffer.getError(),
+ Buffer.getError().message());
+auto Contents = Buffer->get()->getBuffer();
+auto Region =
+getEligiblePoints(Contents, Source->getQualifiedNameAsString(),
+  getFormatStyleForFile(*SourceFile, Contents, ));
+
+assert(!Region.EligiblePoints.empty());
+// FIXME: This selection can be made smarter by looking at the definition
+// locations for adjacent decls to Source. Unfortunately psudeo parsing in
+// getEligibleRegions only knows about namespace begin/end events so we
+// can't match function start/end positions yet.
+auto InsertionPoint = Region.EligiblePoints.back();
+auto InsertionOffset = positionToOffset(Contents, InsertionPoint);
+if (!InsertionOffset)
+  return InsertionOffset.takeError();
+
+auto FuncDef = moveFunctionDef(Source);
+if (!FuncDef)
+  return llvm::createStringError(
+  llvm::inconvertibleErrorCode(),
+  "Couldn't get full 

[PATCH] D69268: [HIP] Add option -fgpu-allow-device-init

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 226044.
yaxunl added a comment.

Add warning


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

https://reviews.llvm.org/D69268

Files:
  include/clang/Basic/DiagnosticCommonKinds.td
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/LangOptions.def
  include/clang/Driver/Options.td
  lib/CodeGen/CGDeclCXX.cpp
  lib/Driver/ToolChains/HIP.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Sema/SemaCUDA.cpp
  test/CodeGenCUDA/device-init-fun.cu
  test/Frontend/warn-device-init-fun.cu

Index: test/Frontend/warn-device-init-fun.cu
===
--- /dev/null
+++ test/Frontend/warn-device-init-fun.cu
@@ -0,0 +1,8 @@
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang_cc1 -triple nvptx -fcuda-is-device \
+// RUN: -fgpu-allow-device-init \
+// RUN:  %s 2>&1 | FileCheck %s
+
+// CHECK: warning: '-fgpu-allow-device-init' is ignored since it is only supported for HIP
+
Index: test/CodeGenCUDA/device-init-fun.cu
===
--- /dev/null
+++ test/CodeGenCUDA/device-init-fun.cu
@@ -0,0 +1,19 @@
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -triple amdgcn -fcuda-is-device -std=c++11 \
+// RUN: -fgpu-allow-device-init -x hip \
+// RUN: -fno-threadsafe-statics -emit-llvm -o - %s \
+// RUN: | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// CHECK: define internal amdgpu_kernel void @_GLOBAL__sub_I_device_init_fun.cu() #[[ATTR:[0-9]*]]
+// CHECK: attributes #[[ATTR]] = {{.*}}"device-init"
+
+__device__ void f();
+
+struct A {
+  __device__ A() { f(); }
+};
+
+__device__ A a;
Index: lib/Sema/SemaCUDA.cpp
===
--- lib/Sema/SemaCUDA.cpp
+++ lib/Sema/SemaCUDA.cpp
@@ -492,6 +492,8 @@
   const Expr *Init = VD->getInit();
   if (VD->hasAttr() || VD->hasAttr() ||
   VD->hasAttr()) {
+if (LangOpts.GPUAllowDeviceInit)
+  return;
 assert(!VD->isStaticLocal() || VD->hasAttr());
 bool AllowedInit = false;
 if (const CXXConstructExpr *CE = dyn_cast(Init))
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2527,6 +2527,13 @@
 Opts.CUDADeviceApproxTranscendentals = 1;
 
   Opts.GPURelocatableDeviceCode = Args.hasArg(OPT_fgpu_rdc);
+  if (Args.hasArg(OPT_fgpu_allow_device_init)) {
+if (Opts.HIP)
+  Opts.GPUAllowDeviceInit = 1;
+else
+  Diags.Report(diag::warn_ignore_hip_only_option)
+  << Args.getLastArg(OPT_fgpu_allow_device_init)->getAsString(Args);
+  }
   Opts.HIPUseNewLaunchAPI = Args.hasArg(OPT_fhip_new_launch_api);
 
   if (Opts.ObjC) {
Index: lib/Driver/ToolChains/HIP.cpp
===
--- lib/Driver/ToolChains/HIP.cpp
+++ lib/Driver/ToolChains/HIP.cpp
@@ -292,6 +292,10 @@
  false))
 CC1Args.push_back("-fgpu-rdc");
 
+  if (DriverArgs.hasFlag(options::OPT_fgpu_allow_device_init,
+ options::OPT_fno_gpu_allow_device_init, false))
+CC1Args.push_back("-fgpu-allow-device-init");
+
   // Default to "hidden" visibility, as object level linking will not be
   // supported for the foreseeable future.
   if (!DriverArgs.hasArg(options::OPT_fvisibility_EQ,
Index: lib/CodeGen/CGDeclCXX.cpp
===
--- lib/CodeGen/CGDeclCXX.cpp
+++ lib/CodeGen/CGDeclCXX.cpp
@@ -437,7 +437,7 @@
   // that are of class type, cannot have a non-empty constructor. All
   // the checks have been done in Sema by now. Whatever initializers
   // are allowed are empty and we just need to ignore them here.
-  if (getLangOpts().CUDA && getLangOpts().CUDAIsDevice &&
+  if (getLangOpts().CUDAIsDevice && !getLangOpts().GPUAllowDeviceInit &&
   (D->hasAttr() || D->hasAttr() ||
D->hasAttr()))
 return;
@@ -608,6 +608,11 @@
 Fn->setCallingConv(llvm::CallingConv::SPIR_KERNEL);
   }
 
+  if (getLangOpts().HIP) {
+Fn->setCallingConv(llvm::CallingConv::AMDGPU_KERNEL);
+Fn->addFnAttr("device-init");
+  }
+
   CXXGlobalInits.clear();
 }
 
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -602,6 +602,9 @@
 def fhip_new_launch_api : Flag<["-"], "fhip-new-launch-api">,
   Flags<[CC1Option]>, HelpText<"Use new kernel launching API for HIP.">;
 def fno_hip_new_launch_api : Flag<["-"], "fno-hip-new-launch-api">;
+def fgpu_allow_device_init : Flag<["-"], "fgpu-allow-device-init">,
+  Flags<[CC1Option]>, HelpText<"Allow device side init function in HIP">;
+def fno_gpu_allow_device_init : Flag<["-"], "fno-gpu-allow-device-init">;
 def libomptarget_nvptx_path_EQ : Joined<["--"], "libomptarget-nvptx-path=">, 

[PATCH] D69268: [HIP] Add option -fgpu-allow-device-init

[Yaxun Liu via Phabricator via cfe-commits]

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



Comment at: lib/Frontend/CompilerInvocation.cpp:2530
   Opts.GPURelocatableDeviceCode = Args.hasArg(OPT_fgpu_rdc);
+  Opts.GPUAllowDeviceInit = Args.hasArg(OPT_fgpu_allow_device_init);
   Opts.HIPUseNewLaunchAPI = Args.hasArg(OPT_fhip_new_launch_api);

tra wrote:
> It would be useful if we could get a warning if someone attempts to use this 
> option for CUDA compilation, where the compiler will not enable device-side 
> init.
> 
> 
I added a warning about this option is ignored for CUDA.


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

https://reviews.llvm.org/D69268



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

[PATCH] D68720: Support -fstack-clash-protection for x86

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

Some benchmark / instrumentation report: due to the way memory moves are 
ordered in the entry block, there tend to be relatively few free probes between 
two stack growth within a function, and a large number after the last stack 
growth.

When recompiling llc, I only get 18 free probes between stack growth, and a 
large amount (several thousands) after the last stack growth.
When recompiling cpython, I only get 4 free probes between stack growth.

This may be improved by rescheduling instructions / changing stack object 
layout but that's probably not worth the effort (there's not that much 
functions with stack space > a page)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68720



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

[PATCH] D69266: [clangd] Define out-of-line availability checks

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:29
+// criteria is met.
+const FunctionDecl *getSelectedFunction(const SelectionTree::Node *SelNode) {
+  if (!SelNode)

hokein wrote:
> nit: looks like we also a similar version in `DefineInline`? would be nice if 
> we could share the implementation. I don't have a good idea where to put it, 
> maybe add a FIXME?
I also had the same concern, but left it here since couldn't find a suitable 
please.
adding a fixme.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:44
+/// Moves definition of a function/method to an appropriate implementation 
file.
+/// If current file is already an implementation file, tries to move the
+/// definition out-of-line.

hokein wrote:
> I'm not sure this is useful in general: saying in .cc we have a single 
> definition `void foo() {}`, after running the code action, we will end up 
> with `void foo(); void foo() {}`.
> 
> If we want to do this, I think we may make it only available for inline class 
> methods.
yes this was implying methods in my head, but forgot to spell it out. updating 
comment.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:75
+
+// Bail out if we are not in a header file.
+// FIXME: We might want to consider moving method definitions below class

hokein wrote:
> The bail-out here seems violating the above comment `/// If current file is 
> already an implementation file, tries to move the definition out-of-line`.  
> Basically, now we only allow moving the function definition to a .cc file.
this was actually representing the state I wanted to arrive, but you are right 
it looks confusing, getting rid of the mention in the class documention.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69266



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

[PATCH] D69266: [clangd] Define out-of-line availability checks

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 226045.
kadircet marked 8 inline comments as done.
kadircet added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69266

Files:
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/unittests/TweakTesting.cpp
  clang-tools-extra/clangd/unittests/TweakTesting.h
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -1519,6 +1519,49 @@
 using namespace a;
 )cpp");
 }
+
+TWEAK_TEST(DefineOutline);
+TEST_F(DefineOutlineTest, TriggersOnFunctionDecl) {
+  // Not available unless in a header file.
+  EXPECT_UNAVAILABLE(R"cpp(
+[[void [[f^o^o]]() [[{
+  return;
+})cpp");
+
+  FileName = "Test.hpp";
+  // Not available unless function name or fully body is selected.
+  EXPECT_UNAVAILABLE(R"cpp(
+// Not a definition
+vo^i[[d^ ^f]]^oo();
+
+[[vo^id ]]foo[[()]] {[[
+  [[(void)(5+3);
+  return;]]
+}]])cpp");
+
+  // Available even if there are no implementation files.
+  EXPECT_AVAILABLE(R"cpp(
+[[void [[f^o^o]]() [[{
+  return;
+})cpp");
+
+  ExtraFiles["Test.cpp"] = "";
+  // Basic check for function body and signature.
+  EXPECT_AVAILABLE(R"cpp(
+class Bar {
+  void baz();
+  [[void [[f^o^o]]() [[{ return; }
+};
+
+[[void [[Bar::[[b^a^z() [[{
+  return;
+}
+
+[[void [[f^o^o]]() [[{
+  return;
+})cpp");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/unittests/TweakTesting.h
===
--- clang-tools-extra/clangd/unittests/TweakTesting.h
+++ clang-tools-extra/clangd/unittests/TweakTesting.h
@@ -12,6 +12,7 @@
 #include "TestTU.h"
 #include "index/Index.h"
 #include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
@@ -62,6 +63,8 @@
   // testcases.
   std::string Header;
 
+  llvm::StringRef FileName = "TestTU.cpp";
+
   // Extra flags passed to the compilation in apply().
   std::vector ExtraArgs;
 
Index: clang-tools-extra/clangd/unittests/TweakTesting.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTesting.cpp
+++ clang-tools-extra/clangd/unittests/TweakTesting.cpp
@@ -62,12 +62,13 @@
   cantFail(positionToOffset(A.code(), SelectionRng.end))};
 }
 
-MATCHER_P5(TweakIsAvailable, TweakID, Ctx, Header, ExtraFiles, Index,
+MATCHER_P6(TweakIsAvailable, TweakID, Ctx, Header, ExtraFiles, Index, FileName,
(TweakID + (negation ? " is unavailable" : " is available")).str()) {
   std::string WrappedCode = wrap(Ctx, arg);
   Annotations Input(WrappedCode);
   auto Selection = rangeOrPoint(Input);
   TestTU TU;
+  TU.Filename = FileName;
   TU.HeaderCode = Header;
   TU.Code = Input.code();
   TU.AdditionalFiles = std::move(ExtraFiles);
@@ -89,6 +90,7 @@
   auto Selection = rangeOrPoint(Input);
 
   TestTU TU;
+  TU.Filename = FileName;
   TU.HeaderCode = Header;
   TU.AdditionalFiles = std::move(ExtraFiles);
   TU.Code = Input.code();
@@ -125,7 +127,7 @@
 
 ::testing::Matcher TweakTest::isAvailable() const {
   return TweakIsAvailable(llvm::StringRef(TweakID), Context, Header, ExtraFiles,
-  Index.get());
+  Index.get(), FileName);
 }
 
 std::vector TweakTest::expandCases(llvm::StringRef MarkedCode) {
Index: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
@@ -0,0 +1,99 @@
+//===--- DefineOutline.cpp ---*- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "HeaderSourceSwitch.h"
+#include "Path.h"
+#include "Selection.h"
+#include "refactor/Tweak.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/Stmt.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/Support/Path.h"
+
+namespace clang {
+namespace clangd {
+namespace {
+
+// Deduces the FunctionDecl from a selection. Requires either the function body
+// or the function decl to be selected. Returns null if none of the above
+// criteria is met.
+// FIXME: This is shared with define inline, 

[PATCH] D68720: Support -fstack-clash-protection for x86

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 226043.
serge-sans-paille added a comment.

Update documentation as suggested by @sylvestre.ledru 
Corner case when a write was touching memory beyond the allocated stack.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68720

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/stack-clash-protection.c
  clang/test/Driver/stack-clash-protection.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/CodeGen/TargetLowering.h
  llvm/lib/Target/X86/X86CallFrameOptimization.cpp
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86ISelLowering.h
  llvm/lib/Target/X86/X86InstrCompiler.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/test/CodeGen/X86/stack-clash-dynamic-alloca.ll
  llvm/test/CodeGen/X86/stack-clash-large.ll
  llvm/test/CodeGen/X86/stack-clash-medium-natural-probes-mutliple-objects.ll
  llvm/test/CodeGen/X86/stack-clash-medium-natural-probes.ll
  llvm/test/CodeGen/X86/stack-clash-medium.ll
  llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
  llvm/test/CodeGen/X86/stack-clash-small.ll
  llvm/test/CodeGen/X86/stack-clash-unknown-call.ll

Index: llvm/test/CodeGen/X86/stack-clash-unknown-call.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-unknown-call.ll
@@ -0,0 +1,31 @@
+; RUN: llc < %s | FileCheck %s
+
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1 immarg);
+
+define void @foo() local_unnamed_addr #0 {
+
+;CHECK-LABEL: foo:
+;CHECK: # %bb.0:
+;CHECK-NEXT:	subq	$4096, %rsp # imm = 0x1000
+; it's important that we don't use the call as a probe here
+;CHECK-NEXT:	movq	$0, (%rsp)
+;CHECK-NEXT:	subq	$3912, %rsp # imm = 0xF48
+;CHECK-NEXT:	.cfi_def_cfa_offset 8016
+;CHECK-NEXT:	movq	%rsp, %rdi
+;CHECK-NEXT:	movl	$8000, %edx # imm = 0x1F40
+;CHECK-NEXT:	xorl	%esi, %esi
+;CHECK-NEXT:	callq	memset
+;CHECK-NEXT:	addq	$8008, %rsp # imm = 0x1F48
+;CHECK-NEXT:	.cfi_def_cfa_offset 8
+;CHECK-NEXT:	retq
+
+  %a = alloca i8, i64 8000, align 16
+  call void @llvm.memset.p0i8.i64(i8* align 16 %a, i8 0, i64 8000, i1 false)
+  ret void
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
Index: llvm/test/CodeGen/X86/stack-clash-small.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-small.ll
@@ -0,0 +1,25 @@
+; RUN: llc < %s | FileCheck %s
+
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define i32 @foo() local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:  subq	$280, %rsp # imm = 0x118
+; CHECK-NEXT:  .cfi_def_cfa_offset 288
+; CHECK-NEXT:  movl	$1, 264(%rsp)
+; CHECK-NEXT:  movl	-128(%rsp), %eax
+; CHECK-NEXT:  addq	$280, %rsp # imm = 0x118
+; CHECK-NEXT:  .cfi_def_cfa_offset 8
+; CHECK-NEXT:  retq
+
+  %a = alloca i32, i64 100, align 16
+  %b = getelementptr inbounds i32, i32* %a, i64 98
+  store volatile i32 1, i32* %b
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
Index: llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
@@ -0,0 +1,27 @@
+; RUN: llc < %s | FileCheck %s
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define i32 @foo(i64 %i) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:  subq	$4096, %rsp # imm = 0x1000
+; CHECK-NEXT:  movq	$0, (%rsp)
+; CHECK-NEXT:  subq	$3784, %rsp # imm = 0xEC8
+; CHECK-NEXT:  .cfi_def_cfa_offset 7888
+; CHECK-NEXT:  movl	$1, -128(%rsp,%rdi,4)
+; CHECK-NEXT:  movl	-128(%rsp), %eax
+; CHECK-NEXT:  addq	$7880, %rsp # imm = 0x1EC8
+; CHECK-NEXT:  .cfi_def_cfa_offset 8
+; CHECK-NEXT:  retq
+
+  %a = alloca i32, i32 2000, align 16
+  %b = getelementptr inbounds i32, i32* %a, i64 %i
+  store volatile i32 1, i32* %b
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
+
Index: llvm/test/CodeGen/X86/stack-clash-medium.ll
===
--- /dev/null
+++ 

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[Haojian Wu via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/FindTarget.cpp:677
 if (const CXXCtorInitializer *CCI = N.get()) {
-  if (CCI->isBaseInitializer())
-return refInTypeLoc(CCI->getBaseClassLoc());
-  assert(CCI->isAnyMemberInitializer());
-  return {ReferenceLoc{NestedNameSpecifierLoc(),
-   CCI->getMemberLocation(),
-   /*IsDecl=*/false,
-   {CCI->getAnyMember()}}};
+  // Other type initializers (e.g. base initializer) are handled by 
visiting
+  // the typeLoc.

ilya-biryukov wrote:
> hokein wrote:
> > ilya-biryukov wrote:
> > > I believe base initializers are the only ones left, but the comment 
> > > suggests there are more cases. Maybe change to:
> > > ```
> > > // Base initializers are handled by visting the type loc.
> > > ```
> > > Or am I missing something?
> > > 
> > there are others, delegating initializers.
> Ah, interesting... Could we add them to the tests too?
it has been added in the tests already, without the change here, the test will 
trigger the `assert(CCI->isAnyMemberInitializer());`.

```
   // delegating initializer
   class $10^Foo {
 $11^Foo(int$12^);
 $13^Foo(): $14^Foo(111) {}
   };
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241



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

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:677
 if (const CXXCtorInitializer *CCI = N.get()) {
-  if (CCI->isBaseInitializer())
-return refInTypeLoc(CCI->getBaseClassLoc());
-  assert(CCI->isAnyMemberInitializer());
-  return {ReferenceLoc{NestedNameSpecifierLoc(),
-   CCI->getMemberLocation(),
-   /*IsDecl=*/false,
-   {CCI->getAnyMember()}}};
+  // Other type initializers (e.g. base initializer) are handled by 
visiting
+  // the typeLoc.

hokein wrote:
> ilya-biryukov wrote:
> > I believe base initializers are the only ones left, but the comment 
> > suggests there are more cases. Maybe change to:
> > ```
> > // Base initializers are handled by visting the type loc.
> > ```
> > Or am I missing something?
> > 
> there are others, delegating initializers.
Ah, interesting... Could we add them to the tests too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241



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

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[Haojian Wu via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/FindTarget.cpp:677
 if (const CXXCtorInitializer *CCI = N.get()) {
-  if (CCI->isBaseInitializer())
-return refInTypeLoc(CCI->getBaseClassLoc());
-  assert(CCI->isAnyMemberInitializer());
-  return {ReferenceLoc{NestedNameSpecifierLoc(),
-   CCI->getMemberLocation(),
-   /*IsDecl=*/false,
-   {CCI->getAnyMember()}}};
+  // Other type initializers (e.g. base initializer) are handled by 
visiting
+  // the typeLoc.

ilya-biryukov wrote:
> I believe base initializers are the only ones left, but the comment suggests 
> there are more cases. Maybe change to:
> ```
> // Base initializers are handled by visting the type loc.
> ```
> Or am I missing something?
> 
there are others, delegating initializers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241



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

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:677
 if (const CXXCtorInitializer *CCI = N.get()) {
-  if (CCI->isBaseInitializer())
-return refInTypeLoc(CCI->getBaseClassLoc());
-  assert(CCI->isAnyMemberInitializer());
-  return {ReferenceLoc{NestedNameSpecifierLoc(),
-   CCI->getMemberLocation(),
-   /*IsDecl=*/false,
-   {CCI->getAnyMember()}}};
+  // Other type initializers (e.g. base initializer) are handled by 
visiting
+  // the typeLoc.

I believe base initializers are the only ones left, but the comment suggests 
there are more cases. Maybe change to:
```
// Base initializers are handled by visting the type loc.
```
Or am I missing something?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241



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

[PATCH] D55125: [clang-tidy] Fix a false positive in misc-redundant-expression check

[Daniel Krupp via Phabricator via cfe-commits]

dkrupp updated this revision to Diff 226037.
dkrupp added a comment.

The patch is rebased to the latest master.


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

https://reviews.llvm.org/D55125

Files:
  clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
@@ -114,6 +114,7 @@
 
 #define COND_OP_MACRO 9
 #define COND_OP_OTHER_MACRO 9
+#define COND_OP_THIRD_MACRO COND_OP_MACRO
 int TestConditional(int x, int y) {
   int k = 0;
   k += (y < 0) ? x : x;
@@ -122,11 +123,27 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:24: warning: 'true' and 'false' expressions are equivalent
   k += (y < 0) ? COND_OP_MACRO : COND_OP_MACRO;
   // CHECK-MESSAGES: :[[@LINE-1]]:32: warning: 'true' and 'false' expressions are equivalent
+  k += (y < 0) ? COND_OP_MACRO + COND_OP_OTHER_MACRO : COND_OP_MACRO + COND_OP_OTHER_MACRO;
+  // CHECK-MESSAGES: :[[@LINE-1]]:54: warning: 'true' and 'false' expressions are equivalent
 
   // Do not match for conditional operators with a macro and a const.
   k += (y < 0) ? COND_OP_MACRO : 9;
   // Do not match for conditional operators with expressions from different macros.
   k += (y < 0) ? COND_OP_MACRO : COND_OP_OTHER_MACRO;
+  // Do not match for conditional operators when a macro is defined to another macro
+  k += (y < 0) ? COND_OP_MACRO : COND_OP_THIRD_MACRO;
+#undef COND_OP_THIRD_MACRO
+#define   COND_OP_THIRD_MACRO 8
+  k += (y < 0) ? COND_OP_MACRO : COND_OP_THIRD_MACRO;
+#undef COND_OP_THIRD_MACRO
+
+  k += (y < 0) ? sizeof(I64) : sizeof(I64);
+  // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: 'true' and 'false' expressions are equivalent
+  k += (y < 0) ? sizeof(TestConditional(k,y)) : sizeof(TestConditional(k,y));
+  // CHECK-MESSAGES: :[[@LINE-1]]:47: warning: 'true' and 'false' expressions are equivalent
+  // No warning if the expression arguments are different.
+  k += (y < 0) ? sizeof(TestConditional(k,y)) : sizeof(Valid(k,y));
+
   return k;
 }
 #undef COND_OP_MACRO
@@ -134,7 +151,7 @@
 
 // Overloaded operators that compare two instances of a struct.
 struct MyStruct {
-  int x;  
+  int x;
   bool operator==(const MyStruct& rhs) const {return this->x == rhs.x; } // not modifing
   bool operator>=(const MyStruct& rhs) const { return this->x >= rhs.x; } // not modifing
   bool operator<=(MyStruct& rhs) const { return this->x <= rhs.x; }
Index: clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
===
--- clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
+++ clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
@@ -131,6 +131,20 @@
   case Stmt::BinaryOperatorClass:
 return cast(Left)->getOpcode() ==
cast(Right)->getOpcode();
+  case Stmt::UnaryExprOrTypeTraitExprClass:
+const auto *LeftUnaryExpr =
+cast(Left);
+const auto *RightUnaryExpr =
+cast(Right);
+if (LeftUnaryExpr->isArgumentType() && RightUnaryExpr->isArgumentType())
+  return LeftUnaryExpr->getArgumentType() ==
+ RightUnaryExpr->getArgumentType();
+else if (!LeftUnaryExpr->isArgumentType() &&
+ !RightUnaryExpr->isArgumentType())
+  return areEquivalentExpr(LeftUnaryExpr->getArgumentExpr(),
+   RightUnaryExpr->getArgumentExpr());
+
+return false;
   }
 }
 
@@ -604,23 +618,62 @@
   return true;
 }
 
+static bool isSameRawIdentifierToken(const Token , const Token ,
+const SourceManager ) {
+  if (T1.getKind() != T2.getKind())
+return false;
+  if (T1.isNot(tok::raw_identifier))
+return true;
+  if (T1.getLength() != T2.getLength())
+return false;
+  return StringRef(SM.getCharacterData(T1.getLocation()), T1.getLength()) ==
+ StringRef(SM.getCharacterData(T2.getLocation()), T2.getLength());
+}
+
+bool isTokAtEndOfExpr(SourceRange ExprSR, Token T, const SourceManager ) {
+  return SM.getExpansionLoc(ExprSR.getEnd()) == T.getLocation();
+}
+
+/// Returns true if both LhsEpxr and RhsExpr are
+/// macro expressions and they are expanded
+/// from different macros.
 static bool areExprsFromDifferentMacros(const Expr *LhsExpr,
 const Expr *RhsExpr,
 const ASTContext *AstCtx) {
   if (!LhsExpr || !RhsExpr)
 return false;
-
-  SourceLocation LhsLoc = LhsExpr->getExprLoc();
-  SourceLocation RhsLoc = RhsExpr->getExprLoc();
-
-  if (!LhsLoc.isMacroID() || !RhsLoc.isMacroID())
+  SourceRange Lsr = LhsExpr->getSourceRange();
+  SourceRange Rsr = RhsExpr->getSourceRange();
+  if (!Lsr.getBegin().isMacroID() || 

[PATCH] D55125: [clang-tidy] Fix a false positive in misc-redundant-expression check

[Daniel Krupp via Phabricator via cfe-commits]

dkrupp added a comment.

@aaron.ballman  could you please check now? Thanks!


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

https://reviews.llvm.org/D55125



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

[PATCH] D69297: [ARM][AArch64] Implement __arm_rsrf, __arm_rsrf64, __arm_wsrf & __arm_wsrf64

[Momchil Velikov via Phabricator via cfe-commits]

chill added a comment.

I'm a bit unsure how much we're willing to pollute the namespace: in this 
particular case looking at the four `__bitcast_*` functions.
I appreciate that getting rid of them would  require emitting LLVM IR bitcasts, 
so a bit more effort compared to the macro approach.

Comments?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69297



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

[PATCH] D68877: [AArch64][SVE] Implement masked load intrinsics

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

Thanks!

It looks like the only supported parameter of the PassThru here is a splat of 0 
or undef. This might get in the way of IR level optimisation that could try to 
producing a masked load with different passthru, which would then fail to 
select. The ARM backed added a custom lowering to turn this case into a select 
of the loaded value and the passthru. Like this, which was further modified in 
later commits:
https://github.com/llvm/llvm-project/commit/b325c057322ce14b5c561d8ac49508adab7649e5#diff-b853ecd5d5e0f73c2c093ffb5b4f2fbbR8855
That way you only have to check on the zero, not undef. I'm not sure if there 
is support yet for vector selects in the SVE codegen?

I was also expecting something that says "setOperationAction(ISD::MLOAD, VT, 
Legal)" somewhere, but I guess that's already the default?




Comment at: llvm/lib/Target/AArch64/SVEInstrFormats.td:4753
+  let hasSideEffects = 1, hasNoSchedulingInfo = 1, mayLoad = 1 in {
+  def "" : Pseudo<(outs listty:$Zt), (ins PPR3bAny:$Pg, GPR64sp:$Rn, 
simm4s1:$imm4), []>,
+   PseudoInstExpansion<(!cast(NAME # _REAL) listty:$Zt, 
PPR3bAny:$Pg, GPR64sp:$Rn, simm4s1:$imm4)>;

Can you explain why is this pseudo is needed, exactly? I feel that using 
pseudos is often the wrong solution to a problem (it may be required here, I'm 
just sure why exactly).

We currently seem to generate ld1b (for example), over ldnf1b. Is there ever a 
time that we expect to generate a nf load?


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

https://reviews.llvm.org/D68877



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

[PATCH] D69266: [clangd] Define out-of-line availability checks

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

the patch looks mostly good. would be interesting to see `apply` implementation.




Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:29
+// criteria is met.
+const FunctionDecl *getSelectedFunction(const SelectionTree::Node *SelNode) {
+  if (!SelNode)

nit: looks like we also a similar version in `DefineInline`? would be nice if 
we could share the implementation. I don't have a good idea where to put it, 
maybe add a FIXME?



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:44
+/// Moves definition of a function/method to an appropriate implementation 
file.
+/// If current file is already an implementation file, tries to move the
+/// definition out-of-line.

I'm not sure this is useful in general: saying in .cc we have a single 
definition `void foo() {}`, after running the code action, we will end up with 
`void foo(); void foo() {}`.

If we want to do this, I think we may make it only available for inline class 
methods.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:75
+
+// Bail out if we are not in a header file.
+// FIXME: We might want to consider moving method definitions below class

The bail-out here seems violating the above comment `/// If current file is 
already an implementation file, tries to move the definition out-of-line`.  
Basically, now we only allow moving the function definition to a .cc file.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp:78
+// definition even if we are inside a source file.
+auto Type = driver::types::lookupTypeForExtension(
+llvm::sys::path::extension(FileName).substr(1));

I think we can use `AST.getASTContext().getLangOpts().IsHeaderFile;` to detect 
the header file rather than relying on the filename extension.



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:1552
+class Bar {
+  void baz();
+};

could you add a testcase where the method is inline? like

```
class Bar {
  void baz2() { return; }
}
``` 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69266



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

[PATCH] D69298: [clangd] Define out-of-line initial apply logic

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added a reviewer: hokein.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Initial implementation for apply logic, replaces function body with a
semicolon in source location and copies the full function definition into target
location.

Will handle qualification of return type and function name in following patches
to keep the changes small.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69298

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -1561,6 +1561,21 @@
 })cpp");
 }
 
+TEST_F(DefineOutlineTest, ApplyTest) {
+  FileName = "Test.hpp";
+
+  // No implementation file.
+  EXPECT_EQ(apply("void fo^o() { return; }"),
+"fail: Couldn't find a suitable implementation file.");
+
+  llvm::StringMap EditedFiles;
+  ExtraFiles["Test.cpp"] = "";
+  EXPECT_EQ(apply("void fo^o() { return; }", ), "void foo() ;");
+  EXPECT_THAT(EditedFiles,
+  testing::ElementsAre(FileWithContents(testPath("Test.cpp"),
+"void foo() { return; }")));
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
@@ -9,14 +9,18 @@
 #include "HeaderSourceSwitch.h"
 #include "Path.h"
 #include "Selection.h"
+#include "SourceCode.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/Stmt.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Driver/Types.h"
+#include "clang/Tooling/Core/Replacement.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
 #include "llvm/Support/Path.h"
 
 namespace clang {
@@ -40,6 +44,29 @@
   return nullptr;
 }
 
+llvm::Optional getSourceFile(llvm::StringRef FileName,
+   const Tweak::Selection ) {
+  if (auto Source = getCorrespondingHeaderOrSource(
+  FileName,
+  ().getFileManager().getVirtualFileSystem()))
+return *Source;
+  return getCorrespondingHeaderOrSource(FileName, Sel.AST, Sel.Index);
+}
+
+// Creates a modified version of function definition that can be inserted at a
+// different location. Contains both function signature and body.
+llvm::Optional moveFunctionDef(const FunctionDecl *FD) {
+  auto  = FD->getASTContext().getSourceManager();
+  auto CharRange = toHalfOpenFileRange(SM, FD->getASTContext().getLangOpts(),
+   FD->getSourceRange());
+  if (!CharRange)
+return llvm::None;
+
+  // FIXME: Qualify return type.
+  // FIXME: Qualify function name depending on the target context.
+  return toSourceCode(SM, *CharRange);
+}
+
 /// Moves definition of a function/method to an appropriate implementation file.
 /// If current file is already an implementation file, tries to move the
 /// definition out-of-line.
@@ -70,7 +97,7 @@
 
   bool prepare(const Selection ) override {
 const SourceManager  = Sel.AST.getSourceManager();
-llvm::StringRef FileName = SM.getFilename(Sel.Cursor);
+FileName = SM.getFilename(Sel.Cursor);
 
 // Bail out if we are not in a header file.
 // FIXME: We might want to consider moving method definitions below class
@@ -93,12 +120,68 @@
   }
 
   Expected apply(const Selection ) override {
-return llvm::createStringError(llvm::inconvertibleErrorCode(),
-   "Not implemented yet");
+auto SourceFile = getSourceFile(FileName, Sel);
+if (!SourceFile)
+  return llvm::createStringError(
+  llvm::inconvertibleErrorCode(),
+  "Couldn't find a suitable implementation file.");
+
+auto  =
+Sel.AST.getSourceManager().getFileManager().getVirtualFileSystem();
+auto Buffer = FS.getBufferForFile(*SourceFile);
+// FIXME: Maybe we should consider creating the implementation file if it
+// doesn't exist?
+if (!Buffer)
+  return llvm::createStringError(Buffer.getError(),
+ Buffer.getError().message());
+auto Contents = Buffer->get()->getBuffer();
+auto Region =
+getEligiblePoints(Contents, Source->getQualifiedNameAsString(),
+  getFormatStyleForFile(*SourceFile, Contents, ));
+
+assert(!Region.EligiblePoints.empty());
+// FIXME: This selection can be made smarter by 

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[pre-merge checks [bot] via Phabricator via cfe-commits]

merge_guards_bot added a comment.

Build result: fail - 59521 tests passed, 1 failed and 805 were skipped.

  failed: LLVM.tools/llvm-ar/mri-utf8.test

Log files: cmake-log.txt 
, 
ninja_check_all-log.txt 
, 
CMakeCache.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241



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

[PATCH] D69297: [ARM][AArch64] Implement __arm_rsrf, __arm_rsrf64, __arm_wsrf & __arm_wsrf64

[Victor Campos via Phabricator via cfe-commits]

vhscampos updated this revision to Diff 226015.
vhscampos added a comment.

Run clang-format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69297

Files:
  clang/lib/Headers/arm_acle.h
  clang/test/CodeGen/arm_acle.c

Index: clang/test/CodeGen/arm_acle.c
===
--- clang/test/CodeGen/arm_acle.c
+++ clang/test/CodeGen/arm_acle.c
@@ -822,6 +822,55 @@
   __arm_wsrp("sysreg", v);
 }
 
+// ARM-LABEL: test_rsrf
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i32 @llvm.read_register.i32(metadata ![[M2:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+float test_rsrf() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf("cp1:2:c3:c4:5");
+#else
+  return __arm_rsrf("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_rsrf64
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i64 @llvm.read_register.i64(metadata ![[M3:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+double test_rsrf64() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf64("cp1:2:c3");
+#else
+  return __arm_rsrf64("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_wsrf
+// ARM-NOT: fptoui
+// ARM: bitcast
+// AArch64: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 %{{.*}})
+// AArch32: call void @llvm.write_register.i32(metadata ![[M2:[0-9]]], i32 %{{.*}})
+void test_wsrf(float v) {
+#ifdef __ARM_32BIT_STATE
+  __arm_wsrf("cp1:2:c3:c4:5", v);
+#else
+  __arm_wsrf("1:2:3:4:5", v);
+#endif
+}
+// ARM-LABEL: test_wsrf64
+// ARM-NOT: fptoui
+// ARM: bitcast
+// AArch64: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 %{{.*}})
+// AArch32: call void @llvm.write_register.i64(metadata ![[M3:[0-9]]], i64 %{{.*}})
+void test_wsrf64(double v) {
+#ifdef __ARM_32BIT_STATE
+  __arm_wsrf64("cp1:2:c3", v);
+#else
+  __arm_wsrf64("1:2:3:4:5", v);
+#endif
+}
+
 // AArch32: ![[M2]] = !{!"cp1:2:c3:c4:5"}
 // AArch32: ![[M3]] = !{!"cp1:2:c3"}
 // AArch32: ![[M4]] = !{!"sysreg"}
Index: clang/lib/Headers/arm_acle.h
===
--- clang/lib/Headers/arm_acle.h
+++ clang/lib/Headers/arm_acle.h
@@ -613,6 +613,38 @@
 #define __arm_wsr64(sysreg, v) __builtin_arm_wsr64(sysreg, v)
 #define __arm_wsrp(sysreg, v) __builtin_arm_wsrp(sysreg, v)
 
+static __inline__ float __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_float_from_uint32(uint32_t __from) {
+  float __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+static __inline__ uint32_t __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_uint32_from_float(float __from) {
+  uint32_t __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+static __inline__ double __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_double_from_uint64(uint64_t __from) {
+  double __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+static __inline__ uint64_t __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_uint64_from_double(double __from) {
+  uint64_t __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+#define __arm_rsrf(sysreg) __bit_cast_to_float_from_uint32(__arm_rsr(sysreg))
+#define __arm_wsrf(sysreg, v)  \
+  __arm_wsr(sysreg, __bit_cast_to_uint32_from_float(v))
+#define __arm_rsrf64(sysreg)   \
+  __bit_cast_to_double_from_uint64(__arm_rsr64(sysreg))
+#define __arm_wsrf64(sysreg, v)\
+  __arm_wsr64(sysreg, __bit_cast_to_uint64_from_double(v))
+
 /* Memory Tagging Extensions (MTE) Intrinsics */
 #if __ARM_FEATURE_MEMORY_TAGGING
 #define __arm_mte_create_random_tag(__ptr, __mask)  __builtin_arm_irg(__ptr, __mask)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69297: [ARM][AArch64] Implement __arm_rsrf, __arm_rsrf64, __arm_wsrf & __arm_wsrf64

[Victor Campos via Phabricator via cfe-commits]

vhscampos created this revision.
Herald added subscribers: cfe-commits, kristof.beyls.
Herald added a project: clang.

Adding support for ACLE intrinsics.

Patch by Michael Platings.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69297

Files:
  clang/lib/Headers/arm_acle.h
  clang/test/CodeGen/arm_acle.c


Index: clang/test/CodeGen/arm_acle.c
===
--- clang/test/CodeGen/arm_acle.c
+++ clang/test/CodeGen/arm_acle.c
@@ -822,6 +822,55 @@
   __arm_wsrp("sysreg", v);
 }
 
+// ARM-LABEL: test_rsrf
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i32 @llvm.read_register.i32(metadata ![[M2:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+float test_rsrf() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf("cp1:2:c3:c4:5");
+#else
+  return __arm_rsrf("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_rsrf64
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i64 @llvm.read_register.i64(metadata ![[M3:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+double test_rsrf64() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf64("cp1:2:c3");
+#else
+  return __arm_rsrf64("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_wsrf
+// ARM-NOT: fptoui
+// ARM: bitcast
+// AArch64: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 
%{{.*}})
+// AArch32: call void @llvm.write_register.i32(metadata ![[M2:[0-9]]], i32 
%{{.*}})
+void test_wsrf(float v) {
+#ifdef __ARM_32BIT_STATE
+  __arm_wsrf("cp1:2:c3:c4:5", v);
+#else
+  __arm_wsrf("1:2:3:4:5", v);
+#endif
+}
+// ARM-LABEL: test_wsrf64
+// ARM-NOT: fptoui
+// ARM: bitcast
+// AArch64: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 
%{{.*}})
+// AArch32: call void @llvm.write_register.i64(metadata ![[M3:[0-9]]], i64 
%{{.*}})
+void test_wsrf64(double v) {
+#ifdef __ARM_32BIT_STATE
+  __arm_wsrf64("cp1:2:c3", v);
+#else
+  __arm_wsrf64("1:2:3:4:5", v);
+#endif
+}
+
 // AArch32: ![[M2]] = !{!"cp1:2:c3:c4:5"}
 // AArch32: ![[M3]] = !{!"cp1:2:c3"}
 // AArch32: ![[M4]] = !{!"sysreg"}
Index: clang/lib/Headers/arm_acle.h
===
--- clang/lib/Headers/arm_acle.h
+++ clang/lib/Headers/arm_acle.h
@@ -613,6 +613,35 @@
 #define __arm_wsr64(sysreg, v) __builtin_arm_wsr64(sysreg, v)
 #define __arm_wsrp(sysreg, v) __builtin_arm_wsrp(sysreg, v)
 
+static __inline__ float __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_float_from_uint32(uint32_t __from) {
+  float __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+static __inline__ uint32_t __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_uint32_from_float(float __from) {
+  uint32_t __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+static __inline__ double __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_double_from_uint64(uint64_t __from) {
+  double __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+static __inline__ uint64_t __attribute__((__always_inline__, __nodebug__))
+__bit_cast_to_uint64_from_double(double __from) {
+  uint64_t __to;
+  __builtin_memcpy(&__to, &__from, sizeof(__to));
+  return __to;
+}
+#define __arm_rsrf(sysreg) __bit_cast_to_float_from_uint32(__arm_rsr(sysreg))
+#define __arm_wsrf(sysreg, v) __arm_wsr(sysreg, 
__bit_cast_to_uint32_from_float(v))
+#define __arm_rsrf64(sysreg) 
__bit_cast_to_double_from_uint64(__arm_rsr64(sysreg))
+#define __arm_wsrf64(sysreg, v) __arm_wsr64(sysreg, 
__bit_cast_to_uint64_from_double(v))
+
 /* Memory Tagging Extensions (MTE) Intrinsics */
 #if __ARM_FEATURE_MEMORY_TAGGING
 #define __arm_mte_create_random_tag(__ptr, __mask)  __builtin_arm_irg(__ptr, 
__mask)


Index: clang/test/CodeGen/arm_acle.c
===
--- clang/test/CodeGen/arm_acle.c
+++ clang/test/CodeGen/arm_acle.c
@@ -822,6 +822,55 @@
   __arm_wsrp("sysreg", v);
 }
 
+// ARM-LABEL: test_rsrf
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i32 @llvm.read_register.i32(metadata ![[M2:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+float test_rsrf() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf("cp1:2:c3:c4:5");
+#else
+  return __arm_rsrf("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_rsrf64
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i64 @llvm.read_register.i64(metadata ![[M3:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+double test_rsrf64() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf64("cp1:2:c3");
+#else
+  return __arm_rsrf64("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_wsrf
+// ARM-NOT: fptoui
+// ARM: bitcast
+// AArch64: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 %{{.*}})
+// AArch32: call void @llvm.write_register.i32(metadata ![[M2:[0-9]]], i32 %{{.*}})
+void test_wsrf(float v) {
+#ifdef __ARM_32BIT_STATE
+  

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

In D69241#1716787 , @ilya-biryukov 
wrote:

> NIT: there's a typo in the revision title: should be **constructor**, not 
> **consturctor**


Done.




Comment at: clang-tools-extra/clangd/unittests/FindTargetTests.cpp:844
+int $1^abc;
+$2^X(): $3^abc() {}
+  };

ilya-biryukov wrote:
> Could you also add a test with the initializer containing a base class? It 
> produces a different kind of `CXXConstructorInitializer`
Done.

While adding more tests, I discover some issues in the implementation, also 
fixed them in this patch, please review the patch again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241



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

[PATCH] D69241: [clangd] Handle the missing constructor initializers in findExplicitReferences.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 226013.
hokein marked 2 inline comments as done.
hokein added a comment.

- fix some issues in the existing implementation;
- add tests for base/delegating initializer;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69241

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -812,6 +812,7 @@
"1: targets = {func}\n"
"2: targets = {w}, decl\n"
"3: targets = {FuncParam}\n"},
+  // declaration references.
   {R"cpp(
  namespace ns {}
  class S {};
@@ -835,6 +836,44 @@
"8: targets = {INT2}, decl\n"
"9: targets = {NS}, decl\n"
"10: targets = {ns}\n"},
+  // cxx constructor initializer.
+  {R"cpp(
+ class Base {};
+ void foo() {
+   // member initializer
+   class $0^X {
+ int $1^abc;
+ $2^X(): $3^abc() {}
+   };
+   // base initializer
+   class $4^Derived : public $5^Base {
+ $6^Base $7^B;
+ $8^Derived() : $9^Base() {}
+   };
+   // delegating initializer
+   class $10^Foo {
+ $11^Foo(int$12^);
+ $13^Foo(): $14^Foo(111) {}
+   };
+ }
+   )cpp",
+   "0: targets = {X}, decl\n"
+   "1: targets = {foo()::X::abc}, decl\n"
+   "2: targets = {foo()::X::X}, decl\n"
+   "3: targets = {foo()::X::abc}\n"
+   "4: targets = {Derived}, decl\n"
+   "5: targets = {Base}\n"
+   "6: targets = {Base}\n"
+   "7: targets = {foo()::Derived::B}, decl\n"
+   "8: targets = {foo()::Derived::Derived}, decl\n"
+   "9: targets = {Base}\n"
+   "10: targets = {Foo}, decl\n"
+   "11: targets = {foo()::Foo::Foo}, decl\n"
+   // FIXME: we should exclude the built-in type.
+   "12: targets = {}, decl\n"
+   "13: targets = {foo()::Foo::Foo}, decl\n"
+   "14: targets = {Foo}\n"},
+
   };
 
   for (const auto  : Cases) {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -642,6 +642,11 @@
 return RecursiveASTVisitor::TraverseNestedNameSpecifierLoc(L);
   }
 
+  bool TraverseConstructorInitializer(CXXCtorInitializer *Init) {
+visitNode(DynTypedNode::create(*Init));
+return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
+  }
+
 private:
   /// Obtain information about a reference directly defined in \p N. Does not
   /// recurse into child nodes, e.g. do not expect references for constructor
@@ -669,13 +674,14 @@
 if (const TypeLoc *TL = N.get())
   return refInTypeLoc(*TL);
 if (const CXXCtorInitializer *CCI = N.get()) {
-  if (CCI->isBaseInitializer())
-return refInTypeLoc(CCI->getBaseClassLoc());
-  assert(CCI->isAnyMemberInitializer());
-  return {ReferenceLoc{NestedNameSpecifierLoc(),
-   CCI->getMemberLocation(),
-   /*IsDecl=*/false,
-   {CCI->getAnyMember()}}};
+  // Other type initializers (e.g. base initializer) are handled by 
visiting
+  // the typeLoc.
+  if (CCI->isAnyMemberInitializer()) {
+return {ReferenceLoc{NestedNameSpecifierLoc(),
+ CCI->getMemberLocation(),
+ /*IsDecl=*/false,
+ {CCI->getAnyMember()}}};
+  }
 }
 // We do not have location information for other nodes (QualType, etc)
 return {};


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -812,6 +812,7 @@
"1: targets = {func}\n"
"2: targets = {w}, decl\n"
"3: targets = {FuncParam}\n"},
+  // declaration references.
   {R"cpp(
  namespace ns {}
  class S {};
@@ -835,6 +836,44 @@
"8: targets = {INT2}, decl\n"
"9: targets = {NS}, decl\n"
"10: targets = {ns}\n"},
+  // cxx constructor initializer.
+  {R"cpp(
+ class Base {};
+ void foo() {
+   // member initializer
+   class $0^X {
+  

[PATCH] D69250: [ARM][AArch64] Implement __cls and __clsl intrinsics from ACLE

[Victor Campos via Phabricator via cfe-commits]

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



Comment at: clang/lib/Headers/arm_acle.h:150
+__clsl(unsigned long __t) {
+#if __SIZEOF_LONG__ == 4
+  return __builtin_arm_cls(__t);

compnerd wrote:
> I don't see a pattern match for the `cls64` on ARM32, would that not fail to 
> lower?
Yes. However, for now, I am not enabling support for `cls64` on ARM32 as it is 
not done yet.



Comment at: clang/lib/Headers/arm_acle.h:155
+#endif
+}
+

compnerd wrote:
> Should we have a `__clsll` extension, otherwise these two are the same in 
> LLP64?  I'm thinking about the LLP64 environments, where `long` and `long 
> long` are different (32-bit vs 64-bit).
ACLE does provide a `long long` version of `cls` called `__clsll`. But since 
the support for `cls64` on Arm32 is not done yet, I decided not to write 
support for `__clsll`. If I did, it would work for 64-bit but not for 32-bit.

Please let me know what you think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69250



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

[PATCH] D68028: [clang] Add no_builtin attribute

[Guillaume Chatelet via Phabricator via cfe-commits]

gchatelet marked an inline comment as done.
gchatelet added a comment.

LGTY @aaron.ballman ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68028



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

[clang] ecc9991 - [FrontendTests] Try again to make test not write an output file

[Benjamin Kramer via cfe-commits]

Author: Benjamin Kramer
Date: 2019-10-22T08:44:34Z
New Revision: ecc999101aadc8dc7d4af9fd88be10fe42674aa0

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

LOG: [FrontendTests] Try again to make test not write an output file

Setting the output stream to nulls seems to work.

llvm-svn: 375491

Added: 


Modified: 
clang/unittests/Frontend/OutputStreamTest.cpp

Removed: 




diff  --git a/clang/unittests/Frontend/OutputStreamTest.cpp 
b/clang/unittests/Frontend/OutputStreamTest.cpp
index 14537ecdc56c..6a867bf053cb 100644
--- a/clang/unittests/Frontend/OutputStreamTest.cpp
+++ b/clang/unittests/Frontend/OutputStreamTest.cpp
@@ -58,6 +58,7 @@ TEST(FrontendOutputTests, TestVerboseOutputStreamShared) {
   std::string VerboseBuffer;
   raw_string_ostream VerboseStream(VerboseBuffer);
 
+  Compiler.setOutputStream(std::make_unique());
   Compiler.setInvocation(std::move(Invocation));
   IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
   Compiler.createDiagnostics(
@@ -86,6 +87,7 @@ TEST(FrontendOutputTests, TestVerboseOutputStreamOwned) {
 std::unique_ptr VerboseStream =
 std::make_unique(VerboseBuffer);
 
+Compiler.setOutputStream(std::make_unique());
 Compiler.setInvocation(std::move(Invocation));
 IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
 Compiler.createDiagnostics(



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

[clang] 2108a97 - Revert "[FrontendTests] Don't actually run the full compiler, parsing is sufficient."

[Benjamin Kramer via cfe-commits]

Author: Benjamin Kramer
Date: 2019-10-22T08:37:15Z
New Revision: 2108a974f78afe5b098758e1a517cd159dcae95c

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

LOG: Revert "[FrontendTests] Don't actually run the full compiler, parsing is 
sufficient."

This reverts commit 375488.

llvm-svn: 375489

Added: 


Modified: 
clang/unittests/Frontend/OutputStreamTest.cpp

Removed: 




diff  --git a/clang/unittests/Frontend/OutputStreamTest.cpp 
b/clang/unittests/Frontend/OutputStreamTest.cpp
index e83b1dd97588..14537ecdc56c 100644
--- a/clang/unittests/Frontend/OutputStreamTest.cpp
+++ b/clang/unittests/Frontend/OutputStreamTest.cpp
@@ -27,7 +27,7 @@ TEST(FrontendOutputTests, TestOutputStream) {
   "test.cc", MemoryBuffer::getMemBuffer("").release());
   Invocation->getFrontendOpts().Inputs.push_back(
   FrontendInputFile("test.cc", Language::CXX));
-  Invocation->getFrontendOpts().ProgramAction = ParseSyntaxOnly;
+  Invocation->getFrontendOpts().ProgramAction = EmitBC;
   Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance Compiler;
 
@@ -51,7 +51,7 @@ TEST(FrontendOutputTests, TestVerboseOutputStreamShared) {
   "test.cc", MemoryBuffer::getMemBuffer("invalid").release());
   Invocation->getFrontendOpts().Inputs.push_back(
   FrontendInputFile("test.cc", Language::CXX));
-  Invocation->getFrontendOpts().ProgramAction = ParseSyntaxOnly;
+  Invocation->getFrontendOpts().ProgramAction = EmitBC;
   Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance Compiler;
 



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

[PATCH] D68362: [libunwind][RISCV] Add 64-bit RISC-V support

[Luís Marques via Phabricator via cfe-commits]

luismarques requested changes to this revision.
luismarques added inline comments.
This revision now requires changes to proceed.



Comment at: libunwind/include/__libunwind_config.h:26
 #define _LIBUNWIND_HIGHEST_DWARF_REGISTER_SPARC 31
+#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_RISCV 63
 

The highest dwarf register number is 64, the Alternate Frame Return Column. See 
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#dwarf-register-numbers-


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

https://reviews.llvm.org/D68362



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

[PATCH] D69215: [DWARF5] Added support for deleted C++ special member functions.

[Sourabh Singh Tomar via Phabricator via cfe-commits]

SouraVX updated this revision to Diff 226004.
SouraVX added a comment.

Updated the documentation for this new flag.


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

https://reviews.llvm.org/D69215

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-deleted.cpp
  llvm/docs/SourceLevelDebugging.rst
  llvm/include/llvm/BinaryFormat/Dwarf.h
  llvm/include/llvm/IR/DebugInfoFlags.def
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/BinaryFormat/Dwarf.cpp
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/X86/DW_AT_deleted.ll

Index: llvm/test/DebugInfo/X86/DW_AT_deleted.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/X86/DW_AT_deleted.ll
@@ -0,0 +1,110 @@
+; RUN: llc < %s -filetype=obj -o %t
+; RUN: llvm-dwarfdump -v %t | FileCheck %s
+
+; C++ source to regenerate:
+; class deleted {
+; public:
+;   // Defaulted on purpose, so as to facilitate object creation
+;deleted() = default;
+; 
+;   deleted(const deleted &) = delete;
+;   deleted =(const deleted &) = delete;
+; 
+;   deleted(deleted &&) = delete;
+;   deleted =(deleted &&) = delete;
+; 
+;   ~deleted() = default;
+; };
+; 
+; void foo() {
+;   deleted obj1;
+; }
+; $ clang++ -O0 -g -gdwarf-5 debug-info-deleted.cpp -c
+
+
+; CHECK: .debug_abbrev contents:
+
+; CHECK: [7] DW_TAG_subprogram   DW_CHILDREN_yes
+; CHECK: DW_AT_deleted   DW_FORM_flag_present
+; CHECK: [9] DW_TAG_subprogram   DW_CHILDREN_yes
+; CHECK: DW_AT_deleted   DW_FORM_flag_present
+
+; CHECK: .debug_info contents:
+
+; CHECK: DW_TAG_subprogram [7]
+; CHECK-NEXT: DW_AT_name [DW_FORM_strx1](indexed (0006) string = "deleted") 
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; CHECK: DW_TAG_subprogram [9]
+; CHECK-NEXT: DW_AT_linkage_name [DW_FORM_strx1](indexed (0007) string = "_ZN7deletedaSERKS_") 
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; CHECK: DW_TAG_subprogram [7]
+; CHECK-NEXT: DW_AT_name [DW_FORM_strx1](indexed (0006) string = "deleted") 
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; CHECK: DW_TAG_subprogram [9]
+; CHECK-NEXT: DW_AT_linkage_name [DW_FORM_strx1](indexed (0009) string = "_ZN7deletedaSEOS_")
+; CHECK-NEXT: DW_AT_name [DW_FORM_strx1](indexed (0008) string = "operator=")
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; ModuleID = 'debug-info-deleted.cpp'
+source_filename = "debug-info-deleted.cpp"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+%class.deleted = type { i8 }
+
+; Function Attrs: noinline nounwind optnone uwtable
+define dso_local void @_Z3foov() #0 !dbg !7 {
+  %1 = alloca %class.deleted, align 1
+  call void @llvm.dbg.declare(metadata %class.deleted* %1, metadata !10, metadata !DIExpression()), !dbg !34
+  ret void, !dbg !35
+}
+
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+attributes #0 = { noinline nounwind optnone uwtable }
+attributes #1 = { nounwind readnone speculatable willreturn }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 10.0.0 (https://github.com/llvm/llvm-project.git 715c47d5de9aa8860050992a7aaf27dca53f7f4a)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
+!1 = !DIFile(filename: "debug-info-deleted.cpp", directory: "/home/sourabh/work/dwarf/c_c++/c++11", checksumkind: CSK_MD5, checksum: "49dc56907586479c64634558b060292d")
+!2 = !{}
+!3 = !{i32 2, !"Dwarf Version", i32 5}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{!"clang version 10.0.0 (https://github.com/llvm/llvm-project.git 715c47d5de9aa8860050992a7aaf27dca53f7f4a)"}
+!7 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov", scope: !1, file: !1, line: 14, type: !8, scopeLine: 14, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!8 = !DISubroutineType(types: !9)
+!9 = !{null}
+!10 = !DILocalVariable(name: "obj1", scope: !7, file: !1, line: 15, type: !11)
+!11 = distinct !DICompositeType(tag: DW_TAG_class_type, name: "deleted", file: !1, line: 1, size: 8, flags: DIFlagTypePassByReference, elements: !12, identifier: "_ZTS7deleted")
+!12 = !{!13, !17, !22, !26, !30, !33}
+!13 = !DISubprogram(name: "deleted", scope: !11, file: !1, line: 3, type: !14, scopeLine: 3, flags: DIFlagPublic | DIFlagPrototyped, spFlags: 0)
+!14 = !DISubroutineType(types: !15)
+!15 = !{null, !16}
+!16 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64, flags: DIFlagArtificial | DIFlagObjectPointer)
+!17 = !DISubprogram(name: "deleted", scope: !11, file: !1, line: 5, type: !18, scopeLine: 5, flags: DIFlagPublic | DIFlagPrototyped, 

[PATCH] D69237: Refactor getDeclAtPosition() to use SelectionTree + targetDecl()

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/XRefs.cpp:139
+// that constructor. FIXME(nridge): this should probably be handled in
+// targetDecl() itself.
+const CXXConstructorDecl *findCalledConstructor(const SelectionTree::Node *N) {

sammccall wrote:
> nridge wrote:
> > I would appreciate some tips on how we could handle this in `targetDecl()`. 
> > Please see more specific comments below.
> My thinking is basically:
>  - C++ syntax is vague and doesn't give us great ways of referring directly 
> to constructors.
>  - there's value to simplicity, and I've found go-to-definition additionally 
> finding implicit nodes to be confusing as often as useful. I think on balance 
> and given the constraints of LSP, we should consider dropping this and having 
> implicit references be returned by find-refs but not targetable by 
> go-to-def/hover/etc. It's OK for simplicity of implementation to be a concern 
> here.
>  - the node that targets the constructor is the CXXConstructExpr. Treating 
> the VarDecl conditionally as a reference to the constructor, while clever, 
> seems like a hack. Ideally the fix is to make SelectionTree yield the 
> CXXConstructExpr, not to change TargetDecl.
>  - CXXConstructExpr is only sometimes implicit. SelectionTree should return 
> it for the parens in `Foo()` or `Foo x()`. And ideally for the equals in `Foo 
> x = {}`, though I think there's no CXXConstructExpr in the AST in that case 
> :-(
>  - When the AST modelling is bad (as it seems to be for some aspects 
> CXXConstructExpr) we should consider accepting some glitches and trying to 
> improve things in clang if they're important. Hacking around them will lead 
> to inconsistencies between different clangd features.
> 
> The TL;DR is I think I'd be happy to drop this special case and try to make 
> SelectionTree surface CXXConstructExpr more often, even if it changes some 
> behavior.
+1 to the idea of landing this and changing behavior.
I don't think we're loosing much in terms of functionality and I personally 
like the new code much more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69237



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

[PATCH] D67763: [Clang FE] Recognize -mnop-mcount CL option

[Jonas Paulsson via Phabricator via cfe-commits]

jonpa added a comment.

ping!


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

https://reviews.llvm.org/D67763



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

[clang] 3ca2b17 - [FrontendTests] Don't actually run the full compiler, parsing is sufficient.

[Benjamin Kramer via cfe-commits]

Author: Benjamin Kramer
Date: 2019-10-22T08:10:51Z
New Revision: 3ca2b17f847d0615f7e0d4fdd8040f3abfde941e

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

LOG: [FrontendTests] Don't actually run the full compiler, parsing is 
sufficient.

llvm-svn: 375488

Added: 


Modified: 
clang/unittests/Frontend/OutputStreamTest.cpp

Removed: 




diff  --git a/clang/unittests/Frontend/OutputStreamTest.cpp 
b/clang/unittests/Frontend/OutputStreamTest.cpp
index 14537ecdc56c..e83b1dd97588 100644
--- a/clang/unittests/Frontend/OutputStreamTest.cpp
+++ b/clang/unittests/Frontend/OutputStreamTest.cpp
@@ -27,7 +27,7 @@ TEST(FrontendOutputTests, TestOutputStream) {
   "test.cc", MemoryBuffer::getMemBuffer("").release());
   Invocation->getFrontendOpts().Inputs.push_back(
   FrontendInputFile("test.cc", Language::CXX));
-  Invocation->getFrontendOpts().ProgramAction = EmitBC;
+  Invocation->getFrontendOpts().ProgramAction = ParseSyntaxOnly;
   Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance Compiler;
 
@@ -51,7 +51,7 @@ TEST(FrontendOutputTests, TestVerboseOutputStreamShared) {
   "test.cc", MemoryBuffer::getMemBuffer("invalid").release());
   Invocation->getFrontendOpts().Inputs.push_back(
   FrontendInputFile("test.cc", Language::CXX));
-  Invocation->getFrontendOpts().ProgramAction = EmitBC;
+  Invocation->getFrontendOpts().ProgramAction = ParseSyntaxOnly;
   Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance Compiler;
 



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

[clang] 64226b2 - [clang-fuzzer] Update proto fuzzer example for r375453.

[Benjamin Kramer via cfe-commits]

Author: Benjamin Kramer
Date: 2019-10-22T07:51:37Z
New Revision: 64226b2df66741a97b6095ae1373154b29d2619e

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

LOG: [clang-fuzzer] Update proto fuzzer example for r375453.

llvm-svn: 375487

Added: 


Modified: 
clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp

Removed: 




diff  --git a/clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp 
b/clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
index 651f5c99a883..1d9636e6f608 100644
--- a/clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
+++ b/clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
@@ -23,5 +23,5 @@ using namespace clang_fuzzer;
 
 DEFINE_BINARY_PROTO_FUZZER(const Function& input) {
   auto S = FunctionToString(input);
-  HandleCXX(S, GetCLArgs());
+  HandleCXX(S, "./test.cc", GetCLArgs());
 }



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

[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff marked an inline comment as done.
sepavloff added a comment.

Try to organize replies for better references.

**Background**

According to the current design, if floating point operations are represented 
by constrained intrinsics somewhere in a function, constrained intrinsics must 
be used in entire function, including inlined function calls 
(http://lists.llvm.org/pipermail/cfe-dev/2017-August/055325.html). As 
constrained intrunsics do not participate in optimizations, this may lead to 
performance drop (discussed in 
http://lists.llvm.org/pipermail/llvm-dev/2019-August/134641.html). There was an 
attempt to alleviate this issue using basic block attributes, but this approach 
was rejected 
(http://lists.llvm.org/pipermail/llvm-dev/2019-October/135623.html).

In this case allowing `#pragma STDC FENV_ACCESS` at function level seems a good 
compromise between performance and flexibility. Users get possibility to use 
non-standard floating point environment and performance impact is limited to 
the scope  of one function and that scope is controlled by user.

The more general solution, where `#pragma STDC FENV_ACCESS` is allowed in any 
block inside a function, as the standard requires, would require extending the 
scope where constrained intrinsics are used. It would result in performance 
drop, which is unacceptable in many cases. There are ideas to implement the 
general case using outlining 
(http://lists.llvm.org/pipermail/llvm-dev/2019-October/135628.html), it could 
be a promising way to extend functionality of this solution.

**Inlining**

Inlining in an issue for functions with `#pragma STDC FENV_ACCESS`, because if 
such function is inlined, the host function must use constrained intrinsics, 
which can result in performance drop. The simplest case is to prohibit inlining 
of such functions, this way is used in this patch. More elaborated solution 
would try to merge attributes if possible. For instance, if the host function 
does not use floating point operations, the function with `#pragma STDC 
FENV_ACCESS` may be inlined. However it does not look like a job of frontend.

In D69272#1717021 , @kpn wrote:

> Does this work for C++? C++ templates? I only see C tests.


Will add C++ tests soon.

In D69272#1717021 , @kpn wrote:

> Is there a way forward to support having the #pragma at the start of any 
> block inside a function? The effect won't be restricted to that block, true, 
> but the standard does say the #pragma is allowed.


Function outlining may be a general solution.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:890
+  "cannot apply to inline functions, ignoring pragma">,
+   InGroup;
 

hfinkel wrote:
> andrew.w.kaylor wrote:
> > rjmccall wrote:
> > > What's the purpose of this restriction?  Whether `inline` really has much 
> > > to do with inlining depends a lot on the exact language settings.  (Also, 
> > > even if this restriction were okay, the diagnostic is quite bad given 
> > > that there are three separate conditions that can lead to it firing.)
> > > 
> > > Also, I thought we were adding instruction-level annotations for this 
> > > kind of thing to LLVM IR.  Was that not in service of implementing this 
> > > pragma?
> > > 
> > > I'm not categorically opposed to taking patches that only partially 
> > > implement a feature, but I do want to feel confident that there's a 
> > > reasonable technical path forward to the full implementation.  In this 
> > > case, it feels like the function-level attribute is a dead end 
> > > technically.
> > I'm guessing this is intended to avoid the optimization problems that would 
> > occur (currently) if a function with strictfp were inlined into a function 
> > without it. I'm just guessing though, so correct me if I'm wrong.
> > 
> > As I've said elsewhere, I hope this is a temporary problem. It is a real 
> > problem though (as is the fact that the inliner isn't currently handling 
> > this case correctly).
> > 
> > What would you think of a new command line option that caused us to mark 
> > functions with strictfp as noinline? We'd still need an error somewhat like 
> > this, but I feel like that would be more likely to accomplish what we want 
> > on a broad scale.
> We would not want to prevent all inlining, just inlining where the attributes 
> don't match. We should fix his first. I think we just need to add a 
> CompatRule to include/llvm/IR/Attributes.td (or something like that).
As Andrew already said, `noinline` attribute is a mean to limit negative 
performance impact. Of course, to inline or not to inline - such decision is 
made by backend. However it a user requested a function to be inline, a warning 
looks useful.

When constrained intrinsics get full support in optimizations, this restriction 
will become unnecessary.

Outlining is one of the ways that converts this solution 

[PATCH] D68720: Support -fstack-clash-protection for x86

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 226002.
serge-sans-paille added a comment.

Better integration with MachineInstr description
Handle stacks with multiple stack objects
More test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68720

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/stack-clash-protection.c
  clang/test/Driver/stack-clash-protection.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/CodeGen/TargetLowering.h
  llvm/lib/Target/X86/X86CallFrameOptimization.cpp
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86ISelLowering.h
  llvm/lib/Target/X86/X86InstrCompiler.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/test/CodeGen/X86/stack-clash-dynamic-alloca.ll
  llvm/test/CodeGen/X86/stack-clash-large.ll
  llvm/test/CodeGen/X86/stack-clash-medium-natural-probes-mutliple-objects.ll
  llvm/test/CodeGen/X86/stack-clash-medium-natural-probes.ll
  llvm/test/CodeGen/X86/stack-clash-medium.ll
  llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
  llvm/test/CodeGen/X86/stack-clash-small.ll
  llvm/test/CodeGen/X86/stack-clash-unknown-call.ll

Index: llvm/test/CodeGen/X86/stack-clash-unknown-call.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-unknown-call.ll
@@ -0,0 +1,31 @@
+; RUN: llc < %s | FileCheck %s
+
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1 immarg);
+
+define void @foo() local_unnamed_addr #0 {
+
+;CHECK-LABEL: foo:
+;CHECK: # %bb.0:
+;CHECK-NEXT:	subq	$4096, %rsp # imm = 0x1000
+; it's important that we don't use the call as a probe here
+;CHECK-NEXT:	movq	$0, (%rsp)
+;CHECK-NEXT:	subq	$3912, %rsp # imm = 0xF48
+;CHECK-NEXT:	.cfi_def_cfa_offset 8016
+;CHECK-NEXT:	movq	%rsp, %rdi
+;CHECK-NEXT:	movl	$8000, %edx # imm = 0x1F40
+;CHECK-NEXT:	xorl	%esi, %esi
+;CHECK-NEXT:	callq	memset
+;CHECK-NEXT:	addq	$8008, %rsp # imm = 0x1F48
+;CHECK-NEXT:	.cfi_def_cfa_offset 8
+;CHECK-NEXT:	retq
+
+  %a = alloca i8, i64 8000, align 16
+  call void @llvm.memset.p0i8.i64(i8* align 16 %a, i8 0, i64 8000, i1 false)
+  ret void
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
Index: llvm/test/CodeGen/X86/stack-clash-small.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-small.ll
@@ -0,0 +1,25 @@
+; RUN: llc < %s | FileCheck %s
+
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define i32 @foo() local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:  subq	$280, %rsp # imm = 0x118
+; CHECK-NEXT:  .cfi_def_cfa_offset 288
+; CHECK-NEXT:  movl	$1, 264(%rsp)
+; CHECK-NEXT:  movl	-128(%rsp), %eax
+; CHECK-NEXT:  addq	$280, %rsp # imm = 0x118
+; CHECK-NEXT:  .cfi_def_cfa_offset 8
+; CHECK-NEXT:  retq
+
+  %a = alloca i32, i64 100, align 16
+  %b = getelementptr inbounds i32, i32* %a, i64 98
+  store volatile i32 1, i32* %b
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
Index: llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
@@ -0,0 +1,27 @@
+; RUN: llc < %s | FileCheck %s
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define i32 @foo(i64 %i) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:  subq	$4096, %rsp # imm = 0x1000
+; CHECK-NEXT:  movq	$0, (%rsp)
+; CHECK-NEXT:  subq	$3784, %rsp # imm = 0xEC8
+; CHECK-NEXT:  .cfi_def_cfa_offset 7888
+; CHECK-NEXT:  movl	$1, -128(%rsp,%rdi,4)
+; CHECK-NEXT:  movl	-128(%rsp), %eax
+; CHECK-NEXT:  addq	$7880, %rsp # imm = 0x1EC8
+; CHECK-NEXT:  .cfi_def_cfa_offset 8
+; CHECK-NEXT:  retq
+
+  %a = alloca i32, i32 2000, align 16
+  %b = getelementptr inbounds i32, i32* %a, i64 %i
+  store volatile i32 1, i32* %b
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
+
Index: llvm/test/CodeGen/X86/stack-clash-medium.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-medium.ll
@@ -0,0 +1,27 @@

[PATCH] D68969: [clang-format] Remove the dependency on frontend

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay marked 2 inline comments as done.
MyDeveloperDay added inline comments.



Comment at: clang/tools/clang-format/ClangFormat.cpp:356
+
+  StringRef Line(StartBuf, (EndBuf - StartBuf) - 1);
+

klimek wrote:
> - 1 is to exclude the \n I'd assume?
correct, without the -1 I end up with an extra blank line in the output


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

https://reviews.llvm.org/D68969



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