r255099 - clang-format: Improve documentation of AlignOperands.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Wed Dec  9 01:56:52 2015
New Revision: 255099

URL: http://llvm.org/viewvc/llvm-project?rev=255099=rev
Log:
clang-format: Improve documentation of AlignOperands.

Modified:
cfe/trunk/include/clang/Format/Format.h

Modified: cfe/trunk/include/clang/Format/Format.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?rev=255099=255098=255099=diff
==
--- cfe/trunk/include/clang/Format/Format.h (original)
+++ cfe/trunk/include/clang/Format/Format.h Wed Dec  9 01:56:52 2015
@@ -100,6 +100,13 @@ struct FormatStyle {
 
   /// \brief If \c true, horizontally align operands of binary and ternary
   /// expressions.
+  ///
+  /// Specifically, this aligns operands of a single expression that needs to 
be
+  /// split over multiple lines, e.g.:
+  /// \code
+  ///   int aaa = bbb +
+  /// ccc;
+  /// \endcode
   bool AlignOperands;
 
   /// \brief If \c true, aligns trailing comments.


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

Re: [PATCH] D13802: [OPENMP] Make -fopenmp to turn on OpenMP support by default.

[Alexey Bataev via cfe-commits]

Hi Hans,
I asked Chandler to look at this once again but seems to me he is very 
busy. Maybe you could ping him also?

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

09.12.2015 0:35, Hans Wennborg пишет:
> hans added a comment.
>
> Alexey & Chandler: Is there any ongoing communication here?
>
> It would be great if we could resolve this, or at least figure out what the 
> status is, before we branch for 3.8 in a month or so.
>
>
> http://reviews.llvm.org/D13802
>
>
>

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

Re: [PATCH] D15309: [CUDA] emit vtables only for classes with methods usable on this side of compilation.

[Jacques Pienaar via cfe-commits]

jpienaar added a comment.

Looks good to me.



Comment at: lib/AST/RecordLayoutBuilder.cpp:2003
@@ +2002,3 @@
+return nullptr;
+  if (!Context.getLangOpts().CUDAIsDevice && !MD->hasAttr() 
&&
+  MD->hasAttr())

Add a comment to explain asymmetry. Perhaps a general comment at the start of 
this section explaining would be the most useful.


Comment at: test/CodeGenCUDA/device-vtable.cu:36
@@ +35,3 @@
+// only device methods would be available during host or device
+// compilation. For now we'll not emit such vtable at all.
+class HD  {

What is the current behavior in this case? Should an error be reported?


http://reviews.llvm.org/D15309



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

Re: [PATCH] D12834: add gcc abi_tag support

[Stephan Bergmann via cfe-commits]

sberg added a subscriber: sberg.
sberg added a comment.

I can't figure out how to add code to someone else's Phabricator review, so 
sent it to the mailing list 
instead: 
 
 
"[PATCH] Re http://reviews.llvm.org/D12834 add gcc abi_tag support."


Repository:
  rL LLVM

http://reviews.llvm.org/D12834



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

[PATCH] D15370: [scan-view] replace deprecated optparse with argparse

[Kirill Bobyrev via cfe-commits]

omtcyf0 created this revision.
omtcyf0 added a reviewer: ddunbar.
omtcyf0 added a subscriber: cfe-commits.

scan-view migrated from optparse deprecated Python module to its replacement 
(argparse) and resolved few conflicts with pep8

http://reviews.llvm.org/D15370

Files:
  tools/scan-view/bin/scan-view

Index: tools/scan-view/bin/scan-view
===
--- tools/scan-view/bin/scan-view
+++ tools/scan-view/bin/scan-view
@@ -24,19 +24,22 @@
 
 ###
 
+
 def url_is_up(url):
 try:
 o = urllib.urlopen(url)
 except IOError:
 return False
 o.close()
 return True
 
+
 def start_browser(port, options):
-import urllib, webbrowser
+import urllib
+import webbrowser
+
+url = 'http://%s:%d' % (options.host, port)
 
-url = 'http://%s:%d'%(options.host, port)
-
 # Wait for server to start...
 if options.debug:
 sys.stderr.write('%s: Waiting for server.' % sys.argv[0])
@@ -49,92 +52,91 @@
 sys.stderr.flush()
 time.sleep(kSleepTimeout)
 else:
-print >>sys.stderr,'WARNING: Unable to detect that server started.'
+print >> sys.stderr, 'WARNING: Unable to detect that server started.'
 
 if options.debug:
-print >>sys.stderr,'%s: Starting webbrowser...' % sys.argv[0]
+print >> sys.stderr, '%s: Starting webbrowser...' % sys.argv[0]
 webbrowser.open(url)
 
+
 def run(port, options, root):
 # Prefer to look relative to the installed binary
 share = os.path.dirname(__file__) + "/../share/scan-view"
 if not os.path.isdir(share):
-  # Otherwise look relative to the source
-  share = os.path.dirname(__file__) + "/../../scan-view/share"
+# Otherwise look relative to the source
+share = os.path.dirname(__file__) + "/../../scan-view/share"
 sys.path.append(share)
 
 import ScanView
 try:
-print 'Starting scan-view at: http://%s:%d'%(options.host,
- port)
+print 'Starting scan-view at: http://%s:%d' % (options.host,
+   port)
 print '  Use Ctrl-C to exit.'
 httpd = ScanView.create_server((options.host, port),
options, root)
 httpd.serve_forever()
 except KeyboardInterrupt:
 pass
 
+
 def port_is_open(port):
 import SocketServer
 try:
-t = SocketServer.TCPServer((kDefaultHost,port),None)
+t = SocketServer.TCPServer((kDefaultHost, port), None)
 except:
 return False
 t.server_close()
 return True
 
-def main():
-from optparse import OptionParser
-parser = OptionParser('usage: %prog [options] ')
-parser.set_description(__doc__)
-parser.add_option(
-'--host', dest="host", default=kDefaultHost, type="string",
+
+def main():
+import argparse
+parser = argparse.ArgumentParser()
+parser.add_argument("root", metavar="", type=str)
+parser.add_argument(
+'--host', dest="host", default=kDefaultHost, type=str,
 help="Host interface to listen on. (default=%s)" % kDefaultHost)
-parser.add_option(
-'--port', dest="port", default=None, type="int",
-help="Port to listen on. (default=%s)" % kDefaultPort)
-parser.add_option("--debug", dest="debug", default=0, 
-  action="count",
-  help="Print additional debugging information.")
-parser.add_option("--auto-reload", dest="autoReload", default=False, 
-  action="store_true",
-  help="Automatically update module for each request.")
-parser.add_option("--no-browser", dest="startBrowser", default=True, 
-  action="store_false",
-  help="Don't open a webbrowser on startup.")
-parser.add_option("--allow-all-hosts", dest="onlyServeLocal", default=True, 
-  action="store_false",
-  help='Allow connections from any host (access restricted to "127.0.0.1" by default)')
-(options, args) = parser.parse_args()
-
-if len(args) != 1:
-parser.error('No results directory specified.')
-root, = args
+parser.add_argument('--port', dest="port", default=None, type=int,
+help="Port to listen on. (default=%s)" % kDefaultPort)
+parser.add_argument("--debug", dest="debug", default=0,
+action="count",
+help="Print additional debugging information.")
+parser.add_argument("--auto-reload", dest="autoReload", default=False,
+action="store_true",
+help="Automatically update module for each request.")
+parser.add_argument("--no-browser", dest="startBrowser", default=True,
+action="store_false",
+help="Don't open a 

[PATCH] D15373: Fix for bug 25786 - Assertion "Chunk.Kind == DeclaratorChunk::Function" failed with regparm attribute.

[Alexander Makarov via cfe-commits]

a.makarov created this revision.
a.makarov added reviewers: aaron.ballman, rsmith.
a.makarov added a subscriber: cfe-commits.
Herald added subscribers: rengolin, aemerson.

This patch is to avoid attaching the calling convention attribute to the result 
type if this attribute was ignored and calling convention was substituted by 
default.

http://reviews.llvm.org/D15373

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaType.cpp
  test/CodeGen/adding_defaulted_attr_to_type.c
  test/Sema/callingconv.c

Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -5913,7 +5913,19 @@
   FunctionType::ExtInfo EI = unwrapped.get()->getExtInfo().withCallingConv(CC);
   QualType Equivalent =
   unwrapped.wrap(S, S.Context.adjustFunctionType(unwrapped.get(), EI));
-  type = S.Context.getAttributedType(CCAttrKind, type, Equivalent);
+
+  // We should add attribute specifier to type only if we didn't subsitute
+  // 'default' calling convention instead of the one provided by the attribute.
+  CallingConv RawCC;
+  bool RecognizedAttr = S.getCCFromAttr(attr, RawCC);
+  assert(!RecognizedAttr &&
+ "Somehow ill-formed calling convention attribute reached here!");
+  TargetInfo::CallingConvCheckResult CCResult =
+  S.Context.getTargetInfo().checkCallingConvention(RawCC);
+  // If calling convention is available (CCCR_OK) or default (CCCR_Ignored), add
+  // it to type.
+  if (CCResult != TargetInfo::CCCR_Warning)
+type = S.Context.getAttributedType(CCAttrKind, type, Equivalent);
   return true;
 }
 
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -3701,8 +3701,11 @@
   }
 }
 
-bool Sema::CheckCallingConvAttr(const AttributeList , CallingConv , 
-const FunctionDecl *FD) {
+/// This function simply dispatches passed attribute to corresponding
+/// calling convention.
+/// If attribute is ill-formed, it returns 'true' and makes marks attribute as
+/// invalid.
+bool Sema::getCCFromAttr(const AttributeList , CallingConv ) {
   if (attr.isInvalid())
 return true;
 
@@ -3714,19 +3717,31 @@
 
   // TODO: diagnose uses of these conventions on the wrong target.
   switch (attr.getKind()) {
-  case AttributeList::AT_CDecl: CC = CC_C; break;
-  case AttributeList::AT_FastCall: CC = CC_X86FastCall; break;
-  case AttributeList::AT_StdCall: CC = CC_X86StdCall; break;
-  case AttributeList::AT_ThisCall: CC = CC_X86ThisCall; break;
-  case AttributeList::AT_Pascal: CC = CC_X86Pascal; break;
-  case AttributeList::AT_VectorCall: CC = CC_X86VectorCall; break;
+  case AttributeList::AT_CDecl:
+CC = CC_C;
+break;
+  case AttributeList::AT_FastCall:
+CC = CC_X86FastCall;
+break;
+  case AttributeList::AT_StdCall:
+CC = CC_X86StdCall;
+break;
+  case AttributeList::AT_ThisCall:
+CC = CC_X86ThisCall;
+break;
+  case AttributeList::AT_Pascal:
+CC = CC_X86Pascal;
+break;
+  case AttributeList::AT_VectorCall:
+CC = CC_X86VectorCall;
+break;
   case AttributeList::AT_MSABI:
-CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_C :
- CC_X86_64Win64;
+CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_C
+   : CC_X86_64Win64;
 break;
   case AttributeList::AT_SysVABI:
-CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_X86_64SysV :
- CC_C;
+CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_X86_64SysV
+   : CC_C;
 break;
   case AttributeList::AT_Pcs: {
 StringRef StrRef;
@@ -3741,13 +3756,27 @@
   CC = CC_AAPCS_VFP;
   break;
 }
-
 attr.setInvalid();
 Diag(attr.getLoc(), diag::err_invalid_pcs);
 return true;
   }
-  case AttributeList::AT_IntelOclBicc: CC = CC_IntelOclBicc; break;
-  default: llvm_unreachable("unexpected attribute kind");
+  case AttributeList::AT_IntelOclBicc:
+CC = CC_IntelOclBicc;
+break;
+  default:
+llvm_unreachable("unexpected attribute kind");
+  }
+  return false;
+}
+
+bool Sema::CheckCallingConvAttr(const AttributeList , CallingConv , 
+const FunctionDecl *FD) {
+  if (attr.isInvalid())
+return true;
+
+  if (getCCFromAttr(attr, CC)) {
+assert(attr.isInvalid() && "Error occured but attribute is not invalid!");
+return true;
   }
 
   const TargetInfo  = Context.getTargetInfo();
Index: include/clang/Sema/Sema.h
===
--- include/clang/Sema/Sema.h
+++ include/clang/Sema/Sema.h
@@ -2935,6 +2935,7 @@
   bool isValidPointerAttrType(QualType T, bool RefOkay = 

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D12761#304823, @Alexander_Droste wrote:

> Ah ok, I wasn't aware that clang-tidy is not restricted to checks which 
> verify stylistic issues.
>  What makes it more convenient to integrate the checks in clang-tidy?  Is it 
> how the AST-Matcher
>  functionality can be accessed?


Yes, less boilerplate code needed to work with AST matchers, powerful clang 
diagnostic infrastructure is used to report errors, also the add_new_check.py 
script ;)

> > I'm not an expert in the static analyzer code, so I'm not the one to review 
> > even AST-based checks there.

> 

> 

> The AST-based checks basically use zero functionality from the static 
> analyzer codebase

>  except the entry callback and the functionality to generate bug reports.


Well, that's one of the ways to say that I have little experience and interest 
in reviewing patches to the static analyzer ;)

> > There's nothing that prevents adding more error-detecting checks to 
> > clang-tidy.

> 

> 

> Wrt. to the checks being part of this patch I have some concerns:

> 

> The first problem I see is that some functionlity is shared between the 
> AST-based 

>  and path-sensitive checks. But I think this should be restricted to the 
> `MPIFunctionClassifier` class.


If this class stays in the static analyzer, the clang-tidy check code could 
probably just depend on the relevant library and use this class?

> Another question I have is how this would affect the usability. At the moment

>  all detected bugs (AST-based and path-sensitive) appear in a single report,

>  generated by `scan-build`. Is there still a way to get the results in a 
> single report 

>  if the checks get moved to `clang-tidy`?


clang-tidy can run static analyzer checks. However, it only supports the plain 
text output format, which is sub-optimal for representing the results of the 
path-based checks. So the single report scenario is not easy to implement right 
now. Gábor Horváth proposed a solution for this a few months ago (PList output 
for clang-tidy), but a proper implementation of this seemed to require some 
changes in the clang's diagnostic subsystem.

> Would the implementation need to change to AST-Matcher based?


That's not a 100% necessary step (you can always add a matcher for 
translationUnitDecl() and then traverse the AST using a RecursiveASTVisitor, 
for example), but this usually results in a more compact and easy to understand 
code.

> The point about the current implementation is that the AST-based checks

>  are also already backed by a range of tests defined in 

>  `tools/clang/test/Analysis/MPIChecker.cpp`.


Clang-tidy checks should also be backed by tests ;)


http://reviews.llvm.org/D12761



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

Re: [PATCH] D15174: [MSVC] Fix for http://llvm.org/PR25636: indexed accessor property not supported correctly.

[Alexey Bataev via cfe-commits]

ABataev updated this revision to Diff 42282.
ABataev added a comment.

Update after review


http://reviews.llvm.org/D15174

Files:
  lib/Sema/SemaPseudoObject.cpp
  test/CodeGenCXX/ms-property.cpp
  test/SemaCXX/ms-property-error.cpp
  test/SemaCXX/ms-property.cpp

Index: lib/Sema/SemaPseudoObject.cpp
===
--- lib/Sema/SemaPseudoObject.cpp
+++ lib/Sema/SemaPseudoObject.cpp
@@ -229,7 +229,7 @@
 }
 
 /// Return true if assignments have a non-void result.
-bool CanCaptureValue(Expr *exp) {
+static bool CanCaptureValue(Expr *exp) {
   if (exp->isGLValue())
 return true;
   QualType ty = exp->getType();
@@ -245,6 +245,20 @@
 virtual ExprResult buildGet() = 0;
 virtual ExprResult buildSet(Expr *, SourceLocation,
 bool captureSetValueAsResult) = 0;
+/// \brief Should the result of an assignment be the formal result of the
+/// setter call or the value that was passed to the setter?
+///
+/// Different pseudo-object language features use different language rules
+/// for this.
+/// The default is to use the set value.  Currently, this affects the
+/// behavior of simple assignments, compound assignments, and prefix
+/// increment and decrement.
+/// Postfix increment and decrement always use the getter result as the
+/// expression result.
+///
+/// If this method returns false, and the set value isn't capturable for
+/// some reason, the result of the expression will be void.
+virtual bool captureSetValueAsResult() const { return true; }
   };
 
   /// A PseudoOpBuilder for Objective-C \@properties.
@@ -339,6 +353,7 @@
Expr *rebuildAndCaptureObject(Expr *) override;
ExprResult buildGet() override;
ExprResult buildSet(Expr *op, SourceLocation, bool) override;
+   bool captureSetValueAsResult() const override { return false; }
  };
 }
 
@@ -455,9 +470,12 @@
 
   // The result of the assignment, if not void, is the value set into
   // the l-value.
-  result = buildSet(result.get(), opcLoc, /*captureSetValueAsResult*/ true);
+  result = buildSet(result.get(), opcLoc, captureSetValueAsResult());
   if (result.isInvalid()) return ExprError();
   addSemanticExpr(result.get());
+  if (!captureSetValueAsResult() && !result.get()->getType()->isVoidType() &&
+  (result.get()->isTypeDependent() || CanCaptureValue(result.get(
+setResultToLastSemantic();
 
   return complete(syntactic);
 }
@@ -499,9 +517,14 @@
 
   // Store that back into the result.  The value stored is the result
   // of a prefix operation.
-  result = buildSet(result.get(), opcLoc, UnaryOperator::isPrefix(opcode));
+  result = buildSet(result.get(), opcLoc, UnaryOperator::isPrefix(opcode) &&
+  captureSetValueAsResult());
   if (result.isInvalid()) return ExprError();
   addSemanticExpr(result.get());
+  if (UnaryOperator::isPrefix(opcode) && !captureSetValueAsResult() &&
+  !result.get()->getType()->isVoidType() &&
+  (result.get()->isTypeDependent() || CanCaptureValue(result.get(
+setResultToLastSemantic();
 
   UnaryOperator *syntactic =
 new (S.Context) UnaryOperator(syntacticOp, opcode, resultType,
Index: test/SemaCXX/ms-property.cpp
===
--- test/SemaCXX/ms-property.cpp
+++ test/SemaCXX/ms-property.cpp
@@ -29,7 +29,7 @@
 public:
   __declspec(property(get=GetX,put=PutX)) T x[];
   T GetX(T i, T j) { return i+j; }
-  void PutX(T i, T j, T k) { j = i = k; }
+  T PutX(T i, T j, T k) { return j = i = k; }
   ~St() { x[0][0] = x[1][1]; }
 };
 
@@ -52,6 +52,8 @@
   ((p2->x)[23])[1] = j1;
   // CHECK-NEXT: ++(((p2->x)[23])[1]);
   ++(((p2->x)[23])[1]);
+  // CHECK-NEXT: j1 = ((p2->x)[23])[1] = j1;
+  j1 = ((p2->x)[23])[1] = j1;
   // CHECK-NEXT: return Test1::GetTest1()->X;
   return Test1::GetTest1()->X;
 }
Index: test/SemaCXX/ms-property-error.cpp
===
--- test/SemaCXX/ms-property-error.cpp
+++ test/SemaCXX/ms-property-error.cpp
@@ -7,17 +7,19 @@
   void PutX(int i, int j, int k) { j = i = k; } // expected-note {{'PutX' declared here}}
 };
 
+char *ptr;
 template 
 class St {
 public:
   __declspec(property(get=GetX,put=PutX)) T x[];
   T GetX(T i, T j) { return i+j; } // expected-note 3 {{'GetX' declared here}}
-  void PutX(T i, T j, T k) { j = i = k; }  // expected-note 2 {{'PutX' declared here}}
+  T PutX(T i, T j, T k) { return j = i = k; }  // expected-note 2 {{'PutX' declared here}}
   ~St() {
 x[1] = 0; // expected-error {{too few arguments to function call, expected 3, have 2}}
 x[2][3] = 4;
 ++x[2][3];
 x[1][2] = x[3][4][5]; // expected-error {{too many arguments to function call, expected 2, have 3}}
+ptr = x[1][2] = x[3][4]; // expected-error {{assigning to 'char *' from incompatible type 'int'}}
   }
 };
 
@@ -30,5 +32,6 @@

[PATCH] Re D12834 add gcc abi_tag support

[Stephan Bergmann via cfe-commits]

I can't figure out how to add code to someone else's Phabricator review 
, so sending it here to the mailing list 
instead.


* Attached 0001-add-gcc-abi_tag-support.patch rebases 
 against recent trunk (there 
were three minor conflicts that needed resolution).


* Attached 0002-Fix-handling-of-abi_tag-attribute-on-namespaces.patch 
fixes the handling of abi_tag attributes on namespaces to match GCC 
behavior.
>From 88aa3688d46ecb49ba236da6f761053b75b01528 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
Date: Thu, 3 Dec 2015 14:51:50 +0100
Subject: [PATCH 1/2] add gcc abi_tag support


conflicts:
	include/clang/Basic/DiagnosticSemaKinds.td
	include/clang/Sema/AttributeList.h
	lib/AST/ItaniumMangle.cpp
---
 docs/ItaniumMangleAbiTags.rst  |  90 +
 include/clang/Basic/Attr.td|   8 +
 include/clang/Basic/DiagnosticSemaKinds.td |  10 +-
 include/clang/Sema/AttributeList.h |   3 +-
 lib/AST/ItaniumMangle.cpp  | 525 -
 lib/Sema/SemaDeclAttr.cpp  |  55 +++
 6 files changed, 609 insertions(+), 82 deletions(-)
 create mode 100644 docs/ItaniumMangleAbiTags.rst

diff --git a/docs/ItaniumMangleAbiTags.rst b/docs/ItaniumMangleAbiTags.rst
new file mode 100644
index 000..d390162
--- /dev/null
+++ b/docs/ItaniumMangleAbiTags.rst
@@ -0,0 +1,90 @@
+
+Abi Tags
+
+
+Introduction
+
+
+This text tries to describe gcc semantic for mangling "abi_tag" attributes
+described in https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
+
+There is no guarantee the following rules are correct, complete or make sense
+in any way as they were determined empirically by experiments with gcc5.
+
+Declaration
+===
+
+Abi tags are declared in an abi_tag attribute and can be applied to a
+function, variable, class or inline namespace declaration. The attribute takes
+one or more strings (called tags); the order does not matter.
+
+See https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html for
+details.
+
+Tags on an inline namespace are called "implicit tags", all other tags are
+"explicit tags".
+
+Mangling
+
+
+All tags that are "active" on a  are emitted after the
+, before  or , and are part of
+the same  the  is.
+
+They are mangled as:
+
+ ::= *   # sort by name
+ ::= B 
+
+Example:
+
+__attribute__((abi_tag("test")))
+void Func();
+
+gets mangled as: _Z4FuncB4testv (prettified as `Func[abi:test]()`)
+
+Active tags
+===
+
+A namespace has never any active tags; for types (class / struct / union /
+enum) the explicit tags are the active tags.
+
+For variables and functions the active tags are the explicit tags plus any
+"required tags" which are not in the "available tags" set:
+
+derived-tags := (required-tags - available-tags)
+active-tags := explicit-tags + derived-tags
+
+Required tags for a function
+
+
+If a function is used as a local scope for another name, and is part of
+another function as local scope, it doesn't have any required tags.
+
+If a function is used as a local scope for a guard variable name, it doesn't
+have any required tags.
+
+Otherwise the function requires any implicit or explicit tag used in the name
+for the return type.
+
+Required tags for a variable
+
+
+A variable requires any implicit or explicit tag used in its type.
+
+Available tags
+==
+
+All tags used in the prefix and in the template arguments for a name are
+available; for functions also all  tags from the  (which
+might include the return type for template functions) are available.
+
+For s all active tags used in the local part () are available, but not implicit tags which were not active!
+
+Implicit and explicit tags used in the  for a function (as
+in the type of a cast operator) are NOT available.
+
+Example: a cast operator to std::string (which is
+std::__cxx11::basic_string<...>) will use 'cxx11' as active tag, as it is
+required from the return type `std::string` but not available.
diff --git a/include/clang/Basic/Attr.td b/include/clang/Basic/Attr.td
index d5ba722..36be1fc 100644
--- a/include/clang/Basic/Attr.td
+++ b/include/clang/Basic/Attr.td
@@ -349,6 +349,14 @@ class IgnoredAttr : Attr {
 // Attributes begin here
 //
 
+def AbiTag : Attr {
+  let Spellings = [GCC<"abi_tag">];
+  let Args = [VariadicStringArgument<"Tags">];
+  let Subjects = SubjectList<[Struct, Var, Function, Namespace], ErrorDiag,
+ "ExpectedStructClassVariableFunctionMethodOrInlineNamespace">;
+  let Documentation = [Undocumented];
+}
+
 def AddressSpace : TypeAttr {
   let Spellings = [GNU<"address_space">];
   let Args = [IntArgument<"AddressSpace">];
diff --git a/include/clang/Basic/DiagnosticSemaKinds.td 

Re: [PATCH] D13802: [OPENMP] Make -fopenmp to turn on OpenMP support by default.

[Chandler Carruth via cfe-commits]

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

Sorry I was a bit slow -- was out when commented in Nov, and was slow catching 
back up the past two weeks.

I've done some more testing, and the check-libomp is passing very nicely now! 
=D Ship it! Also make sure you follow up with the broader set of build bots to 
have them include this repository in the checkout.

Minor documentation tweak below, but feel free to land everything. =D I'm 
excited, it'll be interesting to see if anything else breaks, but so far it 
seems to be working well for me.



Comment at: docs/GettingStarted.rst:58-62
@@ -57,1 +57,7 @@
 
+#. Checkout Libomp (required for OpenMP support) **[Optional]**:
+
+   * ``cd where-you-want-llvm-to-live``
+   * ``cd llvm/projects``
+   * ``svn co http://llvm.org/svn/llvm-project/openmp/trunk openmp``
+

I'd skip the optional tag -- as you've nicely documented, its required for 
OpenMP support.


http://reviews.llvm.org/D13802



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

Re: [PATCH] D15332: new clang-tidy checker readability-non-const-parameter

[Daniel Marjamäki via cfe-commits]

danielmarjamaki marked 12 inline comments as done.


Comment at: clang-tidy/readability/NonConstParameterCheck.cpp:44
@@ +43,3 @@
+  if (B->isAssignmentOp())
+markCanNotBeConst(B, false);
+} else if (const auto *CE = dyn_cast(S)) {

I tried to unify like that. It almost worked. I failed to put the stmt(...) and 
varDecl(...) in the same matcher.


Comment at: clang-tidy/readability/NonConstParameterCheck.cpp:49
@@ +48,3 @@
+  for (const auto *Arg : CE->arguments()) {
+markCanNotBeConst(Arg->IgnoreParenCasts(), true);
+  }

good question!

I tested and the checker seemed to handle these. apparently the ast-matcher 
scanned the functions recursively. However I don't know if we know that it will 
work, so I changed the checker.


Comment at: clang-tidy/readability/NonConstParameterCheck.cpp:84
@@ +83,3 @@
+}
+
+void NonConstParameterCheck::onEndOfTranslationUnit() {

I believe I fixed all these.


http://reviews.llvm.org/D15332



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

Re: [PATCH] D15332: new clang-tidy checker readability-non-const-parameter

[Daniel Marjamäki via cfe-commits]

danielmarjamaki updated this revision to Diff 42292.
danielmarjamaki added a comment.

I have tried to fix the comments.

This patch is mostly untested. I have only run 'make check-all'. I am running 
more tests right now.


http://reviews.llvm.org/D15332

Files:
  clang-tidy/readability/CMakeLists.txt
  clang-tidy/readability/NonConstParameterCheck.cpp
  clang-tidy/readability/NonConstParameterCheck.h
  clang-tidy/readability/ReadabilityTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/readability-non-const-parameter.rst
  test/clang-tidy/readability-non-const-parameter.cpp

Index: test/clang-tidy/readability-non-const-parameter.cpp
===
--- test/clang-tidy/readability-non-const-parameter.cpp
+++ test/clang-tidy/readability-non-const-parameter.cpp
@@ -0,0 +1,211 @@
+// RUN: %check_clang_tidy %s readability-non-const-parameter %t
+
+// Currently the checker only warns about pointer arguments.
+//
+// It can be defined both that the data is const and that the pointer is const,
+// the checker only checks if the data can be const-specified.
+//
+// It does not warn about pointers to records or function pointers.
+
+// Some external function where first argument is nonconst and second is const.
+char *strcpy1(char *dest, const char *src);
+unsigned my_strcpy(char *buf, const char *s);
+unsigned my_strlen(const char *buf);
+
+// CHECK-MESSAGES: :[[@LINE+1]]:29: warning: parameter 'last' can be const [readability-non-const-parameter]
+void warn1(int *first, int *last) {
+  // CHECK-FIXES: {{^}}void warn1(int *first, const int *last) {{{$}}
+  *first = 0;
+  if (first < last) {
+  } // <- last can be const
+}
+
+// TODO: warning should be written here
+void warn2(char *p) {
+  char buf[10];
+  strcpy1(buf, p);
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:19: warning: parameter 'p' can be const [readability-non-const-parameter]
+void assign1(int *p) {
+  // CHECK-FIXES: {{^}}void assign1(const int *p) {{{$}}
+  const int *q;
+  q = p;
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:19: warning: parameter 'p' can be const [readability-non-const-parameter]
+void assign2(int *p) {
+  // CHECK-FIXES: {{^}}void assign2(const int *p) {{{$}}
+  const int *q;
+  q = p + 1;
+}
+
+void assign3(int *p) {
+  *p = 0;
+}
+
+void assign4(int *p) {
+  *p += 2;
+}
+
+void assign5(char *p) {
+  p[0] = 0;
+}
+
+void assign6(int *p) {
+  int *q;
+  q = p++;
+}
+
+void assign7(char *p) {
+  char *a, *b;
+  a = b = p;
+}
+
+void assign8(char *a, char *b) {
+  char *x;
+  x = (a ? a : b);
+}
+
+void assign9(unsigned char *str, const unsigned int i) {
+  unsigned char *p;
+  for (p = str + i; *p;) {
+  }
+}
+
+void assign10(int *buf) {
+  int i, *p;
+  for (i = 0, p = buf; i < 10; i++, p++) {
+*p = 1;
+  }
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:17: warning: parameter 'p' can be const [readability-non-const-parameter]
+void init1(int *p) {
+  // CHECK-FIXES: {{^}}void init1(const int *p) {{{$}}
+  const int *q = p;
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:17: warning: parameter 'p' can be const [readability-non-const-parameter]
+void init2(int *p) {
+  // CHECK-FIXES: {{^}}void init2(const int *p) {{{$}}
+  const int *q = p + 1;
+}
+
+void init3(int *p) {
+  int *q = p;
+}
+
+void init4(float *p) {
+  int *q = (int *)p;
+}
+
+void init5(int *p) {
+  int *i = p ? p : 0;
+}
+
+void init6(int *p) {
+  int *a[] = {p, p, 0};
+}
+
+void init7(int *p, int x) {
+  for (int *q = p + x - 1; 0; q++)
+;
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:18: warning: parameter 'p' can be const [readability-non-const-parameter]
+int return1(int *p) {
+  // CHECK-FIXES: {{^}}int return1(const int *p) {{{$}}
+  return *p;
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:25: warning: parameter 'p' can be const [readability-non-const-parameter]
+const int *return2(int *p) {
+  // CHECK-FIXES: {{^}}const int *return2(const int *p) {{{$}}
+  return p;
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:25: warning: parameter 'p' can be const [readability-non-const-parameter]
+const int *return3(int *p) {
+  // CHECK-FIXES: {{^}}const int *return3(const int *p) {{{$}}
+  return p + 1;
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:27: warning: parameter 'p' can be const [readability-non-const-parameter]
+const char *return4(char *p) {
+  // CHECK-FIXES: {{^}}const char *return4(const char *p) {{{$}}
+  return p ? p : "";
+}
+
+char *return5(char *s) {
+  return s;
+}
+
+char *return6(char *s) {
+  return s + 1;
+}
+
+char *return7(char *a, char *b) {
+  return a ? a : b;
+}
+
+char return8(int *p) {
+  return ++(*p);
+}
+
+void dontwarn1(int *p) {
+  ++(*p);
+}
+
+int dontwarn2(_Atomic(int) * p) {
+  return *p;
+}
+
+void callFunction1(char *p) {
+  strcpy1(p, "abc");
+}
+
+void callFunction2(char *p) {
+  strcpy1([0], "abc");
+}
+
+void callFunction3(char *p) {
+  strcpy1(p + 2, "abc");
+}
+
+char *callFunction4(char *p) {
+  return strcpy1(p, "abc");
+}
+
+unsigned callFunction5(char *buf) {
+  unsigned len = my_strlen(buf);
+  

Re: [PATCH] D9600: Add scan-build python implementation

[Laszlo Nagy via cfe-commits]

rizsotto.mailinglist marked an inline comment as done.
rizsotto.mailinglist added a comment.

> Also, what do you think about renaming intercept-build to "log-build" or some 
> of the other alternatives I proposed above? I think it is important for the 
> name of the executable to communicate its purpose.


i do think differently. :) first, i think you can rename executables to 
whatever you like. previously i made this functionality in a tool called Bear. 
within 4 years got more than 100 bug reports, improvement ideas, but nobody did 
care about the executable name. second, i'm not a native speaker, but to me 
'intercept compiler calls from build' can be shortened to 'intercept-build'. 
third, if i rename the executable from intercept-build, shall rename the 
intercept module too? and to be honest, the executable name scan-build just as 
bad as intercept-build. :) if i did not convinced you, give me a name and i 
will rename to it.



Comment at: tools/scan-build-py/MANIFEST.in:2
@@ +1,3 @@
+include README.md
+include *.txt
+recursive-include libear *

dcoughlin wrote:
> I see that at https://pypi.python.org/pypi/scan-build it lists clang as a 
> prerequisite. But since scan-build-py will now be distributed as part of 
> clang I don't understand what the point of the standalone tool is. Can you 
> explain why this is needed?
thought to have more distribution channel is better. but if that so confusing, 
i've deleted it.


Comment at: tools/scan-build-py/libscanbuild/driver.py:67
@@ +66,3 @@
+except Exception:
+logging.exception("Something unexpected had happened.")
+return 127

jroelofs wrote:
> dcoughlin wrote:
> > rizsotto.mailinglist wrote:
> > > jroelofs wrote:
> > > > rizsotto.mailinglist wrote:
> > > > > dcoughlin wrote:
> > > > > > I think this error message can be improved. Perhaps "Unexpected 
> > > > > > error running intercept-build"?
> > > > > this line is printed as:
> > > > > 
> > > > >   intercept-build: ERROR: Something unexpected had happened.
> > > > >   (and the stack-trace)
> > > > > 
> > > > > because the logging formating. so, 'intercept-build' and 'error' will 
> > > > > be part of the message anyway.
> > > > Is there a pythonic way of doing llvm crash handlers? I.e. the "here's 
> > > > the steps to reproduce this, a stack trace, and a bug report url" 
> > > > things that clang spits out.
> > > this crash/exception is not a clang crash. it's more like this program's 
> > > fault. clang crash reports are recorded already in crash report files 
> > > (and linked into the html report file).
> > Maybe this should ask the user to file a bug against scan-build? Can it 
> > point to the bugzilla and tell the user what information, files, etc. they 
> > should attach to the bug report to help us reproduce the problem? Just 
> > saying "Something unexpected happened" is not as user-friendly as it could 
> > be because it does not tell the user that the problem is not their fault 
> > nor what they should do about it.
> Oh, I don't mean to handle clang crashes... I mean for handling python 
> crashes. I meant to draw an analogy to a feature that clang has: when it 
> crashes, it prints a stack trace, and some steps to reproduce the problem.  I 
> was wondering if a similar thing existed in python, for when a python app 
> crashes.
good point. added some implementation. if you don't like the text, please 
suggest one instead and will replace.


Comment at: tools/scan-build-py/libscanbuild/runner.py:22
@@ +21,3 @@
+def require(required):
+""" Decorator for checking the required values in state.
+

the comment says exactly the value coming from the compilation database. anyway 
added more explanations. if you have something in mind, please write the text 
and will copy it.


http://reviews.llvm.org/D9600



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

Re: [PATCH] D15006: Driver: Better detection of mingw-gcc

[İsmail Dönmez via cfe-commits]

ismail added a comment.

Martell, any update on this?


http://reviews.llvm.org/D15006



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

r255127 - [Hexagon] Use integrated assembler by default

[Krzysztof Parzyszek via cfe-commits]

Author: kparzysz
Date: Wed Dec  9 10:34:24 2015
New Revision: 255127

URL: http://llvm.org/viewvc/llvm-project?rev=255127=rev
Log:
[Hexagon] Use integrated assembler by default

Modified:
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/test/Driver/hexagon-toolchain-elf.c
cfe/trunk/test/Driver/hexagon-toolchain.c
cfe/trunk/test/SemaCXX/warn-unused-local-typedef-serialize.cpp

Modified: cfe/trunk/lib/Driver/ToolChains.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.h?rev=255127=255126=255127=diff
==
--- cfe/trunk/lib/Driver/ToolChains.h (original)
+++ cfe/trunk/lib/Driver/ToolChains.h Wed Dec  9 10:34:24 2015
@@ -871,6 +871,9 @@ public:
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList ) const 
override;
 
   StringRef GetGCCLibAndIncVersion() const { return GCCLibAndIncVersion.Text; }
+  bool IsIntegratedAssemblerDefault() const override {
+return true;
+  }
 
   std::string GetGnuDir(const std::string ,
 const llvm::opt::ArgList ) const;

Modified: cfe/trunk/test/Driver/hexagon-toolchain-elf.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/hexagon-toolchain-elf.c?rev=255127=255126=255127=diff
==
--- cfe/trunk/test/Driver/hexagon-toolchain-elf.c (original)
+++ cfe/trunk/test/Driver/hexagon-toolchain-elf.c Wed Dec  9 10:34:24 2015
@@ -2,7 +2,7 @@
 // Test standard include paths
 // 
-
 
-// RUN: %clang -### -target hexagon-unknown-elf \
+// RUN: %clang -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/qc/bin \
 // RUN:   --gcc-toolchain="" \
 // RUN:   %s 2>&1 \
@@ -12,7 +12,7 @@
 // CHECK001:   "-internal-externc-isystem" 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/hexagon/include"
 // CHECK001-NEXT: 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/bin{{/|}}hexagon-as"
 
-// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN: %clangxx -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/qc/bin \
 // RUN:   --gcc-toolchain="" \
 // RUN:   %s 2>&1 \
@@ -27,7 +27,7 @@
 // Test -nostdinc, -nostdlibinc, -nostdinc++
 // 
-
 
-// RUN: %clang -### -target hexagon-unknown-elf \
+// RUN: %clang -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/qc/bin \
 // RUN:   --gcc-toolchain="" \
 // RUN:   -nostdinc \
@@ -39,7 +39,7 @@
 // CHECK003-NOT: "-internal-externc-isystem" 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/hexagon/include"
 // CHECK003-NEXT: 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/bin{{/|}}hexagon-as"
 
-// RUN: %clang -### -target hexagon-unknown-elf \
+// RUN: %clang -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/qc/bin \
 // RUN:   --gcc-toolchain="" \
 // RUN:   -nostdlibinc \
@@ -51,7 +51,7 @@
 // CHECK004-NOT: "-internal-externc-isystem" 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/hexagon/include"
 // CHECK004-NEXT: 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/bin{{/|}}hexagon-as"
 
-// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN: %clangxx -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/qc/bin \
 // RUN:   --gcc-toolchain="" \
 // RUN:   -nostdlibinc \
@@ -64,7 +64,7 @@
 // CHECK005-NOT: "-internal-externc-isystem" 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/hexagon/include"
 // CHECK005-NEXT: 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/bin{{/|}}hexagon-as"
 
-// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN: %clangxx -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/qc/bin \
 // RUN:   --gcc-toolchain="" \
 // RUN:   -nostdinc++ \
@@ -77,7 +77,7 @@
 // 
-
 // Test -march= -mcpu= -mv
 // 
-
-// RUN: %clang -### -target hexagon-unknown-elf \
+// RUN: %clang -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/qc/bin \
 // RUN:   --gcc-toolchain="" \
 // RUN:   -march=hexagonv3 \
@@ -87,7 +87,7 @@
 // CHECK007-NEXT: 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/bin{{/|}}hexagon-as"{{.*}} 
"-march=v3"
 // CHECK007-NEXT: 
"{{.*}}/Inputs/hexagon_tree/qc/bin/../../gnu/bin{{/|}}hexagon-ld"{{.*}} 
"-mv3"
 
-// RUN: %clang -### -target hexagon-unknown-elf \
+// RUN: %clang -### -target hexagon-unknown-elf -fno-integrated-as\
 // RUN:   -ccc-install-dir 

Re: [PATCH] D15332: new clang-tidy checker readability-non-const-parameter

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Please add tests with templates and macros. Please also run this on LLVM/Clang 
to ensure a) it doesn't crash; b) the number of warnings is sane; c) a 
representative sample of warnings doesn't contain false positives.


http://reviews.llvm.org/D15332



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

Re: [PATCH] D15332: new clang-tidy checker readability-non-const-parameter

[Daniel Marjamäki via cfe-commits]

danielmarjamaki marked 3 inline comments as done.
danielmarjamaki added a comment.

In http://reviews.llvm.org/D15332#305976, @alexfh wrote:

> Please add tests with templates and macros. Please also run this on 
> LLVM/Clang to ensure a) it doesn't crash; b) the number of warnings is sane; 
> c) a representative sample of warnings doesn't contain false positives.


I am running clang-tidy on LLVM/Clang right now. I expect that it will take 
several hours.

I expect that I will get false positives when there are templates and I will 
add corresponding test cases.


http://reviews.llvm.org/D15332



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

Re: [PATCH] D15321: [OpenMP 4.0]Parsing and Sema support for 'omp declare target' directive (accelerator support)

[Michael Wong via cfe-commits]

fraggamuffin removed rL LLVM as the repository for this revision.
fraggamuffin updated this revision to Diff 42307.
fraggamuffin marked an inline comment as done.
fraggamuffin added a comment.

This is just an interim full diff file of changes accepted so far. I still need 
to address the attribute and Helper class comment. Thanks.


http://reviews.llvm.org/D15321

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/DeclOpenMP.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OpenMPKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclOpenMP.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/OpenMP/declare_target_ast_print.cpp
  clang/test/OpenMP/declare_target_messages.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5228,6 +5228,7 @@
   case Decl::ClassScopeFunctionSpecialization:
   case Decl::Import:
   case Decl::OMPThreadPrivate:
+  case Decl::OMPDeclareTarget:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
 return C;
Index: clang/test/OpenMP/declare_target_messages.cpp
===
--- clang/test/OpenMP/declare_target_messages.cpp
+++ clang/test/OpenMP/declare_target_messages.cpp
@@ -0,0 +1,83 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp -fnoopenmp-use-tls -ferror-limit 100 -o - %s
+
+#pragma omp end declare target // expected-error {{unexpected OpenMP directive '#pragma omp end declare target'}}
+
+int a, b; // expected-warning 2 {{declaration is not declared in any declare target region}}
+__thread int t; // expected-error {{threadprivate variables cannot be used in target constructs}}
+#pragma omp declare target private(a) // expected-warning {{extra tokens at the end of '#pragma omp declare target' are ignored}}
+void f();
+#pragma omp end declare target shared(a) // expected-warning {{extra tokens at the end of '#pragma omp end declare target' are ignored}}
+void c(); // expected-warning {{declaration is not declared in any declare target region}}
+
+extern int b;
+
+struct NonT {
+  int a;
+};
+
+typedef int sint;
+
+#pragma omp declare target // expected-note {{to match this '#pragma omp declare target'}}
+#pragma omp threadprivate(a) // expected-error {{threadprivate variables cannot be used in target constructs}} expected-note {{used here}}
+extern int b;
+int g;
+
+struct T { // expected-note {{mappable type cannot be polymorphic}}
+  int a;
+  virtual int method();
+};
+
+class VC { // expected-note {{mappable type cannot be polymorphic}}
+  T member;
+  NonT member1;
+  public:
+virtual int method() { T a; return 0; } // expected-error {{type 'T' is not mappable to target}}
+};
+
+struct C {
+  NonT a;
+  sint b;
+  int method();
+  int method1();
+};
+
+int C::method1() {
+  return 0;
+}
+
+void foo() {
+  a = 0; // expected-note {{used here}}
+  b = 0; // expected-note {{used here}}
+  t = 1; // expected-note {{used here}}
+  C object;
+  VC object1; // expected-error {{type 'VC' is not mappable to target}}
+  g = object.method();
+  g += object.method1();
+  g += object1.method();
+  f();
+  c(); // expected-note {{used here}}
+}
+#pragma omp declare target // expected-error {{expected '#pragma omp end declare target'}}
+void foo1() {}
+#pragma omp end declare target
+#pragma omp end declare target // expected-error {{unexpected OpenMP directive '#pragma omp end declare target'}}
+
+int C::method() {
+  return 0;
+}
+
+struct S {
+#pragma omp declare target // expected-error {{directive must be at file or namespace scope}}
+  int v;
+#pragma omp end declare target // expected-error {{unexpected OpenMP directive '#pragma omp end declare target'}}
+};
+
+int main (int argc, char **argv) {
+#pragma omp declare target // 

Re: [PATCH] D15332: new clang-tidy checker readability-non-const-parameter

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

This check partially implements PR19419. Could it be extended to variables?


http://reviews.llvm.org/D15332



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

r255129 - unique_ptrify some collections in FileManager

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Dec  9 11:23:13 2015
New Revision: 255129

URL: http://llvm.org/viewvc/llvm-project?rev=255129=rev
Log:
unique_ptrify some collections in FileManager

Modified:
cfe/trunk/include/clang/Basic/FileManager.h
cfe/trunk/lib/Basic/FileManager.cpp

Modified: cfe/trunk/include/clang/Basic/FileManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=255129=255128=255129=diff
==
--- cfe/trunk/include/clang/Basic/FileManager.h (original)
+++ cfe/trunk/include/clang/Basic/FileManager.h Wed Dec  9 11:23:13 2015
@@ -126,9 +126,9 @@ class FileManager : public RefCountedBas
   ///
   /// For each virtual file (e.g. foo/bar/baz.cpp), we add all of its parent
   /// directories (foo/ and foo/bar/) here.
-  SmallVector VirtualDirectoryEntries;
+  SmallVector VirtualDirectoryEntries;
   /// \brief The virtual files that we have allocated.
-  SmallVector VirtualFileEntries;
+  SmallVector VirtualFileEntries;
 
   /// \brief A cache that maps paths to directory entries (either real or
   /// virtual) we have looked up

Modified: cfe/trunk/lib/Basic/FileManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileManager.cpp?rev=255129=255128=255129=diff
==
--- cfe/trunk/lib/Basic/FileManager.cpp (original)
+++ cfe/trunk/lib/Basic/FileManager.cpp Wed Dec  9 11:23:13 2015
@@ -22,6 +22,7 @@
 #include "clang/Frontend/PCHContainerOperations.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Config/llvm-config.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
@@ -58,12 +59,7 @@ FileManager::FileManager(const FileSyste
 this->FS = vfs::getRealFileSystem();
 }
 
-FileManager::~FileManager() {
-  for (FileEntry *FE : VirtualFileEntries)
-delete FE;
-  for (DirectoryEntry *DE : VirtualDirectoryEntries)
-delete DE;
-}
+FileManager::~FileManager() = default;
 
 void FileManager::addStatCache(std::unique_ptr statCache,
bool AtBeginning) {
@@ -141,10 +137,10 @@ void FileManager::addAncestorsAsVirtualD
 return;
 
   // Add the virtual directory to the cache.
-  DirectoryEntry *UDE = new DirectoryEntry;
+  auto UDE = llvm::make_unique();
   UDE->Name = NamedDirEnt.first().data();
-  NamedDirEnt.second = UDE;
-  VirtualDirectoryEntries.push_back(UDE);
+  NamedDirEnt.second = UDE.get();
+  VirtualDirectoryEntries.push_back(std::move(UDE));
 
   // Recursively add the other ancestors.
   addAncestorsAsVirtualDirs(DirName);
@@ -375,8 +371,8 @@ FileManager::getVirtualFile(StringRef Fi
   }
 
   if (!UFE) {
-UFE = new FileEntry();
-VirtualFileEntries.push_back(UFE);
+VirtualFileEntries.push_back(llvm::make_unique());
+UFE = VirtualFileEntries.back().get();
 NamedFileEnt.second = UFE;
   }
 
@@ -513,11 +509,9 @@ void FileManager::GetUniqueIDMapping(
   UIDToFiles[FE->getValue()->getUID()] = FE->getValue();
   
   // Map virtual file entries
-  for (SmallVectorImpl::const_iterator
- VFE = VirtualFileEntries.begin(), VFEEnd = VirtualFileEntries.end();
-   VFE != VFEEnd; ++VFE)
-if (*VFE && *VFE != NON_EXISTENT_FILE)
-  UIDToFiles[(*VFE)->getUID()] = *VFE;
+  for (const auto  : VirtualFileEntries)
+if (VFE && VFE.get() != NON_EXISTENT_FILE)
+  UIDToFiles[VFE->getUID()] = VFE.get();
 }
 
 void FileManager::modifyFileEntry(FileEntry *File,


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

Re: r252960 - [modules] Simplify and generalize the existing rule for finding hidden

[Ben Langmuir via cfe-commits]

Hey Richard,

This caused a new error for the following code:

@import Foo.X; // declaration of ‘struct foo’ from Foo.Y is not visible 
yet, but the pcm is loaded.
struct foo *bar; // declares ‘struct foo’
@import Foo.Y; // also declares ‘struct foo’

void useFoo(struct foo *x);  // error: reference to ‘foo’ is ambiguous

This seems to be specific to declaring the tag with an elaborated type 
specifier that is not just ‘struct foo;’.  Any idea what went wrong?  I’m 
trying to track this down and fix it.

Ben

> On Nov 12, 2015, at 2:19 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> Author: rsmith
> Date: Thu Nov 12 16:19:45 2015
> New Revision: 252960
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=252960=rev
> Log:
> [modules] Simplify and generalize the existing rule for finding hidden
> declarations in redeclaration lookup. A declaration is now visible to
> lookup if:
> 
> * It is visible (not in a module, or in an imported module), or
> * We're doing redeclaration lookup and it's externally-visible, or
> * We're doing typo correction and looking for unimported decls.
> 
> We now support multiple modules having different internal-linkage or 
> no-linkage
> definitions of the same name for all entities, not just for functions,
> variables, and some typedefs. As previously, if multiple such entities are
> visible, any attempt to use them will result in an ambiguity error.
> 
> This patch fixes the linkage calculation for a number of entities where we
> previously didn't need to get it right (using-declarations, namespace aliases,
> and so on).  It also classifies enumerators as always having no linkage, which
> is a slight deviation from the C++ standard's definition, but not an 
> observable
> change outside modules (this change is being discussed on the -core reflector
> currently).
> 
> This also removes the prior special case for tag lookup, which made some cases
> of this work, but also led to bizarre, bogus "must use 'struct' to refer to 
> type
> 'Foo' in this scope" diagnostics in C++.
> 
> Added:
>cfe/trunk/test/Modules/Inputs/no-linkage/
>cfe/trunk/test/Modules/Inputs/no-linkage/decls.h
>cfe/trunk/test/Modules/Inputs/no-linkage/empty.h
>cfe/trunk/test/Modules/Inputs/no-linkage/module.modulemap
>cfe/trunk/test/Modules/no-linkage.cpp
> Modified:
>cfe/trunk/include/clang/Sema/Lookup.h
>cfe/trunk/lib/AST/Decl.cpp
>cfe/trunk/lib/Sema/SemaDecl.cpp
>cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>cfe/trunk/test/Index/linkage.c
>cfe/trunk/test/Index/usrs.m
>cfe/trunk/test/Modules/decldef.m
>cfe/trunk/test/Modules/merge-enumerators.cpp
>cfe/trunk/test/Modules/module-private.cpp
>cfe/trunk/test/Modules/submodule-visibility-cycles.cpp
>cfe/trunk/test/Modules/submodules-merge-defs.cpp
> 
> Modified: cfe/trunk/include/clang/Sema/Lookup.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Lookup.h?rev=252960=252959=252960=diff
> ==
> --- cfe/trunk/include/clang/Sema/Lookup.h (original)
> +++ cfe/trunk/include/clang/Sema/Lookup.h Thu Nov 12 16:19:45 2015
> @@ -139,8 +139,7 @@ public:
>   Redecl(Redecl != Sema::NotForRedeclaration),
>   HideTags(true),
>   Diagnose(Redecl == Sema::NotForRedeclaration),
> -  AllowHidden(Redecl == Sema::ForRedeclaration),
> -  AllowHiddenInternal(AllowHidden),
> +  AllowHidden(false),
>   Shadowed(false)
>   {
> configure();
> @@ -162,8 +161,7 @@ public:
>   Redecl(Redecl != Sema::NotForRedeclaration),
>   HideTags(true),
>   Diagnose(Redecl == Sema::NotForRedeclaration),
> -  AllowHidden(Redecl == Sema::ForRedeclaration),
> -  AllowHiddenInternal(AllowHidden),
> +  AllowHidden(false),
>   Shadowed(false)
>   {
> configure();
> @@ -184,7 +182,6 @@ public:
>   HideTags(Other.HideTags),
>   Diagnose(false),
>   AllowHidden(Other.AllowHidden),
> -  AllowHiddenInternal(Other.AllowHiddenInternal),
>   Shadowed(false)
>   {}
> 
> @@ -226,27 +223,16 @@ public:
>   /// \brief Specify whether hidden declarations are visible, e.g.,
>   /// for recovery reasons.
>   void setAllowHidden(bool AH) {
> -AllowHiddenInternal = AllowHidden = AH;
> -  }
> -
> -  /// \brief Specify whether hidden internal declarations are visible.
> -  void setAllowHiddenInternal(bool AHI) {
> -AllowHiddenInternal = AHI;
> +AllowHidden = AH;
>   }
> 
>   /// \brief Determine whether this lookup is permitted to see hidden
>   /// declarations, such as those in modules that have not yet been imported.
>   bool isHiddenDeclarationVisible(NamedDecl *ND) const {
> -// If a using-shadow declaration is hidden, it's never visible, not
> -// even to redeclaration lookup.
> -// FIXME: Should this apply to typedefs and namespace aliases too?
> -if (isa(ND) && LookupKind != Sema::LookupUsingDeclName)
> -  return 

Re: [PATCH] D14814: [libcxx] Use __make_integer_seq builtin when available

[David Majnemer via cfe-commits]

majnemer added a comment.

@EricWF Yes, it will.


http://reviews.llvm.org/D14814



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

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

[Robinson, Paul via cfe-commits]

Actually no, we prefer to have the original typedef names in the instantiation 
name, for source fidelity.  "Name as it is in the source" or something 
reasonably close.  Unwrapping typedefs is going too far.

Re. "looseness" of the DWARF spec, it is not so loose as you like to think.  
Attributes tend to be fairly optional or can be used "in novel ways" but the 
DIEs and their relationships are not like that.  "Where this specification 
provides a means for describing the source language, implementors are expected 
to adhere to that specification."
--paulr

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Wednesday, December 09, 2015 10:49 AM
To: Robinson, Paul
Cc: Marshall, Peter; llvm-dev; cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: [PATCH] D14358: DWARF's forward decl of a template should have 
template parameters.



On Wed, Dec 9, 2015 at 10:40 AM, Robinson, Paul 
> 
wrote:
That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be surprising 
if we used the typedef (or otherwise non-canonical) name in the class name):

Finally getting back to this…..  Ha.  We don't unwrap the typedefs ("name as it 
is in the source"), while the upstream compiler does.

Yeah, I imagine you'd want to fix that as I expect it would cause you other 
problems, no? (or is there some reason you have this change to the compiler? I 
imagine it'd be hard to have that divergence by accident?)

Providing the template-parameter DIEs is still the correct thing to do per the 
DWARF
spec.

I still don't agree that the DWARF we produce here is incorrect (the DWARF spec 
is pretty loose on "correctness" of DWARF). If there's some practical 
problem/use case it'd be useful to understand it so we make sure we're fixing 
it the right way.

- Dave

--paulr

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Friday, November 13, 2015 11:21 AM
To: Marshall, Peter; llvm-dev
Cc: Robinson, Paul

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



On Fri, Nov 13, 2015 at 6:16 AM, 
> wrote:
Hi Paul,

Sorry for the delay, I've been out of the office.

I think this example shows that name matching does not always work:

template class A {
public:
A(T val);
private:
T x;
};

struct B {
typedef float MONKEY;

A *p;
};

B b;

struct C {
typedef int MONKEY;

A *p;
};

C c;

This gives this DWARF:

+-003f DW_TAG_structure_type "B"
   -DW_AT_name  DW_FORM_strp  "B"
  +-0047 DW_TAG_member "p"
 -DW_AT_name  DW_FORM_strp  "p"
+-DW_AT_type  DW_FORM_ref4  0x0054
  +-0054 DW_TAG_pointer_type
+-DW_AT_type  DW_FORM_ref4  0x0059
  +-0059 DW_TAG_class_type "A"
 -DW_AT_name  DW_FORM_strp  "A"
 -DW_AT_declaration  DW_FORM_flag_present

+-0073 DW_TAG_structure_type "C"
   -DW_AT_name  DW_FORM_strp  "C"
  +-007b DW_TAG_member "p"
 -DW_AT_name  DW_FORM_strp  "p"
+-DW_AT_type  DW_FORM_ref4  0x0088
  +-0088 DW_TAG_pointer_type
+-DW_AT_type  DW_FORM_ref4  0x008d
  +-008d DW_TAG_class_type "A"
 -DW_AT_name  DW_FORM_strp  "A"
 -DW_AT_declaration  DW_FORM_flag_present

That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be surprising 
if we used the typedef (or otherwise non-canonical) name in the class name):

(I've trimmed a few irrelevant attributes)
0x001e:   DW_TAG_variable [2]
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x004c] = "b")
DW_AT_type [DW_FORM_ref4]   (cu + 0x0033 => {0x0033})

0x0033:   DW_TAG_structure_type [3] *
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0059] = "B")

0x003b: DW_TAG_member [4]
  DW_AT_name [DW_FORM_strp] ( .debug_str[0x004e] = "p")
  DW_AT_type [DW_FORM_ref4] (cu + 0x0048 => {0x0048})

0x0047: NULL

0x0048:   DW_TAG_pointer_type [5]
DW_AT_type [DW_FORM_ref4]   (cu + 0x004d => {0x004d})

0x004d:   DW_TAG_class_type [6]
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0050] = 
"A")
DW_AT_declaration [DW_FORM_flag_present](true)

0x0052:   DW_TAG_variable [2]
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x005b] = "c")
DW_AT_type [DW_FORM_ref4]   (cu + 0x0067 => {0x0067})

0x0067:   DW_TAG_structure_type [3] *
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0064] = "C")

0x006f: DW_TAG_member [4]
  DW_AT_name [DW_FORM_strp] ( .debug_str[0x004e] = "p")
  DW_AT_type [DW_FORM_ref4] (cu + 0x007c => {0x007c})

0x007b: NULL

0x007c:   DW_TAG_pointer_type 

Re: [libcxx] Reinstate and fix overload sets to be const-correct wherever possible

[Eric Fiselier via cfe-commits]

Richard could you do me a favor and put this on phabricator?

/Eric

On Tue, Dec 8, 2015 at 3:52 PM, Richard Smith  wrote:

> Ping.
>
> On Mon, Nov 23, 2015 at 6:55 PM, Richard Smith 
> wrote:
>
>> Ping.
>>
>> On Thu, Nov 5, 2015 at 6:32 PM, Richard Smith 
>> wrote:
>>
>>> Ping.
>>>
>>> On Thu, Oct 29, 2015 at 5:21 PM, Richard Smith 
>>> wrote:
>>>
 Hi,

 The attached patch undoes the revert of r249929, and adds an extension
 to allow  (and ) to work properly even in environments
 such as iOS where the underlying libc does not provide C++'s const-correct
 overloads of strchr and friends.

 This works as follows:

  * The macro _LIBCPP_PREFERRED_OVERLOAD is, where possible, defined by
 <__config> to an attribute that provides the following semantics:
- A function declaration with the attribute declares a different
 function from a function declaration without the attribute.
- Overload resolution prefers a function with the attribute over a
 function without.
  * For each of the functions that has a "broken" signature in C, if we
 don't believe that the C library provided the C++ signatures, and we have a
 _LIBCPP_PREFERRED_OVERLOAD, then we add the C++ declarations and mark them
 as preferred over the C overloads.
  * The overloads provided in namespace std always exactly match those
 in ::.


 This results in the following changes in cases where the underlying
 libc provides the C signature not the C++ one, compared to the status quo:


 :

   char *strchr(const char*, int) // #1
   char *strchr(char*, int) // #2
   const char *strchr(const char*, int) // #3

 We used to provide #1 and #2 in namespace std (in ) and only
 #1 in global namespace (in ).

 For a very old clang or non-clang compiler, we now have only #1 in both
 places (note that #2 is essentially useless). This is unlikely to be a
 visible change in real code, but it's slightly broken either way and we
 can't fix it.

 For newer clang (3.6 onwards?), we now have correct signatures (#2 and
 #3) in :: and std (depending on header). Taking address of strchr requires
 ~trunk clang (but it didn't work before either, so this is not really a
 regression).


 :

   wchar_t *wcschr(const wchar_t *, wchar_t) // #1
   const wchar_t *wcschr(const wchar_t *, wchar_t) // #2
   wchar_t *wcschr(wchar_t *, wchar_t) // #3

 We used to provide #1 in global namespace, and #2 and #3 in namespace
 std. This broke code that uses 'using namespace std;'.

 For a very old clang or non-clang compiler, we now have #1 in global
 namespace and namespace std. This fixes the ambiguity errors, but decreases
 const-correctness in this case. On the whole, this seems like an
 improvement to me.

 For newer clang, we now have correct signatures (#2 and #3) in :: and
 std (depending on header). As above, taking address doesn't work unless
 you're using very recent Clang (this is not a regression in ::, but is a
 regression in namespace std).


 To summarize, we previously had ad-hoc, inconsistent, slightly broken
 rules for  and , and with this patch we fix the overload
 set to give the exact C++ semantics where possible (for all recent versions
 of Clang), and otherwise leave the C signatures alone.

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

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

[David Blaikie via cfe-commits]

On Wed, Dec 9, 2015 at 11:11 AM, Robinson, Paul <
paul_robin...@playstation.sony.com> wrote:

> Actually no, we prefer to have the original typedef names in the
> instantiation name, for source fidelity.
>

Then perhaps you should keep this change in your tree too - since that's
where the need is?


>   "Name as it is in the source" or something reasonably close.  Unwrapping
> typedefs is going too far.
>

Yet this isn't the choice upstream in Clang or GCC. I don't know about
other DWARF generators, but it seems your interpretation isn't the way some
other people/implementers are reading the DWARF spec.

[This seems like it would present a multitude of challenges to any DWARF
debugger dealing with this kind of debug info - it'd have to know far more
about the rules of the C++ language (which you've previously argued in
favor of avoiding) to perform a variety of operations if the types don't
match up fairly trivially.]

In any case, arguably 5.5.8 (Class Template Instantiations) 1 only applies
to definitions of a type, not declarations. ("Each formal parameterized
type declaration appearing in the template definition is represented by a
debugging information entry with the tag DW_TAG_template_type_parameter")
which, I agree, seems like a bug in the spec to not /allow/ them on
declarations, but I'd equally argue requiring them would seem too narrow to
me.


> Re. "looseness" of the DWARF spec, it is not so loose as you like to
> think.  Attributes tend to be fairly optional or can be used "in novel
> ways" but the DIEs and their relationships are not like that.  "Where this
> specification provides a means for describing the source language,
> implementors are expected to adhere to that specification."
>

Why would that clause apply to attributes any less than it applies to DIEs?
It seems like a fairly broad statement.

I forget whether we already discussed it - but do you have any size data
(preferably/possibly from a fission build or otherwise measurement of "just
the debug info" not the whole binary) on, for example, a clang selfhost?

- Dave


> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Wednesday, December 09, 2015 10:49 AM
> *To:* Robinson, Paul
> *Cc:* Marshall, Peter; llvm-dev; cfe-commits (cfe-commits@lists.llvm.org)
>
> *Subject:* Re: [PATCH] D14358: DWARF's forward decl of a template should
> have template parameters.
>
>
>
>
>
>
>
> On Wed, Dec 9, 2015 at 10:40 AM, Robinson, Paul <
> paul_robin...@playstation.sony.com> wrote:
>
> That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be
> surprising if we used the typedef (or otherwise non-canonical) name in the
> class name):
>
>
>
> Finally getting back to this…..  Ha.  We don't unwrap the typedefs ("name
> as it is in the source"), while the upstream compiler does.
>
>
>
> Yeah, I imagine you'd want to fix that as I expect it would cause you
> other problems, no? (or is there some reason you have this change to the
> compiler? I imagine it'd be hard to have that divergence by accident?)
>
>
>
> Providing the template-parameter DIEs is still the correct thing to do per
> the DWARF
>
> spec.
>
>
>
> I still don't agree that the DWARF we produce here is incorrect (the DWARF
> spec is pretty loose on "correctness" of DWARF). If there's some practical
> problem/use case it'd be useful to understand it so we make sure we're
> fixing it the right way.
>
> - Dave
>
>
>
> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Friday, November 13, 2015 11:21 AM
> *To:* Marshall, Peter; llvm-dev
> *Cc:* Robinson, Paul
>
>
> *Subject:* Re: [PATCH] D14358: DWARF's forward decl of a template should
> have template parameters.
>
>
>
>
>
>
>
> On Fri, Nov 13, 2015 at 6:16 AM,  wrote:
>
> Hi Paul,
>
> Sorry for the delay, I've been out of the office.
>
> I think this example shows that name matching does not always work:
>
> template class A {
> public:
> A(T val);
> private:
> T x;
> };
>
> struct B {
> typedef float MONKEY;
>
> A *p;
> };
>
> B b;
>
> struct C {
> typedef int MONKEY;
>
> A *p;
> };
>
> C c;
>
> This gives this DWARF:
>
> +-003f DW_TAG_structure_type "B"
>-DW_AT_name  DW_FORM_strp  "B"
>   +-0047 DW_TAG_member "p"
>  -DW_AT_name  DW_FORM_strp  "p"
> +-DW_AT_type  DW_FORM_ref4  0x0054
>   +-0054 DW_TAG_pointer_type
> +-DW_AT_type  DW_FORM_ref4  0x0059
>   +-0059 DW_TAG_class_type "A"
>  -DW_AT_name  DW_FORM_strp  "A"
>  -DW_AT_declaration  DW_FORM_flag_present
>
> +-0073 DW_TAG_structure_type "C"
>-DW_AT_name  DW_FORM_strp  "C"
>   +-007b DW_TAG_member "p"
>  -DW_AT_name  DW_FORM_strp  "p"
> +-DW_AT_type  DW_FORM_ref4  0x0088
>   +-0088 DW_TAG_pointer_type
> +-DW_AT_type  DW_FORM_ref4  0x008d
>   +-008d DW_TAG_class_type "A"
>  -DW_AT_name  DW_FORM_strp  "A"
>  

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

Hi,

Have you had a chance to look at this?


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

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

[Robinson, Paul via cfe-commits]

That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be surprising 
if we used the typedef (or otherwise non-canonical) name in the class name):

Finally getting back to this…..  Ha.  We don't unwrap the typedefs ("name as it 
is in the source"), while the upstream compiler does.
Providing the template-parameter DIEs is still the correct thing to do per the 
DWARF spec.
--paulr

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Friday, November 13, 2015 11:21 AM
To: Marshall, Peter; llvm-dev
Cc: Robinson, Paul
Subject: Re: [PATCH] D14358: DWARF's forward decl of a template should have 
template parameters.



On Fri, Nov 13, 2015 at 6:16 AM, 
> wrote:
Hi Paul,

Sorry for the delay, I've been out of the office.

I think this example shows that name matching does not always work:

template class A {
public:
A(T val);
private:
T x;
};

struct B {
typedef float MONKEY;

A *p;
};

B b;

struct C {
typedef int MONKEY;

A *p;
};

C c;

This gives this DWARF:

+-003f DW_TAG_structure_type "B"
   -DW_AT_name  DW_FORM_strp  "B"
  +-0047 DW_TAG_member "p"
 -DW_AT_name  DW_FORM_strp  "p"
+-DW_AT_type  DW_FORM_ref4  0x0054
  +-0054 DW_TAG_pointer_type
+-DW_AT_type  DW_FORM_ref4  0x0059
  +-0059 DW_TAG_class_type "A"
 -DW_AT_name  DW_FORM_strp  "A"
 -DW_AT_declaration  DW_FORM_flag_present

+-0073 DW_TAG_structure_type "C"
   -DW_AT_name  DW_FORM_strp  "C"
  +-007b DW_TAG_member "p"
 -DW_AT_name  DW_FORM_strp  "p"
+-DW_AT_type  DW_FORM_ref4  0x0088
  +-0088 DW_TAG_pointer_type
+-DW_AT_type  DW_FORM_ref4  0x008d
  +-008d DW_TAG_class_type "A"
 -DW_AT_name  DW_FORM_strp  "A"
 -DW_AT_declaration  DW_FORM_flag_present

That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be surprising 
if we used the typedef (or otherwise non-canonical) name in the class name):

(I've trimmed a few irrelevant attributes)
0x001e:   DW_TAG_variable [2]
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x004c] = "b")
DW_AT_type [DW_FORM_ref4]   (cu + 0x0033 => {0x0033})

0x0033:   DW_TAG_structure_type [3] *
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0059] = "B")

0x003b: DW_TAG_member [4]
  DW_AT_name [DW_FORM_strp] ( .debug_str[0x004e] = "p")
  DW_AT_type [DW_FORM_ref4] (cu + 0x0048 => {0x0048})

0x0047: NULL

0x0048:   DW_TAG_pointer_type [5]
DW_AT_type [DW_FORM_ref4]   (cu + 0x004d => {0x004d})

0x004d:   DW_TAG_class_type [6]
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0050] = 
"A")
DW_AT_declaration [DW_FORM_flag_present](true)

0x0052:   DW_TAG_variable [2]
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x005b] = "c")
DW_AT_type [DW_FORM_ref4]   (cu + 0x0067 => {0x0067})

0x0067:   DW_TAG_structure_type [3] *
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0064] = "C")

0x006f: DW_TAG_member [4]
  DW_AT_name [DW_FORM_strp] ( .debug_str[0x004e] = "p")
  DW_AT_type [DW_FORM_ref4] (cu + 0x007c => {0x007c})

0x007b: NULL

0x007c:   DW_TAG_pointer_type [5]
DW_AT_type [DW_FORM_ref4]   (cu + 0x0081 => {0x0081})

0x0081:   DW_TAG_class_type [6]
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x005d] = 
"A")
DW_AT_declaration [DW_FORM_flag_present](true)



As there are no template parameters for the forward declaration of either 
A
they are indistinguishable.

The reason we currently have no need for the parameters in a template name is 
because we
reconstruct template names from their parameter tags. This allow the pretty 
printing to match
the templates from the DWARF to match our demangled symbols from the ELF symbol 
table.

-Pete




From:"Robinson, Paul" 
>
To:David Blaikie >, 
"Marshall, Peter" 
>
Cc:
"reviews+d14358+public+d3104135076f0...@reviews.llvm.org"

>,
 "cfe-commits (cfe-commits@lists.llvm.org)" 
>
Date:10/11/2015 01:08
Subject:RE: [PATCH] D14358: DWARF's forward decl of a template should 
have template parameters.

Re: [PATCH] D15309: [CUDA] emit vtables only for classes with methods usable on this side of compilation.

[Artem Belevich via cfe-commits]

tra added inline comments.


Comment at: test/CodeGenCUDA/device-vtable.cu:36
@@ +35,3 @@
+// only device methods would be available during host or device
+// compilation. For now we'll not emit such vtable at all.
+class HD  {

jpienaar wrote:
> What is the current behavior in this case? Should an error be reported?
Hmm. nvcc actually accepts mixed virtual methods and generates vtable with NULL 
pointers for methods that are not available on particular side. That shifts 
responsibility to end-user which is
reasonable in this situation. A warning about partial availability of some 
virtual method would be helpful here, I think.

OK. Let me try matching nvcc's behavior and add a warning.


http://reviews.llvm.org/D15309



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

[PATCH] D15388: [Clang] Use autos in lib/AST/Expr.cpp

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko created this revision.
Eugene.Zelenko added reviewers: hans, aaron.ballman.
Eugene.Zelenko added a subscriber: cfe-commits.
Eugene.Zelenko set the repository for this revision to rL LLVM.

Autos are also used for pointer variables assigned via casts or memory 
allocation. Patch includes other minor cleanups.

Build and regressions were fine on RHEL 6.

Repository:
  rL LLVM

http://reviews.llvm.org/D15388

Files:
  lib/AST/Expr.cpp

Index: lib/AST/Expr.cpp
===
--- lib/AST/Expr.cpp
+++ lib/AST/Expr.cpp
@@ -1,4 +1,4 @@
-//===--- Expr.cpp - Expression AST Node Implementation ===//
+//===--- Expr.cpp - Expression AST Node Implementation --*- C++ -*-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -34,6 +34,7 @@
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
+
 using namespace clang;
 
 const CXXRecordDecl *Expr::getBestDynamicClassType() const {
@@ -46,7 +47,7 @@
   if (DerivedType->isDependentType())
 return nullptr;
 
-  const RecordType *Ty = DerivedType->castAs();
+  const auto *Ty = DerivedType->castAs();
   Decl *D = Ty->getDecl();
   return cast(D);
 }
@@ -58,12 +59,12 @@
   while (true) {
 E = E->IgnoreParens();
 
-if (const CastExpr *CE = dyn_cast(E)) {
+if (const auto *CE = dyn_cast(E)) {
   if ((CE->getCastKind() == CK_DerivedToBase ||
CE->getCastKind() == CK_UncheckedDerivedToBase) &&
   E->getType()->isRecordType()) {
 E = CE->getSubExpr();
-CXXRecordDecl *Derived
+auto *Derived
   = cast(E->getType()->getAs()->getDecl());
 Adjustments.push_back(SubobjectAdjustment(CE, Derived));
 continue;
@@ -73,7 +74,7 @@
 E = CE->getSubExpr();
 continue;
   }
-} else if (const MemberExpr *ME = dyn_cast(E)) {
+} else if (const auto *ME = dyn_cast(E)) {
   if (!ME->isArrow()) {
 assert(ME->getBase()->getType()->isRecordType());
 if (FieldDecl *Field = dyn_cast(ME->getMemberDecl())) {
@@ -84,7 +85,7 @@
   }
 }
   }
-} else if (const BinaryOperator *BO = dyn_cast(E)) {
+} else if (const auto *BO = dyn_cast(E)) {
   if (BO->isPtrMemOp()) {
 assert(BO->getRHS()->isRValue());
 E = BO->getLHS();
@@ -117,7 +118,7 @@
   // If this is a non-scalar-integer type, we don't care enough to try. 
   if (!E->getType()->isIntegralOrEnumerationType()) return false;
   
-  if (const UnaryOperator *UO = dyn_cast(E)) {
+  if (const auto *UO = dyn_cast(E)) {
 switch (UO->getOpcode()) {
 case UO_Plus:
   return UO->getSubExpr()->isKnownToHaveBooleanValue();
@@ -130,10 +131,10 @@
   
   // Only look through implicit casts.  If the user writes
   // '(int) (a && b)' treat it as an arbitrary int.
-  if (const ImplicitCastExpr *CE = dyn_cast(E))
+  if (const auto *CE = dyn_cast(E))
 return CE->getSubExpr()->isKnownToHaveBooleanValue();
   
-  if (const BinaryOperator *BO = dyn_cast(E)) {
+  if (const auto *BO = dyn_cast(E)) {
 switch (BO->getOpcode()) {
 default: return false;
 case BO_LT:   // Relational operators.
@@ -159,7 +160,7 @@
 }
   }
   
-  if (const ConditionalOperator *CO = dyn_cast(E))
+  if (const auto *CO = dyn_cast(E))
 return CO->getTrueExpr()->isKnownToHaveBooleanValue() &&
CO->getFalseExpr()->isKnownToHaveBooleanValue();
   
@@ -188,7 +189,7 @@
 SourceLocation (Expr::*v)() const) {
 return static_cast(expr)->getLocStart();
   }
-}
+} // anonymous namespace
 
 SourceLocation Expr::getExprLoc() const {
   switch (getStmtClass()) {
@@ -266,7 +267,7 @@
   //  (VD) - FIXME: Missing from the standard:
   //   -  an entity with reference type and is initialized with an
   //  expression that is value-dependent [C++11]
-  if (VarDecl *Var = dyn_cast(D)) {
+  if (const auto *Var = dyn_cast(D)) {
 if ((Ctx.getLangOpts().CPlusPlus11 ?
Var->getType()->isLiteralType(Ctx) :
Var->getType()->isIntegralOrEnumerationType()) &&
@@ -484,16 +485,16 @@
   ASTContext  = CurrentDecl->getASTContext();
 
   if (IT == PredefinedExpr::FuncDName) {
-if (const NamedDecl *ND = dyn_cast(CurrentDecl)) {
+if (const auto *ND = dyn_cast(CurrentDecl)) {
   std::unique_ptr MC;
   MC.reset(Context.createMangleContext());
 
   if (MC->shouldMangleDeclName(ND)) {
 SmallString<256> Buffer;
 llvm::raw_svector_ostream Out(Buffer);
-if (const CXXConstructorDecl *CD = dyn_cast(ND))
+if (const auto *CD = dyn_cast(ND))
   MC->mangleCXXCtor(CD, Ctor_Base, Out);
-else if (const CXXDestructorDecl *DD = dyn_cast(ND))
+else if (const auto *DD = dyn_cast(ND))
   MC->mangleCXXDtor(DD, Dtor_Base, Out);
 else
   MC->mangleName(ND, Out);
@@ -522,14 +523,14 @@
   MC->mangleBlock(DC, BD, Out);
 return Out.str();
   }
-  if 

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Robinson, Paul via cfe-commits]

| And at runtime, on some targets, we use this:
|
|  
https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c
|
| ... which gives a NaN in this case.

I copied that function into a test program on Ubuntu, built with gcc, and it 
gives me +Infinity (0x7f80) not NaN (0x7fc0).
--paulr

From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Tuesday, December 08, 2015 11:42 AM
To: Robinson, Paul
Cc: Joerg Sonnenberger; cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: r254574 - PR17381: Treat undefined behavior during expression 
evaluation as an unmodeled

On Tue, Dec 8, 2015 at 11:18 AM, Richard Smith 
> wrote:
On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul 
> 
wrote:
Okay, I'll bite:  so what *does* UINT128_MAX actually convert to?

$ echo 'unsigned __int128 max = -1; float f = max;' | ~/clang-8/build/bin/clang 
-x c++ - -emit-llvm -S -o - -O3 | grep @f
@f = global float undef, align 4

And at runtime, on some targets, we use this:

  https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c

... which gives a NaN in this case.

From: cfe-commits 
[mailto:cfe-commits-boun...@lists.llvm.org]
 On Behalf Of Richard Smith via cfe-commits
Sent: Tuesday, December 08, 2015 10:52 AM
To: Joerg Sonnenberger; cfe-commits
Subject: Re: r254574 - PR17381: Treat undefined behavior during expression 
evaluation as an unmodeled

On Tue, Dec 8, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-commits 
> wrote:
On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits wrote:
> C11 6.3.1.5/1: "If the value being converted is outside the 
> range of values
> that can be represented, the behavior is undefined."

The value of 1e100 can be represented as +inf, even if not precisely.

Only if +inf is in the range of representable values, which, as already noted, 
is problematic.

This is a bit different from non-IEEE math like VAX, that doesn't have
infinities.

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



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

[PATCH] D15384: Don't ask for the size of dependent integral types in template diffing

[Reid Kleckner via cfe-commits]

rnk created this revision.
rnk added a reviewer: rsmith.
rnk added a subscriber: cfe-commits.

In the following example, we end up diffing 'A' against 'A<>'.
  template  struct A {};
  template > R bar();
  A<> () { return bar(); }

It appears that we end up comparing the default argument of
'SizeType = 0' against the instantiated argument of 'int = 0'. The type
of the default argument is still dependent at this point, and this patch
bails out of the comparison at that point.

The diagnostic we ultimately give is not that great, but maybe we can
live with it:
  error: non-const lvalue reference to type 'A<[...], (no argument)>'
 cannot bind to a temporary of type 'A<[...], 0>'

http://reviews.llvm.org/D15384

Files:
  lib/AST/ASTDiagnostic.cpp
  test/Misc/diag-template-diffing.cpp

Index: test/Misc/diag-template-diffing.cpp
===
--- test/Misc/diag-template-diffing.cpp
+++ test/Misc/diag-template-diffing.cpp
@@ -1274,6 +1274,16 @@
 // CHECK-ELIDE-NOTREE: candidate function [with T = 
BoolArgumentBitExtended::BoolT] not viable: no known conversion from 
'BoolT<0>' to 'BoolT<1>' for 1st argument
 }
 
+namespace DefaultNonTypeArgWithDependentType {
+// We used to crash diffing integer template arguments when the argument type
+// is dependent and default arguments were used.
+template  struct A {};
+template > R bar();
+A<> () { return bar(); }
+// CHECK-ELIDE-NOTREE: error: non-const lvalue reference to type 'A<[...], (no 
argument)>' cannot bind to a temporary of type 'A<[...], 0>'
+// CHECK-NOELIDE-NOTREE: error: non-const lvalue reference to type 'A' cannot bind to a temporary of type 'A'
+}
+
 // CHECK-ELIDE-NOTREE: {{[0-9]*}} errors generated.
 // CHECK-NOELIDE-NOTREE: {{[0-9]*}} errors generated.
 // CHECK-ELIDE-TREE: {{[0-9]*}} errors generated.
Index: lib/AST/ASTDiagnostic.cpp
===
--- lib/AST/ASTDiagnostic.cpp
+++ lib/AST/ASTDiagnostic.cpp
@@ -1290,14 +1290,20 @@
   Int = Iter.getDesugar().getAsIntegral();
   return true;
 case TemplateArgument::Expression:
+  // Fail if we can't extend or truncate.
+  if (IntegerType->isDependentType())
+return false;
   ArgExpr = Iter.getDesugar().getAsExpr();
   Int = ArgExpr->EvaluateKnownConstInt(Context);
   Int = Int.extOrTrunc(Context.getTypeSize(IntegerType));
   return true;
 default:
   llvm_unreachable("Unexpected template argument kind");
   }
 } else if (ArgExpr->isEvaluatable(Context)) {
+  // Fail if we can't extend or truncate.
+  if (IntegerType->isDependentType())
+return false;
   Int = ArgExpr->EvaluateKnownConstInt(Context);
   Int = Int.extOrTrunc(Context.getTypeSize(IntegerType));
   return true;


Index: test/Misc/diag-template-diffing.cpp
===
--- test/Misc/diag-template-diffing.cpp
+++ test/Misc/diag-template-diffing.cpp
@@ -1274,6 +1274,16 @@
 // CHECK-ELIDE-NOTREE: candidate function [with T = BoolArgumentBitExtended::BoolT] not viable: no known conversion from 'BoolT<0>' to 'BoolT<1>' for 1st argument
 }
 
+namespace DefaultNonTypeArgWithDependentType {
+// We used to crash diffing integer template arguments when the argument type
+// is dependent and default arguments were used.
+template  struct A {};
+template > R bar();
+A<> () { return bar(); }
+// CHECK-ELIDE-NOTREE: error: non-const lvalue reference to type 'A<[...], (no argument)>' cannot bind to a temporary of type 'A<[...], 0>'
+// CHECK-NOELIDE-NOTREE: error: non-const lvalue reference to type 'A' cannot bind to a temporary of type 'A'
+}
+
 // CHECK-ELIDE-NOTREE: {{[0-9]*}} errors generated.
 // CHECK-NOELIDE-NOTREE: {{[0-9]*}} errors generated.
 // CHECK-ELIDE-TREE: {{[0-9]*}} errors generated.
Index: lib/AST/ASTDiagnostic.cpp
===
--- lib/AST/ASTDiagnostic.cpp
+++ lib/AST/ASTDiagnostic.cpp
@@ -1290,14 +1290,20 @@
   Int = Iter.getDesugar().getAsIntegral();
   return true;
 case TemplateArgument::Expression:
+  // Fail if we can't extend or truncate.
+  if (IntegerType->isDependentType())
+return false;
   ArgExpr = Iter.getDesugar().getAsExpr();
   Int = ArgExpr->EvaluateKnownConstInt(Context);
   Int = Int.extOrTrunc(Context.getTypeSize(IntegerType));
   return true;
 default:
   llvm_unreachable("Unexpected template argument kind");
   }
 } else if (ArgExpr->isEvaluatable(Context)) {
+  // Fail if we can't extend or truncate.
+  if (IntegerType->isDependentType())
+return false;
   Int = ArgExpr->EvaluateKnownConstInt(Context);
   Int = Int.extOrTrunc(Context.getTypeSize(IntegerType));

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

[David Blaikie via cfe-commits]

On Wed, Dec 9, 2015 at 10:40 AM, Robinson, Paul <
paul_robin...@playstation.sony.com> wrote:

> That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be
> surprising if we used the typedef (or otherwise non-canonical) name in the
> class name):
>
>
>
> Finally getting back to this…..  Ha.  We don't unwrap the typedefs ("name
> as it is in the source"), while the upstream compiler does.
>

Yeah, I imagine you'd want to fix that as I expect it would cause you other
problems, no? (or is there some reason you have this change to the
compiler? I imagine it'd be hard to have that divergence by accident?)


> Providing the template-parameter DIEs is still the correct thing to do per
> the DWARF
>
spec.
>

I still don't agree that the DWARF we produce here is incorrect (the DWARF
spec is pretty loose on "correctness" of DWARF). If there's some practical
problem/use case it'd be useful to understand it so we make sure we're
fixing it the right way.

- Dave


> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Friday, November 13, 2015 11:21 AM
> *To:* Marshall, Peter; llvm-dev
> *Cc:* Robinson, Paul
>
> *Subject:* Re: [PATCH] D14358: DWARF's forward decl of a template should
> have template parameters.
>
>
>
>
>
>
>
> On Fri, Nov 13, 2015 at 6:16 AM,  wrote:
>
> Hi Paul,
>
> Sorry for the delay, I've been out of the office.
>
> I think this example shows that name matching does not always work:
>
> template class A {
> public:
> A(T val);
> private:
> T x;
> };
>
> struct B {
> typedef float MONKEY;
>
> A *p;
> };
>
> B b;
>
> struct C {
> typedef int MONKEY;
>
> A *p;
> };
>
> C c;
>
> This gives this DWARF:
>
> +-003f DW_TAG_structure_type "B"
>-DW_AT_name  DW_FORM_strp  "B"
>   +-0047 DW_TAG_member "p"
>  -DW_AT_name  DW_FORM_strp  "p"
> +-DW_AT_type  DW_FORM_ref4  0x0054
>   +-0054 DW_TAG_pointer_type
> +-DW_AT_type  DW_FORM_ref4  0x0059
>   +-0059 DW_TAG_class_type "A"
>  -DW_AT_name  DW_FORM_strp  "A"
>  -DW_AT_declaration  DW_FORM_flag_present
>
> +-0073 DW_TAG_structure_type "C"
>-DW_AT_name  DW_FORM_strp  "C"
>   +-007b DW_TAG_member "p"
>  -DW_AT_name  DW_FORM_strp  "p"
> +-DW_AT_type  DW_FORM_ref4  0x0088
>   +-0088 DW_TAG_pointer_type
> +-DW_AT_type  DW_FORM_ref4  0x008d
>   +-008d DW_TAG_class_type "A"
>  -DW_AT_name  DW_FORM_strp  "A"
>  -DW_AT_declaration  DW_FORM_flag_present
>
>
>
> That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be
> surprising if we used the typedef (or otherwise non-canonical) name in the
> class name):
>
> (I've trimmed a few irrelevant attributes)
>
> 0x001e:   DW_TAG_variable [2]
>
> DW_AT_name [DW_FORM_strp]   ( .debug_str[0x004c] =
> "b")
>
> DW_AT_type [DW_FORM_ref4]   (cu + 0x0033 =>
> {0x0033})
>
>
>
> 0x0033:   DW_TAG_structure_type [3] *
>
> DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0059] =
> "B")
>
>
>
> 0x003b: DW_TAG_member [4]
>
>   DW_AT_name [DW_FORM_strp] ( .debug_str[0x004e] =
> "p")
>
>   DW_AT_type [DW_FORM_ref4] (cu + 0x0048 =>
> {0x0048})
>
>
>
> 0x0047: NULL
>
>
>
> 0x0048:   DW_TAG_pointer_type [5]
>
> DW_AT_type [DW_FORM_ref4]   (cu + 0x004d =>
> {0x004d})
>
>
>
> 0x004d:   DW_TAG_class_type [6]
>
> DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0050] =
> "A")
>
> DW_AT_declaration [DW_FORM_flag_present](true)
>
>
>
> 0x0052:   DW_TAG_variable [2]
>
> DW_AT_name [DW_FORM_strp]   ( .debug_str[0x005b] =
> "c")
>
> DW_AT_type [DW_FORM_ref4]   (cu + 0x0067 =>
> {0x0067})
>
>
>
> 0x0067:   DW_TAG_structure_type [3] *
>
> DW_AT_name [DW_FORM_strp]   ( .debug_str[0x0064] =
> "C")
>
>
>
> 0x006f: DW_TAG_member [4]
>
>   DW_AT_name [DW_FORM_strp] ( .debug_str[0x004e] =
> "p")
>
>   DW_AT_type [DW_FORM_ref4] (cu + 0x007c =>
> {0x007c})
>
>
>
> 0x007b: NULL
>
>
>
> 0x007c:   DW_TAG_pointer_type [5]
>
> DW_AT_type [DW_FORM_ref4]   (cu + 0x0081 =>
> {0x0081})
>
>
>
> 0x0081:   DW_TAG_class_type [6]
>
> DW_AT_name [DW_FORM_strp]   ( .debug_str[0x005d] =
> "A")
>
> DW_AT_declaration [DW_FORM_flag_present](true)
>
>
>
>
>
> As there are no template parameters for the forward declaration of either
> A
> they are indistinguishable.
>
> The reason we currently have no need for the parameters in a template name
> is because we
> reconstruct template names from their parameter tags. This allow the
> pretty printing to match
> the templates from the DWARF 

Re: [PATCH] D14814: [libcxx] Use __make_integer_seq builtin when available

[Eric Fiselier via cfe-commits]

EricWF added a comment.

@majnemer Will the compiler emit diagnostics comparable to the static asserts 
in the other implementation?


http://reviews.llvm.org/D14814



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

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Richard Smith via cfe-commits]

On Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> | And at runtime, on some targets, we use this:
>
> |
>
> |
> https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c
>
> |
>
> | ... which gives a NaN in this case.
>
>
>
> I copied that function into a test program on Ubuntu, built with gcc, and
> it gives me +Infinity (0x7f80) not NaN (0x7fc0).
>

Oh right, sorry, off-by-one error when evaluating that by hand; I got
0x7fff (which is also a NaN, 0x7fc0 is not the only NaN).

So, I think the question is, do we want to update LLVM to define the value
of an out-of-range uitofp (and "fix" any targets that don't give +/- Inf
for these conversions)?
http://llvm.org/docs/LangRef.html#uitofp-to-instruction is clear that you
get an undefined result for overflow currently.

In (AFAICS) all supported targets, for integer types supported by clang,
there are only two ways to hit the overflow case:
 1) uint128 -> float
 2) uint64 or larger -> half

Case (1) goes through uitofp (which explicitly says the result is undefined
at the moment), case (2) goes via @llvm.convert.to.fp16 (which says nothing
about what happens in this case, but presumably it is defined). These are
both phenomenally rare conversions, so adding (potential) extra cost to
them to make them handle the out-of-range case correctly doesn't seem
unreasonable.


> --paulr
>
>
>
> *From:* meta...@gmail.com [mailto:meta...@gmail.com] *On Behalf Of *Richard
> Smith
> *Sent:* Tuesday, December 08, 2015 11:42 AM
> *To:* Robinson, Paul
> *Cc:* Joerg Sonnenberger; cfe-commits (cfe-commits@lists.llvm.org)
>
> *Subject:* Re: r254574 - PR17381: Treat undefined behavior during
> expression evaluation as an unmodeled
>
>
>
> On Tue, Dec 8, 2015 at 11:18 AM, Richard Smith 
> wrote:
>
> On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul <
> paul_robin...@playstation.sony.com> wrote:
>
> Okay, I'll bite:  so what *does* UINT128_MAX actually convert to?
>
>
>
> $ echo 'unsigned __int128 max = -1; float f = max;' |
> ~/clang-8/build/bin/clang -x c++ - -emit-llvm -S -o - -O3 | grep @f
>
> @f = global float undef, align 4
>
>
>
> And at runtime, on some targets, we use this:
>
>
>
>
> https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c
>
>
>
> ... which gives a NaN in this case.
>
>
>
> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On
> Behalf Of *Richard Smith via cfe-commits
> *Sent:* Tuesday, December 08, 2015 10:52 AM
> *To:* Joerg Sonnenberger; cfe-commits
> *Subject:* Re: r254574 - PR17381: Treat undefined behavior during
> expression evaluation as an unmodeled
>
>
>
> On Tue, Dec 8, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits
> wrote:
> > C11 6.3.1.5/1: "If the value being converted is outside the range of
> values
> > that can be represented, the behavior is undefined."
>
> The value of 1e100 can be represented as +inf, even if not precisely.
>
>
>
> Only if +inf is in the range of representable values, which, as already
> noted, is problematic.
>
>
>
> This is a bit different from non-IEEE math like VAX, that doesn't have
> infinities.
>
>
> Joerg
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
>
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14839: [libcxx] LWG2485: get() should be overloaded for const tuple&

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Added initial review comments.

I need to look a little more into how we form the rvalue reference to the 
returned element in the case where the element is an lvalue reference. I think 
it's currently correct but I just want to double check. I think the new 
language is a bit vague when it says `get returns a reference to the element`.



Comment at: 
test/std/containers/sequences/array/array.tuple/get_const_rv.pass.cpp:32
@@ +31,3 @@
+const C c = {std::unique_ptr(new double(3.5))};
+const T&& t = std::get<0>(std::move(c));
+assert(*t == 3.5);

1. Please test the constexprness of this function in C++14 and beyond.
2. Please `static_assert` the return type using `decltype`. The assignment to 
the expected type might hide conversions (though I doubt it in this case).


Comment at: 
test/std/utilities/tuple/tuple.tuple/tuple.elem/get_const_rv.fail.cpp:30
@@ +29,3 @@
+{
+cref(std::get<0>(tup4()));
+}

Add `// expected-error {{call to deleted function 'cref'}}` to the end of this 
line to make the test use clang verify.


Comment at: 
test/std/utilities/tuple/tuple.tuple/tuple.elem/get_const_rv.pass.cpp:26
@@ +25,3 @@
+struct Empty {};
+
+int main()

Same note as on the array test.


Comment at: 
test/std/utilities/utility/pairs/pair.astuple/get_const_rv.pass.cpp:24
@@ +23,3 @@
+{
+#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+{

I prefer  using `// UNSUPPORTED: c++98, c++03` instead of conditional 
compilation. That way LIT can report that the test was not run.


Comment at: 
test/std/utilities/utility/pairs/pair.astuple/get_const_rv.pass.cpp:25
@@ +24,3 @@
+#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+{
+typedef std::pair P;

Same note as the array and tuple tests.


Comment at: 
test/std/utilities/utility/pairs/pair.astuple/pairs.by.type.pass.cpp:43
@@ -42,1 +42,3 @@
 
+{
+typedef std::unique_ptr upint;

This test seems wrong to me. The name of the file suggests we are testing the 
"by-type" overloads but your tests use indexes with `get`. It seems like the 
test above yours does the same thing as well.

Also please add constexpr tests and tests for the second type as well. 


http://reviews.llvm.org/D14839



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

Re: Lit Test C++11 compatibility patch #5

[Richard Smith via cfe-commits]

Essentially LGTM. A few comments below, feel free to commit once you've
addressed them.

On Tue, Nov 24, 2015 at 9:53 AM, Li, Charles <
charles...@playstation.sony.com> wrote:

> Hi Everyone,
>
>
>
>
>
> I am continuing with updating Lit tests to be C++11 compatible.
>
> Here is the fifth patch. This patch contains 20 tests.
>

+#if __cplusplus <= 199711L // C++03 or earlier

I don't think these comments are useful. It's reasonable to expect that
anyone updating Clang's C++ conformance tests knows what __cplusplus means.


> These are mostly diagnostics changes due to new C++11 features and changes
> in the standard.
>
>
>
> Here are the explanations for each test in the order that they appear in
> the patch.
>
>
>
> CXX/class/class.nest/p1.cpp
>
>   Sizeof has been extended to apply to non-static data members without an
> object [n2253].
>
>   Restrict the following to C++98/03.
>
> error: invalid use of non-static data member 'x'
>
>
>
> Parser/cxx-casting.cpp
>
>   Restrict Digraph errors to C++98/03.
>
> C++98 error: found '<::' after a template name which forms the digraph
> '<:' (aka '[') and a ':', did you mean '< ::'?
>
>
>
> Parser/cxx-reference.cpp
>
>   rvalue references is now support
>
>   Restrict the following to C++98/03.
>
> C++98 Warning rvalue references are a C++11 extension
>
>
>
> Parser/cxx-template-argument.cpp
>
>   Consecutive right angle brackets is no longer a syntax error in C++11
>
>   Restrict the following to C++98/03
>
> C++98: error: a space is required between consecutive right angle
> brackets (use '> >')
>
>
>
> Parser/cxx-typeof.cpp
>
>   Using __typeof to derive the type of a non-static data member was an
> Error in C++98/03. It is now accepted in in C++11.
>
>   Note 1: I could not find GCC documentation on this change,
>
>   but given C++11 has decltype now works on non-static data
> members, this appears logical.
>
>   Note 2: This test uses GNU extension "typeof".
>
>   Therefore the Runs line are expanded with -std=gnu++98 and
> "-std=gnu++11"
>
>   instead of the usual "-std=c++98" and "-std=c++11"
>
>
>
> Parser/objc-init.m
>
>   Added C++11 error and note diagnostics on narrowing conversion.
>
>   Error: non-constant-expression cannot be narrowed from type 'unsigned
> int' to 'int' in initializer list
>
>   Note: insert an explicit cast to silence this issue
>
>   *Please Note: Since this is an Objective-C test, the Run line has not
> been changed.
>

You should be able to split the -x objective-c++ RUN: line into two.

Parser/objcxx-lambda-expressions-neg.mm
>
>   []{}; is now an valid Lambda expression.
>
>   Restrict "warning: expected expression" to C++98/03.
>
>
>
> SemaCXX/decl-expr-ambiguity.cpp
>
>   Change in ambiguity diagnostics due to introduction of initializer list.
>
>   C++11 has 1 extra Note following the pre-existing warning
>
> warning: empty parentheses interpreted as a function declaration
> [-Wvexing-parse]
>
> note: replace parentheses with an initializer to declare a variable
>
>
>
>   *Note: The Run lines are left as-is because this test verifies for
> default diagnostic for "typeof"
>
>  Diagnostics will change if I explicitly specify any dialect.
>
>Default (no -std= flag): error: extension used
> [-Werror,-Wlanguage-extension-token]
>
>C++ (-std=c++ flag): error: expected '(' for
> function-style cast or type construction
>
>GNU++ (-std=gnu++ flag): No diagnostic.
>

The default mode is gnu++98; specifying -std=gnu++98 should not cause a
change in behavior. Did you perhaps accidentally remove the
-pedantic-errors flag when you added -std=gnu++98?

SemaCXX/overload-call.cpp
>
>   This change has 3 separate issues. First two are overload resolutions.
> Last one is C++98/03 specific diagnostic.
>
>
>
> 1. When the actual arg is a string literal and 2 candidate functions
> exist. One with formal argument “char *”, the other with “bool”
>
>In C++98/03, Clang picks "char *" and issues a deprecated writable
> wring diagnostics.
>
>In C++11   , Clang uses picks the "bool" candidate and issues a return
> type miss match diagnostics.
>
>   Default converstion from "const char *" to "bool" came from C++11
> standard 4.12\1 [conv.bool]
>
>   Reference:
> http://stackoverflow.com/questions/26413951/overloaded-bool-string-ambiguity
>
>The difference in diagnostics are as follows:
>
>  C++98 (argument type mismatch): conversion from string literal to
> 'char *' is deprecated
>
>  C++11 (return type mismatch):   cannot initialize a variable of type
> 'int *' with an rvalue of type 'double *'
>
>
>
> 2. Similar to point 1. This time the 2 overloaded functions have formal
> args "char *" and "void *".
>
>In this case Clang picks "char *" but issues a slightly different error:
>
>  C++98 warning: conversion from string literal to 'char *' is
> deprecated
>
>  C++11 warning: ISO C++11 does not allow conversion from string

Re: r252960 - [modules] Simplify and generalize the existing rule for finding hidden

[Ben Langmuir via cfe-commits]

> On Dec 9, 2015, at 1:36 PM, Richard Smith  wrote:
> 
> On Wed, Dec 9, 2015 at 11:55 AM, Ben Langmuir via cfe-commits 
> > wrote:
> > On Dec 9, 2015, at 11:07 AM, Ben Langmuir  > > wrote:
> >
> > Hey Richard,
> >
> > This caused a new error for the following code:
> >
> >@import Foo.X; // declaration of ‘struct foo’ from Foo.Y is not visible 
> > yet, but the pcm is loaded.
> >struct foo *bar; // declares ‘struct foo’
> >@import Foo.Y; // also declares ‘struct foo’
> >
> >void useFoo(struct foo *x);  // error: reference to ‘foo’ is ambiguous
> >
> > This seems to be specific to declaring the tag with an elaborated type 
> > specifier that is not just ‘struct foo;’.  Any idea what went wrong?  I’m 
> > trying to track this down and fix it.
> 
> It’s also specific to non-C++ language modes.  In C++ we seem to cheat and 
> make a second lookup that has ForRedeclaration set (SemaDecl.cpp:12122) which 
> then turns this into a use of the hidden declaration rather than creating a 
> new declaration or redeclaration.  I call this “cheating” because the 
> comments imply this second lookup is for diagnostic purposes, but it clearly 
> has a semantic affect in this case.
> 
> Well, this comes back to our handling of C structs and modules being a little 
> incoherent. Suppose Foo.Y defines one 'struct foo', and we define a 
> completely different 'struct foo':
> 
> // Foo.Y
> struct foo { int n; };
> 
> // my.c
> @import Foo.X;
> struct foo *bar;
> struct foo { double d; };
> // Don't import Foo.Y
> 
> If this is not an error, then our declaration of 'struct foo' cannot be the 
> same type as Foo.Y. The usual C rule for structs is that you can have 
> multiple conflicting definitions in different TUs. Such declarations declare 
> different types, but they're compatible types (and thus can be used 
> interchangeably) if they're structurally equivalent.
> 
> I think implementing that rule for C is the right way to go here. Either 
> that, or we extend C++'s ODR semantics to C modules, but given that the C 
> standard gives us a completely reasonable rule here, it seems more 
> appropriate to follow it.

+ Doug

To make sure I understand: if we followed the C rules then in my original 
example we would get a fresh declaration here:
struct foo *x;

and then when we import
@import Foo.Y;

we would try to merge the types, and if we had more than one definition we 
would diagnose if they aren’t structurally equivalent.

Whereas if we used the ODR we could use the hidden declaration directly like we 
do in C++, although perhaps looking it up with a for-redeclaration lookup 
wouldn’t be sufficient if we fixed the linkage of the structs as you mention 
below.

Switching to structural equivalence checking seems like a big change to make 
just to fix this regression.  Even if that’s what we want I’m not sure I could 
sign up for it right now.  Is there a more tactical way we could fix this in 
the interim?

>  
> I guess the reason this started failing after r252960 is because of this 
> change:
> > This also removes the prior special case for tag lookup, which made some 
> > cases
> > of this work, but also led to bizarre, bogus "must use 'struct' to refer to 
> > type
> > 'Foo' in this scope" diagnostics in C++.
> 
> We could do the for-redeclaration lookup outside of C++ too, which will fix 
> this case,
> 
> I don't think so: structs in C don't have linkage, so the for-redeclaration 
> lookup won't find unimported structs (though it's possible that we get the 
> linkage calculation for C structs wrong).

It does find the struct and the hidden decl is considered “externally visible” 
so I guess that’s incorrect then?  Indeed doing this extra lookup does fix my 
test case (and doesn’t break any other regression tests we have).

>  
> but I’m not sure if this is the correct fix.
> 
> Thoughts?
> 
> Ben
> 
> >
> > Ben
> >
> >> On Nov 12, 2015, at 2:19 PM, Richard Smith via cfe-commits 
> >> > wrote:
> >>
> >> Author: rsmith
> >> Date: Thu Nov 12 16:19:45 2015
> >> New Revision: 252960
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=252960=rev 
> >> 
> >> Log:
> >> [modules] Simplify and generalize the existing rule for finding hidden
> >> declarations in redeclaration lookup. A declaration is now visible to
> >> lookup if:
> >>
> >> * It is visible (not in a module, or in an imported module), or
> >> * We're doing redeclaration lookup and it's externally-visible, or
> >> * We're doing typo correction and looking for unimported decls.
> >>
> >> We now support multiple modules having different internal-linkage or 
> >> no-linkage
> >> definitions of the same name for all entities, not just for functions,
> >> variables, and some typedefs. As previously, if 

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

In http://reviews.llvm.org/D14409#306272, @EricWF wrote:

> Does the `inline` keyword have any effect when it's on function definitions 
> that are externally instantiated?


I could not detect any difference in behavior with or without inline keyword.
Remove it?


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

Re: [PATCH] D14814: [libcxx] Use __make_integer_seq builtin when available

[Eric Fiselier via cfe-commits]

EricWF closed this revision.
EricWF added a comment.

Committted in r255162. Thanks.


http://reviews.llvm.org/D14814



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

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Does the `inline` keyword have any effect when it's on function definitions 
that are externally instantiated?


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

Re: [PATCH] D15208: Patch for inline abort code generation

[Dan Austin via cfe-commits]

danielaustin updated this revision to Diff 42328.
danielaustin added a comment.

Patch that removes the debug-mode sanitizer setting and makes the 
-fsanitize-merge-traps/-fno-sanitize-merge-traps flags, with the default 
setting being to merge traps. Flags tested within the Android build system, 
with presence and absence of flags both working as expected.


Repository:
  rL LLVM

http://reviews.llvm.org/D15208

Files:
  include/clang/Basic/LangOptions.h
  include/clang/Driver/Options.td
  lib/CodeGen/CGExpr.cpp
  lib/Frontend/CompilerInvocation.cpp

Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1569,6 +1569,12 @@
   if (Args.hasArg(OPT_fvisibility_inlines_hidden))
 Opts.InlineVisibilityHidden = 1;
 
+  if (Args.hasArg(OPT_fno_sanitize_merge_traps)) {
+Opts.mergeTraps = false;
+  } else {
+Opts.mergeTraps = true;
+  }
+
   if (Args.hasArg(OPT_ftrapv)) {
 Opts.setSignedOverflowBehavior(LangOptions::SOB_Trapping);
 // Set the handler, if one is specified.
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -27,6 +27,7 @@
 #include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/IR/DataLayout.h"
+#include "llvm/IR/InlineAsm.h"
 #include "llvm/IR/Intrinsics.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/MDBuilder.h"
@@ -2535,9 +2536,25 @@
 void CodeGenFunction::EmitTrapCheck(llvm::Value *Checked) {
   llvm::BasicBlock *Cont = createBasicBlock("cont");
 
-  // If we're optimizing, collapse all calls to trap down to just one per
-  // function to save on code size.
-  if (!CGM.getCodeGenOpts().OptimizationLevel || !TrapBB) {
+  // Collapsing all calls to trap down to one per function makes debugging
+  // these issues much more difficult. Eliminating this optimization 
+  // for debugging purposes.
+  // RE: Bug: 25682
+  if(!getLangOpts().mergeTraps) {
+  llvm::InlineAsm *EmptyAsm = 
llvm::InlineAsm::get(llvm::FunctionType::get(CGM.VoidTy, false), 
+  StringRef(""), 
StringRef(""), true);
+  TrapBB = createBasicBlock("trap");
+  Builder.CreateCondBr(Checked, Cont, TrapBB);
+  EmitBlock(TrapBB);
+  llvm::CallInst *TrapCall = EmitTrapCall(llvm::Intrinsic::trap);
+  TrapCall->setDoesNotReturn();
+  TrapCall->setDoesNotThrow();
+  Builder.CreateUnreachable();
+  //this stops the trap calls from being merged at the end of the function
+  Builder.CreateCall(EmptyAsm, {});
+  } else if(!CGM.getCodeGenOpts().OptimizationLevel || !TrapBB) {
+// If we're optimizing, collapse all calls to trap down to just one per
+// function to save on code size.
 TrapBB = createBasicBlock("trap");
 Builder.CreateCondBr(Checked, Cont, TrapBB);
 EmitBlock(TrapBB);
@@ -2548,7 +2565,7 @@
   } else {
 Builder.CreateCondBr(Checked, Cont, TrapBB);
   }
-
+  
   EmitBlock(Cont);
 }
 
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -607,6 +607,12 @@
 : CommaJoined<["-"], "fno-sanitize-recover=">,
   Group, Flags<[CoreOption]>,
   HelpText<"Disable recovery for specified sanitizers">;
+def fsanitize_merge_traps : Flag<["-"], "fsanitize-merge-traps">, 
+Group,
+HelpText<"Merge all traps for sanitizers to one 
per function.">; 
+def fno_sanitize_merge_traps : Flag<["-"], "fno-sanitize-merge-traps">, 
+   Group,
+   HelpText<"Generate traps for sanitizers inline 
to aid in debugging.">; 
 def fsanitize_trap_EQ : CommaJoined<["-"], "fsanitize-trap=">, 
Group,
 Flags<[CC1Option, CoreOption]>,
 HelpText<"Enable trapping for specified sanitizers">;
Index: include/clang/Basic/LangOptions.h
===
--- include/clang/Basic/LangOptions.h
+++ include/clang/Basic/LangOptions.h
@@ -92,6 +92,10 @@
   /// If none is specified, abort (GCC-compatible behaviour).
   std::string OverflowHandler;
 
+  /// \brief Flag controlling whether or not trap calls are merged
+  /// at the end of each function.
+  bool mergeTraps;
+
   /// \brief The name of the current module.
   std::string CurrentModule;
 


Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1569,6 +1569,12 @@
   if (Args.hasArg(OPT_fvisibility_inlines_hidden))
 Opts.InlineVisibilityHidden = 1;
 
+  if (Args.hasArg(OPT_fno_sanitize_merge_traps)) {
+Opts.mergeTraps = false;
+  } else 

[PATCH] D15395: Add 3 more missing inline/visibility attributes

[Evgeniy Stepanov via cfe-commits]

eugenis created this revision.
eugenis added reviewers: EricWF, mclow.lists.
eugenis added a subscriber: cfe-commits.
eugenis set the repository for this revision to rL LLVM.

These are the cases when an out-of-class definition of a method is marked 
_LIBCPP_INLINE_VISIBILITY, but the in-class declaration is not. This will start 
failing when (or if) we switch to __attribute__((internal_linkage)).


Repository:
  rL LLVM

http://reviews.llvm.org/D15395

Files:
  include/bitset
  include/memory

Index: include/memory
===
--- include/memory
+++ include/memory
@@ -3995,6 +3995,7 @@
 is_convertible<_Yp*, element_type*>::value,
 shared_ptr&
 >::type
+_LIBCPP_INLINE_VISIBILITY
 operator=(auto_ptr<_Yp> __r);
 #endif
 template 
@@ -4008,6 +4009,7 @@
 _LIBCPP_INLINE_VISIBILITY
 operator=(unique_ptr<_Yp, _Dp>&& __r);
 #else  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
+_LIBCPP_INLINE_VISIBILITY
 operator=(unique_ptr<_Yp, _Dp> __r);
 #endif
 
Index: include/bitset
===
--- include/bitset
+++ include/bitset
@@ -202,6 +202,7 @@
 private:
 #ifdef _LIBCPP_HAS_NO_CONSTEXPR
 void __init(unsigned long long __v, false_type) _NOEXCEPT;
+_LIBCPP_INLINE_VISIBILITY
 void __init(unsigned long long __v, true_type) _NOEXCEPT;
 #endif  // _LIBCPP_HAS_NO_CONSTEXPR
 unsigned long to_ulong(false_type) const;


Index: include/memory
===
--- include/memory
+++ include/memory
@@ -3995,6 +3995,7 @@
 is_convertible<_Yp*, element_type*>::value,
 shared_ptr&
 >::type
+_LIBCPP_INLINE_VISIBILITY
 operator=(auto_ptr<_Yp> __r);
 #endif
 template 
@@ -4008,6 +4009,7 @@
 _LIBCPP_INLINE_VISIBILITY
 operator=(unique_ptr<_Yp, _Dp>&& __r);
 #else  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
+_LIBCPP_INLINE_VISIBILITY
 operator=(unique_ptr<_Yp, _Dp> __r);
 #endif
 
Index: include/bitset
===
--- include/bitset
+++ include/bitset
@@ -202,6 +202,7 @@
 private:
 #ifdef _LIBCPP_HAS_NO_CONSTEXPR
 void __init(unsigned long long __v, false_type) _NOEXCEPT;
+_LIBCPP_INLINE_VISIBILITY
 void __init(unsigned long long __v, true_type) _NOEXCEPT;
 #endif  // _LIBCPP_HAS_NO_CONSTEXPR
 unsigned long to_ulong(false_type) const;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r255163 - fix typos; NFC

[Sanjay Patel via cfe-commits]

Author: spatel
Date: Wed Dec  9 16:16:07 2015
New Revision: 255163

URL: http://llvm.org/viewvc/llvm-project?rev=255163=rev
Log:
fix typos; NFC

Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h
cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h?rev=255163=255162=255163=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h Wed 
Dec  9 16:16:07 2015
@@ -545,12 +545,11 @@ public:
 //
 // Here R is the return type of the lambda and P1, P2, ... are
 // its parameter types. 'Lambda' is a fake VarDecl captured by the block
-// that is initialized to a copy of the the lambda.
+// that is initialized to a copy of the lambda.
 //
 // Sema leaves the body of a lambda-converted block empty (it is
 // produced by CodeGen), so we can't analyze it directly. Instead, we skip
-// the block body and analyze the operator() method on the the captured
-// lambda.
+// the block body and analyze the operator() method on the captured lambda.
 const VarDecl *LambdaVD = getRegionStoringCapturedLambda()->getDecl();
 const CXXRecordDecl *LambdaDecl = 
LambdaVD->getType()->getAsCXXRecordDecl();
 CXXMethodDecl* LambdaCallOperator = LambdaDecl->getLambdaCallOperator();

Modified: 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h?rev=255163=255162=255163=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h 
Wed Dec  9 16:16:07 2015
@@ -316,7 +316,7 @@ private:
 // The analyzer may stop exploring if it sees a state it has previously
 // visited ("cache out"). The early return here is a defensive check to
 // prevent accidental caching out by checker API clients. Unless there is a
-// tag or the the client checker has requested that the generated node be
+// tag or the client checker has requested that the generated node be
 // marked as a sink, we assume that a client requesting a transition to a
 // state that is the same as the predecessor state has made a mistake. We
 // return the predecessor rather than cache out.

Modified: cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp?rev=255163=255162=255163=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp Wed Dec  9 16:16:07 2015
@@ -605,7 +605,7 @@ void BlockCall::getInitialStackFrameCont
 Params = LambdaOperatorDecl->parameters();
 
 // For blocks converted from a C++ lambda, the callee declaration is the
-// operator() method on the the lambda so we bind "this" to
+// operator() method on the lambda so we bind "this" to
 // the lambda captured by the block.
 const VarRegion *CapturedLambdaRegion = getRegionStoringCapturedLambda();
 SVal ThisVal = loc::MemRegionVal(CapturedLambdaRegion);


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

Re: [PATCH] D15395: Add 3 more missing inline/visibility attributes

[Eric Fiselier via cfe-commits]

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

LGTM. For clang this patch should have no functionality change because clang 
allows attributes to appear only in the declaration.  GCC however was 
previously ignoring the attributes and only now will it mark those functions as 
hidden. I don't think this will be an issue though. Do you agree?


Repository:
  rL LLVM

http://reviews.llvm.org/D15395



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

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Robinson, Paul via cfe-commits]

| Oh right, sorry, off-by-one error when evaluating that by hand; I got 
0x7fff (which is also a NaN, 0x7fc0 is not the only NaN).
No worries.

| http://llvm.org/docs/LangRef.html#uitofp-to-instruction is clear that you get 
an undefined result for overflow currently.
Other parts of the LangRef are comfortable talking about infinities, e.g. 
there's a way to write them as constants, and IEEE float is pervasive in this 
era, so it would seem consistent for uitofp to return +infinity for the 
overflow case.  I'm not the one to propose it, though. ☺
--paulr

From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Wednesday, December 09, 2015 12:43 PM
To: Robinson, Paul
Cc: Joerg Sonnenberger; cfe-commits (cfe-commits@lists.llvm.org)
Subject: Re: r254574 - PR17381: Treat undefined behavior during expression 
evaluation as an unmodeled

On Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits 
> wrote:
| And at runtime, on some targets, we use this:
|
|  
https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c
|
| ... which gives a NaN in this case.

I copied that function into a test program on Ubuntu, built with gcc, and it 
gives me +Infinity (0x7f80) not NaN (0x7fc0).

Oh right, sorry, off-by-one error when evaluating that by hand; I got 
0x7fff (which is also a NaN, 0x7fc0 is not the only NaN).

So, I think the question is, do we want to update LLVM to define the value of 
an out-of-range uitofp (and "fix" any targets that don't give +/- Inf for these 
conversions)? http://llvm.org/docs/LangRef.html#uitofp-to-instruction is clear 
that you get an undefined result for overflow currently.

In (AFAICS) all supported targets, for integer types supported by clang, there 
are only two ways to hit the overflow case:
 1) uint128 -> float
 2) uint64 or larger -> half

Case (1) goes through uitofp (which explicitly says the result is undefined at 
the moment), case (2) goes via @llvm.convert.to.fp16 (which says nothing about 
what happens in this case, but presumably it is defined). These are both 
phenomenally rare conversions, so adding (potential) extra cost to them to make 
them handle the out-of-range case correctly doesn't seem unreasonable.

--paulr

From: meta...@gmail.com 
[mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Tuesday, December 08, 2015 11:42 AM
To: Robinson, Paul
Cc: Joerg Sonnenberger; cfe-commits 
(cfe-commits@lists.llvm.org)

Subject: Re: r254574 - PR17381: Treat undefined behavior during expression 
evaluation as an unmodeled

On Tue, Dec 8, 2015 at 11:18 AM, Richard Smith 
> wrote:
On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul 
> 
wrote:
Okay, I'll bite:  so what *does* UINT128_MAX actually convert to?

$ echo 'unsigned __int128 max = -1; float f = max;' | ~/clang-8/build/bin/clang 
-x c++ - -emit-llvm -S -o - -O3 | grep @f
@f = global float undef, align 4

And at runtime, on some targets, we use this:

  https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c

... which gives a NaN in this case.

From: cfe-commits 
[mailto:cfe-commits-boun...@lists.llvm.org]
 On Behalf Of Richard Smith via cfe-commits
Sent: Tuesday, December 08, 2015 10:52 AM
To: Joerg Sonnenberger; cfe-commits
Subject: Re: r254574 - PR17381: Treat undefined behavior during expression 
evaluation as an unmodeled

On Tue, Dec 8, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-commits 
> wrote:
On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits wrote:
> C11 6.3.1.5/1: "If the value being converted is outside the 
> range of values
> that can be represented, the behavior is undefined."

The value of 1e100 can be represented as +inf, even if not precisely.

Only if +inf is in the range of representable values, which, as already noted, 
is problematic.

This is a bit different from non-IEEE math like VAX, that doesn't have
infinities.

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




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

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

Re: [PATCH] D15208: Patch for inline abort code generation

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: lib/CodeGen/CGExpr.cpp:2543
@@ +2542,3 @@
+  // RE: Bug: 25682
+  if(!getLangOpts().mergeTraps) {
+  llvm::InlineAsm *EmptyAsm = 
llvm::InlineAsm::get(llvm::FunctionType::get(CGM.VoidTy, false), 

danielaustin wrote:
> samsonov wrote:
> > Note that this will also affect `-ftrapv`, which might be unexpected, as we 
> > mention "sanitize" in the flag name.
> Would it be better in your opinion to remove sanitize from the name, or check 
> for the presence of the integer sanitizers here?
Probably former - we already have `-ftrap-function` which changes the behavior 
of both sanitizer-generated and regular traps - this flag is no different.


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

Re: [PATCH] D10834: Added functions to retrieve information about whether a vardecl is local in libclang and its python bindings.

[Argyrios Kyrtzidis via cfe-commits]

akyrtzi added a subscriber: akyrtzi.
akyrtzi added a comment.

The patch does not apply cleanly, could you provide a more up-to-date one ?


http://reviews.llvm.org/D10834



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

Re: [PATCH] D9600: Add scan-build python implementation

[Devin Coughlin via cfe-commits]

dcoughlin added a comment.

In http://reviews.llvm.org/D9600#305980, @rizsotto.mailinglist wrote:

> > Also, what do you think about renaming intercept-build to "log-build" or 
> > some of the other alternatives I proposed above? I think it is important 
> > for the name of the executable to communicate its purpose.
>
>
> ... and to be honest, the executable name scan-build just as bad as 
> intercept-build. :)


There are many things about the original scan-build that are bad. As you have 
seen, the perl-based scan-build is poorly named, poorly factored, 
insufficiently documented and poorly tested. This has made it very difficult to 
fix bugs, support new platforms, and extend scan-build's functionality -- and 
is exactly the reason why we are so excited about a scan-build 
reimplementation. With this reimplementation, we have the opportunity to do so 
much better! If we live up to the high standards in the rest of the clang/llvm 
codebase about naming, factoring, documentation, and testing then the new 
scan-build will be much easier to maintain and can serve as a solid foundation 
to add new features.



Comment at: tools/scan-build-py/README.md:84
@@ +83,3 @@
+The 2. mode is available only on FreeBSD, Linux and OSX. Where library preload
+is available from the dynamic loader. On OSX System Integrity Protection 
security
+feature enabled prevents library preload, so this method will not work in such

With respect to dynamic library-interposition still not working on OS X, the 
System Integrity Protection in OS X 10.11 should not prevent interposition on 
build tools so in theory intercept-build should work. I'll look into it.



Comment at: tools/scan-build-py/libscanbuild/runner.py:23
@@ +22,3 @@
+""" Decorator for checking the required values in state.
+
+It checks the required attributes in the passed state and stop when

Ok. If I create a patch with additional documentation for these fields, would 
you be willing to take a look at it to make sure the comments are correct?


http://reviews.llvm.org/D9600



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

Re: [PATCH] D10834: Added functions to retrieve information about whether a vardecl is local in libclang and its python bindings.

[Argyrios Kyrtzidis via cfe-commits]

The patch does not apply cleanly, could you provide a more up-to-date one ?

> On Dec 6, 2015, at 11:46 PM, guibufolo+l...@gmail.com wrote:
> 
> RedX2501 added a comment.
> 
> Ping
> 
> 
> http://reviews.llvm.org/D10834
> 
> 
> 

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

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

[Robinson, Paul via cfe-commits]

| Types are a bit more vague (as to whether omitting unreferenced types is 
supported by the standard) DWARF 4 just says "Structure, union, and class types 
are represented by debugging information entries ...".

There's some expansion of the "permissive" discussion in the works for DWARF 5. 
 In essence, DWARF doesn't tell you _what_ to describe, but if you describe 
something, you do it _how_ the spec says.  So, omitting unused types and 
function declarations, or lexical blocks with no containing declarations, or 
even things like inlined subroutines, etc. etc. is all kosher, while things 
like the template parameter DIEs and the artificial import of anonymous 
namespaces are actually required.

| Any size numbers for this change?
I got in the neighborhood of 1% (just under, IIRC) of the sum of .debug_* 
sections for a self-build of Clang.

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

Exposing tuning up through Clang is actually very nearly at the top of my list 
now.
--paulr

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

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[Argyrios Kyrtzidis via cfe-commits]

The patch causes tests to fail, please look into it.

> On Dec 8, 2015, at 10:20 PM, guibufolo+l...@gmail.com wrote:
> 
> RedX2501 updated this revision to Diff 42267.
> RedX2501 added a comment.
> 
> Added explicit integer assignment to enum to emphasize api contract behaviour.
> 
> 
> http://reviews.llvm.org/D10833
> 
> Files:
>  bindings/python/clang/cindex.py
>  bindings/python/tests/cindex/test_cursor.py
>  include/clang-c/Index.h
>  include/clang/AST/OperationKinds.h
>  test/Index/binop.cpp
>  tools/c-index-test/c-index-test.c
>  tools/libclang/CIndex.cpp
> 
> 

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

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[Argyrios Kyrtzidis via cfe-commits]

akyrtzi added a comment.

The patch causes tests to fail, please look into it.


http://reviews.llvm.org/D10833



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

Re: [PATCH] D15208: Patch for inline abort code generation

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Please consider adding a test case.



Comment at: include/clang/Basic/LangOptions.h:95
@@ -94,1 +94,3 @@
 
+  /// \brief Flag controlling whether or not trap calls are merged
+  /// at the end of each function.

Why is it a language, not codegen option?


Comment at: include/clang/Basic/LangOptions.h:97
@@ +96,3 @@
+  /// at the end of each function.
+  bool mergeTraps;
+

MergeTraps


Comment at: include/clang/Driver/Options.td:614
@@ +613,3 @@
+def fno_sanitize_merge_traps : Flag<["-"], "fno-sanitize-merge-traps">, 
+   Group,
+   HelpText<"Generate traps for sanitizers inline 
to aid in debugging.">; 

These should probably be CC1Option as well.


Comment at: lib/CodeGen/CGExpr.cpp:2543
@@ +2542,3 @@
+  // RE: Bug: 25682
+  if(!getLangOpts().mergeTraps) {
+  llvm::InlineAsm *EmptyAsm = 
llvm::InlineAsm::get(llvm::FunctionType::get(CGM.VoidTy, false), 

Note that this will also affect `-ftrapv`, which might be unexpected, as we 
mention "sanitize" in the flag name.


Comment at: lib/CodeGen/CGExpr.cpp:2549
@@ +2548,3 @@
+  EmitBlock(TrapBB);
+  llvm::CallInst *TrapCall = EmitTrapCall(llvm::Intrinsic::trap);
+  TrapCall->setDoesNotReturn();

Looks like most of this block (everything except for the empty asm statement) 
is duplicated below.


Comment at: lib/Frontend/CompilerInvocation.cpp:1572
@@ -1571,1 +1571,3 @@
 
+  if (Args.hasArg(OPT_fno_sanitize_merge_traps)) {
+Opts.mergeTraps = false;

  Args.hasFlag(OPT_fsanitize_merge_traps, OPT_fno_sanitize_merge_traps, true);


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

Re: [PATCH] D15373: Fix for bug 25786 - Assertion "Chunk.Kind == DeclaratorChunk::Function" failed with regparm attribute.

[Reid Kleckner via cfe-commits]

rnk added a subscriber: rnk.


Comment at: include/clang/Sema/Sema.h:2938
@@ -2937,2 +2937,3 @@
   bool CheckRegparmAttr(const AttributeList , unsigned );
+  bool getCCFromAttr(const AttributeList , CallingConv );
   bool CheckCallingConvAttr(const AttributeList , CallingConv , 

Rather than adding this extra entry point, I think it would be simpler to 
extend CheckCallingConvAttr to return whatever extra info we need.

Besides, this new entry point also emits diagnostics, and it has a name that 
suggests it will not emit diagnostics.


Comment at: lib/Sema/SemaType.cpp:5866
@@ -5865,3 +5865,3 @@
   CallingConv CC;
   if (S.CheckCallingConvAttr(attr, CC))
 return true;

Right, we've already done the work that you are doing down below. We should 
just get what we needed to know out of here and pass it on.


Comment at: lib/Sema/SemaType.cpp:5925-5926
@@ +5924,4 @@
+  S.Context.getTargetInfo().checkCallingConvention(RawCC);
+  // If calling convention is available (CCCR_OK) or default (CCCR_Ignored), 
add
+  // it to type.
+  if (CCResult != TargetInfo::CCCR_Warning)

At a high level, why would you want to not create an AttributedType here? That 
seems desirable, the user wrote the type attribute in the source, and that 
should be reflected in the AST sugar.

If adding this sugar causes assertions later, then the bug must be somewhere 
else.


Comment at: test/CodeGen/adding_defaulted_attr_to_type.c:5
@@ +4,2 @@
+
+// CHECK: @f = common global void (i32)*

You can add more tests. I noticed this crashes for me:
  void (__attribute__((regparm(2), stdcall)) foo)(int);
That seems like a good one to add.

You can also rerun the test with i686-unknown-linux-gnu and #ifdefs to see that 
we accept the convention as desired on 32-bit.




http://reviews.llvm.org/D15373



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

[libcxx] r255162 - Use __make_integer_seq builtin for std::make_integer_sequence. Patch by K-ballo.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Dec  9 16:03:06 2015
New Revision: 255162

URL: http://llvm.org/viewvc/llvm-project?rev=255162=rev
Log:
Use __make_integer_seq builtin for std::make_integer_sequence. Patch by K-ballo.

Added:

libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq_fallback.fail.cpp

libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq_fallback.pass.cpp
Modified:
libcxx/trunk/include/utility
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.fail.cpp
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.pass.cpp
libcxx/trunk/test/support/test_macros.h

Modified: libcxx/trunk/include/utility
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/utility?rev=255162=255161=255162=diff
==
--- libcxx/trunk/include/utility (original)
+++ libcxx/trunk/include/utility Wed Dec  9 16:03:06 2015
@@ -680,6 +680,16 @@ struct _LIBCPP_TYPE_VIS_ONLY integer_seq
 template
 using index_sequence = integer_sequence;
 
+#if __has_builtin(__make_integer_seq) && 
!defined(_LIBCPP_TESTING_FALLBACK_MAKE_INTEGER_SEQUENCE)
+
+template 
+struct __make_integer_sequence
+{
+typedef __make_integer_seq type;
+};
+
+#else
+
 namespace __detail {
 
 template struct __repeat;
@@ -733,10 +743,12 @@ struct __make_integer_sequence
 {
 static_assert(is_integral<_Tp>::value,
   "std::make_integer_sequence can only be instantiated with an 
integral type" );
-static_assert(0 <= _Ep, "std::make_integer_sequence input shall not be 
negative");
+static_assert(0 <= _Ep, "std::make_integer_sequence must have a 
non-negative sequence length");
 typedef __make_integer_sequence_unchecked<_Tp, _Ep> type;
 };
 
+#endif
+
 template
 using make_integer_sequence = typename __make_integer_sequence<_Tp, 
_Np>::type;
 

Modified: 
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.fail.cpp?rev=255162=255161=255162=diff
==
--- 
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.fail.cpp 
(original)
+++ 
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.fail.cpp 
Wed Dec  9 16:03:06 2015
@@ -12,19 +12,23 @@
 // template
 //   using make_integer_sequence = integer_sequence;
 
+// UNSUPPORTED: c++98, c++03, c++11
+
 #include 
 #include 
 #include 
 
+#include "test_macros.h"
+
 int main()
 {
-#if _LIBCPP_STD_VER > 11
-
-std::make_integer_sequence::value_type i;
+  typedef std::make_integer_sequence MakeSeqT;
 
+  // std::make_integer_sequence is implemented using a compiler builtin if 
available.
+  // this builtin has different diagnostic messages than the fallback 
implementation.
+#if TEST_HAS_BUILTIN(__make_integer_seq) && 
!defined(_LIBCPP_TESTING_FALLBACK_MAKE_INTEGER_SEQUENCE)
+MakeSeqT i; // expected-error@utility:* {{integer sequences must have 
non-negative sequence length}}
 #else
-
-X
-
-#endif  // _LIBCPP_STD_VER > 11
+MakeSeqT i; // expected-error@utility:* {{static_assert failed 
"std::make_integer_sequence must have a non-negative sequence length"}}
+#endif
 }

Modified: 
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.pass.cpp?rev=255162=255161=255162=diff
==
--- 
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq.pass.cpp 
Wed Dec  9 16:03:06 2015
@@ -12,14 +12,14 @@
 // template
 //   using make_integer_sequence = integer_sequence;
 
+// UNSUPPORTED: c++98, c++03, c++11
+
 #include 
 #include 
 #include 
 
 int main()
 {
-#if _LIBCPP_STD_VER > 11
-
 static_assert(std::is_same, 
std::integer_sequence>::value, "");
 static_assert(std::is_same, 
std::integer_sequence>::value, "");
 static_assert(std::is_same, 
std::integer_sequence>::value, "");
@@ -29,6 +29,4 @@ int main()
 static_assert(std::is_same::value, "");
 static_assert(std::is_same::value, "");
 static_assert(std::is_same::value, "");
-
-#endif  // _LIBCPP_STD_VER > 11
 }

Added: 
libcxx/trunk/test/std/utilities/intseq/intseq.make/make_integer_seq_fallback.fail.cpp
URL: 

Re: [PATCH] D15208: Patch for inline abort code generation

[Dan Austin via cfe-commits]

danielaustin added a comment.

Test makes sense, will add it with the revisions.



Comment at: include/clang/Basic/LangOptions.h:95
@@ -94,1 +94,3 @@
 
+  /// \brief Flag controlling whether or not trap calls are merged
+  /// at the end of each function.

samsonov wrote:
> Why is it a language, not codegen option?
Wasn't aware, will relocate it there, as it makes more sense


Comment at: include/clang/Driver/Options.td:614
@@ +613,3 @@
+def fno_sanitize_merge_traps : Flag<["-"], "fno-sanitize-merge-traps">, 
+   Group,
+   HelpText<"Generate traps for sanitizers inline 
to aid in debugging.">; 

samsonov wrote:
> These should probably be CC1Option as well.
Agree


Comment at: lib/CodeGen/CGExpr.cpp:2543
@@ +2542,3 @@
+  // RE: Bug: 25682
+  if(!getLangOpts().mergeTraps) {
+  llvm::InlineAsm *EmptyAsm = 
llvm::InlineAsm::get(llvm::FunctionType::get(CGM.VoidTy, false), 

samsonov wrote:
> Note that this will also affect `-ftrapv`, which might be unexpected, as we 
> mention "sanitize" in the flag name.
Would it be better in your opinion to remove sanitize from the name, or check 
for the presence of the integer sanitizers here?


Comment at: lib/CodeGen/CGExpr.cpp:2549
@@ +2548,3 @@
+  EmitBlock(TrapBB);
+  llvm::CallInst *TrapCall = EmitTrapCall(llvm::Intrinsic::trap);
+  TrapCall->setDoesNotReturn();

samsonov wrote:
> Looks like most of this block (everything except for the empty asm statement) 
> is duplicated below.
Yea, I can simplify that.


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

Re: [PATCH] D15309: [CUDA] emit vtables only for classes with methods usable on this side of compilation.

[Artem Belevich via cfe-commits]

tra updated the summary for this revision.
tra updated this revision to Diff 42341.
tra added a comment.

Changed key method algorithm to ignore methods that we will not emit during 
this compilation (previous version didn't allow mixed host/device virtual 
methods).

For vtables with mixed host/device virtual methods, use NULL for methods we're 
not going to codegen.


http://reviews.llvm.org/D15309

Files:
  lib/AST/RecordLayoutBuilder.cpp
  lib/CodeGen/CGVTables.cpp
  test/CodeGenCUDA/device-vtable.cu

Index: test/CodeGenCUDA/device-vtable.cu
===
--- /dev/null
+++ test/CodeGenCUDA/device-vtable.cu
@@ -0,0 +1,60 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Make sure we don't emit vtables for classes with methods that have
+// inappropriate target attributes. Currently it's mostly needed in
+// order to avoid emitting vtables for host-only classes on device
+// side where we can't codegen them.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-HOST -check-prefix=CHECK-BOTH
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-DEVICE -check-prefix=CHECK-BOTH
+
+#include "Inputs/cuda.h"
+
+struct H  {
+  virtual void method();
+};
+//CHECK-HOST: @_ZTV1H =
+//CHECK-HOST-SAME: @_ZN1H6methodEv
+//CHECK-DEVICE-NOT: @_ZTV1H =
+
+struct D  {
+   __device__ virtual void method();
+};
+
+//CHECK-DEVICE: @_ZTV1D
+//CHECK-DEVICE-SAME: @_ZN1D6methodEv
+//CHECK-HOST-NOT: @_ZTV1D
+
+// This is the case with mixed host and device virtual methods.  It's
+// impossible to emit a valid vtable in that case because only host or
+// only device methods would be available during host or device
+// compilation. For now we'll not emit such vtable at all.
+struct HD  {
+  virtual void h_method();
+  __device__ virtual void d_method();
+};
+// CHECK-BOTH: @_ZTV2HD
+// CHECK-DEVICE-NOT: @_ZN2HD8h_methodEv
+// CHECK-DEVICE-SAME: null
+// CHECK-DEVICE-SAME: @_ZN2HD8d_methodEv
+// CHECK-HOST-SAME: @_ZN2HD8h_methodEv
+// CHECK-HOST-NOT: @_ZN2HD8d_methodEv
+// CHECK-HOST-SAME: null
+// CHECK-BOTH-SAME: ]
+
+void H::method() {}
+//CHECK-HOST: define void @_ZN1H6methodEv
+
+void __device__ D::method() {}
+//CHECK-DEVICE: define void @_ZN1D6methodEv
+
+void __device__ HD::d_method() {}
+// CHECK-DEVICE: define void @_ZN2HD8d_methodEv
+// CHECK-HOST-NOT: define void @_ZN2HD8d_methodEv
+void HD::h_method() {}
+// CHECK-HOST: define void @_ZN2HD8h_methodEv
+// CHECK-DEVICE-NOT: define void @_ZN2HD8h_methodEv
+
Index: lib/CodeGen/CGVTables.cpp
===
--- lib/CodeGen/CGVTables.cpp
+++ lib/CodeGen/CGVTables.cpp
@@ -582,6 +582,24 @@
 break;
   }
 
+  if (CGM.getLangOpts().CUDA) {
+// Emit NULL for methods we can't codegen on this
+// side. Otherwise we'd end up with vtable with unresolved
+// references.
+const CXXMethodDecl *MD = cast(GD.getDecl());
+// OK on device side: functions w/ __device__ attribute
+// OK on host side: anything except __device__-only functions.
+bool CanEmitMethod = CGM.getLangOpts().CUDAIsDevice
+ ? MD->hasAttr()
+ : (MD->hasAttr() ||
+!MD->hasAttr());
+if (!CanEmitMethod) {
+  Init = llvm::ConstantExpr::getNullValue(Int8PtrTy);
+  break;
+}
+// Method is acceptable, continue processing as usual.
+  }
+
   if (cast(GD.getDecl())->isPure()) {
 // We have a pure virtual member function.
 if (!PureVirtualFn) {
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -2025,6 +2025,21 @@
 continue;
 }
 
+if (Context.getLangOpts().CUDA) {
+  // While compiler may see key method in this TU, during CUDA
+  // compilation we should ignore methods that are not accessible
+  // on this side of compilation.
+  if (Context.getLangOpts().CUDAIsDevice) {
+// In device mode ignore methods without __device__ attribute.
+if (!MD->hasAttr())
+  continue;
+  } else {
+// In host mode ignore __device__-only methods.
+if (!MD->hasAttr() && MD->hasAttr())
+  continue;
+  }
+}
+
 // If the key function is dllimport but the class isn't, then the class has
 // no key function. The DLL that exports the key function won't export the
 // vtable in this case.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14814: [libcxx] Use __make_integer_seq builtin when available

[Agustín Bergé via cfe-commits]

K-ballo added a comment.

> After that these changes LGTM. @K-ballo I'm happy to make the changes as I 
> commit this if your OK with that?


@EricWF Go ahead, thank you!


http://reviews.llvm.org/D14814



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

Re: [PATCH] D14839: [libcxx] LWG2485: get() should be overloaded for const tuple&

[Eric Fiselier via cfe-commits]

EricWF added a comment.

To expand on my concerns about lvalue elements, I would like to see tests 
something like this:

  int x = 42;
  int const y = 43;
  std::pair const p(x, y);
  static_assert(std::is_same(std::move(p)))>::value, "");
  static_assert(std::is_same(std::move(p)))>::value, "");

I assume you agree that this test has the correct behavior?


http://reviews.llvm.org/D14839



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

Re: [PATCH] D15395: Add 3 more missing inline/visibility attributes

[Evgeniy Stepanov via cfe-commits]

eugenis closed this revision.
eugenis added a comment.

r255166


Repository:
  rL LLVM

http://reviews.llvm.org/D15395



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

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

[David Blaikie via cfe-commits]

On Wed, Dec 9, 2015 at 11:59 AM, Robinson, Paul <
paul_robin...@playstation.sony.com> wrote:

> Maybe we are being too pedantic about the names.  I'll have to go back and
> look in detail at why we decided to do that.
>
>
>
> In any case, arguably 5.5.8 (Class Template Instantiations) 1 only applies
> to definitions of a type, not declarations. ("Each formal parameterized
> type declaration appearing in the template definition is represented by a
> debugging information entry with the tag DW_TAG_template_type_parameter")
>
> Not so fast… It's a template definition of a type declaration.  DWARF 5 is
> less ambiguous about this IMO, although you are actually very good at
> finding the ambiguities!  The relevant text in DWARF 5 current draft is: "A
> debugging information entry that represents a template instantiation will
> contain child entries describing the actual template parameters."  Are you
> willing to argue that this type declaration is not an instantiation?  (If
> not, what is it?)
>

Nope, it is an instantiation, for sure.

Beyond that, I'd still argue that existing implementation experience points
to this being pretty reasonable - and without the motivating use case
(which only exists in your fork) it seems hard to justify adding the extra
data.


>  Why would that clause apply to attributes any less than it applies to
> DIEs?
>
> It does apply equally.  However, nearly all attribute descriptions are
> specified as "may have" and therefore can be omitted freely without being
> non-conforming.
>

Fair point (& the same goes for the example I was going to give of omitting
DW_TAG_friends - they're "may" too)

Types are a bit more vague (as to whether omitting unreferenced types is
supported by the standard) DWARF 4 just says "Structure, union, and class
types are represented by debugging information entries ...".

Any size numbers for this change?

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

- David


> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Wednesday, December 09, 2015 11:28 AM
>
> *To:* Robinson, Paul
> *Cc:* Marshall, Peter; llvm-dev; cfe-commits (cfe-commits@lists.llvm.org)
> *Subject:* Re: [PATCH] D14358: DWARF's forward decl of a template should
> have template parameters.
>
>
>
>
>
>
>
> On Wed, Dec 9, 2015 at 11:11 AM, Robinson, Paul <
> paul_robin...@playstation.sony.com> wrote:
>
> Actually no, we prefer to have the original typedef names in the
> instantiation name, for source fidelity.
>
>
>
> Then perhaps you should keep this change in your tree too - since that's
> where the need is?
>
>
>
>   "Name as it is in the source" or something reasonably close.  Unwrapping
> typedefs is going too far.
>
>
>
> Yet this isn't the choice upstream in Clang or GCC. I don't know about
> other DWARF generators, but it seems your interpretation isn't the way some
> other people/implementers are reading the DWARF spec.
>
> [This seems like it would present a multitude of challenges to any DWARF
> debugger dealing with this kind of debug info - it'd have to know far more
> about the rules of the C++ language (which you've previously argued in
> favor of avoiding) to perform a variety of operations if the types don't
> match up fairly trivially.]
>
> In any case, arguably 5.5.8 (Class Template Instantiations) 1 only applies
> to definitions of a type, not declarations. ("Each formal parameterized
> type declaration appearing in the template definition is represented by a
> debugging information entry with the tag DW_TAG_template_type_parameter")
> which, I agree, seems like a bug in the spec to not /allow/ them on
> declarations, but I'd equally argue requiring them would seem too narrow to
> me.
>
>
>
> Re. "looseness" of the DWARF spec, it is not so loose as you like to
> think.  Attributes tend to be fairly optional or can be used "in novel
> ways" but the DIEs and their relationships are not like that.  "Where this
> specification provides a means for describing the source language,
> implementors are expected to adhere to that specification."
>
>
>
> Why would that clause apply to attributes any less than it applies to
> DIEs? It seems like a fairly broad statement.
>
> I forget whether we already discussed it - but do you have any size data
> (preferably/possibly from a fission build or otherwise measurement of "just
> the debug info" not the whole binary) on, for example, a clang selfhost?
>
> - Dave
>
>
>
> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Wednesday, December 09, 2015 10:49 AM
> *To:* Robinson, Paul
> *Cc:* Marshall, Peter; llvm-dev; cfe-commits (cfe-commits@lists.llvm.org)
>
>
> *Subject:* Re: [PATCH] D14358: DWARF's forward decl of a template should
> have 

Re: [PATCH] D14814: [libcxx] Use __make_integer_seq builtin when available

[Eric Fiselier via cfe-commits]

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

The only issue I have with this is that we should still test both code patchs 
with clang so we can ensure the fallback implementation remains correct. I 
would change

  #if __has_builtin(__make_integer_seq) && 
!defined(_LIBCPP_TESTING_FALLBACK_MAKE_INTEGER_SEQUENCE)

Then add a test called 
`test/std/utilities/intseq/intseq.make/make_integer_seq_fallback.pass.cpp` that 
contains:

  #define _LIBCPP_TESTING_FALLBACK_MAKE_INTEGER_SEQUENCE
  #include "make_integer_seq.pass.cpp"

After that these changes LGTM. @K-ballo I'm happy to make the changes as I 
commit this if your OK with that?


http://reviews.llvm.org/D14814



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

Re: r252960 - [modules] Simplify and generalize the existing rule for finding hidden

[Richard Smith via cfe-commits]

On Wed, Dec 9, 2015 at 11:55 AM, Ben Langmuir via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> > On Dec 9, 2015, at 11:07 AM, Ben Langmuir  wrote:
> >
> > Hey Richard,
> >
> > This caused a new error for the following code:
> >
> >@import Foo.X; // declaration of ‘struct foo’ from Foo.Y is not
> visible yet, but the pcm is loaded.
> >struct foo *bar; // declares ‘struct foo’
> >@import Foo.Y; // also declares ‘struct foo’
> >
> >void useFoo(struct foo *x);  // error: reference to ‘foo’ is ambiguous
> >
> > This seems to be specific to declaring the tag with an elaborated type
> specifier that is not just ‘struct foo;’.  Any idea what went wrong?  I’m
> trying to track this down and fix it.
>
> It’s also specific to non-C++ language modes.  In C++ we seem to cheat and
> make a second lookup that has ForRedeclaration set (SemaDecl.cpp:12122)
> which then turns this into a use of the hidden declaration rather than
> creating a new declaration or redeclaration.  I call this “cheating”
> because the comments imply this second lookup is for diagnostic purposes,
> but it clearly has a semantic affect in this case.
>

Well, this comes back to our handling of C structs and modules being a
little incoherent. Suppose Foo.Y defines one 'struct foo', and we define a
completely different 'struct foo':

// Foo.Y
struct foo { int n; };

// my.c
@import Foo.X;
struct foo *bar;
struct foo { double d; };
// Don't import Foo.Y

If this is not an error, then our declaration of 'struct foo' cannot be the
same type as Foo.Y. The usual C rule for structs is that you can have
multiple conflicting definitions in different TUs. Such declarations
declare different types, but they're compatible types (and thus can be used
interchangeably) if they're structurally equivalent.

I think implementing that rule for C is the right way to go here. Either
that, or we extend C++'s ODR semantics to C modules, but given that the C
standard gives us a completely reasonable rule here, it seems more
appropriate to follow it.


> I guess the reason this started failing after r252960 is because of this
> change:
> > This also removes the prior special case for tag lookup, which made some
> cases
> > of this work, but also led to bizarre, bogus "must use 'struct' to refer
> to type
> > 'Foo' in this scope" diagnostics in C++.
>
> We could do the for-redeclaration lookup outside of C++ too, which will
> fix this case,


I don't think so: structs in C don't have linkage, so the for-redeclaration
lookup won't find unimported structs (though it's possible that we get the
linkage calculation for C structs wrong).


> but I’m not sure if this is the correct fix.
>
> Thoughts?
>
> Ben
>
> >
> > Ben
> >
> >> On Nov 12, 2015, at 2:19 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >>
> >> Author: rsmith
> >> Date: Thu Nov 12 16:19:45 2015
> >> New Revision: 252960
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=252960=rev
> >> Log:
> >> [modules] Simplify and generalize the existing rule for finding hidden
> >> declarations in redeclaration lookup. A declaration is now visible to
> >> lookup if:
> >>
> >> * It is visible (not in a module, or in an imported module), or
> >> * We're doing redeclaration lookup and it's externally-visible, or
> >> * We're doing typo correction and looking for unimported decls.
> >>
> >> We now support multiple modules having different internal-linkage or
> no-linkage
> >> definitions of the same name for all entities, not just for functions,
> >> variables, and some typedefs. As previously, if multiple such entities
> are
> >> visible, any attempt to use them will result in an ambiguity error.
> >>
> >> This patch fixes the linkage calculation for a number of entities where
> we
> >> previously didn't need to get it right (using-declarations, namespace
> aliases,
> >> and so on).  It also classifies enumerators as always having no
> linkage, which
> >> is a slight deviation from the C++ standard's definition, but not an
> observable
> >> change outside modules (this change is being discussed on the -core
> reflector
> >> currently).
> >>
> >> This also removes the prior special case for tag lookup, which made
> some cases
> >> of this work, but also led to bizarre, bogus "must use 'struct' to
> refer to type
> >> 'Foo' in this scope" diagnostics in C++.
> >>
> >> Added:
> >>   cfe/trunk/test/Modules/Inputs/no-linkage/
> >>   cfe/trunk/test/Modules/Inputs/no-linkage/decls.h
> >>   cfe/trunk/test/Modules/Inputs/no-linkage/empty.h
> >>   cfe/trunk/test/Modules/Inputs/no-linkage/module.modulemap
> >>   cfe/trunk/test/Modules/no-linkage.cpp
> >> Modified:
> >>   cfe/trunk/include/clang/Sema/Lookup.h
> >>   cfe/trunk/lib/AST/Decl.cpp
> >>   cfe/trunk/lib/Sema/SemaDecl.cpp
> >>   cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> >>   cfe/trunk/test/Index/linkage.c
> >>   cfe/trunk/test/Index/usrs.m
> >>   cfe/trunk/test/Modules/decldef.m
> >>   

Re: [PATCH] D9600: Add scan-build python implementation

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

Hi Laszlo,

Here are some comments from me.

Should we be worried about the name conflicts (between old scan-build and this 
tool) during rollout? I think it would be beneficial to rename the tools, but 
let's discuss the names later. (If we integrate Codecheck, that will affect 
naming too.)

The libear library should be built as part of clang cmake build; looks like 
@jroelofs offered to do this.
We should also integrate your tests into lit, which is the way we test all of 
the other tools in clang.



Comment at: tools/scan-build-py/README.md:1
@@ +1,2 @@
+[![Build 
Status](https://travis-ci.org/rizsotto/scan-build.svg?branch=master)](https://travis-ci.org/rizsotto/scan-build)
+

What's this? Please, remove.


Comment at: tools/scan-build-py/README.md:6
@@ +5,3 @@
+
+It's a static analyzer wrapper for [Clang][1]. The original `scan-build`
+is written in Perl. This package contains reimplementation of that scripts

I do not think you need to mention the old scan-build. I'd just describe the 
tool. Here is a slightly modified copy and paste from scan-build:

"A package designed to wrap a build so that all calls to gcc/clang are 
intercepted and logged into a compilation database [2] and/or piped to the 
clang static analyzer. Includes intercept-build tool, which logs the build, as 
well as scan-build tool, which logs the build and runs the clang static 
analyzer on it."

I have a bunch of comments about other parts of the documentation. However, I 
can rewrite parts of it as a separate commit. (It will be more efficient than 
going back and forth.)



Comment at: tools/scan-build-py/README.md:59
@@ +58,3 @@
+
+1.  Use compiler wrappers to make actions.
+The compiler wrappers does run the real compiler and the analyzer.

This is a good place to point out how each mode can be activated. (Which 
parameters should be used.)


Comment at: tools/scan-build-py/README.md:85
@@ +84,3 @@
+is available from the dynamic loader. On OSX System Integrity Protection 
security
+feature enabled prevents library preload, so this method will not work in such
+environment.

Would be good to find out which specific binaries used by the build we are not 
allowed to interpose on. It would be very unfortunate if this does not work 
with the System Integrity Protection feature, which is turned on by default.


Comment at: tools/scan-build-py/README.md:114
@@ +113,3 @@
+
+The project is licensed under University of Illinois/NCSA Open Source License.
+

Please, refer to the LICENSE.TXT file like you do in the other files.


Comment at: tools/scan-build-py/bin/analyze-c++:1
@@ +1,2 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-

What calls this script?


Comment at: tools/scan-build-py/bin/analyze-cc:14
@@ +13,2 @@
+from libscanbuild.analyze import wrapper
+sys.exit(wrapper(False))

It is hard to figure out/search which functions actually get called from the 
top level tools. Could you rename all of the public functions so that they have 
unique names? For example, "wrapper" -> "scan_build_wrapper". This would 
greatly improve searchability!


Comment at: tools/scan-build-py/libear/ear.c:406
@@ +405,3 @@
+if (0 == fd) {
+perror("bear: fopen");
+exit(EXIT_FAILURE);

It will be hard for the users to interpret these error messages; especially if 
the tool is widely distributed. (Can be addressed after the initial commit.)


Comment at: tools/scan-build-py/libscanbuild/__init__.py:11
@@ +10,3 @@
+This work is derived from the original 'scan-build' Perl implementation and
+from an independent project 'bear'. """
+

Not sure if this comment helps to understand the functionality, please, remove.


Comment at: tools/scan-build-py/libscanbuild/analyze.py:55
@@ +54,3 @@
+exit_code = capture(args, bin_dir)
+# next step to run the analyzer against the captured commands
+if need_analyzer(args.build):

http://llvm.org/docs/CodingStandards.html#commenting


Comment at: tools/scan-build-py/libscanbuild/intercept.py:71
@@ +70,3 @@
+
+def post_processing(commands):
+# run post processing only if that was requested

What does post_processing do? Looks like it allows to append to the compilation 
database and more.. Could you add a comment or rename the function?


Comment at: tools/scan-build-py/libscanbuild/intercept.py:287
@@ +286,3 @@
+action='store_true',
+help="""Disable filter, unformated output.""")
+

Do you explain what the "filter" means somewhere visible to the user? When is 
filter useful and when it is not?


Comment 

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

[David Blaikie via cfe-commits]

On Wed, Dec 9, 2015 at 12:46 PM, Robinson, Paul <
paul_robin...@playstation.sony.com> wrote:

> | Types are a bit more vague (as to whether omitting unreferenced types is
> supported by the standard) DWARF 4 just says "Structure, union, and class
> types are represented by debugging information entries ...".
>
> There's some expansion of the "permissive" discussion in the works for
> DWARF 5.  In essence, DWARF doesn't tell you _what_ to describe, but if you
> describe something, you do it _how_ the spec says.  So, omitting unused
> types and function declarations, or lexical blocks with no containing
> declarations, or even things like inlined subroutines, etc. etc. is all
> kosher, while things like the template parameter DIEs and the artificial
> import of anonymous namespaces are actually required.
>

Honestly I'm more with you on the template parameter DIEs than I am on the
anonymous namespace... especially from a source fidelity perspective.


>
>
> | Any size numbers for this change?
>
> I got in the neighborhood of 1% (just under, IIRC) of the sum of .debug_*
> sections for a self-build of Clang.
>

Ah, cool - good to know. Thanks!


>
>
> | In any case, it seems like it might make sense for you to upstream your
> template naming change and put it under the PS4 debugger tuning option, and
> put this change there too, once the motivation for it is in-tree. At that
> point, while I'd be curious about the size tradeoff, it'd be essentially
> academic
>
>
>
> Exposing tuning up through Clang is actually very nearly at the top of my
> list now.
>

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

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[Argyrios Kyrtzidis via cfe-commits]

akyrtzi added a comment.

Also you need to add the functions in libclang.exports.


http://reviews.llvm.org/D10833



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

Re: [PATCH] D15030: [clang-tidy] add check cppcoreguidelines-pro-bounds-constant-array-index

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 42338.
mgehre added a comment.

Thanks for the comments!


http://reviews.llvm.org/D15030

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
  clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.rst
  docs/clang-tidy/checks/list.rst
  
test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index-gslheader.cpp
  test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
@@ -0,0 +1,76 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-bounds-constant-array-index %t
+
+typedef unsigned int size_t;
+
+namespace std {
+  template
+  struct array {
+T& operator[](size_t n);
+T& at(size_t n);
+  };
+}
+
+
+namespace gsl {
+  template
+  T& at( T()[N], size_t index );
+
+  template
+  T& at( std::array , size_t index );
+}
+
+constexpr int const_index(int base) {
+  return base + 3;
+}
+
+void f(std::array a, int pos) {
+  a [ pos / 2 /*comment*/] = 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead [cppcoreguidelines-pro-bounds-constant-array-index]
+  int j = a[pos - 1];
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead
+
+  a.at(pos-1) = 2; // OK, at() instead of []
+  gsl::at(a, pos-1) = 2; // OK, gsl::at() instead of []
+
+  a[-1] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: std::array<> index -1 is negative [cppcoreguidelines-pro-bounds-constant-array-index]
+  a[10] = 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: std::array<> index 10 is past the end of the array (which contains 10 elements) [cppcoreguidelines-pro-bounds-constant-array-index]
+
+  a[const_index(7)] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: std::array<> index 10 is past the end of the array (which contains 10 elements)
+
+  a[0] = 3; // OK, constant index and inside bounds
+  a[1] = 3; // OK, constant index and inside bounds
+  a[9] = 3; // OK, constant index and inside bounds
+  a[const_index(6)] = 3; // OK, constant index and inside bounds
+}
+
+void g() {
+  int a[10];
+  for (int i = 0; i < 10; ++i) {
+a[i] = i;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead
+// CHECK-FIXES: gsl::at(a, i) = i;
+gsl::at(a, i) = i; // OK, gsl::at() instead of []
+  }
+
+  a[-1] = 3; // flagged by clang-diagnostic-array-bounds
+  a[10] = 4; // flagged by clang-diagnostic-array-bounds
+  a[const_index(7)] = 3; // flagged by clang-diagnostic-array-bounds
+
+  a[0] = 3; // OK, constant index and inside bounds
+  a[1] = 3; // OK, constant index and inside bounds
+  a[9] = 3; // OK, constant index and inside bounds
+  a[const_index(6)] = 3; // OK, constant index and inside bounds
+}
+
+struct S {
+  int& operator[](int i);
+};
+
+void customOperator() {
+  S s;
+  int i = 0;
+  s[i] = 3; // OK, custom operator
+}
Index: test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index-gslheader.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index-gslheader.cpp
@@ -0,0 +1,79 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-bounds-constant-array-index %t -- -config='{CheckOptions: [{key: cppcoreguidelines-pro-bounds-constant-array-index.GslHeader, value: "dir1/gslheader.h"}]}' -- -std=c++11
+// CHECK-FIXES: #include "dir1/gslheader.h"
+
+typedef unsigned int size_t;
+
+namespace std {
+  template
+  struct array {
+T& operator[](size_t n);
+T& at(size_t n);
+  };
+}
+
+
+namespace gsl {
+  template
+  T& at( T()[N], size_t index );
+
+  template
+  T& at( std::array , size_t index );
+}
+
+constexpr int const_index(int base) {
+  return base + 3;
+}
+
+void f(std::array a, int pos) {
+  a [ pos / 2 /*comment*/] = 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead [cppcoreguidelines-pro-bounds-constant-array-index]
+  // CHECK-FIXES: gsl::at(a,  pos / 2 /*comment*/) = 1;
+  int j = a[pos - 1];
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead
+  // CHECK-FIXES: int j = gsl::at(a, pos - 1);
+
+  a.at(pos-1) = 2; // OK, at() instead of []
+  gsl::at(a, pos-1) = 2; // OK, 

Re: [PATCH] D15395: Add 3 more missing inline/visibility attributes

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

Should be fine.


Repository:
  rL LLVM

http://reviews.llvm.org/D15395



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

r255174 - Objective-C properties: loosen 'atomic' checking for readonly properties.

[Douglas Gregor via cfe-commits]

Author: dgregor
Date: Wed Dec  9 16:57:32 2015
New Revision: 255174

URL: http://llvm.org/viewvc/llvm-project?rev=255174=rev
Log:
Objective-C properties: loosen 'atomic' checking for readonly properties.

r251874 reworked the way we handle properties declared within
Objective-C class extensions, which had the effective of tightening up
property checking in a number of places. In this particular class of
cases, we end up complaining about "atomic" mismatches between an
implicitly-atomic, readonly property and a nonatomic, readwrite
property, which doesn't make sense because "atomic" is essentially
irrelevant to readonly properties.

Therefore, suppress this diagnostic when the readonly property is
implicitly atomic. Fixes rdar://problem/23803109.

Added:
cfe/trunk/test/SemaObjC/property-atomic-redecl.m
Modified:
cfe/trunk/lib/Sema/SemaObjCProperty.cpp
cfe/trunk/test/SemaObjC/property-3.m
cfe/trunk/test/SemaObjC/property-in-class-extension-1.m

Modified: cfe/trunk/lib/Sema/SemaObjCProperty.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaObjCProperty.cpp?rev=255174=255173=255174=diff
==
--- cfe/trunk/lib/Sema/SemaObjCProperty.cpp (original)
+++ cfe/trunk/lib/Sema/SemaObjCProperty.cpp Wed Dec  9 16:57:32 2015
@@ -339,6 +339,54 @@ static bool LocPropertyAttribute( ASTCon
   
 }
 
+/// Check for a mismatch in the atomicity of the given properties.
+static void checkAtomicPropertyMismatch(Sema ,
+ObjCPropertyDecl *OldProperty,
+ObjCPropertyDecl *NewProperty) {
+  // If the atomicity of both matches, we're done.
+  bool OldIsAtomic =
+(OldProperty->getPropertyAttributes() & ObjCDeclSpec::DQ_PR_nonatomic) == 
0;
+  bool NewIsAtomic =
+(NewProperty->getPropertyAttributes() & ObjCDeclSpec::DQ_PR_nonatomic) == 
0;
+  if (OldIsAtomic == NewIsAtomic) return;
+
+  // Determine whether the given property is readonly and implicitly
+  // atomic.
+  auto isImplicitlyReadonlyAtomic = [](ObjCPropertyDecl *Property) -> bool {
+// Is it readonly?
+auto Attrs = Property->getPropertyAttributes();
+if ((Attrs & ObjCDeclSpec::DQ_PR_readonly) == 0) return false;
+
+// Is it nonatomic?
+if (Attrs & ObjCDeclSpec::DQ_PR_nonatomic) return false;
+
+// Was 'atomic' specified directly?
+if (Property->getPropertyAttributesAsWritten() & 
ObjCDeclSpec::DQ_PR_atomic)
+  return false;
+
+return true;
+  };
+
+  // One of the properties is atomic; if it's a readonly property, and
+  // 'atomic' wasn't explicitly specified, we're okay.
+  if ((OldIsAtomic && isImplicitlyReadonlyAtomic(OldProperty)) ||
+  (NewIsAtomic && isImplicitlyReadonlyAtomic(NewProperty)))
+return;
+
+  // Diagnose the conflict.
+  const IdentifierInfo *OldContextName;
+  auto *OldDC = OldProperty->getDeclContext();
+  if (auto Category = dyn_cast(OldDC))
+OldContextName = Category->getClassInterface()->getIdentifier();
+  else
+OldContextName = cast(OldDC)->getIdentifier();
+
+  S.Diag(NewProperty->getLocation(), diag::warn_property_attribute)
+<< NewProperty->getDeclName() << "atomic"
+<< OldContextName;
+  S.Diag(OldProperty->getLocation(), diag::note_property_declare);
+}
+
 ObjCPropertyDecl *
 Sema::HandlePropertyInClassExtension(Scope *S,
  SourceLocation AtLoc,
@@ -464,20 +512,7 @@ Sema::HandlePropertyInClassExtension(Sco
   
   // Check that atomicity of property in class extension matches the previous
   // declaration.
-  unsigned PDeclAtomicity =
-PDecl->getPropertyAttributes() & (ObjCDeclSpec::DQ_PR_atomic | 
ObjCDeclSpec::DQ_PR_nonatomic);
-  unsigned PIDeclAtomicity =
-PIDecl->getPropertyAttributes() & (ObjCDeclSpec::DQ_PR_atomic | 
ObjCDeclSpec::DQ_PR_nonatomic);
-  if (PDeclAtomicity != PIDeclAtomicity) {
-bool PDeclAtomic = (!PDeclAtomicity || PDeclAtomicity & 
ObjCDeclSpec::DQ_PR_atomic);
-bool PIDeclAtomic = (!PIDeclAtomicity || PIDeclAtomicity & 
ObjCDeclSpec::DQ_PR_atomic);
-if (PDeclAtomic != PIDeclAtomic) {
-  Diag(PDecl->getLocation(), diag::warn_property_attribute)
-<< PDecl->getDeclName() << "atomic"
-<< cast(PIDecl->getDeclContext())->getName();
-  Diag(PIDecl->getLocation(), diag::note_property_declare);
-}
-  }
+  checkAtomicPropertyMismatch(*this, PIDecl, PDecl);
 
   *isOverridingProperty = true;
 
@@ -1326,12 +1361,10 @@ Sema::DiagnosePropertyMismatch(ObjCPrope
 }
   }
 
-  if ((CAttr & ObjCPropertyDecl::OBJC_PR_nonatomic)
-  != (SAttr & ObjCPropertyDecl::OBJC_PR_nonatomic)) {
-Diag(Property->getLocation(), diag::warn_property_attribute)
-  << Property->getDeclName() << "atomic" << inheritedName;
-Diag(SuperProperty->getLocation(), diag::note_property_declare);
-  }
+  // Check for nonatomic; note that nonatomic is effectively
+  // meaningless for readonly properties, so don't 

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

In http://reviews.llvm.org/D14409#306531, @eugenis wrote:

> In http://reviews.llvm.org/D14409#306379, @eugenis wrote:
>
> > In http://reviews.llvm.org/D14409#306272, @EricWF wrote:
> >
> > > Does the `inline` keyword have any effect when it's on function 
> > > definitions that are externally instantiated?
> >
> >
> > I could not detect any difference in behavior with or without inline 
> > keyword.
> >  Remove it?
>
>
> Actually, remove the inline breaks tests, because now the method is declared 
> hidden (in-class), so template instantiation in libc++.so produces a hidden 
> symbol.
>
> As an alternative, we could remove both "inline" and the in-class hidden 
> attribute.


That change would be an ABI break. This change is perfect as-is.


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Evgeniy Stepanov via cfe-commits]

eugenis closed this revision.
eugenis added a comment.

r255177
Thanks for the review!


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

[libcxx] r255185 - Remove redundant _LIBCPP_ALWAYS_INLINE attribute from __convert_to_integral overloads

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Dec  9 18:43:37 2015
New Revision: 255185

URL: http://llvm.org/viewvc/llvm-project?rev=255185=rev
Log:
Remove redundant _LIBCPP_ALWAYS_INLINE attribute from __convert_to_integral 
overloads

Modified:
libcxx/trunk/include/type_traits

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=255185=255184=255185=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Wed Dec  9 18:43:37 2015
@@ -4257,34 +4257,34 @@ struct __sfinae_underlying_type
 template 
 struct __sfinae_underlying_type<_Tp, false> {};
 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 int __convert_to_integral(int __val) { return __val; }
 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 unsigned __convert_to_integral(unsigned __val) { return __val; }
 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 long __convert_to_integral(long __val) { return __val; }
 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 unsigned long __convert_to_integral(unsigned long __val) { return __val; }
 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 long long __convert_to_integral(long long __val) { return __val; }
 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 unsigned long long __convert_to_integral(unsigned long long __val) {return 
__val; }
 
 #ifndef _LIBCPP_HAS_NO_INT128
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 __int128_t __convert_to_integral(__int128_t __val) { return __val; }
 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 __uint128_t __convert_to_integral(__uint128_t __val) { return __val; }
 #endif
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_ALWAYS_INLINE
+inline _LIBCPP_INLINE_VISIBILITY
 typename __sfinae_underlying_type<_Tp>::__promoted_type
 __convert_to_integral(_Tp __val) { return __val; }
 


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

[libcxxabi] r255186 - Replace cmake check for printf with a check for fopen.

[Evgeniy Stepanov via cfe-commits]

Author: eugenis
Date: Wed Dec  9 18:44:42 2015
New Revision: 255186

URL: http://llvm.org/viewvc/llvm-project?rev=255186=rev
Log:
Replace cmake check for printf with a check for fopen.

Printf is a builtin, and the check fails with -Werror because of a clang
warning about an incompatible redeclaration.

Modified:
libcxxabi/trunk/cmake/config-ix.cmake

Modified: libcxxabi/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/cmake/config-ix.cmake?rev=255186=255185=255186=diff
==
--- libcxxabi/trunk/cmake/config-ix.cmake (original)
+++ libcxxabi/trunk/cmake/config-ix.cmake Wed Dec  9 18:44:42 2015
@@ -39,7 +39,7 @@ check_cxx_compiler_flag(/EHa-
 check_cxx_compiler_flag(/GR-  LIBCXXABI_HAS_NO_GR_FLAG)
 
 # Check libraries
-check_library_exists(c printf "" LIBCXXABI_HAS_C_LIB)
+check_library_exists(c fopen "" LIBCXXABI_HAS_C_LIB)
 check_library_exists(dl dladdr "" LIBCXXABI_HAS_DL_LIB)
 check_library_exists(pthread pthread_once "" LIBCXXABI_HAS_PTHREAD_LIB)
 check_library_exists(gcc_eh _Unwind_GetRegionStart "" LIBCXXABI_HAS_GCC_EH_LIB)


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

Re: [clang-tools-extra] r254785 - Added coverage check for extensionless headers, and exclude hidden dot directoryies.

[Joshua Magee via cfe-commits]

Hi John,

> +if (file.startswith(".") || (file.find("\\.") != StringRef::npos)
> +  || (file.find("/.") != StringRef::npos))

This will also filter out things like ./foo.h, which probably isn't what we want
and breaks on relative/non-absolute paths.

For example, given a trivial test:
//- test.modulemap
module foo {
  header "foo.h"
  export *
}
//-

And some headers:
// - foo.h
typedef unsigned long ulong_t;

// - bar
typedef unsigned long ulong_t;

$ modularize -coverage-check-only test.modulemap
warning: No headers found in include path: ""

It is only OK if I specific the full path:
$ modularize -coverage-check-only /tmp/mod_test/test.modulemap
warning: /tmp/mod_test/test.modulemap does not account for file: 
/tmp/mod_test/bar

A simple refinement to your StringRef checks can catch the "./" case,
but I worry about other corner cases.
Once all corner cases are identified, it may be worth considering
abstracting the logic for identifying hidden/dot directories into some common 
API.

Thanks,
 - Josh



At 1449268938 seconds past the Epoch, John Thompson via cfe-commits wrote:
> Author: jtsoftware
> Date: Fri Dec  4 16:42:18 2015
> New Revision: 254785
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=254785=rev
> Log:
> Added coverage check for extensionless headers, and exclude hidden dot 
> directoryies.
> 
> Added:
> 
> clang-tools-extra/trunk/test/modularize/Inputs/CoverageNoProblems/Includes1/.hidden/
> 
> clang-tools-extra/trunk/test/modularize/Inputs/CoverageNoProblems/Includes1/.hidden/DontFindMe.h
> clang-tools-extra/trunk/test/modularize/Inputs/CoverageProblems/Level3B
> Modified:
> clang-tools-extra/trunk/modularize/CoverageChecker.cpp
> clang-tools-extra/trunk/modularize/ModularizeUtilities.cpp
> clang-tools-extra/trunk/test/modularize/ProblemsCoverage.modularize
> 
> Modified: clang-tools-extra/trunk/modularize/CoverageChecker.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/modularize/CoverageChecker.cpp?rev=254785=254784=254785=diff
> ==
> --- clang-tools-extra/trunk/modularize/CoverageChecker.cpp (original)
> +++ clang-tools-extra/trunk/modularize/CoverageChecker.cpp Fri Dec  4 
> 16:42:18 2015
> @@ -370,12 +370,18 @@ bool CoverageChecker::collectFileSystemH
>  I.increment(EC)) {
>  if (EC)
>return false;
> -std::string file(I->path());
> +//std::string file(I->path());
> +StringRef file(I->path());
>  I->status(Status);
>  sys::fs::file_type type = Status.type();
>  // If the file is a directory, ignore the name (but still recurses).
>  if (type == sys::fs::file_type::directory_file)
>continue;
> +// Assume directories or files starting with '.' are private and not to
> +// be considered.
> +if (file.startswith(".") || (file.find("\\.") != StringRef::npos)
> +  || (file.find("/.") != StringRef::npos))
> +  continue;
>  // If the file does not have a common header extension, ignore it.
>  if (!ModularizeUtilities::isHeader(file))
>continue;
> 
> Modified: clang-tools-extra/trunk/modularize/ModularizeUtilities.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/modularize/ModularizeUtilities.cpp?rev=254785=254784=254785=diff
> ==
> --- clang-tools-extra/trunk/modularize/ModularizeUtilities.cpp (original)
> +++ clang-tools-extra/trunk/modularize/ModularizeUtilities.cpp Fri Dec  4 
> 16:42:18 2015
> @@ -468,7 +468,7 @@ std::string ModularizeUtilities::getCano
>  bool ModularizeUtilities::isHeader(StringRef FileName) {
>StringRef Extension = llvm::sys::path::extension(FileName);
>if (Extension.size() == 0)
> -return false;
> +return true;
>if (Extension.equals_lower(".h"))
>  return true;
>if (Extension.equals_lower(".inc"))
> 
> Added: 
> clang-tools-extra/trunk/test/modularize/Inputs/CoverageNoProblems/Includes1/.hidden/DontFindMe.h
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/modularize/Inputs/CoverageNoProblems/Includes1/.hidden/DontFindMe.h?rev=254785=auto
> ==
> --- 
> clang-tools-extra/trunk/test/modularize/Inputs/CoverageNoProblems/Includes1/.hidden/DontFindMe.h
>  (added)
> +++ 
> clang-tools-extra/trunk/test/modularize/Inputs/CoverageNoProblems/Includes1/.hidden/DontFindMe.h
>  Fri Dec  4 16:42:18 2015
> @@ -0,0 +1,3 @@
> +#error DontFindMe.h shouldn't be found.
> +
> +
> 
> Added: clang-tools-extra/trunk/test/modularize/Inputs/CoverageProblems/Level3B
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/modularize/Inputs/CoverageProblems/Level3B?rev=254785=auto
> ==
> --- 

[clang-tools-extra] r255199 - There were problems if a relative path is used for an include path, the path will be normalized to ./xxx. I don't know how to test this in a way that will work in a separ

[John Thompson via cfe-commits]

Author: jtsoftware
Date: Wed Dec  9 19:33:09 2015
New Revision: 255199

URL: http://llvm.org/viewvc/llvm-project?rev=255199=rev
Log:
There were problems if a relative path is used for an include path, the path 
will be normalized to ./xxx.  I don't know how to test this in a way that will 
work in a separated source/output environment, but it seems reasonable to 
assume that -I options won't be for provate directories.

Modified:
clang-tools-extra/trunk/modularize/CoverageChecker.cpp

Modified: clang-tools-extra/trunk/modularize/CoverageChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/modularize/CoverageChecker.cpp?rev=255199=255198=255199=diff
==
--- clang-tools-extra/trunk/modularize/CoverageChecker.cpp (original)
+++ clang-tools-extra/trunk/modularize/CoverageChecker.cpp Wed Dec  9 19:33:09 
2015
@@ -379,8 +379,8 @@ bool CoverageChecker::collectFileSystemH
   continue;
 // Assume directories or files starting with '.' are private and not to
 // be considered.
-if (file.startswith(".") || (file.find("\\.") != StringRef::npos)
-  || (file.find("/.") != StringRef::npos))
+if ((file.find("\\.") != StringRef::npos) ||
+(file.find("/.") != StringRef::npos))
   continue;
 // If the file does not have a common header extension, ignore it.
 if (!ModularizeUtilities::isHeader(file))


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

Re: [PATCH] D15367: Cross-DSO control flow integrity (Clang part)

[Peter Collingbourne via cfe-commits]

pcc added inline comments.


Comment at: lib/CodeGen/CGExpr.cpp:2558
@@ +2557,3 @@
+  false));
+  llvm::MDString *MDS = dyn_cast(MD);
+  llvm::Constant *TypeId =

What happens if `MD` is not an `MDString`?


Comment at: lib/CodeGen/CodeGenModule.cpp:998
@@ -986,1 +997,3 @@
+  if (!CodeGenOpts.SanitizeCfiCrossDso)
+EmitFunctionBitSetEntry(FD, F);
 }

I would move the logic back here and make the check for definedness etc 
explicit. We shouldn't emit a bitset entry if the function has 
`available_externally` linkage for example.


Repository:
  rL LLVM

http://reviews.llvm.org/D15367



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

r255172 - [CMake] Pass CMAKE_MAKE_PROGRAM through to compiler-rt build.

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Wed Dec  9 16:46:25 2015
New Revision: 255172

URL: http://llvm.org/viewvc/llvm-project?rev=255172=rev
Log:
[CMake] Pass CMAKE_MAKE_PROGRAM through to compiler-rt build.

This is needed if your make tool is overridden.

Modified:
cfe/trunk/runtime/CMakeLists.txt

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=255172=255171=255172=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Wed Dec  9 16:46:25 2015
@@ -64,6 +64,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
-DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+   -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config

-DCOMPILER_RT_OUTPUT_DIR=${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}
-DCOMPILER_RT_EXEC_OUTPUT_DIR=${LLVM_RUNTIME_OUTPUT_INTDIR}


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

[PATCH] D15400: [Clang] Use autos in lib/AST/Type.cpp

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko created this revision.
Eugene.Zelenko added reviewers: hans, aaron.ballman.
Eugene.Zelenko added a subscriber: cfe-commits.
Eugene.Zelenko set the repository for this revision to rL LLVM.

Autos are also used for pointer variables assigned via casts or memory 
allocation. Patch includes other minor cleanups.

Build and regressions were fine on RHEL 6.

Repository:
  rL LLVM

http://reviews.llvm.org/D15400

Files:
  lib/AST/Type.cpp

Index: lib/AST/Type.cpp
===
--- lib/AST/Type.cpp
+++ lib/AST/Type.cpp
@@ -1,4 +1,4 @@
-//===--- Type.cpp - Type representation and manipulation --===//
+//===--- Type.cpp - Type representation and manipulation *- C++ -*-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -27,6 +27,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
+
 using namespace clang;
 
 bool Qualifiers::isStrictSupersetOf(Qualifiers Other) const {
@@ -190,7 +191,7 @@
 /// This method should never be used when type qualifiers are meaningful.
 const Type *Type::getArrayElementTypeNoTypeQual() const {
   // If this is directly an array type, return it.
-  if (const ArrayType *ATy = dyn_cast(this))
+  if (const auto *ATy = dyn_cast(this))
 return ATy->getElementType().getTypePtr();
 
   // If the canonical form of this type isn't the right kind, reject it.
@@ -226,7 +227,7 @@
 #define ABSTRACT_TYPE(Class, Parent)
 #define TYPE(Class, Parent) \
   case Type::Class: { \
-const Class##Type *ty = cast(this); \
+const auto *ty = cast(this); \
 if (!ty->isSugared()) return QualType(ty, 0); \
 return ty->desugar(); \
   }
@@ -245,7 +246,7 @@
 #define ABSTRACT_TYPE(Class, Parent)
 #define TYPE(Class, Parent) \
 case Type::Class: { \
-  const Class##Type *Ty = cast(CurTy); \
+  const auto *Ty = cast(CurTy); \
   if (!Ty->isSugared()) \
 return SplitQualType(Ty, Qs); \
   Cur = Ty->desugar(); \
@@ -274,7 +275,7 @@
 #define ABSTRACT_TYPE(Class, Parent)
 #define TYPE(Class, Parent) \
 case Type::Class: { \
-  const Class##Type *ty = cast(split.Ty); \
+  const auto *ty = cast(split.Ty); \
   if (!ty->isSugared()) goto done; \
   next = ty->desugar(); \
   break; \
@@ -307,13 +308,13 @@
 /// reaches a T or a non-sugared type.
 template static const T *getAsSugar(const Type *Cur) {
   while (true) {
-if (const T *Sugar = dyn_cast(Cur))
+if (const auto *Sugar = dyn_cast(Cur))
   return Sugar;
 switch (Cur->getTypeClass()) {
 #define ABSTRACT_TYPE(Class, Parent)
 #define TYPE(Class, Parent) \
 case Type::Class: { \
-  const Class##Type *Ty = cast(Cur); \
+  const auto *Ty = cast(Cur); \
   if (!Ty->isSugared()) return 0; \
   Cur = Ty->desugar().getTypePtr(); \
   break; \
@@ -346,7 +347,7 @@
 #define ABSTRACT_TYPE(Class, Parent)
 #define TYPE(Class, Parent) \
 case Class: { \
-  const Class##Type *Ty = cast(Cur); \
+  const auto *Ty = cast(Cur); \
   if (!Ty->isSugared()) return Cur; \
   Cur = Ty->desugar().getTypePtr(); \
   break; \
@@ -395,7 +396,7 @@
 }
 
 bool Type::isComplexType() const {
-  if (const ComplexType *CT = dyn_cast(CanonicalType))
+  if (const auto *CT = dyn_cast(CanonicalType))
 return CT->getElementType()->isFloatingType();
   return false;
 }
@@ -430,13 +431,13 @@
 
 const RecordType *Type::getAsStructureType() const {
   // If this is directly a structure type, return it.
-  if (const RecordType *RT = dyn_cast(this)) {
+  if (const auto *RT = dyn_cast(this)) {
 if (RT->getDecl()->isStruct())
   return RT;
   }
 
   // If the canonical form of this type isn't the right kind, reject it.
-  if (const RecordType *RT = dyn_cast(CanonicalType)) {
+  if (const auto *RT = dyn_cast(CanonicalType)) {
 if (!RT->getDecl()->isStruct())
   return nullptr;
 
@@ -449,13 +450,13 @@
 
 const RecordType *Type::getAsUnionType() const {
   // If this is directly a union type, return it.
-  if (const RecordType *RT = dyn_cast(this)) {
+  if (const auto *RT = dyn_cast(this)) {
 if (RT->getDecl()->isUnion())
   return RT;
   }
 
   // If the canonical form of this type isn't the right kind, reject it.
-  if (const RecordType *RT = dyn_cast(CanonicalType)) {
+  if (const auto *RT = dyn_cast(CanonicalType)) {
 if (!RT->getDecl()->isUnion())
   return nullptr;
 
@@ -519,7 +520,7 @@
 bool Type::isObjCInertUnsafeUnretainedType() const {
   const Type *cur = this;
   while (true) {
-if (auto attributed = dyn_cast(cur)) {
+if (const auto *attributed = dyn_cast(cur)) {
   if (attributed->getAttrKind() ==
 AttributedType::attr_objc_inert_unsafe_unretained)
 return true;
@@ -651,7 +652,6 @@
 }
 
 namespace {
-
 template
 QualType 

Re: [PATCH] D9600: Add scan-build python implementation

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

Hi Laszlo,



Comment at: tools/scan-build-py/libear/ear.c:281
@@ +280,3 @@
+
+DLSYM(func, fp, "execve");
+

This is not the recommended way of interposing on Darwin. All you need to do is 
provide your function, which can call the function you are interposing on and 
tell the linker about it as described in this example:

http://www.opensource.apple.com/source/dyld/dyld-97.1/include/mach-o/dyld-interposing.h

You would only need to set DYLD_INSERT_LIBRARIES and would not need to require 
flat namespace. We should not be setting DYLD_FORCE_FLAT_NAMESPACE; some of the 
problems it causes are described on this thread: 

https://mikeash.com/pyblog/friday-qa-2009-01-30-code-injection.html

compiler-rt (sanitizers) also intercept on all platforms including Windows (see 
interception.h); that code is very platform dependent.


http://reviews.llvm.org/D9600



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

Re: [PATCH] D14653: [libcxx] Introduce the mechanism for fixing -fno-exceptions test failures.

[Eric Fiselier via cfe-commits]

EricWF added a reviewer: EricWF.
EricWF added a comment.

Sorry I'm late to this party. Please let me know if my concerns have already 
been discussed.

First, thanks for taking on all this work. Getting the test suite passing 
without exceptions is a tall order.

My two cents:

- I like the approach taken in the library. `__throw_helper` and 
`__libcxx_noexceptions_abort()`. However I don't like that they are in their 
own header. We should find another header for these to live in. `` 
tends to be the dumping ground for these sorts of things.

- I'm concerned about the cost of the call to `__throw_helper()` when 
exceptions are turned on. Mostly because it copies the exception given to it 
but also because it's an unneeded layer of indirection.  Perhaps we could have 
a macro called `_LIBCPP_THROW(E, MSG)` that is simply defined as `throw E` when 
exceptions are turned on and `__throw_helper(E, MSG)` otherwise.

- I would really like to avoid `#define try` and `#define catch`. Replacing 
keywords has serious code smell and hides the fact that the test does something 
useful with exceptions turned off. It also has the slightest possibility of 
hiding bugs in libc++ (ex it might hide a 'try' keyword within a 
_LIBCPP_HAS_NO_EXCEPTIONS block). I would be happy simply using `TEST_TRY` and 
`TEST_CATCH` macros or similar.  This communicates the intent of the test (w/o 
exceptions) to the reader.

- While your setjmp/longjmp solution is quite clever it concerns me that 
longjmp doesn't respect destructors (AFAIK). This means that the tests may leak 
resources with -fno-exceptions. I would like to avoid this because I think it 
will prevent the use of sanitizers. Unfortunately I think this means that we 
will need to actually modify each test.

- The `#define try` and `#define catch` only work when the expression only has 
one catch block and also when that catch block does not reference the caught 
exception by name. It seems like this would greatly limit the effectiveness of 
your approach. How many tests begin to pass after applying your patch?

- We should document libc++'s support -fno-exceptions in general but we should 
also document each function that now has well defined behavior with 
-fno-exceptions as we update the tests.

- Is `__libcpp_noexceptions_abort()` is intended to be a customization point 
for users of -fno-exceptions?




http://reviews.llvm.org/D14653



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

Re: [PATCH] D14411: Use __attribute__((internal_linkage)) when available.

[Evgeniy Stepanov via cfe-commits]

eugenis added a dependency: D12502: [libcxx] Better constain tuples 
constructors -- Fix PR23256 and PR22806.
eugenis added a comment.

Note, this breaks tuple_cat.pass.cpp test.

With -O0, replacing always_inline with internal_linkage results in less 
optimization being done (namely, no inlining happens). This ends up exposing

  https://llvm.org/bugs/show_bug.cgi?id=23256

which is fixed by

  http://reviews.llvm.org/D12502

The same failure can be reproduced in the current ToT libc++ by running this 
test with -O2.

This change depends on http://reviews.llvm.org/D12502.


Repository:
  rL LLVM

http://reviews.llvm.org/D14411



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

Re: [PATCH] D15161: [CMake] On Darwin the LIBCXX_INSTALL_HEADERS and LIBCXX_INSTALL_LIBRARY options should default off

[Eric Fiselier via cfe-commits]

EricWF added a comment.

> The current implementation doesn't work as intended because of CMake's 
> caching behavior. The CMake set command doesn't globally override cached 
> options.


Sort of. It doesn't override the value in the cache but it should mean that the 
cache value is overridden by the newly set non-cache value. If I am correct the 
following code will print "VAR = OFF".

  option(VAR "description" ON)
  set(VAR OFF)
  message(STATUS "VAR = ${VAR}")

Could you give me an example of where this breaks? It won't override the values 
in the cache but it should work correctly.


http://reviews.llvm.org/D15161



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

Re: [PATCH] D15399: MS inline ASM: mark the function noinline if the asm has labels (PR23715)

[Hans Wennborg via cfe-commits]

hans added inline comments.


Comment at: lib/CodeGen/CGStmt.cpp:2005
@@ -1998,3 +2004,3 @@
  /* IsAlignStack */ false, AsmDialect);
   llvm::CallInst *Result = Builder.CreateCall(IA, Args);
   Result->addAttribute(llvm::AttributeSet::FunctionIndex,

majnemer wrote:
> rnk wrote:
> > If this inline asm has labels, we should also add the noduplicate attribute 
> > to the callsite. That will prevent CFG transforms like tail duplication 
> > from duplicating it.
> Actually, isn't noduplicate sufficient?  I'm having trouble seeing where 
> noinline inhibits problematic transforms over noduplicate.
You're right. I'll just do that.


Comment at: test/CodeGen/ms-inline-asm.c:536
@@ -535,3 +535,3 @@
   }
-  // CHECK-LABEL: define void @label1
+  // CHECK: define void @label1() [[ATTR1:#[0-9]+]] {
   // CHECK: call void asm sideeffect inteldialect 
"{{.*}}__MSASMLABEL_.1__label:\0A\09jmp {{.*}}__MSASMLABEL_.1__label", 
"~{dirflag},~{fpsr},~{flags}"()

rsmith wrote:
> Why is this not a CHECK-LABEL any more?
FileCheck got upset:
error: found 'CHECK-LABEL:' with variable definition or use


http://reviews.llvm.org/D15399



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

r255201 - Mark MS inline ASM 'nodplicate' it it has labels (PR23715)

[Hans Wennborg via cfe-commits]

Author: hans
Date: Wed Dec  9 19:38:04 2015
New Revision: 255201

URL: http://llvm.org/viewvc/llvm-project?rev=255201=rev
Log:
Mark MS inline ASM 'nodplicate' it it has labels (PR23715)

Duplicating it can lead to labels being defined twice.

Differential revision: http://reviews.llvm.org/D15399

Modified:
cfe/trunk/lib/CodeGen/CGStmt.cpp
cfe/trunk/test/CodeGen/ms-inline-asm.c

Modified: cfe/trunk/lib/CodeGen/CGStmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmt.cpp?rev=255201=255200=255201=diff
==
--- cfe/trunk/lib/CodeGen/CGStmt.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmt.cpp Wed Dec  9 19:38:04 2015
@@ -1999,6 +1999,15 @@ void CodeGenFunction::EmitAsmStmt(const
   Result->addAttribute(llvm::AttributeSet::FunctionIndex,
llvm::Attribute::NoUnwind);
 
+  if (isa()) {
+// If the assembly contains any labels, mark the call noduplicate to 
prevent
+// defining the same ASM label twice (PR23715). This is pretty hacky, but 
it
+// works.
+if (AsmString.find("__MSASMLABEL_") != std::string::npos)
+  Result->addAttribute(llvm::AttributeSet::FunctionIndex,
+   llvm::Attribute::NoDuplicate);
+  }
+
   // Attach readnone and readonly attributes.
   if (!HasSideEffect) {
 if (ReadNone)

Modified: cfe/trunk/test/CodeGen/ms-inline-asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ms-inline-asm.c?rev=255201=255200=255201=diff
==
--- cfe/trunk/test/CodeGen/ms-inline-asm.c (original)
+++ cfe/trunk/test/CodeGen/ms-inline-asm.c Wed Dec  9 19:38:04 2015
@@ -533,8 +533,8 @@ void label1() {
 label:
 jmp label
   }
-  // CHECK-LABEL: define void @label1
-  // CHECK: call void asm sideeffect inteldialect 
"{{.*}}__MSASMLABEL_.1__label:\0A\09jmp {{.*}}__MSASMLABEL_.1__label", 
"~{dirflag},~{fpsr},~{flags}"()
+  // CHECK-LABEL: define void @label1()
+  // CHECK: call void asm sideeffect inteldialect 
"{{.*}}__MSASMLABEL_.1__label:\0A\09jmp {{.*}}__MSASMLABEL_.1__label", 
"~{dirflag},~{fpsr},~{flags}"() [[ATTR1:#[0-9]+]]
 }
 
 void label2() {
@@ -581,3 +581,6 @@ int test_indirect_field(LARGE_INTEGER La
 }
 // CHECK-LABEL: define i32 @test_indirect_field(
 // CHECK: call i32 asm sideeffect inteldialect "mov eax, dword ptr $1",
+
+// MS ASM containing labels must not be duplicated (PR23715).
+// CHECK: attributes [[ATTR1]] = { {{.*}}noduplicate{{.*}} }


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

Re: [PATCH] D12624: Top-level anonymous namespaces are missing import DW_TAG_imported_module and nested anonymous namespaces are not

[Katya Romanova via cfe-commits]

kromanova updated the summary for this revision.
kromanova set the repository for this revision to rL LLVM.
kromanova updated this revision to Diff 42364.
kromanova added a comment.

I have made all the changes that Richard suggested. Sorry for the delay, got 
distracted by other tasks.
Anything else I need to change?


Repository:
  rL LLVM

http://reviews.llvm.org/D12624

Files:
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/CodeGen/CGDebugInfo.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Sema/SemaDeclCXX.cpp
  test/CodeGenCXX/debug-info-anon-namespace.cpp

Index: test/CodeGenCXX/debug-info-anon-namespace.cpp
===
--- test/CodeGenCXX/debug-info-anon-namespace.cpp
+++ test/CodeGenCXX/debug-info-anon-namespace.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited -triple x86_64-scei-ps4 -O0 %s -o - | FileCheck --check-prefix=PS4 %s
+// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited -triple x86_64-unknown-linux-gnu -O0 %s -o - | FileCheck --check-prefix=NON-PS4 %s
+
+namespace
+{
+  int a = 5;
+}
+int *b = 
+
+namespace
+{
+  namespace {
+int a1 = 5;
+  }
+  int a2 = 7;
+}
+int *b1 = 
+int *b2 = 
+
+
+// PS4:  [[NS:![0-9]+]] = !DINamespace
+// PS4:  [[NS2:![0-9]+]] = !DINamespace
+// PS4: !DIImportedEntity(tag: DW_TAG_imported_module, scope: !0, entity: [[NS]])
+// PS4: !DIImportedEntity(tag: DW_TAG_imported_module, scope: [[NS]], entity: [[NS2]], line: {{[0-9]+}})
+// NON-PS4-NOT: !DIImportedEntity
+
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -7185,7 +7185,8 @@
SourceLocation IdentLoc,
IdentifierInfo *II,
SourceLocation LBrace,
-   AttributeList *AttrList) {
+   AttributeList *AttrList,
+   UsingDirectiveDecl *) {
   SourceLocation StartLoc = InlineLoc.isValid() ? InlineLoc : NamespaceLoc;
   // For anonymous namespace, take the location of the left brace.
   SourceLocation Loc = II ? IdentLoc : LBrace;
@@ -7299,14 +7300,13 @@
 // namespace internal linkage.
 
 if (!PrevNS) {
-  UsingDirectiveDecl* UD
-= UsingDirectiveDecl::Create(Context, Parent,
- /* 'using' */ LBrace,
- /* 'namespace' */ SourceLocation(),
- /* qualifier */ NestedNameSpecifierLoc(),
- /* identifier */ SourceLocation(),
- Namespc,
- /* Ancestor */ Parent);
+  UD = UsingDirectiveDecl::Create(Context, Parent,
+  /* 'using' */ LBrace,
+  /* 'namespace' */ SourceLocation(),
+  /* qualifier */ NestedNameSpecifierLoc(),
+  /* identifier */ SourceLocation(),
+  Namespc,
+  /* Ancestor */ Parent);
   UD->setImplicit();
   Parent->addDecl(UD);
 }
Index: lib/Parse/ParseDeclCXX.cpp
===
--- lib/Parse/ParseDeclCXX.cpp
+++ lib/Parse/ParseDeclCXX.cpp
@@ -55,17 +55,17 @@
 ///   namespace-alias-definition:  [C++ 7.3.2: namespace.alias]
 /// 'namespace' identifier '=' qualified-namespace-specifier ';'
 ///
-Decl *Parser::ParseNamespace(unsigned Context,
- SourceLocation ,
- SourceLocation InlineLoc) {
+Parser::DeclGroupPtrTy Parser::ParseNamespace(unsigned Context,
+  SourceLocation ,
+  SourceLocation InlineLoc) {
   assert(Tok.is(tok::kw_namespace) && "Not a namespace!");
   SourceLocation NamespaceLoc = ConsumeToken();  // eat the 'namespace'.
   ObjCDeclContextSwitch ObjCDC(*this);
 
   if (Tok.is(tok::code_completion)) {
 Actions.CodeCompleteNamespaceDecl(getCurScope());
 cutOffParsing();
-return nullptr;
+return DeclGroupPtrTy();;
   }
 
   SourceLocation IdentLoc;
@@ -109,31 +109,32 @@
   Diag(Tok, diag::err_expected) << tok::identifier;
   // Skip to end of the definition and eat the ';'.
   SkipUntil(tok::semi);
-  return nullptr;
+  return DeclGroupPtrTy();
 }
 if (attrLoc.isValid())
   Diag(attrLoc, diag::err_unexpected_namespace_attributes_alias);
 if (InlineLoc.isValid())
   Diag(InlineLoc, diag::err_inline_namespace_alias)
   << FixItHint::CreateRemoval(InlineLoc);
-

r255200 - Fix a typo in the clang user manual.

[Yunzhong Gao via cfe-commits]

Author: ygao
Date: Wed Dec  9 19:37:18 2015
New Revision: 255200

URL: http://llvm.org/viewvc/llvm-project?rev=255200=rev
Log:
Fix a typo in the clang user manual.
-fmax-unknown-pointer-align => -fmax-type-align

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=255200=255199=255200=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Wed Dec  9 19:37:18 2015
@@ -1108,7 +1108,7 @@ are listed below.
This option restricts the generated code to use general registers
only. This only applies to the AArch64 architecture.
 
-**-f[no-]max-unknown-pointer-align=[number]**
+**-f[no-]max-type-align=[number]**
Instruct the code generator to not enforce a higher alignment than the given
number (of bytes) when accessing memory via an opaque pointer or reference.
This cap is ignored when directly accessing a variable or when the pointee
@@ -1136,7 +1136,7 @@ are listed below.
 
   void initialize_vector(__aligned_v16si *v) {
 // The compiler may assume that ‘v’ is 64-byte aligned, regardless 
of the
-// value of -fmax-unknown-pointer-align.
+// value of -fmax-type-align.
   }
 
 


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

Re: [PATCH] D15006: Driver: Better detection of mingw-gcc

[Martell Malone via cfe-commits]

martell added a comment.

hi ismail,
I will tidy up for review closer towards the weekend where i can work on out of 
work stuff


http://reviews.llvm.org/D15006



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

Re: [PATCH] D12624: Top-level anonymous namespaces are missing import DW_TAG_imported_module and nested anonymous namespaces are not

[Richard Smith via cfe-commits]

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

This looks good to me.

Once we have this in place we can think about factoring the debug-specific 
flags out of `CodeGenOpts` into some kind of `DebugInfoOpts`, to be configured 
by whatever debugger tuning mechanism we end up with.


Repository:
  rL LLVM

http://reviews.llvm.org/D12624



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

Re: [PATCH] D14274: Add alloc_size attribute to clang

[George Burgess IV via cfe-commits]

george.burgess.iv added a comment.

Also, due to allowing the evaluation of const expressions as constexpr 
expressions, this patch needs http://reviews.llvm.org/D14877 to go in so we 
don't break tests. :)


http://reviews.llvm.org/D14274



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

Re: [PATCH] D15399: MS inline ASM: mark the function noinline if the asm has labels (PR23715)

[Richard Smith via cfe-commits]

rsmith added a subscriber: rsmith.


Comment at: test/CodeGen/ms-inline-asm.c:536
@@ -535,3 +535,3 @@
   }
-  // CHECK-LABEL: define void @label1
+  // CHECK: define void @label1() [[ATTR1:#[0-9]+]] {
   // CHECK: call void asm sideeffect inteldialect 
"{{.*}}__MSASMLABEL_.1__label:\0A\09jmp {{.*}}__MSASMLABEL_.1__label", 
"~{dirflag},~{fpsr},~{flags}"()

Why is this not a CHECK-LABEL any more?


http://reviews.llvm.org/D15399



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

[PATCH] D15404: Cleanup: move visibility/linkage attributes to the first declaration (part 2).

[Evgeniy Stepanov via cfe-commits]

eugenis created this revision.
eugenis added reviewers: EricWF, mclow.lists.
eugenis added a subscriber: cfe-commits.
eugenis set the repository for this revision to rL LLVM.

This is a follow-up to r252385.
For some reason, I missed a lot of cases when the visibility attribute was 
applied to the definition, but not to an earlier declaration.


Repository:
  rL LLVM

http://reviews.llvm.org/D15404

Files:
  include/complex
  include/experimental/any
  include/experimental/dynarray
  include/ext/hash_map
  include/ext/hash_set
  include/forward_list
  include/fstream
  include/list
  include/queue
  include/unordered_map
  include/unordered_set
  test/libcxx/test/config.py

Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -364,6 +364,7 @@
 self.cxx.compile_flags += shlex.split(compile_flags_str)
 sysroot_flags = getSysrootFlagsOnDarwin(self.config, self.lit_config)
 self.cxx.compile_flags.extend(sysroot_flags)
+	self.cxx.compile_flags.append("-ferror-limit=0")
 
 def configure_default_compile_flags(self):
 # Try and get the std version from the command line. Fall back to
Index: include/unordered_set
===
--- include/unordered_set
+++ include/unordered_set
@@ -404,10 +404,12 @@
   size_type __n, const hasher& __hf, const allocator_type& __a)
 : unordered_set(__first, __last, __n, __hf, key_equal(), __a) {}
 #endif
+_LIBCPP_INLINE_VISIBILITY
 explicit unordered_set(const allocator_type& __a);
 unordered_set(const unordered_set& __u);
 unordered_set(const unordered_set& __u, const allocator_type& __a);
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+_LIBCPP_INLINE_VISIBILITY
 unordered_set(unordered_set&& __u)
 _NOEXCEPT_(is_nothrow_move_constructible<__table>::value);
 unordered_set(unordered_set&& __u, const allocator_type& __a);
@@ -439,10 +441,12 @@
 return *this;
 }
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+_LIBCPP_INLINE_VISIBILITY
 unordered_set& operator=(unordered_set&& __u)
 _NOEXCEPT_(is_nothrow_move_assignable<__table>::value);
 #endif
 #ifndef _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS
+_LIBCPP_INLINE_VISIBILITY
 unordered_set& operator=(initializer_list __il);
 #endif  // _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS
 
@@ -527,6 +531,7 @@
 #endif
 #endif  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
 template 
+_LIBCPP_INLINE_VISIBILITY
 void insert(_InputIterator __first, _InputIterator __last);
 #ifndef _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS
 _LIBCPP_INLINE_VISIBILITY
@@ -678,7 +683,7 @@
 }
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 unordered_set<_Value, _Hash, _Pred, _Alloc>::unordered_set(
 const allocator_type& __a)
 : __table_(__a)
@@ -715,7 +720,7 @@
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 unordered_set<_Value, _Hash, _Pred, _Alloc>::unordered_set(
 unordered_set&& __u)
 _NOEXCEPT_(is_nothrow_move_constructible<__table>::value)
@@ -792,7 +797,7 @@
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 unordered_set<_Value, _Hash, _Pred, _Alloc>&
 unordered_set<_Value, _Hash, _Pred, _Alloc>::operator=(unordered_set&& __u)
 _NOEXCEPT_(is_nothrow_move_assignable<__table>::value)
@@ -806,7 +811,7 @@
 #ifndef _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 unordered_set<_Value, _Hash, _Pred, _Alloc>&
 unordered_set<_Value, _Hash, _Pred, _Alloc>::operator=(
 initializer_list __il)
@@ -819,7 +824,7 @@
 
 template 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 void
 unordered_set<_Value, _Hash, _Pred, _Alloc>::insert(_InputIterator __first,
 _InputIterator __last)
@@ -940,10 +945,12 @@
size_type __n, const hasher& __hf, const allocator_type& __a)
 : unordered_multiset(__first, __last, __n, __hf, key_equal(), __a) {}
 #endif
+_LIBCPP_INLINE_VISIBILITY
 explicit unordered_multiset(const allocator_type& __a);
 unordered_multiset(const unordered_multiset& __u);
 unordered_multiset(const unordered_multiset& __u, const allocator_type& __a);
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+_LIBCPP_INLINE_VISIBILITY
 unordered_multiset(unordered_multiset&& __u)
 _NOEXCEPT_(is_nothrow_move_constructible<__table>::value);
 unordered_multiset(unordered_multiset&& __u, const allocator_type& __a);
@@ -973,6 +980,7 @@
 return *this;
 }
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+_LIBCPP_INLINE_VISIBILITY
 unordered_multiset& operator=(unordered_multiset&& __u)
 _NOEXCEPT_(is_nothrow_move_assignable<__table>::value);
 #endif
@@ -1029,6 +1037,7 @@
  

Re: [PATCH] D14411: Use __attribute__((internal_linkage)) when available.

[Evgeniy Stepanov via cfe-commits]

eugenis added a dependency: D15404: Cleanup: move visibility/linkage attributes 
to the first declaration (part 2)..
eugenis added a comment.

This change depends on http://reviews.llvm.org/D15404.


Repository:
  rL LLVM

http://reviews.llvm.org/D14411



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

Re: [PATCH] D14411: Use __attribute__((internal_linkage)) when available.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Why does this depend on  http://reviews.llvm.org/D15404?


Repository:
  rL LLVM

http://reviews.llvm.org/D14411



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

Re: [PATCH] D15161: [CMake] On Darwin the LIBCXX_INSTALL_HEADERS and LIBCXX_INSTALL_LIBRARY options should default off

[Chris Bieneman via cfe-commits]

beanz abandoned this revision.
beanz added a comment.

Short answer. I was doing something terrible and wrong in out-of-tree code, and 
this was getting tripped up. I was reading the LIBCXX_INSTALL_* variables from 
a higher-level CMake file. I've stopped doing that (because it was stupid), so 
I'll abandon this patch.

For context the CMake behavior I was hitting was this:

CMakeLists.txt:

  add_subdirectory(foo)
  message(STATUS "VAR = ${VAR}") # prints On

foo/CMakeLists.txt:

  option(VAR "description" ON)
  set(VAR OFF)
  message(STATUS "VAR = ${VAR}") # prints OFF

Overriding a cached variable in CMake only overrides it in the current scope 
and lower.


http://reviews.llvm.org/D15161



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

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

In http://reviews.llvm.org/D14409#306379, @eugenis wrote:

> In http://reviews.llvm.org/D14409#306272, @EricWF wrote:
>
> > Does the `inline` keyword have any effect when it's on function definitions 
> > that are externally instantiated?
>
>
> I could not detect any difference in behavior with or without inline keyword.
>  Remove it?


Actually, remove the inline breaks tests, because now the method is declared 
hidden (in-class), so template instantiation in libc++.so produces a hidden 
symbol.

As an alternative, we could remove both "inline" and the in-class hidden 
attribute.


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

r255176 - Fix crash on invalid initialization with std::initializer_list

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Wed Dec  9 17:18:38 2015
New Revision: 255176

URL: http://llvm.org/viewvc/llvm-project?rev=255176=rev
Log:
Fix crash on invalid initialization with std::initializer_list

It is possible for CheckListElementTypes to fail without filling in any
initializer list elements.

Modified:
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=255176=255175=255176=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Wed Dec  9 17:18:38 2015
@@ -805,7 +805,8 @@ void InitListChecker::CheckImplicitInitL
 unsigned EndIndex = (Index == StartIndex? StartIndex : Index - 1);
 // Update the structured sub-object initializer so that it's ending
 // range corresponds with the end of the last initializer it used.
-if (EndIndex < ParentIList->getNumInits()) {
+if (EndIndex < ParentIList->getNumInits() &&
+ParentIList->getInit(EndIndex)) {
   SourceLocation EndLoc
 = ParentIList->getInit(EndIndex)->getSourceRange().getEnd();
   StructuredSubobjectInitList->setRBraceLoc(EndLoc);

Modified: cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp?rev=255176=255175=255176=diff
==
--- cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp (original)
+++ cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp Wed Dec  9 
17:18:38 2015
@@ -284,3 +284,28 @@ namespace ParameterPackNestedInitializer
 
   void foo() { f({{0}}, {{'\0'}}); }
 }
+
+namespace update_rbrace_loc_crash {
+  // We used to crash-on-invalid on this example when updating the right brace
+  // location.
+  template 
+  struct A {};
+  template 
+  std::initializer_list ExplodeImpl(F p1, A) {
+// expected-error@+1 {{reference to type 'const 
update_rbrace_loc_crash::Incomplete' could not bind to an rvalue of type 
'void'}}
+return {p1(I)...};
+  }
+  template 
+  void Explode(F p1) {
+// expected-note@+1 {{in instantiation of function template 
specialization}}
+ExplodeImpl(p1, A());
+  }
+  class Incomplete;
+  struct ContainsIncomplete {
+const Incomplete 
+  };
+  void f() {
+// expected-note@+1 {{in instantiation of function template 
specialization}}
+Explode([](int) {});
+  }
+}


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

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

In http://reviews.llvm.org/D14409#306531, @eugenis wrote:

> In http://reviews.llvm.org/D14409#306379, @eugenis wrote:
>
> > In http://reviews.llvm.org/D14409#306272, @EricWF wrote:
> >
> > > Does the `inline` keyword have any effect when it's on function 
> > > definitions that are externally instantiated?
> >
> >
> > I could not detect any difference in behavior with or without inline 
> > keyword.
> >  Remove it?
>
>
> Actually, remove the inline breaks tests, because now the method is declared 
> hidden (in-class), so template instantiation in libc++.so produces a hidden 
> symbol.
>
> As an alternative, we could remove both "inline" and the in-class hidden 
> attribute.


So, we can not remove "inline" because without it always_inline does not seem 
to have any effect.
We can remove always_inline from the declarations, but that would add a few 
more exported symbols to libc++.

I'll land this change as is, if you don't mind.


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

Re: [PATCH] D14411: Use __attribute__((internal_linkage)) when available.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

In http://reviews.llvm.org/D14411#306716, @EricWF wrote:

> Why does this depend on  http://reviews.llvm.org/D15404?


Woops, I meant the tuple patch but I see the other comment now. I'm curious as 
to how inlininging ends up affecting which overload's SFINAE are evaluated.

Drive by comment: Is the change from `__attribute__((__visibility__("hidden"), 
__always_inline__))` to `__attribute__((__internal_linkage__))` ABI compatible?


Repository:
  rL LLVM

http://reviews.llvm.org/D14411



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

[libcxx] r255177 - Remove visibility attributes from out-of-class method definitions in iostreams.

[Evgeniy Stepanov via cfe-commits]

Author: eugenis
Date: Wed Dec  9 17:42:30 2015
New Revision: 255177

URL: http://llvm.org/viewvc/llvm-project?rev=255177=rev
Log:
Remove visibility attributes from out-of-class method definitions in iostreams.

No point in pretending that these methods are hidden - they are
actually exported from libc++.so. Extern template declarations make
them part of libc++ ABI.

This patch does not change libc++.so export list (at least on Linux).

Modified:
libcxx/trunk/include/istream
libcxx/trunk/include/ostream
libcxx/trunk/include/sstream
libcxx/trunk/include/streambuf

Modified: libcxx/trunk/include/istream
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/istream?rev=255177=255176=255177=diff
==
--- libcxx/trunk/include/istream (original)
+++ libcxx/trunk/include/istream Wed Dec  9 17:42:30 2015
@@ -304,7 +304,7 @@ basic_istream<_CharT, _Traits>::sentry::
 }
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>::basic_istream(basic_streambuf* __sb)
 : __gc_(0)
 {
@@ -314,7 +314,7 @@ basic_istream<_CharT, _Traits>::basic_is
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>::basic_istream(basic_istream&& __rhs)
 : __gc_(__rhs.__gc_)
 {
@@ -323,7 +323,7 @@ basic_istream<_CharT, _Traits>::basic_is
 }
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator=(basic_istream&& __rhs)
 {
@@ -339,7 +339,7 @@ basic_istream<_CharT, _Traits>::~basic_i
 }
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 void
 basic_istream<_CharT, _Traits>::swap(basic_istream& __rhs)
 {
@@ -725,7 +725,7 @@ basic_istream<_CharT, _Traits>::operator
 }
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator>>(basic_istream& 
(*__pf)(basic_istream&))
 {
@@ -733,7 +733,7 @@ basic_istream<_CharT, _Traits>::operator
 }
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator>>(basic_ios&
(*__pf)(basic_ios&))
@@ -743,7 +743,7 @@ basic_istream<_CharT, _Traits>::operator
 }
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator>>(ios_base& (*__pf)(ios_base&))
 {
@@ -800,7 +800,7 @@ operator>>(basic_istream<_CharT, _Traits
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream&
 operator>>(basic_istream& __is, unsigned char* __s)
 {
@@ -808,7 +808,7 @@ operator>>(basic_istream&
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream&
 operator>>(basic_istream& __is, signed char* __s)
 {
@@ -843,7 +843,7 @@ operator>>(basic_istream<_CharT, _Traits
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream&
 operator>>(basic_istream& __is, unsigned char& __c)
 {
@@ -851,7 +851,7 @@ operator>>(basic_istream&
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream&
 operator>>(basic_istream& __is, signed char& __c)
 {
@@ -947,7 +947,7 @@ basic_istream<_CharT, _Traits>::get()
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::get(char_type& __c)
 {
@@ -1006,7 +1006,7 @@ basic_istream<_CharT, _Traits>::get(char
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::get(char_type* __s, streamsize __n)
 {
@@ -1068,7 +1068,7 @@ basic_istream<_CharT, _Traits>::get(basi
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::get(basic_streambuf& 
__sb)
 {
@@ -1129,7 +1129,7 @@ basic_istream<_CharT, _Traits>::getline(
 }
 
 template
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::getline(char_type* __s, streamsize __n)
 {
@@ -1462,7 +1462,7 @@ ws(basic_istream<_CharT, _Traits>& __is)
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_istream<_CharT, _Traits>&
 operator>>(basic_istream<_CharT, _Traits>&& __is, _Tp& __x)
 {
@@ -1504,7 +1504,7 @@ public:
 };
 
 template 
-inline _LIBCPP_INLINE_VISIBILITY
+inline
 basic_iostream<_CharT, _Traits>::basic_iostream(basic_streambuf* __sb)
 : basic_istream<_CharT, _Traits>(__sb)
 {
@@ -1513,14 +1513,14 @@ basic_iostream<_CharT, _Traits>::basic_i
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 
 template 
-inline 

r255196 - [Lit Test] Updated 20 Lit tests to be C++11 compatible.

[Charles Li via cfe-commits]

Author: lcharles
Date: Wed Dec  9 19:07:17 2015
New Revision: 255196

URL: http://llvm.org/viewvc/llvm-project?rev=255196=rev
Log:
[Lit Test] Updated 20 Lit tests to be C++11 compatible.

This is the 5th Lit test patch.
Expanded expected diagnostics to vary by C++ dialect.
Expanded RUN line to: default, C++98/03 and C++11.

Modified:
cfe/trunk/test/CXX/class/class.nest/p1.cpp
cfe/trunk/test/Parser/cxx-casting.cpp
cfe/trunk/test/Parser/cxx-reference.cpp
cfe/trunk/test/Parser/cxx-template-argument.cpp
cfe/trunk/test/Parser/cxx-typeof.cpp
cfe/trunk/test/Parser/objc-init.m
cfe/trunk/test/Parser/objcxx-lambda-expressions-neg.mm
cfe/trunk/test/SemaCXX/decl-expr-ambiguity.cpp
cfe/trunk/test/SemaCXX/overload-call.cpp
cfe/trunk/test/SemaCXX/pragma-init_seg.cpp
cfe/trunk/test/SemaCXX/typo-correction-delayed.cpp
cfe/trunk/test/SemaCXX/unknown-type-name.cpp
cfe/trunk/test/SemaCXX/writable-strings-deprecated.cpp
cfe/trunk/test/SemaObjCXX/message.mm
cfe/trunk/test/SemaTemplate/instantiate-function-2.cpp
cfe/trunk/test/SemaTemplate/instantiate-static-var.cpp
cfe/trunk/test/SemaTemplate/nested-name-spec-template.cpp
cfe/trunk/test/SemaTemplate/overload-candidates.cpp
cfe/trunk/test/SemaTemplate/partial-spec-instantiate.cpp
cfe/trunk/test/SemaTemplate/temp_arg_template.cpp

Modified: cfe/trunk/test/CXX/class/class.nest/p1.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/class/class.nest/p1.cpp?rev=255196=255195=255196=diff
==
--- cfe/trunk/test/CXX/class/class.nest/p1.cpp (original)
+++ cfe/trunk/test/CXX/class/class.nest/p1.cpp Wed Dec  9 19:07:17 2015
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++98 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
 
 class Outer {
   int x;
@@ -7,7 +9,10 @@ class Outer {
 
   // C++11 does relax this rule (see 5.1.1.10) in the first case, but we need 
to enforce it in C++03 mode.
   class Inner {
-static char a[sizeof(x)]; // expected-error {{invalid use of non-static 
data member 'x'}}
+static char a[sizeof(x)];
+#if __cplusplus <= 199711L
+// expected-error@-2 {{invalid use of non-static data member 'x'}}
+#endif
 static char b[sizeof(sx)]; // okay
 static char c[sizeof(f)]; // expected-error {{call to non-static member 
function without an object argument}}
   };

Modified: cfe/trunk/test/Parser/cxx-casting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/cxx-casting.cpp?rev=255196=255195=255196=diff
==
--- cfe/trunk/test/Parser/cxx-casting.cpp (original)
+++ cfe/trunk/test/Parser/cxx-casting.cpp Wed Dec  9 19:07:17 2015
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++98 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
 
 char *const_cast_test(const char *var)
 {
@@ -41,10 +43,25 @@ namespace test1 {
 typedef char* c;
 typedef A* a;
 void test2(char x, struct B * b) {
-  (void)const_cast<::c>();  // expected-error{{found '<::' after a 
const_cast which forms the digraph '<:' (aka '[') and a ':', did you mean '< 
::'?}}
-  (void)dynamic_cast<::a>(b);  // expected-error{{found '<::' after a 
dynamic_cast which forms the digraph '<:' (aka '[') and a ':', did you mean '< 
::'?}}
-  (void)reinterpret_cast<::c>(x);  // expected-error{{found '<::' after a 
reinterpret_cast which forms the digraph '<:' (aka '[') and a ':', did you mean 
'< ::'?}}
-  (void)static_cast<::c>();  // expected-error{{found '<::' after a 
static_cast which forms the digraph '<:' (aka '[') and a ':', did you mean '< 
::'?}}
+  (void)const_cast<::c>();
+#if __cplusplus <= 199711L
+  // expected-error@-2 {{found '<::' after a const_cast which forms the 
digraph '<:' (aka '[') and a ':', did you mean '< ::'?}}
+#endif
+
+  (void)dynamic_cast<::a>(b);
+#if __cplusplus <= 199711L
+  // expected-error@-2 {{found '<::' after a dynamic_cast which forms the 
digraph '<:' (aka '[') and a ':', did you mean '< ::'?}}
+#endif
+
+  (void)reinterpret_cast<::c>(x);
+#if __cplusplus <= 199711L
+  // expected-error@-2 {{found '<::' after a reinterpret_cast which forms the 
digraph '<:' (aka '[') and a ':', did you mean '< ::'?}}
+#endif
+
+  (void)static_cast<::c>();
+#if __cplusplus <= 199711L
+  // expected-error@-2 {{found '<::' after a static_cast which forms the 
digraph '<:' (aka '[') and a ':', did you mean '< ::'?}}
+#endif
 
   // Do not do digraph correction.
   (void)static_cast<: :c>(); //\
@@ -64,8 +81,15 @@ void test2(char x, struct B * b) {
   (void)static_cast<:C c>(); // expected-error {{expected '<' after 
'static_cast'}} expected-error 2{{}} expected-note{{}}
 
 #define LCC <::
-  test1::A LCC B> e; // expected-error{{found '<::' after a template name 
which forms the digraph '<:' (aka