Re: [PATCH] Ensure __va_list_tag has default visibility

[Stephan Bergmann]

ping

On 06/25/2014 05:45 PM, Stephan Bergmann wrote:

I stumbled across this on Linux with -fvisibility=hidden when
-fsanitize=function reported a false positive for an indirect call to a
function with a va_list (aka __builtin_va_list, aka __va_list_tag
(*)[1]) parameter.  Because __va_list_tag was considered hidden, the
RTTI for the function's type was not exported from the two shared
libraries involved, so the equality check failed.

This would apparently also need to be fixed in the other
Create*BuiltinVaListDecl variants, but I'm not sure (a) whether the
added const_cast is really deemed appropriate here (though I guess so,
given the large number of existing similar const_casts across
ASTContext.cpp), and (b) what the preferred way would be to break that
long line. ;)

Stephan


Index: lib/AST/ASTContext.cpp
===
--- lib/AST/ASTContext.cpp	(revision 211695)
+++ lib/AST/ASTContext.cpp	(working copy)
@@ -5916,6 +5916,7 @@
   RecordDecl *VaListTagDecl;
   VaListTagDecl = Context->buildImplicitRecord("__va_list_tag");
   VaListTagDecl->startDefinition();
+  VaListTagDecl->addAttr(TypeVisibilityAttr::CreateImplicit(const_cast(*Context), TypeVisibilityAttr::Default));
 
   const size_t NumFields = 4;
   QualType FieldTypes[NumFields];
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [AArch64] Implement Clang CLI interface proposal about "-march".

[Kevin Qin]

HI Eric,

Thanks for your feedback. Below is my comments.


2014-07-09 2:25 GMT+08:00 Eric Christopher :

> >> > 4. Implement support of "-mtune". Usage is: "-march=CPU_NAME". For
> >> > instance, "-march=cortex-a57". This option will ONLY get
> micro-architecture
> >> > level feature enabled specifying to target CPU, like "zcm" and "zcz"
> for
> >> > cyclone. Any architecture features WON'T be modified.
> >>
> >> That's not what -mtune is. According to GCC's manual: "Tune to
> >> cpu-type everything applicable about the generated code, except for
> >> the ABI and the set of available instructions."
> >>
> >> The difference between -mcup and -mtune is that the former selects ABI
> >> and ISAs supported by the CPU, while the former doesn't. This is
> >> particularly important if you want to run the code on a newer CPU but
> >> doesn't want to break older ones, so you can't use instructions that
> >> the old ones don't have, but you can optimise for the pipeline and
> >> branch decisions of the newer CPU, as long as it just slows down the
> >> older ones.
> >
> > I didn't explain it clearly. Your point is totally what I did in this
> patch.
> > I emphasize " ONLY get micro-architecture level feature enabled" is want
> to
> > say ISA won't be changed by this option. This option is to select target
> CPU
> > to optimize for, including enabling micro-architecture level feature,
> > choosing MI scheduler and triggering any optimizations specific for
> target.
> >>
> >>
> >>
> >> > 5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is
> an
> >> > alias to "-march={feature of CPU_NAME}+[no]feature" and
> "-mtune=CPU_NAME"
> >> > together. An warning is added to discourage use of this option.
> >>
> >> I find this one redundant with -march and don't think we should add
> >> deprecated features. -mcpu is the flag you want for the behaviour
> >> you've done -mtune above. AFAIK, we don't have the infrastructure to
> >> implement -mtune yet. Also, the driver is a bit bonkers when going
> >> from CPU to Arch from a different arch than the host without using
> >> -target (which is the point with -march, I guess).
> >>
> >> I don't think -mcpu should be used on its own, only in conjunction
> >> with -target or -march.
> >
> > In my patch, the difference between "-mcpu" and "-mtune" is that, "-mcpu"
> > will enable all ISAs which target CPU supports, while "-mtune" won't do
> > this. And "-mcpu" can accept extra feature modifiers to make a change,
> but
> > "-mtune" accepts CPU name only. So "-mcpu" is an shortcut of "-march" and
> > "-tune". Keeping this option alive in clang is because it's still alive
> in
> > gcc, and may still be used in many projects.  An warning is added to
> > discourage use of this option.
>
> This is fine, and I encourage the warning. Also, -march should
> probably default to -mtune of the same architecture. I didn't read to
> verify, but just making sure this is the case.
>
Currently, there's only one architecture available,  so -march will always
default to "armv8-a+neon". We can do further when there's more and more
architectures on AArch64 target.

>
> >>
> >>
> >>
> >>
> >> > 1. Neon is enabled by default, and "generic" will be used if no CPU
> type
> >> > is specified.
> >>
> >> Makes sense to me.
> >>
> >>
> >> > 2. For most scenario, Using "-mtune=CPU" only is recommended as neon
> is
> >> > enabled by default and all micro-architecture optimizations are
> selected,
> >> > and it would provide great compatibility to run on most of AArch64
> devices.
> >>
> >> That'd be -mcpu, and we still need -march or -target.
> >
> > "-target" is still necessary at moment while "-march" can be omitted
> > sometimes, because the settings of default feature can work well for most
> > scenarios and provide good code migration. All I want to do is to get
> > "-mcpu" supporter happy to use "-mtune" instead. They don't need to
> complain
> > typing too much as splitting "-mcpu" into "-march" and "-mtune" because
> they
> > can use "-mtune" only. For a standard sets of compiling flags, pair use
> of
> > "-march" and "-mtune" is strongly recommended.
>
> This seems to be a good idea. Can you give examples of behavior you're
> expecting to see just to verify?
>

Single use of "-target aarch64-linux-gnu" equals "-target aarch64-linux-gnu
-march=armv8-a+neon mtune=generic", which can provide correct codes but not
fully optimized.

"-target aarch64-linux-gnu -mtune=cortex-a57" euqals "-target
aarch64-linux-gnu -march=armv8-a+neon mtune=cortex-a57" ,which can work
quite well in most scenarios. NEON is enabled for vectorization and MI
scheduler is selected to optimize codes for cortex-a57. And it provides
good compatibility which allows binary running on most AArch64 devices as
it doesn't rely on any crc or crypto support. New starters of AArch64 can
easily start their project from these flags, and it is good enough for
experiment purpose for experienced developer.

If user wants to control more featu

r212589 - Fix typos.

[Nikola Smiljanic]

Author: nikola
Date: Wed Jul  9 00:42:35 2014
New Revision: 212589

URL: http://llvm.org/viewvc/llvm-project?rev=212589&view=rev
Log:
Fix typos.

Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=212589&r1=212588&r2=212589&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Wed Jul  9 00:42:35 2014
@@ -2103,7 +2103,7 @@ ExprResult Sema::ActOnIdExpression(Scope
 return E;
 }
 
-// Don't diagnose an empty lookup for inline assmebly.
+// Don't diagnose an empty lookup for inline assembly.
 if (IsInlineAsmIdentifier)
   return ExprError();
 

Modified: cfe/trunk/lib/Sema/SemaLookup.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLookup.cpp?rev=212589&r1=212588&r2=212589&view=diff
==
--- cfe/trunk/lib/Sema/SemaLookup.cpp (original)
+++ cfe/trunk/lib/Sema/SemaLookup.cpp Wed Jul  9 00:42:35 2014
@@ -1723,7 +1723,7 @@ bool Sema::LookupQualifiedName(LookupRes
  != Context.getCanonicalType(PathElement.Base->getType())) {
   // We found members of the given name in two subobjects of
   // different types. If the declaration sets aren't the same, this
-  // this lookup is ambiguous.
+  // lookup is ambiguous.
   if (HasOnlyStaticMembers(Path->Decls.begin(), Path->Decls.end())) {
 CXXBasePaths::paths_iterator FirstPath = Paths.begin();
 DeclContext::lookup_iterator FirstD = FirstPath->Decls.begin();


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Support constant expressions, including non-type template parameters, in pragma loop hints

[Tyler Nowicki]

Hi,

Thanks for all the feedback. I’ve applied your suggestions. Please see the 
attached patch.

I tried terminating the token list with EoF but it didn’t produce the desired 
result. I don’t know enough about parsing to even try to say what was 
happening. It seemed like something about the parsers state was messed up after 
the eof. Also I tried the example, vectorize_width(1+) 1 and it does seem to 
consume tokens past the end of the directive. Any ideas how I can fix this?

>> +bool Sema::DiagnoseLoopHintValue(Expr *ValueExpr) {
> 
> This should take a const Expr *.


Unfortunately VerifyIntegerConstantExpression() for getting the IntAPS of the 
expression doesn’t take a const Expr *, although I don’t think it modifies the 
result. So we have to pass in an Expr *.

>> +if (!R.isUsable()) {
>> +  Diag(Args[0].getLocation(), diag::err_pragma_loop_invalid_expression);
>> +  return LoopHint(); // Uninitialized loop hints are ignored.
>> +}
>> +
>> +QualType QT = R.get()->getType();
>> +if (!QT->isIntegerType() || QT->isBooleanType() || QT->isCharType()) {
> 
> Are char and bool types truly that heinous? (I agree they would look
> odd, but do they require restricting?). What about scoped
> enumerations?

I don’t like the idea of allowing statements like #pragma clang loop 
vectorize_width(‘A’) because it is unclear what we should do. What is an ‘A’ 
width? I’ve added a test for scoped enumerations.

> +  /// \brief Transform the given attribute.
> +  ///
> +  /// By default, this routine transforms a statement by delegating to the
> +  /// appropriate TransformXXXAttr function to transform a specific kind
> +  /// of attribute. Subclasses may override this function to transform
> +  /// attributed statements using some other mechanism.
> +  ///
> +  /// \returns the transformed attribute
> +  const Attr *TransformAttr(const Attr *S);
> 
> I don't like that this gives us two completely different ways to instantiate 
> attributes (TreeTransform::transformAttrs / Sema::InstantiateAttrs and this 
> new function). I'm OK with this as a stopgap measure if you're prepared to 
> clean this duplication up afterwards, but this is not reasonable as a 
> long-term situation.

Each is used for a different kind of attribute. Attributes on declaration and 
attributes on statements. Each attribute is handled in a completely different 
manner throughout clang. For example, statement attributes are stored in a 
wrapper called an AttributedStmt while declaration attributes are stored in a 
list that is mapped to the pointer of the Decl object.  I’m not sure why they 
are treated differently, but it would be a lot of work to unify them. There are 
currently only two statement attributes: loop hint and switch fallthrough.

> +  ValueInt = ValueAPS.getSExtValue();
> +}
> 
> What if the value doesn't fit in 64 bits? Asserting is not a friendly 
> response. Since you're looking for a 32-bit int anyway, maybe saturate at 
> 0xF’?

Not sure what you mean by saturate at 0xFF…? The loop hint metadata only takes 
a 32-bit value so we can’t support anything more than that. I added a condition 
on the value that it be represented with at most 32 bits. Otherwise an 
invalid_argument error will be triggered which uses a special print method to 
report the erroneous value. There is already a test for it.

Tyler



pragma_nontypetemplate-svn.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] CodeGen: Don't emit a thread-wrapper if we can't touch the backing variable

[David Majnemer]

  - Address review comments.
  - Give wrappers WeakAnyLinkage for WeakODRLinkage vars

http://reviews.llvm.org/D4109

Files:
  lib/CodeGen/ItaniumCXXABI.cpp
  test/CodeGenCXX/tls-init-funcs.cpp
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -1818,6 +1818,15 @@
   CGF.registerGlobalDtorWithAtExit(D, dtor, addr);
 }
 
+static bool isThreadWrapperReplaceable(const VarDecl *VD,
+   CodeGen::CodeGenModule &CGM) {
+  assert(!VD->isStaticLocal() && "static local VarDecls don't need wrappers!");
+  // OS X prefers to have references to thread local variables to go through
+  // the thread wrapper instead of directly referencing the backing variable.
+  return VD->getTLSKind() == VarDecl::TLS_Dynamic &&
+ CGM.getTarget().getTriple().isMacOSX();
+}
+
 /// Get the appropriate linkage for the wrapper function. This is essentially
 /// the weak form of the variable's linkage; every translation unit which needs
 /// the wrapper emits a copy, and we want the linker to merge them.
@@ -1830,12 +1839,15 @@
   if (llvm::GlobalValue::isLocalLinkage(VarLinkage))
 return VarLinkage;
 
-  // All accesses to the thread_local variable go through the thread wrapper.
-  // However, this means that we cannot allow the thread wrapper to get inlined
-  // into any functions.
-  if (VD->getTLSKind() == VarDecl::TLS_Dynamic &&
-  CGM.getTarget().getTriple().isMacOSX())
-return llvm::GlobalValue::WeakAnyLinkage;
+  // The thread wrapper can't be inlined if the backing variable cannot always
+  // be referenced.  However, the thread wrapper can be replaced by a different
+  // definition in another translation unit.
+  if (isThreadWrapperReplaceable(VD, CGM)) {
+if (llvm::GlobalVariable::isLinkOnceLinkage(VarLinkage) ||
+llvm::GlobalVariable::isWeakODRLinkage(VarLinkage))
+  return llvm::GlobalVariable::WeakAnyLinkage;
+return VarLinkage;
+  }
   return llvm::GlobalValue::WeakODRLinkage;
 }
 
@@ -1862,7 +1874,7 @@
   llvm::Function::Create(FnTy, getThreadLocalWrapperLinkage(VD, CGM),
  WrapperName.str(), &CGM.getModule());
   // Always resolve references to the wrapper at link time.
-  if (!Wrapper->hasLocalLinkage())
+  if (!Wrapper->hasLocalLinkage() && !isThreadWrapperReplaceable(VD, CGM))
 Wrapper->setVisibility(llvm::GlobalValue::HiddenVisibility);
   return Wrapper;
 }
@@ -1874,6 +1886,12 @@
 const VarDecl *VD = Decls[I].first;
 llvm::GlobalVariable *Var = Decls[I].second;
 
+// Some targets require that all access to thread local variables go through
+// the thread wrapper.  This means that we cannot attempt to create a thread
+// wrapper or a thread helper.
+if (isThreadWrapperReplaceable(VD, CGM) && !VD->hasDefinition())
+  continue;
+
 // Mangle the name for the thread_local initialization function.
 SmallString<256> InitFnName;
 {
Index: test/CodeGenCXX/tls-init-funcs.cpp
===
--- test/CodeGenCXX/tls-init-funcs.cpp
+++ test/CodeGenCXX/tls-init-funcs.cpp
@@ -1,11 +1,34 @@
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.8 -std=c++11 -S -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.8 -std=c++1y -S -emit-llvm %s -o - | FileCheck %s
 
 // CHECK: @a = internal thread_local global
+// CHECK: @_Z2vtIiE = internal thread_local global i32 5
+// CHECK: @_ZZ3inlvE3loc = linkonce_odr thread_local global i32 0
 // CHECK: @_tlv_atexit({{.*}}@_ZN1AD1Ev
-// CHECK: define weak hidden {{.*}} @_ZTW1a
+// CHECK: call i32* @_ZTW3ext()
+// CHECK: declare i32* @_ZTW3ext()
+// CHECK: define weak i32* @_ZTW2vtIiE()
+// CHECK: define weak i32* @_ZTW2vtIvE()
+// CHECK: define {{.*}} @_ZTW1a
 
 struct A {
   ~A();
 };
 
 thread_local A a;
+
+extern thread_local int ext;
+int &get_ext() { return ext; }
+
+template 
+thread_local int vt = 5;
+
+int get_vt() { return vt; }
+
+inline int &inl() {
+  thread_local int loc;
+  return loc;
+}
+int &use_inl() { return inl(); }
+
+template int vt;
+int &get_vt_void() { return vt; }
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212585 - clang-interpreter: don't check input file existence, we're in-process

[Alp Toker]

Author: alp
Date: Tue Jul  8 20:37:36 2014
New Revision: 212585

URL: http://llvm.org/viewvc/llvm-project?rev=212585&view=rev
Log:
clang-interpreter: don't check input file existence, we're in-process

This flag is set by most other tools and avoids extra stat() calls. The
frontend will diagnose anyway as it performs the check atomically while opening
files at point of use.

We could probably make Driver::CheckInputsExist default to false and only
enable it in the main 'clang' binary, or even better only perform the checks if
we know the tool is external but that needs more thought.

Modified:
cfe/trunk/examples/clang-interpreter/main.cpp

Modified: cfe/trunk/examples/clang-interpreter/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/examples/clang-interpreter/main.cpp?rev=212585&r1=212584&r2=212585&view=diff
==
--- cfe/trunk/examples/clang-interpreter/main.cpp (original)
+++ cfe/trunk/examples/clang-interpreter/main.cpp Tue Jul  8 20:37:36 2014
@@ -77,6 +77,7 @@ int main(int argc, const char **argv, ch
   DiagnosticsEngine Diags(DiagID, &*DiagOpts, DiagClient);
   Driver TheDriver(Path, llvm::sys::getProcessTriple(), Diags);
   TheDriver.setTitle("clang interpreter");
+  TheDriver.setCheckInputsExist(false);
 
   // FIXME: This is a hack to try to force the driver to do something we can
   // recognize. We need to extend the driver library to support this use model


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212584 - Simplify warning flag value handling from r206826

[Alp Toker]

Author: alp
Date: Tue Jul  8 20:37:24 2014
New Revision: 212584

URL: http://llvm.org/viewvc/llvm-project?rev=212584&view=rev
Log:
Simplify warning flag value handling from r206826

Also give the field it a more appropriate name and improve the docs.

Modified:
cfe/trunk/include/clang/Basic/Diagnostic.h
cfe/trunk/lib/Frontend/TextDiagnosticPrinter.cpp

Modified: cfe/trunk/include/clang/Basic/Diagnostic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diagnostic.h?rev=212584&r1=212583&r2=212584&view=diff
==
--- cfe/trunk/include/clang/Basic/Diagnostic.h (original)
+++ cfe/trunk/include/clang/Basic/Diagnostic.h Tue Jul  8 20:37:24 2014
@@ -335,13 +335,12 @@ private:
   /// \brief Second string argument for the delayed diagnostic.
   std::string DelayedDiagArg2;
 
-  /// \brief Flag name value.
+  /// \brief Optional flag value.
   ///
-  /// Some flags accept values. For instance, -Wframe-larger-than or -Rpass.
-  /// When reporting a diagnostic with those flags, it is useful to also
-  /// report the value that actually triggered the flag. The content of this
-  /// string is a value to be emitted after the flag name.
-  std::string FlagNameValue;
+  /// Some flags accept values, for instance: -Wframe-larger-than= and
+  /// -Rpass=. The content of this string is emitted after the flag name
+  /// and '='.
+  std::string FlagValue;
 
 public:
   explicit DiagnosticsEngine(
@@ -703,11 +702,8 @@ public:
   /// \brief Clear out the current diagnostic.
   void Clear() { CurDiagID = ~0U; }
 
-  /// \brief Return the value associated to this diagnostic flag.
-  StringRef getFlagNameValue() const { return StringRef(FlagNameValue); }
-
-  /// \brief Set the value associated to this diagnostic flag.
-  void setFlagNameValue(StringRef V) { FlagNameValue = V; }
+  /// \brief Return the value associated with this diagnostic flag.
+  StringRef getFlagValue() const { return FlagValue; }
 
 private:
   /// \brief Report the delayed diagnostic.
@@ -997,7 +993,7 @@ public:
 DiagObj->DiagFixItHints.push_back(Hint);
   }
 
-  void addFlagValue(StringRef V) const { DiagObj->setFlagNameValue(V); }
+  void addFlagValue(StringRef V) const { DiagObj->FlagValue = V; }
 };
 
 struct AddFlagValue {
@@ -1108,7 +1104,7 @@ inline DiagnosticBuilder DiagnosticsEngi
   assert(CurDiagID == ~0U && "Multiple diagnostics in flight at once!");
   CurDiagLoc = Loc;
   CurDiagID = DiagID;
-  FlagNameValue.clear();
+  FlagValue.clear();
   return DiagnosticBuilder(this);
 }
 

Modified: cfe/trunk/lib/Frontend/TextDiagnosticPrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/TextDiagnosticPrinter.cpp?rev=212584&r1=212583&r2=212584&view=diff
==
--- cfe/trunk/lib/Frontend/TextDiagnosticPrinter.cpp (original)
+++ cfe/trunk/lib/Frontend/TextDiagnosticPrinter.cpp Tue Jul  8 20:37:24 2014
@@ -83,7 +83,7 @@ static void printDiagnosticOptions(raw_o
 if (!Opt.empty()) {
   OS << (Started ? "," : " [")
  << (Level == DiagnosticsEngine::Remark ? "-R" : "-W") << Opt;
-  StringRef OptValue = Info.getDiags()->getFlagNameValue();
+  StringRef OptValue = Info.getDiags()->getFlagValue();
   if (!OptValue.empty())
 OS << "=" << OptValue;
   Started = true;


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Avoid referencing a vtable when not required

[Nico Weber]

(fixes PR20221)

http://reviews.llvm.org/D4429



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Avoid referencing a vtable when not required

[Nico Weber]

(fixes PR20221)


On Tue, Jul 8, 2014 at 6:19 PM, Reid Kleckner  wrote:

> Hi rsmith,
>
> This fixes compilation errors about incomplete types used with WebKit's
> RefPtr template.  Simply an out of line constructor should not
> instantiate all inline and defaulted virtual methods.
>
> http://reviews.llvm.org/D4429
>
> Files:
>   lib/Sema/SemaExpr.cpp
>   test/SemaTemplate/virtual-member-functions.cpp
>
> Index: lib/Sema/SemaExpr.cpp
> ===
> --- lib/Sema/SemaExpr.cpp
> +++ lib/Sema/SemaExpr.cpp
> @@ -11445,8 +11445,6 @@
>  } else if (Constructor->getInheritedConstructor()) {
>DefineInheritingConstructor(Loc, Constructor);
>  }
> -
> -MarkVTableUsed(Loc, Constructor->getParent());
>} else if (CXXDestructorDecl *Destructor =
>   dyn_cast(Func)) {
>  Destructor = cast(Destructor->getFirstDecl());
> Index: test/SemaTemplate/virtual-member-functions.cpp
> ===
> --- test/SemaTemplate/virtual-member-functions.cpp
> +++ test/SemaTemplate/virtual-member-functions.cpp
> @@ -44,16 +44,16 @@
>
>  template
>  struct HasOutOfLineKey {
> -  HasOutOfLineKey() { }
> +  HasOutOfLineKey() { } // expected-note{{in instantiation of member
> function 'HasOutOfLineKey::f' requested here}}
>virtual T *f(float *fp);
>  };
>
>  template
>  T *HasOutOfLineKey::f(float *fp) {
>return fp; // expected-error{{cannot initialize return object of type
> 'int *' with an lvalue of type 'float *'}}
>  }
>
> -HasOutOfLineKey out_of_line; // expected-note{{in instantiation of
> member function 'HasOutOfLineKey::f' requested here}}
> +HasOutOfLineKey out_of_line; // expected-note{{in instantiation of
> member function 'HasOutOfLineKey::HasOutOfLineKey' requested here}}
>
>  namespace std {
>class type_info;
> @@ -102,3 +102,53 @@
>Y* f(X* x) { return dynamic_cast(x); } // expected-note {{in
> instantiation of member function 'DynamicCast::X::foo' requested
> here}}
>Y* f2(X* x) { return dynamic_cast(x); }
>  }
> +
> +namespace avoid_using_vtable {
> +// We shouldn't emit the vtable for this code, in any ABI.  If we emit the
> +// vtable, we emit an implicit virtual dtor, which calls ~RefPtr, which
> requires
> +// a complete type for DeclaredOnly.
> +//
> +// Previously we would reference the vtable in the MS C++ ABI, even
> though we
> +// don't need to emit either the ctor or the dtor.  In the Itanium C++
> ABI, the
> +// 'trace' method is the key function, so even though we use the vtable,
> we
> +// don't emit it.
> +
> +template 
> +struct RefPtr {
> +  T *m_ptr;
> +  ~RefPtr() { m_ptr->deref(); }
> +};
> +struct DeclaredOnly;
> +struct Base {
> +  virtual ~Base();
> +};
> +
> +struct AvoidVTable : Base {
> +  RefPtr m_insertionStyle;
> +  virtual void trace();
> +  AvoidVTable();
> +};
> +// Don't call the dtor, because that will emit an implicit dtor, and
> require a
> +// complete type for DeclaredOnly.
> +void foo() { new AvoidVTable; }
> +}
> +
> +namespace vtable_uses_incomplete {
> +// Opposite of the previous test that avoids a vtable, this one tests
> that we
> +// use the vtable when the ctor is defined inline.
> +template 
> +struct RefPtr {
> +  T *m_ptr;
> +  ~RefPtr() { m_ptr->deref(); }  // expected-error {{member access into
> incomplete type 'vtable_uses_incomplete::DeclaredOnly'}}
> +};
> +struct DeclaredOnly; // expected-note {{forward declaration of
> 'vtable_uses_incomplete::DeclaredOnly'}}
> +struct Base {
> +  virtual ~Base();
> +};
> +
> +struct UsesVTable : Base {
> +  RefPtr m_insertionStyle;
> +  virtual void trace();
> +  UsesVTable() {} // expected-note {{in instantiation of member function
> 'vtable_uses_incomplete::RefPtr::~RefPtr'
> requested here}}
> +};
> +}
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r212499 - [Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule

[Alexey Samsonov]

On Tue, Jul 8, 2014 at 5:45 PM, Richard Smith  wrote:

> On Mon, Jul 7, 2014 at 4:34 PM, Alexey Samsonov 
> wrote:
>
>> Author: samsonov
>> Date: Mon Jul  7 18:34:34 2014
>> New Revision: 212499
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=212499&view=rev
>> Log:
>> [Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule
>>
>> Get rid of cached CodeGenModule::SanOpts, which was used to turn off
>> sanitizer codegen options if current LLVM Module is blacklisted, and use
>> plain LangOpts.Sanitize instead.
>>
>> 1) Some codegen decisions (turning TBAA or writable strings on/off)
>>shouldn't depend on the contents of blacklist.
>>
>> 2) llvm.asan.globals should *always* be created, even if the module
>>is blacklisted - soon Clang's CodeGen where we read sanitizer
>>blacklist files, so we should properly report which globals are
>>blacklisted to the backend.
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.h
>> cfe/trunk/test/CodeGen/asan-globals.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=212499&r1=212498&r2=212499&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Mon Jul  7 18:34:34 2014
>> @@ -245,12 +245,14 @@ CreateGlobalInitOrDestructFunction(CodeG
>>if (!CGM.getLangOpts().Exceptions)
>>  Fn->setDoesNotThrow();
>>
>> -  if (CGM.getSanOpts().Address)
>> -Fn->addFnAttr(llvm::Attribute::SanitizeAddress);
>> -  if (CGM.getSanOpts().Thread)
>> -Fn->addFnAttr(llvm::Attribute::SanitizeThread);
>> -  if (CGM.getSanOpts().Memory)
>> -Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
>> +  if (!CGM.getSanitizerBlacklist().isIn(*Fn)) {
>> +if (CGM.getLangOpts().Sanitize.Address)
>> +  Fn->addFnAttr(llvm::Attribute::SanitizeAddress);
>> +if (CGM.getLangOpts().Sanitize.Thread)
>> +  Fn->addFnAttr(llvm::Attribute::SanitizeThread);
>> +if (CGM.getLangOpts().Sanitize.Memory)
>> +  Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
>> +  }
>>
>>return Fn;
>>  }
>>
>> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=212499&r1=212498&r2=212499&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Jul  7 18:34:34 2014
>> @@ -89,9 +89,7 @@ CodeGenModule::CodeGenModule(ASTContext
>>GenericBlockLiteralType(nullptr), LifetimeStartFn(nullptr),
>>LifetimeEndFn(nullptr),
>>SanitizerBlacklist(
>> -
>>  llvm::SpecialCaseList::createOrDie(CGO.SanitizerBlacklistFile)),
>> -  SanOpts(SanitizerBlacklist->isIn(M) ? SanitizerOptions::Disabled
>> -  : LangOpts.Sanitize) {
>> +
>>  llvm::SpecialCaseList::createOrDie(CGO.SanitizerBlacklistFile)) {
>>
>>// Initialize the type cache.
>>llvm::LLVMContext &LLVMContext = M.getContext();
>> @@ -122,7 +120,7 @@ CodeGenModule::CodeGenModule(ASTContext
>>  createCUDARuntime();
>>
>>// Enable TBAA unless it's suppressed. ThreadSanitizer needs TBAA even
>> at O0.
>> -  if (SanOpts.Thread ||
>> +  if (LangOpts.Sanitize.Thread ||
>>(!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel >
>> 0))
>>  TBAA = new CodeGenTBAA(Context, VMContext, CodeGenOpts,
>> getLangOpts(),
>> getCXXABI().getMangleContext());
>> @@ -735,14 +733,13 @@ void CodeGenModule::SetLLVMFunctionAttri
>>if (!SanitizerBlacklist->isIn(*F)) {
>>  // When AddressSanitizer is enabled, set SanitizeAddress attribute
>>  // unless __attribute__((no_sanitize_address)) is used.
>> -if (SanOpts.Address && !D->hasAttr())
>> +if (LangOpts.Sanitize.Address &&
>> !D->hasAttr())
>>B.addAttribute(llvm::Attribute::SanitizeAddress);
>>
>
> Should this be set if the module is blacklisted? (Likewise for tsan and
> msan attributes.)
>

Currently SanitizerBlacklist::isIn(llvm::Function *F) returns true if
function or the module it is located in
is blacklisted. So, we won't set sanitize_address if module is blacklisted,
as expected.


>
>  // Same for ThreadSanitizer and __attribute__((no_sanitize_thread))
>> -if (SanOpts.Thread && !D->hasAttr()) {
>> +if (LangOpts.Sanitize.Thread && !D->hasAttr())
>>B.addAttribute(llvm::Attribute::SanitizeThread);
>> -}
>>  // Same for MemorySanitizer and __attribute__((no_sanitize_memory))
>> -if (SanOpts.Memory && !D->hasAttr())
>> +if (LangOpts.Sanitize.Memory && !D->hasAttr())
>>B.addAttribute(llvm::Attribute::SanitizeMemory);
>>}
>>
>> @@ -1966,7 +1963,7 @@ void 

[PATCH] Avoid referencing a vtable when not required

[Reid Kleckner]

Hi rsmith,

This fixes compilation errors about incomplete types used with WebKit's
RefPtr template.  Simply an out of line constructor should not
instantiate all inline and defaulted virtual methods.

http://reviews.llvm.org/D4429

Files:
  lib/Sema/SemaExpr.cpp
  test/SemaTemplate/virtual-member-functions.cpp

Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -11445,8 +11445,6 @@
 } else if (Constructor->getInheritedConstructor()) {
   DefineInheritingConstructor(Loc, Constructor);
 }
-
-MarkVTableUsed(Loc, Constructor->getParent());
   } else if (CXXDestructorDecl *Destructor =
  dyn_cast(Func)) {
 Destructor = cast(Destructor->getFirstDecl());
Index: test/SemaTemplate/virtual-member-functions.cpp
===
--- test/SemaTemplate/virtual-member-functions.cpp
+++ test/SemaTemplate/virtual-member-functions.cpp
@@ -44,16 +44,16 @@
 
 template
 struct HasOutOfLineKey {
-  HasOutOfLineKey() { } 
+  HasOutOfLineKey() { } // expected-note{{in instantiation of member function 
'HasOutOfLineKey::f' requested here}}
   virtual T *f(float *fp);
 };
 
 template
 T *HasOutOfLineKey::f(float *fp) {
   return fp; // expected-error{{cannot initialize return object of type 'int 
*' with an lvalue of type 'float *'}}
 }
 
-HasOutOfLineKey out_of_line; // expected-note{{in instantiation of member 
function 'HasOutOfLineKey::f' requested here}}
+HasOutOfLineKey out_of_line; // expected-note{{in instantiation of member 
function 'HasOutOfLineKey::HasOutOfLineKey' requested here}}
 
 namespace std {
   class type_info;
@@ -102,3 +102,53 @@
   Y* f(X* x) { return dynamic_cast(x); } // expected-note {{in 
instantiation of member function 'DynamicCast::X::foo' requested here}}
   Y* f2(X* x) { return dynamic_cast(x); }
 }
+
+namespace avoid_using_vtable {
+// We shouldn't emit the vtable for this code, in any ABI.  If we emit the
+// vtable, we emit an implicit virtual dtor, which calls ~RefPtr, which 
requires
+// a complete type for DeclaredOnly.
+//
+// Previously we would reference the vtable in the MS C++ ABI, even though we
+// don't need to emit either the ctor or the dtor.  In the Itanium C++ ABI, the
+// 'trace' method is the key function, so even though we use the vtable, we
+// don't emit it.
+
+template 
+struct RefPtr {
+  T *m_ptr;
+  ~RefPtr() { m_ptr->deref(); }
+};
+struct DeclaredOnly;
+struct Base {
+  virtual ~Base();
+};
+
+struct AvoidVTable : Base {
+  RefPtr m_insertionStyle;
+  virtual void trace();
+  AvoidVTable();
+};
+// Don't call the dtor, because that will emit an implicit dtor, and require a
+// complete type for DeclaredOnly.
+void foo() { new AvoidVTable; }
+}
+
+namespace vtable_uses_incomplete {
+// Opposite of the previous test that avoids a vtable, this one tests that we
+// use the vtable when the ctor is defined inline.
+template 
+struct RefPtr {
+  T *m_ptr;
+  ~RefPtr() { m_ptr->deref(); }  // expected-error {{member access into 
incomplete type 'vtable_uses_incomplete::DeclaredOnly'}}
+};
+struct DeclaredOnly; // expected-note {{forward declaration of 
'vtable_uses_incomplete::DeclaredOnly'}}
+struct Base {
+  virtual ~Base();
+};
+
+struct UsesVTable : Base {
+  RefPtr m_insertionStyle;
+  virtual void trace();
+  UsesVTable() {} // expected-note {{in instantiation of member function 
'vtable_uses_incomplete::RefPtr::~RefPtr' 
requested here}}
+};
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -11445,8 +11445,6 @@
 } else if (Constructor->getInheritedConstructor()) {
   DefineInheritingConstructor(Loc, Constructor);
 }
-
-MarkVTableUsed(Loc, Constructor->getParent());
   } else if (CXXDestructorDecl *Destructor =
  dyn_cast(Func)) {
 Destructor = cast(Destructor->getFirstDecl());
Index: test/SemaTemplate/virtual-member-functions.cpp
===
--- test/SemaTemplate/virtual-member-functions.cpp
+++ test/SemaTemplate/virtual-member-functions.cpp
@@ -44,16 +44,16 @@
 
 template
 struct HasOutOfLineKey {
-  HasOutOfLineKey() { } 
+  HasOutOfLineKey() { } // expected-note{{in instantiation of member function 'HasOutOfLineKey::f' requested here}}
   virtual T *f(float *fp);
 };
 
 template
 T *HasOutOfLineKey::f(float *fp) {
   return fp; // expected-error{{cannot initialize return object of type 'int *' with an lvalue of type 'float *'}}
 }
 
-HasOutOfLineKey out_of_line; // expected-note{{in instantiation of member function 'HasOutOfLineKey::f' requested here}}
+HasOutOfLineKey out_of_line; // expected-note{{in instantiation of member function 'HasOutOfLineKey::HasOutOfLineKey' requested here}}
 
 namespace std {
   class type_info;
@@ -102,3 +102,53 @@
   Y* f(X* x) { return dynamic_cast(x); } // 

Re: [PATCH] CodeGen: Don't emit a thread-wrapper if we can't touch the backing variable

[Richard Smith]

Comment at: lib/CodeGen/ItaniumCXXABI.cpp:1846-1848
@@ +1845,5 @@
+  if (isThreadWrapperReplaceable(VD, CGM)) {
+if (llvm::GlobalVariable::isLinkOnceLinkage(VarLinkage))
+  return llvm::GlobalVariable::WeakAnyLinkage;
+return VarLinkage;
+  }

I think you should also give a `WeakODRLinkage` variable a `WeakAnyLinkage` 
wrapper.

http://reviews.llvm.org/D4109



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r212499 - [Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule

[Richard Smith]

On Mon, Jul 7, 2014 at 4:34 PM, Alexey Samsonov  wrote:

> Author: samsonov
> Date: Mon Jul  7 18:34:34 2014
> New Revision: 212499
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212499&view=rev
> Log:
> [Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule
>
> Get rid of cached CodeGenModule::SanOpts, which was used to turn off
> sanitizer codegen options if current LLVM Module is blacklisted, and use
> plain LangOpts.Sanitize instead.
>
> 1) Some codegen decisions (turning TBAA or writable strings on/off)
>shouldn't depend on the contents of blacklist.
>
> 2) llvm.asan.globals should *always* be created, even if the module
>is blacklisted - soon Clang's CodeGen where we read sanitizer
>blacklist files, so we should properly report which globals are
>blacklisted to the backend.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.h
> cfe/trunk/test/CodeGen/asan-globals.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=212499&r1=212498&r2=212499&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Mon Jul  7 18:34:34 2014
> @@ -245,12 +245,14 @@ CreateGlobalInitOrDestructFunction(CodeG
>if (!CGM.getLangOpts().Exceptions)
>  Fn->setDoesNotThrow();
>
> -  if (CGM.getSanOpts().Address)
> -Fn->addFnAttr(llvm::Attribute::SanitizeAddress);
> -  if (CGM.getSanOpts().Thread)
> -Fn->addFnAttr(llvm::Attribute::SanitizeThread);
> -  if (CGM.getSanOpts().Memory)
> -Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
> +  if (!CGM.getSanitizerBlacklist().isIn(*Fn)) {
> +if (CGM.getLangOpts().Sanitize.Address)
> +  Fn->addFnAttr(llvm::Attribute::SanitizeAddress);
> +if (CGM.getLangOpts().Sanitize.Thread)
> +  Fn->addFnAttr(llvm::Attribute::SanitizeThread);
> +if (CGM.getLangOpts().Sanitize.Memory)
> +  Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
> +  }
>
>return Fn;
>  }
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=212499&r1=212498&r2=212499&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Jul  7 18:34:34 2014
> @@ -89,9 +89,7 @@ CodeGenModule::CodeGenModule(ASTContext
>GenericBlockLiteralType(nullptr), LifetimeStartFn(nullptr),
>LifetimeEndFn(nullptr),
>SanitizerBlacklist(
> -  llvm::SpecialCaseList::createOrDie(CGO.SanitizerBlacklistFile)),
> -  SanOpts(SanitizerBlacklist->isIn(M) ? SanitizerOptions::Disabled
> -  : LangOpts.Sanitize) {
> +  llvm::SpecialCaseList::createOrDie(CGO.SanitizerBlacklistFile))
> {
>
>// Initialize the type cache.
>llvm::LLVMContext &LLVMContext = M.getContext();
> @@ -122,7 +120,7 @@ CodeGenModule::CodeGenModule(ASTContext
>  createCUDARuntime();
>
>// Enable TBAA unless it's suppressed. ThreadSanitizer needs TBAA even
> at O0.
> -  if (SanOpts.Thread ||
> +  if (LangOpts.Sanitize.Thread ||
>(!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0))
>  TBAA = new CodeGenTBAA(Context, VMContext, CodeGenOpts, getLangOpts(),
> getCXXABI().getMangleContext());
> @@ -735,14 +733,13 @@ void CodeGenModule::SetLLVMFunctionAttri
>if (!SanitizerBlacklist->isIn(*F)) {
>  // When AddressSanitizer is enabled, set SanitizeAddress attribute
>  // unless __attribute__((no_sanitize_address)) is used.
> -if (SanOpts.Address && !D->hasAttr())
> +if (LangOpts.Sanitize.Address && !D->hasAttr())
>B.addAttribute(llvm::Attribute::SanitizeAddress);
>

Should this be set if the module is blacklisted? (Likewise for tsan and
msan attributes.)

 // Same for ThreadSanitizer and __attribute__((no_sanitize_thread))
> -if (SanOpts.Thread && !D->hasAttr()) {
> +if (LangOpts.Sanitize.Thread && !D->hasAttr())
>B.addAttribute(llvm::Attribute::SanitizeThread);
> -}
>  // Same for MemorySanitizer and __attribute__((no_sanitize_memory))
> -if (SanOpts.Memory && !D->hasAttr())
> +if (LangOpts.Sanitize.Memory && !D->hasAttr())
>B.addAttribute(llvm::Attribute::SanitizeMemory);
>}
>
> @@ -1966,7 +1963,7 @@ void CodeGenModule::EmitGlobalVarDefinit
>
>  void CodeGenModule::reportGlobalToASan(llvm::GlobalVariable *GV,
> SourceLocation Loc, bool
> IsDynInit) {
> -  if (!SanOpts.Address)
> +  if (!LangOpts.Sanitize.Address)
>  return;
>IsDynInit &= !SanitizerBlacklist->isIn(*GV, "init");
>bool IsBlacklisted = SanitizerBlacklist->

[PATCH] clang-cl: Store the linker options for the ASAN runtime libraries in the obj files as opposed to pass it to the linker on the command line

[Ehsan Akhgari]

Hi rnk,

This enables using  to compile the code and then
link it using link.exe directly without invoking the linker through clang-cl.
It should hopefully make it easier for projects that don't use the compiler
to invoke the linker to use ASAN.

http://reviews.llvm.org/D4428

Files:
  lib/Driver/Tools.cpp
  test/Driver/cl-link.c
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -4389,6 +4389,17 @@
   return EH;
 }
 
+static void addSanitizerRTDependentLib(const ToolChain &TC, const ArgList &Args,
+   ArgStringList &CmdArgs,
+   const StringRef RTName) {
+  SmallString<128> LibSanitizer(getCompilerRTLibDir(TC));
+  llvm::sys::path::append(LibSanitizer,
+  Twine("clang_rt.") + RTName + ".lib");
+  SmallString<128> ArgStr("--dependent-lib=");
+  ArgStr.append(LibSanitizer);
+  CmdArgs.push_back(Args.MakeArgString(ArgStr));
+}
+
 void Clang::AddClangCLArgs(const ArgList &Args, ArgStringList &CmdArgs) const {
   unsigned RTOptionID = options::OPT__SLASH_MT;
 
@@ -4400,6 +4411,17 @@
   if (Arg *A = Args.getLastArg(options::OPT__SLASH_M_Group))
 RTOptionID = A->getOption().getID();
 
+  if (getToolChain().getSanitizerArgs().needsAsanRt()) {
+// FIXME: Handle 64-bit.
+bool DLL = Args.hasArg(options::OPT__SLASH_LD, options::OPT__SLASH_LDd);
+if (DLL) {
+  addSanitizerRTDependentLib(getToolChain(), Args, CmdArgs, "asan_dll_thunk-i386");
+} else {
+  addSanitizerRTDependentLib(getToolChain(), Args, CmdArgs, "asan-i386");
+  addSanitizerRTDependentLib(getToolChain(), Args, CmdArgs, "asan_cxx-i386");
+}
+  }
+
   switch(RTOptionID) {
 case options::OPT__SLASH_MD:
   if (Args.hasArg(options::OPT__SLASH_LDd))
@@ -7557,15 +7579,6 @@
   C.addCommand(new Command(JA, *this, Exec, CmdArgs));
 }
 
-static void addSanitizerRTWindows(const ToolChain &TC, const ArgList &Args,
-  ArgStringList &CmdArgs,
-  const StringRef RTName) {
-  SmallString<128> LibSanitizer(getCompilerRTLibDir(TC));
-  llvm::sys::path::append(LibSanitizer,
-  Twine("clang_rt.") + RTName + ".lib");
-  CmdArgs.push_back(Args.MakeArgString(LibSanitizer));
-}
-
 void visualstudio::Link::ConstructJob(Compilation &C, const JobAction &JA,
   const InputInfo &Output,
   const InputInfoList &Inputs,
@@ -7606,14 +7619,6 @@
   if (getToolChain().getSanitizerArgs().needsAsanRt()) {
 CmdArgs.push_back(Args.MakeArgString("-debug"));
 CmdArgs.push_back(Args.MakeArgString("-incremental:no"));
-// FIXME: Handle 64-bit.
-if (DLL) {
-  addSanitizerRTWindows(getToolChain(), Args, CmdArgs,
-"asan_dll_thunk-i386");
-} else {
-  addSanitizerRTWindows(getToolChain(), Args, CmdArgs, "asan-i386");
-  addSanitizerRTWindows(getToolChain(), Args, CmdArgs, "asan_cxx-i386");
-}
   }
 
   Args.AddAllArgValues(CmdArgs, options::OPT_l);
Index: test/Driver/cl-link.c
===
--- test/Driver/cl-link.c
+++ test/Driver/cl-link.c
@@ -12,11 +12,12 @@
 // LINK: "baz"
 
 // RUN: %clang_cl /Tc%s -### -fsanitize=address 2>&1 | FileCheck --check-prefix=ASAN %s
+// ASAN: "--dependent-lib={{.*}}clang_rt.asan-i386.lib"
+// ASAN: "--dependent-lib={{.*}}clang_rt.asan_cxx-i386.lib"
 // ASAN: link.exe
 // ASAN: "-debug"
 // ASAN: "-incremental:no"
-// ASAN: "{{.*}}clang_rt.asan-i386.lib"
-// ASAN: "{{.*}}clang_rt.asan_cxx-i386.lib"
+// ASAN-NOT: .lib
 // ASAN: "{{.*}}cl-link{{.*}}.obj"
 
 // RUN: %clang_cl /LD -### /Tc%s 2>&1 | FileCheck --check-prefix=DLL %s
@@ -26,11 +27,12 @@
 
 // RUN: %clang_cl /LD /Tc%s -### -fsanitize=address 2>&1 | FileCheck --check-prefix=ASAN-DLL %s
 // RUN: %clang_cl /LDd /Tc%s -### -fsanitize=address 2>&1 | FileCheck --check-prefix=ASAN-DLL %s
+// ASAN-DLL: "--dependent-lib={{.*}}clang_rt.asan_dll_thunk-i386.lib"
 // ASAN-DLL: link.exe
 // ASAN-DLL: "-dll"
 // ASAN-DLL: "-debug"
 // ASAN-DLL: "-incremental:no"
-// ASAN-DLL: "{{.*}}clang_rt.asan_dll_thunk-i386.lib"
+// ASAN-DLL-NOT: .lib
 // ASAN-DLL: "{{.*}}cl-link{{.*}}.obj"
 
 // RUN: %clang_cl /Zi /Tc%s -### 2>&1 | FileCheck --check-prefix=DEBUG %s
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH v2 2/9] Add the initial TypoExpr AST node for delayed typo correction.

[Richard Smith]

On Mon, Jul 7, 2014 at 3:38 PM, Kaelyn Takata  wrote:

> On Fri, Jun 27, 2014 at 10:42 AM, Kaelyn Takata  wrote:
>
>> On Fri, Jun 27, 2014 at 7:31 AM, Richard Smith 
>> wrote:
>>
>>> +  TypoExpr(std::unique_ptr TCC,
>>> +   std::unique_ptr TDG);
>>> +  child_range children() { return child_range(); }
>>> +  SourceLocation getLocStart() const LLVM_READONLY { return
>>> SourceLocation(); }
>>> +  SourceLocation getLocEnd() const LLVM_READONLY { return
>>> SourceLocation(); }
>>> +
>>> +  std::unique_ptr Consumer;
>>> +  std::unique_ptr DiagHandler;
>>>
>>> These unique_ptrs will be leaked; AST nodes don't get destroyed. Please
>>> allocate your handlers on the ASTContext instead.
>>>
>>
>> Well @#$%. I'm assuming that allocating these on the ASTContext would
>> mean calling e.g. "new (SemaRef.Context) TypoCorrectionConsumer(...)"
>> instead of "llvm::make_unique(...)" and passing
>> around raw pointers instead of unique_ptrs?
>>
> ping 
>

Yes, that's exactly what I had in mind.


>>
>>>
>>> +TypoExpr::TypoExpr(std::unique_ptr TCC,
>>> +   std::unique_ptr TDG)
>>> +: Expr(TypoExprClass, TCC->getContext().DependentTy, VK_LValue,
>>> OK_Ordinary,
>>> +   /*isTypeDependent*/ true,
>>> +   /*isValueDependent*/ true,
>>> +   /*isInstantiationDependent*/ true,
>>> +   /*containsUnexpandedParameterPack*/ false),
>>>
>>> Hmm, parameter packs are an interesting twist on this. Suppose we have:
>>>
>>>   template void f(Thing ...thing) { g(rhing...); }
>>>
>>> if we set containsUnexpandedParameterPack to false, we'll reject this in
>>> the initial parse. If we set it to true, we'll reject other stuff instead.
>>> =( Maybe we should suppress diagnosing an unexpanded pack if we've got an
>>> active typo correction?
>>>
>>
>> Umm... yeah... having not really worked with parameter packs or looked at
>> any (failing) typo-correction unit tests involving parameter packs yet, I
>> don't know what the right answer is. Nor do I quite know where the boundary
>> of containsUnexpandedParameterPack being true would fall relative to an
>> expression placeholder that represents a possibly-qualified identifier and
>> the hooks needed to expand the identifier into an expression that fits in
>> where the identifier was seen.
>>
>>
>>>
>>>  template
>>>  ExprResult
>>> +TreeTransform::TransformTypoExpr(TypoExpr *E) {
>>> +  assert(getDerived().AlreadyTransformed(E->getType()) &&
>>> + "typo-correction placeholder expression requires
>>> transformation");
>>> +  return Owned(E);
>>> +}
>>>
>>> Can we really not get here with a TypoExpr still in the tree? We have
>>> enough TreeTransforms these days that I find this a bit surprising. Maybe
>>> TreeTransform should just preserve TypoExprs by default.
>>>
>>
>> D'oh, you're right. When I added all of the (Transform|Visit)TypoExpr
>> methods to the various classes like this one and ASTStmtReader in order to
>> make the compiler happy, I applied pretty much the same code or mentality
>> to all of the methods: "a TypoExpr is internal to Sema so shouldn't ever
>> hit these paths since it should never still be in the AST tree when the
>> tree is serialized, deserialized, etc)". I've dropped the assert here (and
>> the now-defunct call to Owned).
>>
>>
>>>
>>> +void ASTStmtReader::VisitTypoExpr(TypoExpr *E) {
>>> +  VisitExpr(E);
>>> +  // TODO: Figure out sane reader behavior for a TypoExpr, if necessary.
>>> +  assert(false && "Cannot read TypoExpr nodes");
>>> +}
>>>
>>> I think this should be unreachable; if things have gone so badly wrong
>>> that we couldn't resolve a TypoExpr, we shouldn't serialize it either.
>>>
>>
>> I've replaced the three lines in the body with a call to
>> llvm_unreachable().
>>
>>
>>>
>>> On Tue, Jun 17, 2014 at 5:29 PM, Kaelyn Takata  wrote:
>>>
 ---
  include/clang/AST/DataRecursiveASTVisitor.h |  1 +
  include/clang/AST/Expr.h| 17 +
  include/clang/AST/RecursiveASTVisitor.h |  1 +
  include/clang/Basic/StmtNodes.td|  1 +
  include/clang/Sema/SemaInternal.h   |  3 +++
  include/clang/Sema/TypoCorrection.h |  5 +
  lib/AST/Expr.cpp|  1 +
  lib/AST/ExprClassification.cpp  |  3 ++-
  lib/AST/ExprConstant.cpp|  1 +
  lib/AST/ItaniumMangle.cpp   |  1 +
  lib/AST/StmtPrinter.cpp |  5 +
  lib/AST/StmtProfile.cpp |  4 
  lib/Sema/SemaExceptionSpec.cpp  |  1 +
  lib/Sema/SemaLookup.cpp | 11 +++
  lib/Sema/TreeTransform.h|  8 
  lib/Serialization/ASTReaderStmt.cpp |  6 ++
  lib/Serialization/ASTWriterStmt.cpp |  6 ++
  lib/StaticAnalyzer/Core/ExprEngine.cpp  |  1 +
  tools/libclang/CXCursor.cpp |  1 +
  19 files changed

Re: [PATCH] [RFC] PR20146 - Cannot return void with qualifiers

[Richard Smith]

   unsigned FunctionChunkIndex)
{
+
+  // C99 6.9.1/3: The return type of a function shall be void or
+  // an object type other than array type.
+  // A return type of void cannot be qualified.


Micro-nit: no blank line at the start of a function body.

This should only apply in C; 'const void' is explicitly a valid return type
in C++ (see for instance 6.6.3/2, "a function with the return type cv
void").

Please make this an ExtWarn rather than an error, since GCC accepts it by
default (and doesn't even diagnose it if it's on a non-definition function
declaration), and it seems thoroughly harmless.

On Mon, Jul 7, 2014 at 9:22 AM, Zach Davis  wrote:

> Thanks for the comments.  I have:
>
> - Cleaned up the code
> - Made the warning an error
> - Moved the check into diagnoseIgnoredFunctionQualifiers()
> - Added 3 test cases to test/Sema/function.c
>
>
>
> On Thu, Jul 3, 2014 at 4:41 PM, Alp Toker  wrote:
> >
> > On 03/07/2014 22:08, Zach Davis wrote:
> >>
> >> As reported in bug 20146, a function cannot have a return type of
> >> 'void' with qualifiers.
> >>
> >> Clang does emit a warning that the qualifiers are ignored
> >> [-Wignored-qualifiers] (off by default), but according to [1] this
> >> code is non-conforming.
> >>
> >> The attached patch makes Clang issue a more specific warning like so:
> >>
> >>  test3.c:8:18: warning: return type of void cannot be qualified
> >> 'volatile void'
> >>  volatile void baz(void) { return; }
> >>^
> >>
> >> [1]http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_113.html
> >
> >
> > It seems fine to make this a hard error instead of a warning for C, and
> > probably C++ too. Richard?
> >
> >>
> >> 20146_return_qual_void.patch
> >>
> >>
> >> Index: lib/Sema/SemaType.cpp
> >> ===
> >> --- lib/Sema/SemaType.cpp   (revision 212275)
> >> +++ lib/Sema/SemaType.cpp   (working copy)
> >> @@ -2741,6 +2741,15 @@
> >>   D.setInvalidType(true);
> >> }
> >>   +  // C99 6.9.1/3: The return type of a function shall be void or
> >> +  // an object type other than array type.
> >> +  // A return type of void cannot be qualified.
> >> +  if (T->isVoidType() && T.getCVRQualifiers()) {
> >> +  unsigned diagID = diag::warn_func_returning_qualified_void;
> >
> >
> > Just pass the ID directly to Diag().
> >
> >> +  S.Diag(DeclType.Loc, diagID) << T;
> >> +  D.setInvalidType(true);
> >> +  }
> >> +
> >
> >
> > How about placing this check with an early return at the top of
> > diagnoseIgnoredFunctionQualifiers()?
> >
> >> // Do not allow returning half FP value.
> >> // FIXME: This really should be in BuildFunctionType.
> >> if (T->isHalfType()) {
> >> Index: include/clang/Basic/DiagnosticSemaKinds.td
> >> ===
> >> --- include/clang/Basic/DiagnosticSemaKinds.td  (revision 212275)
> >> +++ include/clang/Basic/DiagnosticSemaKinds.td  (working copy)
> >> @@ -4160,6 +4160,8 @@
> >> def err_func_returning_array_function : Error<
> >> "function cannot return %select{array|function}0 type %1">;
> >> +def warn_func_returning_qualified_void : Warning<
> >> +  "return type of void cannot be qualified %0">;
> >
> >
> > (Warnings need to have a diagnostic group / -W flag, though it doesn't
> > matter if you go ahead and make it an error.)
> >
> >>   def err_field_declared_as_function : Error<"field %0 declared as a
> >> function">;
> >>   def err_field_incomplete : Error<"field has incomplete type %0">;
> >>   def ext_variable_sized_type_in_struct : ExtWarn<
> >
> >
> > Test case?
> >
> > Alp.
> >
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
> >
> > --
> > http://www.nuanti.com
> > the browser experts
> >
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [Patch] UBsan: Type-based blacklisting

[Richard Smith]

The code change looks fine to me, but needs a testcase.

http://reviews.llvm.org/D4407



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [Patch] UBsan: Type-based blacklisting

[Richard Smith]

The code change looks fine to me, but needs a testcase.


On Mon, Jul 7, 2014 at 9:04 AM, Byoungyoung Lee 
wrote:

> Hi samsonov, rsmith, kcc,
>
> This is a Clang side patch for type-based blacklisting in Ubsan. As this
> patch is depending on llvm-side patch, please see
> http://reviews.llvm.org/D4406 for more details.
>
> Although the diff looks more complicated than it has to be, this patch
> only adds a simple branch   if
> (!CGM.getSanitizerBlacklist().isIn(Out.str())).
>
> http://reviews.llvm.org/D4407
>
> Files:
>   lib/CodeGen/CGExpr.cpp
>
> Index: lib/CodeGen/CGExpr.cpp
> ===
> --- lib/CodeGen/CGExpr.cpp
> +++ lib/CodeGen/CGExpr.cpp
> @@ -539,44 +539,47 @@
>  llvm::raw_svector_ostream Out(MangledName);
>
>  CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty.getUnqualifiedType(),
>   Out);
> -llvm::hash_code TypeHash = hash_value(Out.str());
>
> -// Load the vptr, and compute hash_16_bytes(TypeHash, vptr).
> -llvm::Value *Low = llvm::ConstantInt::get(Int64Ty, TypeHash);
> -llvm::Type *VPtrTy = llvm::PointerType::get(IntPtrTy, 0);
> -llvm::Value *VPtrAddr = Builder.CreateBitCast(Address, VPtrTy);
> -llvm::Value *VPtrVal = Builder.CreateLoad(VPtrAddr);
> -llvm::Value *High = Builder.CreateZExt(VPtrVal, Int64Ty);
> +// Blacklist based on the mangled types
> +if (!CGM.getSanitizerBlacklist().isIn(Out.str())) {
> +  llvm::hash_code TypeHash = hash_value(Out.str());
>
> -llvm::Value *Hash = emitHash16Bytes(Builder, Low, High);
> -Hash = Builder.CreateTrunc(Hash, IntPtrTy);
> +  // Load the vptr, and compute hash_16_bytes(TypeHash, vptr).
> +  llvm::Value *Low = llvm::ConstantInt::get(Int64Ty, TypeHash);
> +  llvm::Type *VPtrTy = llvm::PointerType::get(IntPtrTy, 0);
> +  llvm::Value *VPtrAddr = Builder.CreateBitCast(Address, VPtrTy);
> +  llvm::Value *VPtrVal = Builder.CreateLoad(VPtrAddr);
> +  llvm::Value *High = Builder.CreateZExt(VPtrVal, Int64Ty);
>
> -// Look the hash up in our cache.
> -const int CacheSize = 128;
> -llvm::Type *HashTable = llvm::ArrayType::get(IntPtrTy, CacheSize);
> -llvm::Value *Cache = CGM.CreateRuntimeVariable(HashTable,
> -
> "__ubsan_vptr_type_cache");
> -llvm::Value *Slot = Builder.CreateAnd(Hash,
> -  llvm::ConstantInt::get(IntPtrTy,
> -
> CacheSize-1));
> -llvm::Value *Indices[] = { Builder.getInt32(0), Slot };
> -llvm::Value *CacheVal =
> -  Builder.CreateLoad(Builder.CreateInBoundsGEP(Cache, Indices));
> +  llvm::Value *Hash = emitHash16Bytes(Builder, Low, High);
> +  Hash = Builder.CreateTrunc(Hash, IntPtrTy);
>
> -// If the hash isn't in the cache, call a runtime handler to perform
> the
> -// hard work of checking whether the vptr is for an object of the
> right
> -// type. This will either fill in the cache and return, or produce a
> -// diagnostic.
> -llvm::Constant *StaticData[] = {
> -  EmitCheckSourceLocation(Loc),
> -  EmitCheckTypeDescriptor(Ty),
> -  CGM.GetAddrOfRTTIDescriptor(Ty.getUnqualifiedType()),
> -  llvm::ConstantInt::get(Int8Ty, TCK)
> -};
> -llvm::Value *DynamicData[] = { Address, Hash };
> -EmitCheck(Builder.CreateICmpEQ(CacheVal, Hash),
> -  "dynamic_type_cache_miss", StaticData, DynamicData,
> -  CRK_AlwaysRecoverable);
> +  // Look the hash up in our cache.
> +  const int CacheSize = 128;
> +  llvm::Type *HashTable = llvm::ArrayType::get(IntPtrTy, CacheSize);
> +  llvm::Value *Cache = CGM.CreateRuntimeVariable(HashTable,
> +
> "__ubsan_vptr_type_cache");
> +  llvm::Value *Slot =
> +Builder.CreateAnd(Hash,llvm::ConstantInt::get(IntPtrTy,
> CacheSize-1));
> +  llvm::Value *Indices[] = { Builder.getInt32(0), Slot };
> +  llvm::Value *CacheVal =
> +Builder.CreateLoad(Builder.CreateInBoundsGEP(Cache, Indices));
> +
> +  // If the hash isn't in the cache, call a runtime handler to
> perform the
> +  // hard work of checking whether the vptr is for an object of the
> right
> +  // type. This will either fill in the cache and return, or produce a
> +  // diagnostic.
> +  llvm::Constant *StaticData[] = {
> +EmitCheckSourceLocation(Loc),
> +EmitCheckTypeDescriptor(Ty),
> +CGM.GetAddrOfRTTIDescriptor(Ty.getUnqualifiedType()),
> +llvm::ConstantInt::get(Int8Ty, TCK)
> +  };
> +  llvm::Value *DynamicData[] = { Address, Hash };
> +  EmitCheck(Builder.CreateICmpEQ(CacheVal, Hash),
> +"dynamic_type_cache_miss", StaticData, DynamicData,
> +CRK_AlwaysRecoverable);
> +}
>}
>
>if (Done) {
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>

Re: [PATCH] Canonicalize the variadic template alias with multiple ellipsis.

[Richard Smith]

On Mon, Jul 7, 2014 at 6:01 AM, Logan Chien 
wrote:

> Ping?
>
> This patch tries to fix an assertion failure related to the template alias
> with two (or more) parameter packs.  For example,
>
>
> template  struct tuple;
> template  struct extract_;
> template  using extract = typename extract_::type;
>
> template 
> inline auto test(tuple&& xs, B&&... ys) -> extract { }
>
> Please have a look, and feel free to let me know if there is any problem.
> Thanks!
>

Testcase reduced to:

template  struct extract_;
template  using extract = typename extract_::type;
template  void test(extract);

Sincerely,
> Logan
>
>
> On Mon, Jun 30, 2014 at 1:10 AM, Logan Chien 
> wrote:
>
>> Hi rsmith,
>>
>> If the template has two variadic formal parameters, then the type
>> might not be canonical.  We have call ASTContext.getCanonicalType()
>> to canonicalize the type; otherwise, an assertion failure will be
>> raised.
>>
>> This patch fix this issue by adding getCanonicalType() in
>> TransformTemplateTypeParmType.
>>
>
This seems to be blindly addressing a symptom rather than going after the
actual problem.

When we match the template arguments  against the parameters of
'extract', we form . Note we canonicalize the
first but not the second. This is because Sema::CheckTemplateArgumentList
does no checking for template arguments after the first pack expansion:

  // If we just saw a pack expansion, then directly convert the
remaining
  // arguments, because we don't know what parameters they'll match up
  // with.

This means we fail to check or canonicalize any arguments after a pack
expansion. With that knowledge in hand, here's a testcase for the same bug
that your patch won't fix:

  template  struct extract_;
  template  using extract = typename extract_::type;
  template  void test(extract);

The right fix here would be for CheckTemplateArgumentList to distinguish
between the case where more substitution and expansion will be performed
before the template is instantiated, and the case where it actually needs
to match up the parameters and arguments properly.

And then in a case like this:

  template struct A {
template using B = V;
void f(B);
  };

(for which we currently reject-valid), if CheckTemplateArgumentList is
called for an alias template, it needs to tell its caller to create a
dependent type rather than performing a substitution.

http://reviews.llvm.org/D4343
>>
>> Files:
>>   lib/Sema/SemaTemplateInstantiate.cpp
>>   test/SemaTemplate/alias-templates.cpp
>>
>> Index: lib/Sema/SemaTemplateInstantiate.cpp
>> ===
>> --- lib/Sema/SemaTemplateInstantiate.cpp
>> +++ lib/Sema/SemaTemplateInstantiate.cpp
>> @@ -1376,7 +1376,7 @@
>>  assert(Arg.getKind() == TemplateArgument::Type &&
>> "Template argument kind mismatch");
>>
>> -QualType Replacement = Arg.getAsType();
>> +QualType Replacement =
>> getSema().Context.getCanonicalType(Arg.getAsType());
>>
>>  // TODO: only do this uniquing once, at the start of instantiation.
>>  QualType Result
>> Index: test/SemaTemplate/alias-templates.cpp
>> ===
>> --- test/SemaTemplate/alias-templates.cpp
>> +++ test/SemaTemplate/alias-templates.cpp
>> @@ -201,3 +201,17 @@
>>template 
>>using derived2 = ::PR16904::base::template derived; //
>> expected-error {{expected a type}} expected-error {{expected ';'}}
>>  }
>> +
>> +namespace VariadicTemplateAlias {
>> +  template  struct tuple;
>> +  template  struct extract_;
>> +
>> +  // Note: Both the template alias and the concatenation of variadic
>> template
>> +  // arguments A and B are required to trigger the assertion failure.
>> +
>> +  template 
>> +  using extract = typename extract_::type;
>> +
>> +  template 
>> +  inline auto test(tuple&& xs, B&&... ys) -> extract
>> { }
>> +}
>>
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Canonicalize the variadic template alias with multiple ellipsis.

[Logan Chien]

Ping.


On Mon, Jul 7, 2014 at 9:01 PM, Logan Chien 
wrote:

> Ping?
>
> This patch tries to fix an assertion failure related to the template alias
> with two (or more) parameter packs.  For example,
>
>
> template  struct tuple;
> template  struct extract_;
> template  using extract = typename extract_::type;
>
> template 
> inline auto test(tuple&& xs, B&&... ys) -> extract { }
>
> Please have a look, and feel free to let me know if there is any problem.
> Thanks!
>
> Sincerely,
> Logan
>
>
> On Mon, Jun 30, 2014 at 1:10 AM, Logan Chien 
> wrote:
>
>> Hi rsmith,
>>
>> If the template has two variadic formal parameters, then the type
>> might not be canonical.  We have call ASTContext.getCanonicalType()
>> to canonicalize the type; otherwise, an assertion failure will be
>> raised.
>>
>> This patch fix this issue by adding getCanonicalType() in
>> TransformTemplateTypeParmType.
>>
>> http://reviews.llvm.org/D4343
>>
>> Files:
>>   lib/Sema/SemaTemplateInstantiate.cpp
>>   test/SemaTemplate/alias-templates.cpp
>>
>> Index: lib/Sema/SemaTemplateInstantiate.cpp
>> ===
>> --- lib/Sema/SemaTemplateInstantiate.cpp
>> +++ lib/Sema/SemaTemplateInstantiate.cpp
>> @@ -1376,7 +1376,7 @@
>>  assert(Arg.getKind() == TemplateArgument::Type &&
>> "Template argument kind mismatch");
>>
>> -QualType Replacement = Arg.getAsType();
>> +QualType Replacement =
>> getSema().Context.getCanonicalType(Arg.getAsType());
>>
>>  // TODO: only do this uniquing once, at the start of instantiation.
>>  QualType Result
>> Index: test/SemaTemplate/alias-templates.cpp
>> ===
>> --- test/SemaTemplate/alias-templates.cpp
>> +++ test/SemaTemplate/alias-templates.cpp
>> @@ -201,3 +201,17 @@
>>template 
>>using derived2 = ::PR16904::base::template derived; //
>> expected-error {{expected a type}} expected-error {{expected ';'}}
>>  }
>> +
>> +namespace VariadicTemplateAlias {
>> +  template  struct tuple;
>> +  template  struct extract_;
>> +
>> +  // Note: Both the template alias and the concatenation of variadic
>> template
>> +  // arguments A and B are required to trigger the assertion failure.
>> +
>> +  template 
>> +  using extract = typename extract_::type;
>> +
>> +  template 
>> +  inline auto test(tuple&& xs, B&&... ys) -> extract
>> { }
>> +}
>>
>
>
From a8cf42306c6092ba15ed6a13c8e738eb852bd55d Mon Sep 17 00:00:00 2001
From: Logan Chien 
Date: Mon, 30 Jun 2014 01:00:15 +0800
Subject: [PATCH] Canonicalize the variadic template alias with multiple
 ellipsis.

---
 lib/Sema/SemaTemplateInstantiate.cpp  |  2 +-
 test/SemaTemplate/alias-templates.cpp | 14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/lib/Sema/SemaTemplateInstantiate.cpp b/lib/Sema/SemaTemplateInstantiate.cpp
index 14c6405..c51ffd4 100644
--- a/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1376,7 +1376,7 @@ TemplateInstantiator::TransformTemplateTypeParmType(TypeLocBuilder &TLB,
 assert(Arg.getKind() == TemplateArgument::Type &&
"Template argument kind mismatch");
 
-QualType Replacement = Arg.getAsType();
+QualType Replacement = getSema().Context.getCanonicalType(Arg.getAsType());
 
 // TODO: only do this uniquing once, at the start of instantiation.
 QualType Result
diff --git a/test/SemaTemplate/alias-templates.cpp b/test/SemaTemplate/alias-templates.cpp
index e7be184..c82b69e 100644
--- a/test/SemaTemplate/alias-templates.cpp
+++ b/test/SemaTemplate/alias-templates.cpp
@@ -201,3 +201,17 @@ namespace PR16904 {
   template 
   using derived2 = ::PR16904::base::template derived; // expected-error {{expected a type}} expected-error {{expected ';'}}
 }
+
+namespace VariadicTemplateAlias {
+  template  struct tuple;
+  template  struct extract_;
+
+  // Note: Both the template alias and the concatenation of variadic template
+  // arguments A and B are required to trigger the assertion failure.
+
+  template 
+  using extract = typename extract_::type;
+
+  template 
+  inline auto test(tuple&& xs, B&&... ys) -> extract { }
+}
-- 
1.9.1

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212578 - rewrap to 80 cols, no behavior change

[Nico Weber]

Author: nico
Date: Tue Jul  8 18:54:25 2014
New Revision: 212578

URL: http://llvm.org/viewvc/llvm-project?rev=212578&view=rev
Log:
rewrap to 80 cols, no behavior change

Modified:
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/lib/Sema/SemaType.cpp

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=212578&r1=212577&r2=212578&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Tue Jul  8 18:54:25 2014
@@ -6652,7 +6652,8 @@ bool InitializationSequence::Diagnose(Se
   Args.back()->getLocEnd());
 
 if (Failure == FK_ListConstructorOverloadFailed) {
-  assert(Args.size() == 1 && "List construction from other than 1 
argument.");
+  assert(Args.size() == 1 &&
+ "List construction from other than 1 argument.");
   InitListExpr *InitList = cast(Args[0]);
   Args = MultiExprArg(InitList->getInits(), InitList->getNumInits());
 }

Modified: cfe/trunk/lib/Sema/SemaType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaType.cpp?rev=212578&r1=212577&r2=212578&view=diff
==
--- cfe/trunk/lib/Sema/SemaType.cpp (original)
+++ cfe/trunk/lib/Sema/SemaType.cpp Tue Jul  8 18:54:25 2014
@@ -2395,9 +2395,9 @@ static void warnAboutAmbiguousFunction(S
   }
 
   if (FTI.NumParams > 0) {
-// For a declaration with parameters, eg. "T var(T());", suggest adding 
parens
-// around the first parameter to turn the declaration into a variable
-// declaration.
+// For a declaration with parameters, eg. "T var(T());", suggest adding
+// parens around the first parameter to turn the declaration into a
+// variable declaration.
 SourceRange Range = FTI.Params[0].Param->getSourceRange();
 SourceLocation B = Range.getBegin();
 SourceLocation E = S.getLocForEndOfToken(Range.getEnd());
@@ -2407,8 +2407,8 @@ static void warnAboutAmbiguousFunction(S
   << FixItHint::CreateInsertion(B, "(")
   << FixItHint::CreateInsertion(E, ")");
   } else {
-// For a declaration without parameters, eg. "T var();", suggest replacing 
the
-// parens with an initializer to turn the declaration into a variable
+// For a declaration without parameters, eg. "T var();", suggest replacing
+// the parens with an initializer to turn the declaration into a variable
 // declaration.
 const CXXRecordDecl *RD = RT->getAsCXXRecordDecl();
 


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212574 - rewrap to 80 cols, no behavior change

[Nico Weber]

Author: nico
Date: Tue Jul  8 18:46:20 2014
New Revision: 212574

URL: http://llvm.org/viewvc/llvm-project?rev=212574&view=rev
Log:
rewrap to 80 cols, no behavior change

Modified:
cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp

Modified: cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp?rev=212574&r1=212573&r2=212574&view=diff
==
--- cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp (original)
+++ cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp Tue Jul  8 18:46:20 2014
@@ -611,8 +611,9 @@ static bool SuggestInitializationFixit(S
   QualType VariableTy = VD->getType().getCanonicalType();
   if (VariableTy->isBlockPointerType() &&
   !VD->hasAttr()) {
-S.Diag(VD->getLocation(), diag::note_block_var_fixit_add_initialization) 
<< VD->getDeclName()
-<< FixItHint::CreateInsertion(VD->getLocation(), "__block ");
+S.Diag(VD->getLocation(), diag::note_block_var_fixit_add_initialization)
+<< VD->getDeclName()
+<< FixItHint::CreateInsertion(VD->getLocation(), "__block ");
 return true;
   }
 


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[libcxx] r212569 - string_view enhancements. Move to the correct namespace. Better constexpr support (thanks to Richard for the suggestions). Update the tests to match this. Add

[Marshall Clow]

Author: marshall
Date: Tue Jul  8 17:38:11 2014
New Revision: 212569

URL: http://llvm.org/viewvc/llvm-project?rev=212569&view=rev
Log:
string_view enhancements. Move to the correct namespace. Better constexpr 
support (thanks to Richard for the suggestions). Update the tests to match 
this. Add http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/experimental/__config?rev=212569&view=auto
==
--- libcxx/trunk/include/experimental/__config (added)
+++ libcxx/trunk/include/experimental/__config Tue Jul  8 17:38:11 2014
@@ -0,0 +1,24 @@
+// -*- C++ -*-
+//===--- __config 
-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef _LIBCPP_EXPERIMENTAL_CONFIG
+#define _LIBCPP_EXPERIMENTAL_CONFIG
+
+#include <__config>
+
+#define _LIBCPP_BEGIN_NAMESPACE_EXPERIMENTAL namespace std { namespace 
experimental {
+#define _LIBCPP_END_NAMESPACE_EXPERIMENTAL  } }
+#define _VSTD_EXPERIMENTAL std::experimental
+
+#define _LIBCPP_BEGIN_NAMESPACE_LFTS _LIBCPP_BEGIN_NAMESPACE_EXPERIMENTAL 
inline namespace fundamentals_v1 {
+#define _LIBCPP_END_NAMESPACE_LFTS  } } }
+#define _VSTD_LFTS _VSTD_EXPERIMENTAL::fundamentals_v1
+
+#endif

Modified: libcxx/trunk/include/experimental/string_view
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/experimental/string_view?rev=212569&r1=212568&r2=212569&view=diff
==
--- libcxx/trunk/include/experimental/string_view (original)
+++ libcxx/trunk/include/experimental/string_view Tue Jul  8 17:38:11 2014
@@ -174,7 +174,7 @@ namespace std {
 
 */
 
-#include <__config>
+#include 
 
 #include 
 #include 
@@ -186,9 +186,7 @@ namespace std {
 #pragma GCC system_header
 #endif
 
-namespace std {
- namespace experimental {
-  inline namespace library_fundamentals_v1 {
+_LIBCPP_BEGIN_NAMESPACE_LFTS
 
 template >
 class _LIBCPP_TYPE_VIS_ONLY basic_string_view {
@@ -276,12 +274,15 @@ namespace std {
 _LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
 const_reference operator[](size_type __pos) const { return 
__data[__pos]; }
 
-_LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
+_LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
 const_reference at(size_type __pos) const
 {
-if (__pos >= size())
-throw out_of_range("string_view::at");
-return __data[__pos]; 
+return __pos >= size()
+? throw out_of_range("string_view::at")
+: __data[__pos];
+// if (__pos >= size())
+// throw out_of_range("string_view::at");
+// return __data[__pos]; 
 }
 
 _LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
@@ -358,7 +359,8 @@ namespace std {
 return __rlen;
 }
 
-_LIBCPP_CONSTEXPR basic_string_view substr(size_type __pos = 0, 
size_type __n = npos) const
+_LIBCPP_CONSTEXPR
+basic_string_view substr(size_type __pos = 0, size_type __n = npos) 
const
 {
 // if (__pos > size())
 // throw out_of_range("string_view::substr");
@@ -776,8 +778,7 @@ namespace std {
   typedef basic_string_view u32string_view;
   typedef basic_string_view  wstring_view;
 
-}}}  // close std::experimental::library_fundamentals_v1
-
+_LIBCPP_END_NAMESPACE_LFTS
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 // [string.view.hash]

Modified: 
libcxx/trunk/test/experimental/string.view/string.view.access/at.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/experimental/string.view/string.view.access/at.pass.cpp?rev=212569&r1=212568&r2=212569&view=diff
==
--- libcxx/trunk/test/experimental/string.view/string.view.access/at.pass.cpp 
(original)
+++ libcxx/trunk/test/experimental/string.view/string.view.access/at.pass.cpp 
Tue Jul  8 17:38:11 2014
@@ -43,7 +43,7 @@ int main () {
 test ( U"a", 1 );
 #endif
 
-#if _LIBCPP_STD_VER > 11
+#if __cplusplus >= 201103L
 {
 constexpr std::experimental::basic_string_view sv ( "ABC", 2 );
 static_assert ( sv.length() ==  2,  "" );


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Use the correct from type in a SCS

[Ehsan Akhgari]

On Tue, Jul 8, 2014 at 6:05 PM, Richard Smith  wrote:

> On Sun, Jul 6, 2014 at 12:16 PM, Ehsan Akhgari 
> wrote:
>
>> Hi doug.gregor,
>>
>> If during constructing a standard conversion sequence, we resolve an
>> overload, we need to adjust the from type in the SCS according to the
>> resolved operator.
>>
>> I found this bug when debugging PR20218.  It doesn't completely fix that
>> test case though.
>>
>
> The fix looks correct, but please provide some kind of test case for this
> patch (even if it doesn't solve PR20218's test case).
>

I tried to do that, but I wasn't able to write a simpler test case similar
to that of PR20218 which would have an observable outcome different after
this patch...  Any ideas how I can write a good test case for this?

Thanks!
--
Ehsan



>
>
>> http://reviews.llvm.org/D4402
>>
>> Files:
>>   lib/Sema/SemaOverload.cpp
>>
>> Index: lib/Sema/SemaOverload.cpp
>> ===
>> --- lib/Sema/SemaOverload.cpp
>> +++ lib/Sema/SemaOverload.cpp
>> @@ -1462,6 +1462,7 @@
>>// We were able to resolve the address of the overloaded function,
>>// so we can convert to the type of that function.
>>FromType = Fn->getType();
>> +  SCS.setFromType(FromType);
>>
>>// we can sometimes resolve &foo regardless of ToType, so
>> check
>>// if the type matches (identity) or we are converting to bool
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Use the correct from type in a SCS

[Richard Smith]

On Sun, Jul 6, 2014 at 12:16 PM, Ehsan Akhgari 
wrote:

> Hi doug.gregor,
>
> If during constructing a standard conversion sequence, we resolve an
> overload, we need to adjust the from type in the SCS according to the
> resolved operator.
>
> I found this bug when debugging PR20218.  It doesn't completely fix that
> test case though.
>

The fix looks correct, but please provide some kind of test case for this
patch (even if it doesn't solve PR20218's test case).


> http://reviews.llvm.org/D4402
>
> Files:
>   lib/Sema/SemaOverload.cpp
>
> Index: lib/Sema/SemaOverload.cpp
> ===
> --- lib/Sema/SemaOverload.cpp
> +++ lib/Sema/SemaOverload.cpp
> @@ -1462,6 +1462,7 @@
>// We were able to resolve the address of the overloaded function,
>// so we can convert to the type of that function.
>FromType = Fn->getType();
> +  SCS.setFromType(FromType);
>
>// we can sometimes resolve &foo regardless of ToType, so check
>// if the type matches (identity) or we are converting to bool
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r212512 - Headers: conditionalise more declarations

[Saleem Abdulrasool]

On Jul 8, 2014, at 1:00 PM, Reid Kleckner  wrote:

> As mentioned on IRC, we should just merge this with 
> test/Headers/ms-intrin.cpp with another RUN line for WoA.

As mentioned on IRC, SVN r212563 (sorry, too easy to be cheeky here!).

> 
> On Mon, Jul 7, 2014 at 10:46 PM, Saleem Abdulrasool  
> wrote:
> Author: compnerd
> Date: Tue Jul  8 00:46:04 2014
> New Revision: 212512
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=212512&view=rev
> Log:
> Headers: conditionalise more declarations
> 
> Protect MMX specific declarations under a __MMX__ guard.  This header can be
> included on non-x86 architectures (e.g. ARM) which do not support the MMX ISA.
> Use the preprocessor to prevent these declarations from being processed.
> 
> Added:
> cfe/trunk/test/Headers/arm-intrin.c
> Modified:
> cfe/trunk/lib/Headers/Intrin.h
> 
> Modified: cfe/trunk/lib/Headers/Intrin.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=212512&r1=212511&r2=212512&view=diff
> ==
> --- cfe/trunk/lib/Headers/Intrin.h (original)
> +++ cfe/trunk/lib/Headers/Intrin.h Tue Jul  8 00:46:04 2014
> @@ -41,12 +41,14 @@
>  extern "C" {
>  #endif
> 
> +#if defined(__MMX__)
>  /* And the random ones that aren't in those files. */
>  __m64 _m_from_float(float);
>  __m64 _m_from_int(int _l);
>  void _m_prefetch(void *);
>  float _m_to_float(__m64);
>  int _m_to_int(__m64 _M);
> +#endif
> 
>  /* Other assorted instruction intrinsics. */
>  void __addfsbyte(unsigned long, unsigned char);
> 
> Added: cfe/trunk/test/Headers/arm-intrin.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/arm-intrin.c?rev=212512&view=auto
> ==
> --- cfe/trunk/test/Headers/arm-intrin.c (added)
> +++ cfe/trunk/test/Headers/arm-intrin.c Tue Jul  8 00:46:04 2014
> @@ -0,0 +1,6 @@
> +// RUN: %clang -target armv7-windows -I %S/Inputs/include -Xclang -verify -E 
> %s
> +// expected-no-diagnostics
> +
> +typedef __SIZE_TYPE__ size_t;
> +#include 
> +
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=7GFNnyjVtZp6gN8cMznsEMYhfb1cYJ9RpW24wCoa5D8%3D%0A&s=86e011fa83bab663668836c2a3c0b93c03fce2b17fa6a4534fd1a803bf2b4a1c

-- 
Saleem Abdulrasool
abdulras (at) fb (dot) com






___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212566 - MS compat: Allow lookup of types from dependent bases in functions

[Reid Kleckner]

Author: rnk
Date: Tue Jul  8 16:35:03 2014
New Revision: 212566

URL: http://llvm.org/viewvc/llvm-project?rev=212566&view=rev
Log:
MS compat: Allow lookup of types from dependent bases in functions

If we want to resolve the remaining FIXMEs here, we probably want to
extend the main lookup mechanism to perform lookup into dependent bases,
but we would have to tread lightly.  Adding more name lookup has major
impact on compile time.

If we did extend the main mechanism, we would add a flag to LookupResult
that allows us to find names from dependent base classes where the base
is a specialization of a known template.  The final LookupResult would
still return LookupResult::NotFoundInCurrentInstantiation, but it would
have a collection of Decls.  If we find a real lookup result, we would
clear the flag and the existing lookup results and begin accumulating
only real lookup results.

We would structure the lookup as a secondary lookup between normal
lookup and typo correction for normal compilation, but for MSVC
compatibility mode, we would always enable this extra lookup into
dependent bases.

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=212566&r1=212565&r2=212566&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jul  8 16:35:03 2014
@@ -131,8 +131,15 @@ bool Sema::isSimpleTypeSpecifier(tok::To
 static ParsedType recoverFromTypeInKnownDependentBase(Sema &S,
   const IdentifierInfo &II,
   SourceLocation NameLoc) {
-  auto *RD = dyn_cast(S.CurContext);
-  if (!RD || !RD->getDescribedClassTemplate())
+  // Find the first parent class template context, if any.
+  // FIXME: Perform the lookup in all enclosing class templates.
+  const CXXRecordDecl *RD = nullptr;
+  for (DeclContext *DC = S.CurContext; DC; DC = DC->getParent()) {
+RD = dyn_cast(DC);
+if (RD && RD->getDescribedClassTemplate())
+  break;
+  }
+  if (!RD)
 return ParsedType();
 
   // Look for type decls in dependent base classes that have known primary
@@ -146,6 +153,8 @@ static ParsedType recoverFromTypeInKnown
 if (!TD)
   continue;
 auto *BasePrimaryTemplate = cast(TD->getTemplatedDecl());
+// FIXME: Allow lookup into non-dependent bases of dependent bases, 
possibly
+// by calling or integrating with the main LookupQualifiedName mechanism.
 for (NamedDecl *ND : BasePrimaryTemplate->lookup(&II)) {
   if (FoundTypeDecl)
 return ParsedType();

Modified: cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp?rev=212566&r1=212565&r2=212566&view=diff
==
--- cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp (original)
+++ cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp Tue Jul  8 
16:35:03 2014
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++1y -fms-compatibility -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++1y -fms-compatibility -fno-spell-checking 
-fsyntax-only -verify %s
 
 
 template 
@@ -380,6 +380,15 @@ struct B : A { NameFromBase m; }; //
 struct C : A { NameFromBase m; }; // expected-error {{unknown type name 
'NameFromBase'}}
 }
 
+namespace type_in_base_of_dependent_base {
+struct A { typedef int NameFromBase; };
+template 
+struct B : A {};
+// FIXME: MSVC accepts this.
+template 
+struct C : B { NameFromBase m; }; // expected-error {{unknown type name 
'NameFromBase'}}
+}
+
 namespace lookup_in_function_contexts {
 template  struct A { typedef T NameFromBase; };
 template 
@@ -389,23 +398,20 @@ struct B : A {
 return {};
   }
 
-  // FIXME: MSVC accepts all of the code below that isn't C++14 only.  
Downgrade
-  // these errors to warnings.
-
   static void memberFunc() {
-NameFromBase x; // expected-error {{unknown type name 'NameFromBase'}}
+NameFromBase x; // expected-warning {{lookup into dependent bases}}
   }
 
   static void funcLocalClass() {
 struct X {
-  NameFromBase x; // expected-error {{unknown type name 'NameFromBase'}}
+  NameFromBase x; // expected-warning {{lookup into dependent bases}}
 } y;
   }
 
   void localClassMethod() {
 struct X {
   void bar() {
-NameFromBase m; // expected-error {{unknown type name 'NameFromBase'}}
+NameFromBase m; // expected-warning {{lookup into dependent bases}}
   }
 } x;
 x.bar();
@@ -413,20 +419,18 @@ struct B : A {
 
   static void funcLambda() {
 auto l = []() {
-  NameFromBase x; // expected-error {{unknown type name 'NameFromBase

Re: [LLVMdev] Usability of phabricator review threads for non-phab-users

[Zachary Turner]

Here's an example of a use case that would be nice to fix:

http://reviews.llvm.org/D4425

It's possible this has already been pointed out earlier in the thread.  The
situation was, I forgot to include lldb-commits on the original patch, and
then added it subsequently.  I could not find any way to get it to send out
a new email containing the full patch + summary, so as a result I had to
manually copy/paste the summary + patch text into an email response, and
manually attach the patch as a file.


On Sun, Jul 6, 2014 at 8:28 AM, Manuel Klimek  wrote:

> On Sun, Jul 6, 2014 at 4:42 AM, Nick Lewycky  wrote:
>
>> Chandler Carruth wrote:
>>
>>>
>>> On Thu, Jul 3, 2014 at 11:00 PM, Nick Lewycky >> > wrote:
>>>
>>> I don't like the lack attached patch files on the mailing list to do
>>> a normal review.
>>>
>>>
>>> Wait what? The emails I get from phab *have* an attached patch file.
>>> That was a hard requirement when we first set up Phabricator.
>>>
>>
>> Aaron nailed it. The initial emails come with attached patches. The
>> problem is when people comment with the changes they made to the code, but
>> there's no updated patch attached to that email. Aaron found examples so
>> I'll defer to those. I can also keep an eye out for the next time it
>> happens if you want.
>
>
> You should usually see 2 messages directly after each other - one with the
> patch, and one with the comment updates.
>
>
>>
>>
>> Nick
>>
>
>
> ___
> LLVM Developers mailing list
> llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] CodeGen: Let arrays be inputs to inline asm

[Reid Kleckner]

lgtm, but please wait for http://crbug.com/391927 in libyuv to be resolved.

http://reviews.llvm.org/D4382



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212564 - Remove unnecessary check for NULL

[Alexey Samsonov]

Author: samsonov
Date: Tue Jul  8 15:23:18 2014
New Revision: 212564

URL: http://llvm.org/viewvc/llvm-project?rev=212564&view=rev
Log:
Remove unnecessary check for NULL

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

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp?rev=212564&r1=212563&r2=212564&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.cpp Tue Jul  8 15:23:18 2014
@@ -788,16 +788,13 @@ void CodeGenFunction::GenerateCode(Globa
   // of the declaration as the location for the subprogram. A function
   // may lack a declaration in the source code if it is created by code
   // gen. (examples: _GLOBAL__I_a, __cxx_global_array_dtor, thunk).
-  SourceLocation Loc;
-  if (FD) {
-Loc = FD->getLocation();
+  SourceLocation Loc = FD->getLocation();
 
-// If this is a function specialization then use the pattern body
-// as the location for the function.
-if (const FunctionDecl *SpecDecl = FD->getTemplateInstantiationPattern())
-  if (SpecDecl->hasBody(SpecDecl))
-Loc = SpecDecl->getLocation();
-  }
+  // If this is a function specialization then use the pattern body
+  // as the location for the function.
+  if (const FunctionDecl *SpecDecl = FD->getTemplateInstantiationPattern())
+if (SpecDecl->hasBody(SpecDecl))
+  Loc = SpecDecl->getLocation();
 
   // Emit the standard function prologue.
   StartFunction(GD, ResTy, Fn, FnInfo, Args, Loc, BodyRange.getBegin());


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212563 - test: merge arm-intrin into ms-intrin, fix invocation

[Saleem Abdulrasool]

Author: compnerd
Date: Tue Jul  8 15:21:29 2014
New Revision: 212563

URL: http://llvm.org/viewvc/llvm-project?rev=212563&view=rev
Log:
test: merge arm-intrin into ms-intrin, fix invocation

This merges the two tests into one since there is no real reason to separate
them.  It also fixes the test invocation to specify -fms-compatibility without
which we would end up without an Intrin.h header.

Removed:
cfe/trunk/test/Headers/arm-intrin.c
Modified:
cfe/trunk/test/Headers/ms-intrin.cpp

Removed: cfe/trunk/test/Headers/arm-intrin.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/arm-intrin.c?rev=212562&view=auto
==
--- cfe/trunk/test/Headers/arm-intrin.c (original)
+++ cfe/trunk/test/Headers/arm-intrin.c (removed)
@@ -1,6 +0,0 @@
-// RUN: %clang -target armv7-windows -I %S/Inputs/include -Xclang -verify -E %s
-// expected-no-diagnostics
-
-typedef __SIZE_TYPE__ size_t;
-#include 
-

Modified: cfe/trunk/test/Headers/ms-intrin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/ms-intrin.cpp?rev=212563&r1=212562&r2=212563&view=diff
==
--- cfe/trunk/test/Headers/ms-intrin.cpp (original)
+++ cfe/trunk/test/Headers/ms-intrin.cpp Tue Jul  8 15:21:29 2014
@@ -8,6 +8,11 @@
 // RUN: -ffreestanding -fsyntax-only -Werror \
 // RUN: -isystem %S/Inputs/include %s
 
+// RUN: %clang_cc1 -triple thumbv7--windows \
+// RUN: -ffreestanding -fsyntax-only -fms-compatibility -fmsc-version=1700 
\
+// RUN: -Werror \
+// RUN: -isystem %S/Inputs/include %s
+
 // Intrin.h needs size_t, but -ffreestanding prevents us from getting it from
 // stddef.h.  Work around it with this typedef.
 typedef __SIZE_TYPE__ size_t;


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [analyzer] [patch] Path-sensitive different.IntegerOverflow checker

[Anna Zaks]

Hi Julia,

Thanks for working on this!

In general, we prefer to get incremental patches rather than something that is 
close to the end-result. That way it is easier to get the guidance along the 
way and easier for a reviewer to review.

Here are some high level comments. 

The package name lacks description. 

It would be very helpful to differentiate the overflows that are considered 
undefined behavior from the ones that are defined. I would have 2 checkers for 
these, to allow users to turn them on/off independently. However, this might be 
a separate future improvement.

Could you add more documentation in doxygen style as well as a high level 
description of the algorithm? 

After briefly looking at the patch, I am still not sure how exactly 
"ExternalSym" is used. Looks like you are tracking symbols that the analyzer 
may not have values for (like globals). But that should not be needed: if a 
value is not known by the analyzer you can determine that when evaluating the 
overflow check. Specifically, State->assume() returns two states, which you can 
use to find out which situation you are dealing with:
 - there was an overflow
 - there was no overflow
 - under constrained or unknown - this would correspond to the case where both 
states are feasible.
There should be other posts on the mailing list describing this API as well as 
other uses of it throughout the analyzer.

Also, I did not notice tests that are testing these heuristics...

The error message seems to be constructed prematurely and I do not see any 
tests that test it fully.

Another checker that is somewhat related to this one is the String API checker. 
One reason why it is still in alpha is that it was very difficult to interpret 
the reports; most of which were due to overflows earlier on the path. It would 
be very interesting to see how this checker works on various codebases (with 
respect to bugs found vs false positives). 

Cheers,
Anna.


Comment at: lib/StaticAnalyzer/Checkers/IntegerOverflowChecker.cpp:35
@@ +34,3 @@
+  mutable std::unique_ptr BT;
+
+  mutable std::set OverflowLoc;

Are you getting multiple reports on the same location? I don't think that 
should be happening - the bug reporting infrastructure should unique reports.


Comment at: lib/StaticAnalyzer/Checkers/IntegerOverflowChecker.cpp:349
@@ +348,3 @@
+
+// Don't track global variables and class members we can't reason about.
+bool

Need a better comment here - the function returns a bool.
Also, comments should be in doxygen form and added to the declarations.


Comment at: lib/StaticAnalyzer/Checkers/IntegerOverflowChecker.cpp:446
@@ +445,3 @@
+}
+
+ProgramStateRef

addGoodSink seem to add a symbol to a state. Looks like it's used to track 
symbols we are not supposed to diagnose - symbols with global state? Could you 
add a better comment/name here?

Sink has a very specific meaning in the analyzer - it's a node at which the 
simulation stops. Usually, it's used for unrecoverable error nodes.


Comment at: lib/StaticAnalyzer/Checkers/IntegerOverflowChecker.cpp:498
@@ +497,3 @@
+  addRangeInformation(Lhs, C, LValue);
+
+  if (makeGlobalsMembersHeuristics(Lhs, ExprLhs, C)) {

It looks like you are building an error message string before the issue is 
diagnosed..

http://reviews.llvm.org/D4066



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212561 - Allow more lookup of types in dependent base classes

[Reid Kleckner]

Author: rnk
Date: Tue Jul  8 15:05:48 2014
New Revision: 212561

URL: http://llvm.org/viewvc/llvm-project?rev=212561&view=rev
Log:
Allow more lookup of types in dependent base classes

MSVC appears to perform name lookup into dependent base classes when the
dependent base class has a known primary template.  This allows them to
know whether some unqualified ids are types or not, which allows them to
parse more class templates without typename keywords.

We can do the same thing when type name lookup fails, and if we find a
single type decl in one of our dependent base classes, recover as though
the user wrote 'typename MyClass::TypeFromBase'.

This allows us to parse some COM smart pointer classes in wrl/client.h
from the Windows 8 SDK.

Reviewers: rsmith

Differential Revision: http://reviews.llvm.org/D4237

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=212561&r1=212560&r2=212561&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jul  8 15:05:48 2014
@@ -128,6 +128,56 @@ bool Sema::isSimpleTypeSpecifier(tok::To
   return false;
 }
 
+static ParsedType recoverFromTypeInKnownDependentBase(Sema &S,
+  const IdentifierInfo &II,
+  SourceLocation NameLoc) {
+  auto *RD = dyn_cast(S.CurContext);
+  if (!RD || !RD->getDescribedClassTemplate())
+return ParsedType();
+
+  // Look for type decls in dependent base classes that have known primary
+  // templates.
+  bool FoundTypeDecl = false;
+  for (const auto &Base : RD->bases()) {
+auto *TST = Base.getType()->getAs();
+if (!TST || !TST->isDependentType())
+  continue;
+auto *TD = TST->getTemplateName().getAsTemplateDecl();
+if (!TD)
+  continue;
+auto *BasePrimaryTemplate = cast(TD->getTemplatedDecl());
+for (NamedDecl *ND : BasePrimaryTemplate->lookup(&II)) {
+  if (FoundTypeDecl)
+return ParsedType();
+  FoundTypeDecl = isa(ND);
+  if (!FoundTypeDecl)
+return ParsedType();
+}
+  }
+  if (!FoundTypeDecl)
+return ParsedType();
+
+  // We found some types in dependent base classes.  Recover as if the user
+  // wrote 'typename MyClass::II' instead of 'II'.  We'll fully resolve the
+  // lookup during template instantiation.
+  S.Diag(NameLoc, diag::ext_found_via_dependent_bases_lookup) << &II;
+
+  ASTContext &Context = S.Context;
+  auto *NNS = NestedNameSpecifier::Create(Context, nullptr, false,
+  
cast(Context.getRecordType(RD)));
+  QualType T = Context.getDependentNameType(ETK_Typename, NNS, &II);
+
+  CXXScopeSpec SS;
+  SS.MakeTrivial(Context, NNS, SourceRange(NameLoc));
+
+  TypeLocBuilder Builder;
+  DependentNameTypeLoc DepTL = Builder.push(T);
+  DepTL.setNameLoc(NameLoc);
+  DepTL.setElaboratedKeywordLoc(SourceLocation());
+  DepTL.setQualifierLoc(SS.getWithLocInContext(Context));
+  return S.CreateParsedType(T, Builder.getTypeSourceInfo(Context, T));
+}
+
 /// \brief If the identifier refers to a type name within this scope,
 /// return the declaration of that type.
 ///
@@ -209,6 +259,14 @@ ParsedType Sema::getTypeName(const Ident
   } else {
 // Perform unqualified name lookup.
 LookupName(Result, S);
+
+// For unqualified lookup in a class template in MSVC mode, look into
+// dependent base classes where the primary class template is known.
+if (Result.empty() && getLangOpts().MSVCCompat && (!SS || SS->isEmpty())) {
+  if (ParsedType TypeInBase =
+  recoverFromTypeInKnownDependentBase(*this, II, NameLoc))
+return TypeInBase;
+}
   }
 
   NamedDecl *IIDecl = nullptr;
@@ -630,6 +688,14 @@ Sema::NameClassification Sema::ClassifyN
   LookupResult Result(*this, Name, NameLoc, LookupOrdinaryName);
   LookupParsedName(Result, S, &SS, !CurMethod);
 
+  // For unqualified lookup in a class template in MSVC mode, look into
+  // dependent base classes where the primary class template is known.
+  if (Result.empty() && SS.isEmpty() && getLangOpts().MSVCCompat) {
+if (ParsedType TypeInBase =
+recoverFromTypeInKnownDependentBase(*this, *Name, NameLoc))
+  return TypeInBase;
+  }
+
   // Perform lookup for Objective-C instance variables (including 
automatically 
   // synthesized instance variables), if we're in an Objective-C method.
   // FIXME: This lookup really, really needs to be folded in to the normal

Modified: cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp?rev=212561&r1=212560&r2=212561&view=diff
===

Re: [PATCH] Allow more lookup of types in dependent base classes

[Reid Kleckner]

Closed by commit rL212561 (authored by @rnk).

REPOSITORY
  rL LLVM

http://reviews.llvm.org/D4237

Files:
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp
Index: cfe/trunk/lib/Sema/SemaDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaDecl.cpp
+++ cfe/trunk/lib/Sema/SemaDecl.cpp
@@ -128,6 +128,56 @@
   return false;
 }
 
+static ParsedType recoverFromTypeInKnownDependentBase(Sema &S,
+  const IdentifierInfo &II,
+  SourceLocation NameLoc) {
+  auto *RD = dyn_cast(S.CurContext);
+  if (!RD || !RD->getDescribedClassTemplate())
+return ParsedType();
+
+  // Look for type decls in dependent base classes that have known primary
+  // templates.
+  bool FoundTypeDecl = false;
+  for (const auto &Base : RD->bases()) {
+auto *TST = Base.getType()->getAs();
+if (!TST || !TST->isDependentType())
+  continue;
+auto *TD = TST->getTemplateName().getAsTemplateDecl();
+if (!TD)
+  continue;
+auto *BasePrimaryTemplate = cast(TD->getTemplatedDecl());
+for (NamedDecl *ND : BasePrimaryTemplate->lookup(&II)) {
+  if (FoundTypeDecl)
+return ParsedType();
+  FoundTypeDecl = isa(ND);
+  if (!FoundTypeDecl)
+return ParsedType();
+}
+  }
+  if (!FoundTypeDecl)
+return ParsedType();
+
+  // We found some types in dependent base classes.  Recover as if the user
+  // wrote 'typename MyClass::II' instead of 'II'.  We'll fully resolve the
+  // lookup during template instantiation.
+  S.Diag(NameLoc, diag::ext_found_via_dependent_bases_lookup) << &II;
+
+  ASTContext &Context = S.Context;
+  auto *NNS = NestedNameSpecifier::Create(Context, nullptr, false,
+  cast(Context.getRecordType(RD)));
+  QualType T = Context.getDependentNameType(ETK_Typename, NNS, &II);
+
+  CXXScopeSpec SS;
+  SS.MakeTrivial(Context, NNS, SourceRange(NameLoc));
+
+  TypeLocBuilder Builder;
+  DependentNameTypeLoc DepTL = Builder.push(T);
+  DepTL.setNameLoc(NameLoc);
+  DepTL.setElaboratedKeywordLoc(SourceLocation());
+  DepTL.setQualifierLoc(SS.getWithLocInContext(Context));
+  return S.CreateParsedType(T, Builder.getTypeSourceInfo(Context, T));
+}
+
 /// \brief If the identifier refers to a type name within this scope,
 /// return the declaration of that type.
 ///
@@ -209,6 +259,14 @@
   } else {
 // Perform unqualified name lookup.
 LookupName(Result, S);
+
+// For unqualified lookup in a class template in MSVC mode, look into
+// dependent base classes where the primary class template is known.
+if (Result.empty() && getLangOpts().MSVCCompat && (!SS || SS->isEmpty())) {
+  if (ParsedType TypeInBase =
+  recoverFromTypeInKnownDependentBase(*this, II, NameLoc))
+return TypeInBase;
+}
   }
 
   NamedDecl *IIDecl = nullptr;
@@ -630,6 +688,14 @@
   LookupResult Result(*this, Name, NameLoc, LookupOrdinaryName);
   LookupParsedName(Result, S, &SS, !CurMethod);
 
+  // For unqualified lookup in a class template in MSVC mode, look into
+  // dependent base classes where the primary class template is known.
+  if (Result.empty() && SS.isEmpty() && getLangOpts().MSVCCompat) {
+if (ParsedType TypeInBase =
+recoverFromTypeInKnownDependentBase(*this, *Name, NameLoc))
+  return TypeInBase;
+  }
+
   // Perform lookup for Objective-C instance variables (including automatically 
   // synthesized instance variables), if we're in an Objective-C method.
   // FIXME: This lookup really, really needs to be folded in to the normal
Index: cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp
===
--- cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp
+++ cfe/trunk/test/SemaTemplate/ms-lookup-template-base-classes.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++11 -fms-compatibility -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++1y -fms-compatibility -fsyntax-only -verify %s
 
 
 template 
@@ -275,3 +275,184 @@
 };
 template struct Derived;
 }
+
+namespace typedef_in_base {
+template  struct A { typedef T NameFromBase; };
+template  struct B : A {
+  NameFromBase m; // expected-warning {{found via unqualified lookup into dependent bases}}
+};
+static_assert(sizeof(B) == 4, "");
+}
+
+namespace struct_in_base {
+template  struct A { struct NameFromBase {}; };
+template  struct B : A {
+  NameFromBase m; // expected-warning {{found via unqualified lookup into dependent bases}}
+};
+static_assert(sizeof(B) == 1, "");
+}
+
+namespace enum_in_base {
+template  struct A { enum NameFromBase { X }; };
+template  struct B : A {
+  NameFromBase m; // expected-warning {{found via unqualified lookup into dependent bases}}
+};
+static_assert(sizeof(B) == sizeof(A::NameFromBase), "");
+}
+
+namespace two_types_in_base {

Re: [PATCH] Fix for Bug 19480 -- Adding a test case.

[Richard Smith]

Comment at: test/CodeGenCXX/cxx1y-variable-template-linkage.cpp:9
@@ +8,3 @@
+// File A
+#ifdef FILEA
+

Instead of `#ifdef`s, can you merge together the two parts of this file into 
one? The small amount of the test that differs between the modes can be guarded 
by

#if __has_feature(cxx_exceptions)

http://reviews.llvm.org/D4362



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Allow more lookup of types in dependent base classes

[Reid Kleckner]

thanks!


Comment at: test/SemaTemplate/ms-lookup-template-base-classes.cpp:383
@@ +382,3 @@
+
+namespace lookup_in_function_contexts {
+template  struct A { typedef T NameFromBase; };

Richard Smith wrote:
> Do you have any tests here for lookup in late-parsed function bodies? (I 
> expect that'll fail too, and probably shouldn't.)
Hm, as I add these test cases, I'm starting to think we should generalize the 
lookup recovery like you suggested.  I'll commit this change with more tests 
and send you a new patch to generalize the check.  I'm a more worried because 
we need to loop over parent DeclContexts to do correct lookup, which I'm less 
confident about.

http://reviews.llvm.org/D4237



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Avoid crash if default argument parsed with errors.

[Richard Smith]

On Thu, Jul 3, 2014 at 11:43 AM, Serge Pavlov  wrote:

> If function parameters have default values, and that of the second
> parameter is parsed with errors, function declaration would have
> a parameter without default value that follows a parameter with
> that. Such declaration breaks logic of selecting overloaded
> function.
>
> As a solution, erase default value of all parameters that precedes
> the erroneous parameter.
>
> This patch fixes PR20055.
>
> http://reviews.llvm.org/D4378
>
> Files:
>   lib/Sema/SemaDecl.cpp
>   test/SemaCXX/default1.cpp
>
> Index: lib/Sema/SemaDecl.cpp
> ===
> --- lib/Sema/SemaDecl.cpp
> +++ lib/Sema/SemaDecl.cpp
> @@ -7074,15 +7074,25 @@
>  // single void argument.
>  // We let through "const void" here because Sema::GetTypeForDeclarator
>  // already checks for that case.
> +ParmVarDecl *Prev = nullptr;
>  if (FTIHasNonVoidParameters(FTI) && FTI.Params[0].Param) {
>for (unsigned i = 0, e = FTI.NumParams; i != e; ++i) {
>  ParmVarDecl *Param = cast(FTI.Params[i].Param);
>  assert(Param->getDeclContext() != NewFD && "Was set before ?");
>  Param->setDeclContext(NewFD);
>  Params.push_back(Param);
>
> -if (Param->isInvalidDecl())
> +if (Param->isInvalidDecl()) {
>NewFD->setInvalidDecl();
> +  if (!Param->hasDefaultArg() && Prev && Prev->hasDefaultArg()) {
> +for (unsigned j = i; j != 0; --j) {
> +  ParmVarDecl *Param = cast(FTI.Params[j -
> 1].Param);
> +  if (!Param->hasDefaultArg()) break;
> +  Param->setDefaultArg(nullptr);
> +}
> +  }
> +}
> +Prev = Param;
>}
>  }
>
> Index: test/SemaCXX/default1.cpp
> ===
> --- test/SemaCXX/default1.cpp
> +++ test/SemaCXX/default1.cpp
> @@ -62,3 +62,7 @@
>  j(2, 3); // expected-error{{too many arguments to function call,
> expected at most single argument 'f', have 2}}
>}
>  }
> +
> +int pr20055_f(int x = 0, int y = UNDEFINED); // expected-error{{use of
> undeclared identifier}} \
> + // expected-note{{candidate
> function not viable}}
> +int pr20055_v = pr20055_f(0); // expected-error{{no matching function for
> call}}


This error recovery doesn't seem ideal. Perhaps instead we could create an
OpaqueValueExpr of the appropriate type to represent a default argument
that couldn't be parsed?
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH, PowerPC] ABI fixes / improvements for powerpc64-linux

[Hal Finkel]

- Original Message -
> From: "Ulrich Weigand" 
> To: "cfe commits" 
> Cc: "Hal Finkel" 
> Sent: Tuesday, July 8, 2014 12:11:16 PM
> Subject: [PATCH, PowerPC] ABI fixes / improvements for powerpc64-linux
> 
> 
> 
> Hello,
> 
> I've been working to verify ABI compatibility between GCC and LLVM on
> powerpc64-linux using the GCC ABI compatibility test suite.  While
> for the
> most part, the compilers are of course compatible in the "usual"
> scenarios,
> this testing uncovered a number of bugs in corner-case situations.  [
> Some
> of these are actually GCC bugs which I'll be addressing on that side.
>  ]

Great! Thanks for working on this.

> 
> In LLVM, the main issues I found are fixed by the patches attached
> here.
> There are three issues (which are somewhat independent, but the
> patches
> build on top of each other so I'll send them all in one mail):
> 
> - "synthetic" (non-Altivec) vector types
> 
> LLVM currently does not correctly implement the ABI for passing
> non-Altivec
> vector types (defined via attribute((vector_size))).  While there is
> no
> "official" ABI for these in any case, it still would make sense to
> implement the ad-hoc ABI as implemented by GCC for those types.  This
> is
> done by the following patch:
> (See attached file: diff-clang-synthvector)

+// Return true if Ty represents an Altivec (or VSX) vector type.
+bool
+PPC64_SVR4_ABIInfo::isAltivecVectorType(const Type *Ty) const {
+  if (const VectorType *VT = Ty->getAs()) {
+// We accept all vector types that are 16 bytes in size
+// and have a power-of-two number of elements.
+unsigned NumElements = VT->getNumElements();
+uint64_t Size = getContext().getTypeSize(VT);
+
+if ((NumElements & (NumElements - 1)) == 0 && Size == 128)
+  return true;
+  }
+
+  return false;
+}

Why are we restricting to power-of-two element numbers? <3 x float> will become 
a <4 x float> and end up in vector registers anyhow.

@@ -2951,6 +2972,22 @@ PPC64_SVR4_ABIInfo::classifyArgumentType
   if (Ty->isAnyComplexType())
 return ABIArgInfo::getDirect();
 
+  // Non-Altivec vector types are passed in GPRs (up to 16 bytes)
+  // or via reference (larger than 16 bytes).
+  if (Ty->isVectorType() && !isAltivecVectorType(Ty)) {
+uint64_t Size = getContext().getTypeSize(Ty);
+if (Size > 128)
+  return ABIArgInfo::getIndirect(0, /*ByVal=*/false);
+else if (Size > 64) {
+  llvm::Type *CoerceTy = llvm::IntegerType::get(getVMContext(), 64);
+  CoerceTy = llvm::StructType::get(CoerceTy, CoerceTy, NULL);
+  return ABIArgInfo::getDirect(CoerceTy);
+} else {
+  llvm::Type *CoerceTy = llvm::IntegerType::get(getVMContext(), Size);
+  return ABIArgInfo::getDirect(CoerceTy);
+}
+  }
+
   if (isAggregateTypeForABI(Ty)) {
 if (CGCXXABI::RecordArgABI RAA = getRecordArgABI(Ty, getCXXABI()))
   return ABIArgInfo::getIndirect(0, RAA == CGCXXABI::RAA_DirectInMemory);
@@ -2970,6 +3007,22 @@ PPC64_SVR4_ABIInfo::classifyReturnType(Q
   if (RetTy->isAnyComplexType())
 return ABIArgInfo::getDirect();
 
+  // Non-Altivec vector types are returned in GPRs (up to 16 bytes)
+  // or via reference (larger than 16 bytes).
+  if (RetTy->isVectorType() && !isAltivecVectorType(RetTy)) {
+uint64_t Size = getContext().getTypeSize(RetTy);
+if (Size > 128)
+  return ABIArgInfo::getIndirect(0);
+else if (Size > 64) {
+  llvm::Type *CoerceTy = llvm::IntegerType::get(getVMContext(), 64);
+  CoerceTy = llvm::StructType::get(CoerceTy, CoerceTy, NULL);
+  return ABIArgInfo::getDirect(CoerceTy);
+} else {
+  llvm::Type *CoerceTy = llvm::IntegerType::get(getVMContext(), Size);
+  return ABIArgInfo::getDirect(CoerceTy);
+}
+  }
+
   if (isAggregateTypeForABI(RetTy))
 return ABIArgInfo::getIndirect(0);

These two hunks are very similar, can they be refactored into a single function?

Please add some tests for non-power-of-two-number-of-elements types.

> 
> - Alignment of arguments in the parameter save area
> 
> Certain arguments are supposed to be aligned to a 16-byte boundary in
> the
> argument save area.  This affects vector types as well as aggregates
> that
> have a 16-byte (or higher) alignment requirement.  LLVM currently
> implements this alignment for vector types, but not for aggregates,
> and it
> does not respect the alignment at all (even for vector types) when
> accessing a variable argument list via va_arg.
> 
> Aggregates are passed using the "byval" mechanism, so in theory
> either
> Clang or LLVM could compute the correct alignment required for an
> aggregate
> parameter.  However, it seems preferable to do this in Clang, since
> it has
> the more complete type information, and Clang needs the information
> anyway
> in order to expand va_arg correctly.  So this is what the following
> patch
> does.  As a result, every byval parameter will now carry an explicit
> "align" attribute in the IR created by Clang (which I understand is
> recommended 

Re: r212512 - Headers: conditionalise more declarations

[Reid Kleckner]

As mentioned on IRC, we should just merge this with
test/Headers/ms-intrin.cpp with another RUN line for WoA.


On Mon, Jul 7, 2014 at 10:46 PM, Saleem Abdulrasool 
wrote:

> Author: compnerd
> Date: Tue Jul  8 00:46:04 2014
> New Revision: 212512
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212512&view=rev
> Log:
> Headers: conditionalise more declarations
>
> Protect MMX specific declarations under a __MMX__ guard.  This header can
> be
> included on non-x86 architectures (e.g. ARM) which do not support the MMX
> ISA.
> Use the preprocessor to prevent these declarations from being processed.
>
> Added:
> cfe/trunk/test/Headers/arm-intrin.c
> Modified:
> cfe/trunk/lib/Headers/Intrin.h
>
> Modified: cfe/trunk/lib/Headers/Intrin.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=212512&r1=212511&r2=212512&view=diff
>
> ==
> --- cfe/trunk/lib/Headers/Intrin.h (original)
> +++ cfe/trunk/lib/Headers/Intrin.h Tue Jul  8 00:46:04 2014
> @@ -41,12 +41,14 @@
>  extern "C" {
>  #endif
>
> +#if defined(__MMX__)
>  /* And the random ones that aren't in those files. */
>  __m64 _m_from_float(float);
>  __m64 _m_from_int(int _l);
>  void _m_prefetch(void *);
>  float _m_to_float(__m64);
>  int _m_to_int(__m64 _M);
> +#endif
>
>  /* Other assorted instruction intrinsics. */
>  void __addfsbyte(unsigned long, unsigned char);
>
> Added: cfe/trunk/test/Headers/arm-intrin.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/arm-intrin.c?rev=212512&view=auto
>
> ==
> --- cfe/trunk/test/Headers/arm-intrin.c (added)
> +++ cfe/trunk/test/Headers/arm-intrin.c Tue Jul  8 00:46:04 2014
> @@ -0,0 +1,6 @@
> +// RUN: %clang -target armv7-windows -I %S/Inputs/include -Xclang -verify
> -E %s
> +// expected-no-diagnostics
> +
> +typedef __SIZE_TYPE__ size_t;
> +#include 
> +
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [libcxx] Take advantage of gcc4.7 frontend support in type_traits

[Albert Wong]

gentle ping...

http://reviews.llvm.org/D4340



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r200344 - Intrin.h: include setjmp.h to get a jmp_buf definition

[Nico Weber]

r212557, thanks!


On Tue, Jul 8, 2014 at 11:29 AM, Reid Kleckner  wrote:

> On Tue, Jul 8, 2014 at 11:08 AM, Nico Weber  wrote:
>
>> Two zombie review comments below.
>>
>> On Tue, Jan 28, 2014 at 3:01 PM, Hans Wennborg  wrote:
>>
>>> Author: hans
>>> Date: Tue Jan 28 17:01:59 2014
>>> New Revision: 200344
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=200344&view=rev
>>> Log:
>>> Intrin.h: include setjmp.h to get a jmp_buf definition
>>>
>>> This makes sure that the ms-intrin.cpp test passes by providing
>>> a mock setjmp.h as a test input.
>>>
>>> Added:
>>> cfe/trunk/test/Headers/Inputs/include/setjmp.h
>>> Modified:
>>> cfe/trunk/lib/Headers/Intrin.h
>>> cfe/trunk/test/Headers/ms-intrin.cpp
>>>
>>> Modified: cfe/trunk/lib/Headers/Intrin.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=200344&r1=200343&r2=200344&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Headers/Intrin.h (original)
>>> +++ cfe/trunk/lib/Headers/Intrin.h Tue Jan 28 17:01:59 2014
>>> @@ -32,6 +32,9 @@
>>>  /* First include the standard intrinsics. */
>>>  #include 
>>>
>>> +/* For the definition of jmp_buf. */
>>> +#include 
>>>
>>
>> Should this (and the functions below) be behind a #if __STDC_HOSTED__,
>> like the stdlib.h include in xmmintrin.h? (My use case is that I sometimes
>> use clang-cl with -Xclang -ffreestanding on a non-Windows machine, and that
>> doesn't work because of this include. It's arguably a somewhat strange use
>> case, given that -ffreestanding is a cc1 flag.)
>>
>
> Yeah, let's do that.  clang -cc1 -ffreestanding should be able to include
>  without pulling in crt headers.
>
>
>>  +
>>>  #ifdef __cplusplus
>>>  extern "C" {
>>>  #endif
>>> @@ -279,10 +282,7 @@ unsigned __int64 __cdecl _rotr64(unsigne
>>>  static __inline__
>>>  unsigned char _rotr8(unsigned char _Value, unsigned char _Shift);
>>>  int _sarx_i32(int, unsigned int);
>>> -
>>> -/* FIXME: Need definition for jmp_buf.
>>> -   int __cdecl _setjmp(jmp_buf); */
>>>
>>
>> There's another FIXME like this in the 64bit section below; should that
>> go away too?
>>
>
> Sure.
>
>
>>
>>
>>> -
>>> +int __cdecl _setjmp(jmp_buf);
>>>  unsigned int _shlx_u32(unsigned int, unsigned int);
>>>  unsigned int _shrx_u32(unsigned int, unsigned int);
>>>  void _Store_HLERelease(long volatile *, long);
>>>
>>> Added: cfe/trunk/test/Headers/Inputs/include/setjmp.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/Inputs/include/setjmp.h?rev=200344&view=auto
>>>
>>> ==
>>> --- cfe/trunk/test/Headers/Inputs/include/setjmp.h (added)
>>> +++ cfe/trunk/test/Headers/Inputs/include/setjmp.h Tue Jan 28 17:01:59
>>> 2014
>>> @@ -0,0 +1,8 @@
>>> +#ifndef SETJMP_H
>>> +#define SETJMP_H
>>> +
>>> +typedef struct {
>>> +  int x[42];
>>> +} jmp_buf;
>>> +
>>> +#endif
>>>
>>> Modified: cfe/trunk/test/Headers/ms-intrin.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/ms-intrin.cpp?rev=200344&r1=200343&r2=200344&view=diff
>>>
>>> ==
>>> --- cfe/trunk/test/Headers/ms-intrin.cpp (original)
>>> +++ cfe/trunk/test/Headers/ms-intrin.cpp Tue Jan 28 17:01:59 2014
>>> @@ -1,6 +1,7 @@
>>>  // RUN: %clang_cc1 -triple i386-pc-win32 -target-cpu pentium4 \
>>>  // RUN: -fms-extensions -fms-compatibility -fmsc-version=1700 \
>>> -// RUN: -ffreestanding -fsyntax-only -Werror %s
>>> +// RUN: -ffreestanding -fsyntax-only -Werror \
>>> +// RUN: -isystem %S/Inputs/include %s
>>>
>>>  // Intrin.h needs size_t, but -ffreestanding prevents us from getting
>>> it from
>>>  // stddef.h.  Work around it with this typedef.
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212557 - Don't pull in setjmp.h in -ffreestanding compiles.

[Nico Weber]

Author: nico
Date: Tue Jul  8 13:34:46 2014
New Revision: 212557

URL: http://llvm.org/viewvc/llvm-project?rev=212557&view=rev
Log:
Don't pull in setjmp.h in -ffreestanding compiles.

Also provide _setjmpex(). r200243 put in _setjmp() and _setjmpex() behind a
comment since jmp_buf wasn't available. r200344 added jmp_buf and put in
_setjmp(), but missed _setjmpex().

Modified:
cfe/trunk/lib/Headers/Intrin.h

Modified: cfe/trunk/lib/Headers/Intrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=212557&r1=212556&r2=212557&view=diff
==
--- cfe/trunk/lib/Headers/Intrin.h (original)
+++ cfe/trunk/lib/Headers/Intrin.h Tue Jul  8 13:34:46 2014
@@ -35,7 +35,9 @@
 #endif
 
 /* For the definition of jmp_buf. */
+#if __STDC_HOSTED__
 #include 
+#endif
 
 #ifdef __cplusplus
 extern "C" {
@@ -291,7 +293,9 @@ unsigned __int64 __cdecl _rotr64(unsigne
 static __inline__
 unsigned char _rotr8(unsigned char _Value, unsigned char _Shift);
 int _sarx_i32(int, unsigned int);
+#if __STDC_HOSTED__
 int __cdecl _setjmp(jmp_buf);
+#endif
 unsigned int _shlx_u32(unsigned int, unsigned int);
 unsigned int _shrx_u32(unsigned int, unsigned int);
 void _Store_HLERelease(long volatile *, long);
@@ -449,8 +453,9 @@ unsigned int __cdecl _readgsbase_u32(voi
 unsigned __int64 __cdecl _readgsbase_u64(void);
 unsigned __int64 _rorx_u64(unsigned __int64, const unsigned int);
 __int64 _sarx_i64(__int64, unsigned int);
-/* FIXME: Need definition for jmp_buf.
-  int __cdecl _setjmpex(jmp_buf); */
+#if __STDC_HOSTED__
+int __cdecl _setjmpex(jmp_buf);
+#endif
 unsigned __int64 _shlx_u64(unsigned __int64, unsigned int);
 unsigned __int64 shrx_u64(unsigned __int64, unsigned int);
 unsigned __int64 _tzcnt_u64(unsigned __int64);


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212556 - Replace a few // comments with /**/ comments in headers, for consistency.

[Nico Weber]

Author: nico
Date: Tue Jul  8 13:29:27 2014
New Revision: 212556

URL: http://llvm.org/viewvc/llvm-project?rev=212556&view=rev
Log:
Replace a few // comments with /**/ comments in headers, for consistency.

Modified:
cfe/trunk/lib/Headers/x86intrin.h
cfe/trunk/lib/Headers/xmmintrin.h

Modified: cfe/trunk/lib/Headers/x86intrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/x86intrin.h?rev=212556&r1=212555&r2=212556&view=diff
==
--- cfe/trunk/lib/Headers/x86intrin.h (original)
+++ cfe/trunk/lib/Headers/x86intrin.h Tue Jul  8 13:29:27 2014
@@ -76,6 +76,6 @@
 #include 
 #endif
 
-// FIXME: LWP
+/* FIXME: LWP */
 
 #endif /* __X86INTRIN_H */

Modified: cfe/trunk/lib/Headers/xmmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/xmmintrin.h?rev=212556&r1=212555&r2=212556&view=diff
==
--- cfe/trunk/lib/Headers/xmmintrin.h (original)
+++ cfe/trunk/lib/Headers/xmmintrin.h Tue Jul  8 13:29:27 2014
@@ -34,8 +34,8 @@ typedef int __v4si __attribute__((__vect
 typedef float __v4sf __attribute__((__vector_size__(16)));
 typedef float __m128 __attribute__((__vector_size__(16)));
 
-// This header should only be included in a hosted environment as it depends on
-// a standard library to provide allocation routines.
+/* This header should only be included in a hosted environment as it depends on
+ * a standard library to provide allocation routines. */
 #if __STDC_HOSTED__
 #include 
 #endif
@@ -589,7 +589,7 @@ _mm_set1_ps(float __w)
   return (__m128){ __w, __w, __w, __w };
 }
 
-// Microsoft specific.
+/* Microsoft specific. */
 static __inline__ __m128 __attribute__((__always_inline__, __nodebug__))
 _mm_set_ps1(float __w)
 {


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [libcxxabi] Add lit configs for libcxxabi tests.

[Dan Albert]

Some cleanup: now uses add_lit_testsuiite(), use find_path() to determine 
libcxx include directories (which also fixes a bug caused by relative paths).
Address some review comments.

http://reviews.llvm.org/D4414

Files:
  CMakeLists.txt
  src/CMakeLists.txt
  test/CMakeLists.txt
  test/lit.cfg
  test/lit.site.cfg.in
  www/index.html
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -53,6 +53,7 @@
   if(EXISTS ${LLVMCONFIG_FILE})
 list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
 include(${LLVMCONFIG_FILE})
+include("${LLVM_CMAKE_PATH}/AddLLVM.cmake")
   else()
 message(FATAL_ERROR "Not found: ${LLVMCONFIG_FILE}")
   endif()
@@ -91,6 +92,8 @@
   set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
 
   set(LIBCXXABI_BUILT_STANDALONE 1)
+else()
+  set(LLVM_LIT "${CMAKE_SOURCE_DIR}/utils/lit/lit.py")
 endif()
 
 #===
@@ -101,7 +104,26 @@
 option(LIBCXXABI_ENABLE_ASSERTIONS "Enable assertions independent of build mode." ON)
 option(LIBCXXABI_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
 option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
-option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." OFF)
+
+# Default to building a shared library so that the default options still test
+# the libc++abi that is being built. There are two problems with testing a
+# static libc++abi. In the case of a standalone build, the tests will link the
+# system's libc++, which might not have been built against our libc++abi. In the
+# case of an in tree build, libc++ will prefer a dynamic libc++abi from the
+# system over a static libc++abi from the output directory.
+option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
+
+find_path(
+  LIBCXXABI_LIBCXX_INCLUDES
+  vector
+  PATHS ${LIBCXXABI_LIBCXX_INCLUDES}
+${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBCXX_INCLUDES}
+${LLVM_MAIN_SRC_DIR}/projects/libcxx/include
+${LLVM_INCLUDE_DIR}/c++/v1
+  )
+
+set(LIBCXXABI_LIBCXX_INCLUDES "${LIBCXXABI_LIBCXX_INCLUDES}" CACHE STRING
+"Specify path to libc++ includes." FORCE)
 
 #===
 # Configure System
@@ -210,3 +232,16 @@
 # Add source code. This also contains all of the logic for deciding linker flags
 # soname, etc...
 add_subdirectory(src)
+
+if(NOT LIBCXXABI_ENABLE_SHARED)
+  # TODO: Fix the libc++ cmake files so that libc++abi can be statically linked.
+  # As it is now, libc++ will prefer linking against a dynamic libc++abi in the
+  # system library paths over a static libc++abi in the out directory. This
+  # would test the system library rather than the one we just built, which isn't
+  # very helpful.
+  message(WARNING "The libc++abi tests are currently only valid when "
+  "LIBCXXABI_ENABLE_SHARED is on, no check target will be "
+  "available!")
+else()
+  add_subdirectory(test)
+endif()
Index: src/CMakeLists.txt
===
--- src/CMakeLists.txt
+++ src/CMakeLists.txt
@@ -48,13 +48,7 @@
 )
 endif()
 
-if (LIBCXXABI_LIBCXX_INCLUDES)
-  include_directories("${LIBCXXABI_LIBCXX_INCLUDES}")
-elseif (NOT LIBCXXABI_BUILT_STANDALONE)
-  include_directories("${LLVM_MAIN_SRC_DIR}/projects/libcxx/include")
-else()
-  include_directories("${LLVM_INCLUDE_DIR}/c++/v1")
-endif()
+include_directories("${LIBCXXABI_LIBCXX_INCLUDES}")
 
 # Generate library list.
 set(libraries ${LIBCXXABI_CXX_ABI_LIBRARIES})
Index: test/CMakeLists.txt
===
--- /dev/null
+++ test/CMakeLists.txt
@@ -0,0 +1,28 @@
+macro(pythonize_bool var)
+  if (${var})
+set(${var} True)
+  else()
+set(${var} False)
+  endif()
+endmacro()
+
+set(LIBCXXABI_COMPILER ${CMAKE_CXX_COMPILER})
+set(LIBCXXABI_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/..)
+set(LIBCXXABI_BINARY_DIR ${CMAKE_BINARY_DIR})
+pythonize_bool(LIBCXXABI_ENABLE_SHARED)
+
+set(AUTO_GEN_COMMENT "## Autogenerated by libcxxabi configuration.\n# Do not edit!")
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+  @ONLY)
+
+set(LIBCXXABI_TEST_DEPS cxxabi)
+if (NOT LIBCXXABI_BUILT_STANDALONE)
+  list(APPEND LIBCXXABI_TEST_DEPS cxx)
+endif()
+
+add_lit_testsuite(check-libcxxabi "Running libcxxabi tests"
+  ${CMAKE_CURRENT_BINARY_DIR}
+  DEPENDS ${LIBCXXABI_TEST_DEPS}
+  )
Index: test/lit.cfg
===
--- /dev/null
+++ test/lit.cfg
@@ -0,0 +1,236 @@
+# -*- Python -*- vim: set syntax=python tabstop=4 expandtab cc=80:
+
+# Configuration file for the 'lit' test runner.
+
+import errno
+import os
+import platform
+import re
+import shlex
+import signal
+import subprocess
+import sys
+import tempfile
+import time
+
+i

Re: r200344 - Intrin.h: include setjmp.h to get a jmp_buf definition

[Reid Kleckner]

On Tue, Jul 8, 2014 at 11:08 AM, Nico Weber  wrote:

> Two zombie review comments below.
>
> On Tue, Jan 28, 2014 at 3:01 PM, Hans Wennborg  wrote:
>
>> Author: hans
>> Date: Tue Jan 28 17:01:59 2014
>> New Revision: 200344
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=200344&view=rev
>> Log:
>> Intrin.h: include setjmp.h to get a jmp_buf definition
>>
>> This makes sure that the ms-intrin.cpp test passes by providing
>> a mock setjmp.h as a test input.
>>
>> Added:
>> cfe/trunk/test/Headers/Inputs/include/setjmp.h
>> Modified:
>> cfe/trunk/lib/Headers/Intrin.h
>> cfe/trunk/test/Headers/ms-intrin.cpp
>>
>> Modified: cfe/trunk/lib/Headers/Intrin.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=200344&r1=200343&r2=200344&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Headers/Intrin.h (original)
>> +++ cfe/trunk/lib/Headers/Intrin.h Tue Jan 28 17:01:59 2014
>> @@ -32,6 +32,9 @@
>>  /* First include the standard intrinsics. */
>>  #include 
>>
>> +/* For the definition of jmp_buf. */
>> +#include 
>>
>
> Should this (and the functions below) be behind a #if __STDC_HOSTED__,
> like the stdlib.h include in xmmintrin.h? (My use case is that I sometimes
> use clang-cl with -Xclang -ffreestanding on a non-Windows machine, and that
> doesn't work because of this include. It's arguably a somewhat strange use
> case, given that -ffreestanding is a cc1 flag.)
>

Yeah, let's do that.  clang -cc1 -ffreestanding should be able to include
 without pulling in crt headers.


> +
>>  #ifdef __cplusplus
>>  extern "C" {
>>  #endif
>> @@ -279,10 +282,7 @@ unsigned __int64 __cdecl _rotr64(unsigne
>>  static __inline__
>>  unsigned char _rotr8(unsigned char _Value, unsigned char _Shift);
>>  int _sarx_i32(int, unsigned int);
>> -
>> -/* FIXME: Need definition for jmp_buf.
>> -   int __cdecl _setjmp(jmp_buf); */
>>
>
> There's another FIXME like this in the 64bit section below; should that go
> away too?
>

Sure.


>
>
>> -
>> +int __cdecl _setjmp(jmp_buf);
>>  unsigned int _shlx_u32(unsigned int, unsigned int);
>>  unsigned int _shrx_u32(unsigned int, unsigned int);
>>  void _Store_HLERelease(long volatile *, long);
>>
>> Added: cfe/trunk/test/Headers/Inputs/include/setjmp.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/Inputs/include/setjmp.h?rev=200344&view=auto
>>
>> ==
>> --- cfe/trunk/test/Headers/Inputs/include/setjmp.h (added)
>> +++ cfe/trunk/test/Headers/Inputs/include/setjmp.h Tue Jan 28 17:01:59
>> 2014
>> @@ -0,0 +1,8 @@
>> +#ifndef SETJMP_H
>> +#define SETJMP_H
>> +
>> +typedef struct {
>> +  int x[42];
>> +} jmp_buf;
>> +
>> +#endif
>>
>> Modified: cfe/trunk/test/Headers/ms-intrin.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/ms-intrin.cpp?rev=200344&r1=200343&r2=200344&view=diff
>>
>> ==
>> --- cfe/trunk/test/Headers/ms-intrin.cpp (original)
>> +++ cfe/trunk/test/Headers/ms-intrin.cpp Tue Jan 28 17:01:59 2014
>> @@ -1,6 +1,7 @@
>>  // RUN: %clang_cc1 -triple i386-pc-win32 -target-cpu pentium4 \
>>  // RUN: -fms-extensions -fms-compatibility -fmsc-version=1700 \
>> -// RUN: -ffreestanding -fsyntax-only -Werror %s
>> +// RUN: -ffreestanding -fsyntax-only -Werror \
>> +// RUN: -isystem %S/Inputs/include %s
>>
>>  // Intrin.h needs size_t, but -ffreestanding prevents us from getting it
>> from
>>  // stddef.h.  Work around it with this typedef.
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212555 - Sema: Don't allow CVR qualifiers before structors

[David Majnemer]

Author: majnemer
Date: Tue Jul  8 13:18:04 2014
New Revision: 212555

URL: http://llvm.org/viewvc/llvm-project?rev=212555&view=rev
Log:
Sema: Don't allow CVR qualifiers before structors

We would silently accept volatile ~S() when the user probably intended
to write virtual ~S().

This fixes PR20238.

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/SemaCXX/constructor.cpp
cfe/trunk/test/SemaCXX/destructor.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=212555&r1=212554&r2=212555&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jul  8 13:18:04 2014
@@ -1556,6 +1556,14 @@ public:
   bool diagnoseQualifiedDeclaration(CXXScopeSpec &SS, DeclContext *DC,
 DeclarationName Name,
 SourceLocation Loc);
+  void
+  diagnoseIgnoredQualifiers(unsigned DiagID, unsigned Quals,
+SourceLocation FallbackLoc,
+SourceLocation ConstQualLoc = SourceLocation(),
+SourceLocation VolatileQualLoc = SourceLocation(),
+SourceLocation RestrictQualLoc = SourceLocation(),
+SourceLocation AtomicQualLoc = SourceLocation());
+
   static bool adjustContextForLocalExternDecl(DeclContext *&DC);
   void DiagnoseFunctionSpecifiers(const DeclSpec &DS);
   void CheckShadow(Scope *S, VarDecl *D, const LookupResult& R);

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=212555&r1=212554&r2=212555&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Jul  8 13:18:04 2014
@@ -6279,6 +6279,15 @@ QualType Sema::CheckConstructorDeclarato
 SC = SC_None;
   }
 
+  if (unsigned TypeQuals = D.getDeclSpec().getTypeQualifiers()) {
+diagnoseIgnoredQualifiers(
+diag::err_constructor_return_type, TypeQuals, SourceLocation(),
+D.getDeclSpec().getConstSpecLoc(), 
D.getDeclSpec().getVolatileSpecLoc(),
+D.getDeclSpec().getRestrictSpecLoc(),
+D.getDeclSpec().getAtomicSpecLoc());
+D.setInvalidType();
+  }
+
   DeclaratorChunk::FunctionTypeInfo &FTI = D.getFunctionTypeInfo();
   if (FTI.TypeQuals != 0) {
 if (FTI.TypeQuals & Qualifiers::Const)
@@ -6426,7 +6435,7 @@ QualType Sema::CheckDestructorDeclarator
 
 SC = SC_None;
   }
-  if (D.getDeclSpec().hasTypeSpecifier() && !D.isInvalidType()) {
+  if (!D.isInvalidType()) {
 // Destructors don't have return types, but the parser will
 // happily parse something like:
 //
@@ -6435,9 +6444,19 @@ QualType Sema::CheckDestructorDeclarator
 //   };
 //
 // The return type will be eliminated later.
-Diag(D.getIdentifierLoc(), diag::err_destructor_return_type)
-  << SourceRange(D.getDeclSpec().getTypeSpecTypeLoc())
-  << SourceRange(D.getIdentifierLoc());
+if (D.getDeclSpec().hasTypeSpecifier())
+  Diag(D.getIdentifierLoc(), diag::err_destructor_return_type)
+<< SourceRange(D.getDeclSpec().getTypeSpecTypeLoc())
+<< SourceRange(D.getIdentifierLoc());
+else if (unsigned TypeQuals = D.getDeclSpec().getTypeQualifiers()) {
+  diagnoseIgnoredQualifiers(diag::err_destructor_return_type, TypeQuals,
+SourceLocation(),
+D.getDeclSpec().getConstSpecLoc(),
+D.getDeclSpec().getVolatileSpecLoc(),
+D.getDeclSpec().getRestrictSpecLoc(),
+D.getDeclSpec().getAtomicSpecLoc());
+  D.setInvalidType();
+}
   }
 
   DeclaratorChunk::FunctionTypeInfo &FTI = D.getFunctionTypeInfo();

Modified: cfe/trunk/lib/Sema/SemaType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaType.cpp?rev=212555&r1=212554&r2=212555&view=diff
==
--- cfe/trunk/lib/Sema/SemaType.cpp (original)
+++ cfe/trunk/lib/Sema/SemaType.cpp Tue Jul  8 13:18:04 2014
@@ -1989,18 +1989,15 @@ static void inferARCWriteback(TypeProces
   // TODO: mark whether we did this inference?
 }
 
-static void diagnoseIgnoredQualifiers(
-Sema &S, unsigned Quals,
-SourceLocation FallbackLoc,
-SourceLocation ConstQualLoc = SourceLocation(),
-SourceLocation VolatileQualLoc = SourceLocation(),
-SourceLocation RestrictQualLoc = SourceLocation(),
-SourceLocation AtomicQualLoc = SourceLocation()) {
+void Sema::diagnoseIgnoredQualifiers(unsigned DiagID, unsigned Quals,
+   

Re: [PATCH] Bugs in SemaOverload.cpp

[Richard Smith]

I like Alp's suggestion of a .def file: the duplication and distribution of
this information has been a (low level) annoyance for quite some time and
it'd be good to properly fix it.


On Wed, Jul 2, 2014 at 1:09 AM, Dmitry Babokin  wrote:

> Alp,
>
> To me both approaches look good, as they are eliminating possibility of
> future errors. I don't have preference for one or another. I think it's up
> to file maintainers (Richard?) to decide what approach to follow.
>
> By the way, my patch also contains fixes for missing cases in these
> routines. Are these fixes matches with what you have in your changes? Do
> they look correct to you?
>
> Dmitry.
>
>
> On Tue, Jul 1, 2014 at 11:33 PM, Alp Toker  wrote:
>
>>
>> On 01/07/2014 22:00, Alp Toker wrote:
>>
>>> Hi Dmitry,
>>>
>>> I agree the current setup isn't ideal.
>>>
>>> An alternative to your approach is to convert this into an X macro table
>>> (or just a big rectangular array perhaps). Something like:
>>>
>>> ImplicitConversions.def:
>>>
>>>   IC(Kind, Name, Category, Rank):
>>>   IC(Identity, "No conversion", Identity, Exact_Match)
>>>   IC(Lvalue_To_Rvalue, "Lvalue-to-rvalue", Lvalue_Transformation,
>>> Exact_Match)
>>>   ...
>>>
>>>
>> In other words, that'd be similar to what we already do for overloaded
>> operators:
>>
>>   include/clang/Basic/OperatorKinds.def
>>
>> Alp.
>>
>>
>>
>>> (We've made this change in our clang derivative, which implements
>>> several new conversion kinds, and the above format is serving us well
>>> because it also acts as documentation for the language extension, making it
>>> easy to see the ranks at a glance.)
>>>
>>> What do you think?
>>>
>>> Alp.
>>>
>>>
>>> On 01/07/2014 14:56, Dmitry Babokin wrote:
>>>
 Hi rsmith,

 I've noticed that GetConversionCategory(), GetConversionRank() and
 GetImplicitConversionName() from lib/Sema/SemaOverload.cpp have a bunch of
 bugs, namely:
   - GetConversionCategory() is missing cases for 
 ICK_TransparentUnionConversion,
 ICK_Writeback_Conversion and ICK_Zero_Event_Conversion cases (ok to not
 handle ICK_Num_Conversion_Kinds, though would be good to report an error);
   - GetConversionRank() is missing the case for
 ICK_Zero_Event_Conversion;
   - GetImplicitConversionName() doesn't have a comma after "Transparent
 Union Conversion";

 I think it's better to rewrite these functions using switch, so adding
 new ICKs would trigger a warning or an error if it's not handled in these
 functions.

 Except style changes and typo fix (missing comma), the changes add case
 for missing records, please verify that they've got correct values.

 I have no commit rights, so I would appreciate if reviewer commits the
 patch. Thanks!

 http://reviews.llvm.org/D4354

 Files:
lib/Sema/SemaOverload.cpp


 ___
 cfe-commits mailing list
 cfe-commits@cs.uiuc.edu
 http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

>>>
>>>
>> --
>> http://www.nuanti.com
>> the browser experts
>>
>>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH, v3] ARM: fix inline atomic handling

[Phoebe Buckheister]

On Tue, 8 Jul 2014 19:10:39 +0100, Tim Northover wrote:
> Hi Phoebe,
> 
> On 8 July 2014 18:58, Phoebe Buckheister 
> wrote:
> > Another attempt at fixing atomic handling. This version includes
> > tests that atomics are used on the v7M profile only for widths up
> > to 32 bits, and not at all on the v6M profile.
> 
> Thanks for persisting with this! I think this looks OK now, and from
> what I remember there was a reasonable consensus in the original
> thread that opt-out was the right position. So I say go ahead!
> 
> I've not noticed you committing before, do you have access or would
> you like me to do it for you?

I don't have access, so it'd be much appreciated if you committed. :)

> Cheers.
> 
> Tim.
> 
> (P.S. Very minor point, but we usually try to avoid creating a new
> thread with each update. If you fix anything else (please do!),
> replying to the previous discussion keeps everything together).

Oh. Thanks, I'll keep that in mind for future patches - Linux handles
this a bit differently ;)
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [AArch64] Implement Clang CLI interface proposal about "-march".

[Eric Christopher]

>> > 4. Implement support of "-mtune". Usage is: "-march=CPU_NAME". For
>> > instance, "-march=cortex-a57". This option will ONLY get micro-architecture
>> > level feature enabled specifying to target CPU, like "zcm" and "zcz" for
>> > cyclone. Any architecture features WON'T be modified.
>>
>> That's not what -mtune is. According to GCC's manual: "Tune to
>> cpu-type everything applicable about the generated code, except for
>> the ABI and the set of available instructions."
>>
>> The difference between -mcup and -mtune is that the former selects ABI
>> and ISAs supported by the CPU, while the former doesn't. This is
>> particularly important if you want to run the code on a newer CPU but
>> doesn't want to break older ones, so you can't use instructions that
>> the old ones don't have, but you can optimise for the pipeline and
>> branch decisions of the newer CPU, as long as it just slows down the
>> older ones.
>
> I didn't explain it clearly. Your point is totally what I did in this patch.
> I emphasize " ONLY get micro-architecture level feature enabled" is want to
> say ISA won't be changed by this option. This option is to select target CPU
> to optimize for, including enabling micro-architecture level feature,
> choosing MI scheduler and triggering any optimizations specific for target.
>>
>>
>>
>> > 5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is an
>> > alias to "-march={feature of CPU_NAME}+[no]feature" and "-mtune=CPU_NAME"
>> > together. An warning is added to discourage use of this option.
>>
>> I find this one redundant with -march and don't think we should add
>> deprecated features. -mcpu is the flag you want for the behaviour
>> you've done -mtune above. AFAIK, we don't have the infrastructure to
>> implement -mtune yet. Also, the driver is a bit bonkers when going
>> from CPU to Arch from a different arch than the host without using
>> -target (which is the point with -march, I guess).
>>
>> I don't think -mcpu should be used on its own, only in conjunction
>> with -target or -march.
>
> In my patch, the difference between "-mcpu" and "-mtune" is that, "-mcpu"
> will enable all ISAs which target CPU supports, while "-mtune" won't do
> this. And "-mcpu" can accept extra feature modifiers to make a change, but
> "-mtune" accepts CPU name only. So "-mcpu" is an shortcut of "-march" and
> "-tune". Keeping this option alive in clang is because it's still alive in
> gcc, and may still be used in many projects.  An warning is added to
> discourage use of this option.

This is fine, and I encourage the warning. Also, -march should
probably default to -mtune of the same architecture. I didn't read to
verify, but just making sure this is the case.

>>
>>
>>
>>
>> > 1. Neon is enabled by default, and "generic" will be used if no CPU type
>> > is specified.
>>
>> Makes sense to me.
>>
>>
>> > 2. For most scenario, Using "-mtune=CPU" only is recommended as neon is
>> > enabled by default and all micro-architecture optimizations are selected,
>> > and it would provide great compatibility to run on most of AArch64 devices.
>>
>> That'd be -mcpu, and we still need -march or -target.
>
> "-target" is still necessary at moment while "-march" can be omitted
> sometimes, because the settings of default feature can work well for most
> scenarios and provide good code migration. All I want to do is to get
> "-mcpu" supporter happy to use "-mtune" instead. They don't need to complain
> typing too much as splitting "-mcpu" into "-march" and "-mtune" because they
> can use "-mtune" only. For a standard sets of compiling flags, pair use of
> "-march" and "-mtune" is strongly recommended.

This seems to be a good idea. Can you give examples of behavior you're
expecting to see just to verify?

>>
>>
>>
>> > 3. "-march" is designed to be used only if user wants to use crc and
>> > crypto instructions, or disable fp/neon. So "-march" will not be frequently
>> > used and won't bring too much finger burden.
>>
>> I thought the idea was to encourage -march... at least on new targets...
>
> Yes, we always encourage people to specifying architecture features via
> "-march". Letting "-march" and "-mtune" replace "-mcpu" and "-mfpu" is what
> we want to do.

Very much so.

Thanks!

-eric

>>
>>
>> --renato
>
>
>
>
> --
> Best Regards,
>
> Kevin Qin
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH, v3] ARM: fix inline atomic handling

[Tim Northover]

Hi Phoebe,

On 8 July 2014 18:58, Phoebe Buckheister  wrote:
> Another attempt at fixing atomic handling. This version includes tests
> that atomics are used on the v7M profile only for widths up to 32 bits,
> and not at all on the v6M profile.

Thanks for persisting with this! I think this looks OK now, and from
what I remember there was a reasonable consensus in the original
thread that opt-out was the right position. So I say go ahead!

I've not noticed you committing before, do you have access or would
you like me to do it for you?

Cheers.

Tim.

(P.S. Very minor point, but we usually try to avoid creating a new
thread with each update. If you fix anything else (please do!),
replying to the previous discussion keeps everything together).
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r200344 - Intrin.h: include setjmp.h to get a jmp_buf definition

[Nico Weber]

Two zombie review comments below.

On Tue, Jan 28, 2014 at 3:01 PM, Hans Wennborg  wrote:

> Author: hans
> Date: Tue Jan 28 17:01:59 2014
> New Revision: 200344
>
> URL: http://llvm.org/viewvc/llvm-project?rev=200344&view=rev
> Log:
> Intrin.h: include setjmp.h to get a jmp_buf definition
>
> This makes sure that the ms-intrin.cpp test passes by providing
> a mock setjmp.h as a test input.
>
> Added:
> cfe/trunk/test/Headers/Inputs/include/setjmp.h
> Modified:
> cfe/trunk/lib/Headers/Intrin.h
> cfe/trunk/test/Headers/ms-intrin.cpp
>
> Modified: cfe/trunk/lib/Headers/Intrin.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=200344&r1=200343&r2=200344&view=diff
>
> ==
> --- cfe/trunk/lib/Headers/Intrin.h (original)
> +++ cfe/trunk/lib/Headers/Intrin.h Tue Jan 28 17:01:59 2014
> @@ -32,6 +32,9 @@
>  /* First include the standard intrinsics. */
>  #include 
>
> +/* For the definition of jmp_buf. */
> +#include 
>

Should this (and the functions below) be behind a #if __STDC_HOSTED__, like
the stdlib.h include in xmmintrin.h? (My use case is that I sometimes use
clang-cl with -Xclang -ffreestanding on a non-Windows machine, and that
doesn't work because of this include. It's arguably a somewhat strange use
case, given that -ffreestanding is a cc1 flag.)


> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> @@ -279,10 +282,7 @@ unsigned __int64 __cdecl _rotr64(unsigne
>  static __inline__
>  unsigned char _rotr8(unsigned char _Value, unsigned char _Shift);
>  int _sarx_i32(int, unsigned int);
> -
> -/* FIXME: Need definition for jmp_buf.
> -   int __cdecl _setjmp(jmp_buf); */
>

There's another FIXME like this in the 64bit section below; should that go
away too?


> -
> +int __cdecl _setjmp(jmp_buf);
>  unsigned int _shlx_u32(unsigned int, unsigned int);
>  unsigned int _shrx_u32(unsigned int, unsigned int);
>  void _Store_HLERelease(long volatile *, long);
>
> Added: cfe/trunk/test/Headers/Inputs/include/setjmp.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/Inputs/include/setjmp.h?rev=200344&view=auto
>
> ==
> --- cfe/trunk/test/Headers/Inputs/include/setjmp.h (added)
> +++ cfe/trunk/test/Headers/Inputs/include/setjmp.h Tue Jan 28 17:01:59 2014
> @@ -0,0 +1,8 @@
> +#ifndef SETJMP_H
> +#define SETJMP_H
> +
> +typedef struct {
> +  int x[42];
> +} jmp_buf;
> +
> +#endif
>
> Modified: cfe/trunk/test/Headers/ms-intrin.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/ms-intrin.cpp?rev=200344&r1=200343&r2=200344&view=diff
>
> ==
> --- cfe/trunk/test/Headers/ms-intrin.cpp (original)
> +++ cfe/trunk/test/Headers/ms-intrin.cpp Tue Jan 28 17:01:59 2014
> @@ -1,6 +1,7 @@
>  // RUN: %clang_cc1 -triple i386-pc-win32 -target-cpu pentium4 \
>  // RUN: -fms-extensions -fms-compatibility -fmsc-version=1700 \
> -// RUN: -ffreestanding -fsyntax-only -Werror %s
> +// RUN: -ffreestanding -fsyntax-only -Werror \
> +// RUN: -isystem %S/Inputs/include %s
>
>  // Intrin.h needs size_t, but -ffreestanding prevents us from getting it
> from
>  // stddef.h.  Work around it with this typedef.
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] PR10405 Missing actual type (aka) in error message when using decltype as a template parameter

[Richard Smith]

Comment at: lib/AST/ASTDiagnostic.cpp:70-81
@@ -69,5 +69,14 @@
+// or decltype appears anywhere in the type.
 if (const TemplateSpecializationType *TST
-  = dyn_cast(Ty))
-  if (!TST->isTypeAlias())
+= dyn_cast(Ty)) {
+  for (auto Arg : *TST) {
+  if (Arg.getKind() == TemplateArgument::Type)
+  Desugar(Context, Arg.getAsType(), ShouldAKA);
+  if (ShouldAKA)
+  break;
+  }
+
+  if (!ShouldAKA && !TST->isTypeAlias())
 break;
+}
 

Nikola Smiljanić wrote:
> Richard Smith wrote:
> > It'd be better here to rebuild a TemplateSpecializationType that has the 
> > desugared template arguments in it.
> What exactly do you mean by **rebuild**?
I mean, ask the ASTContext to create a new TemplateSpecializationType with the 
desugared template arguments.

http://reviews.llvm.org/D3588



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH, v3] ARM: fix inline atomic handling

[Phoebe Buckheister]

Another attempt at fixing atomic handling. This version includes tests
that atomics are used on the v7M profile only for widths up to 32 bits,
and not at all on the v6M profile.Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp	(revision 212482)
+++ lib/Basic/Targets.cpp	(working copy)
@@ -3475,27 +3475,14 @@
   static const Builtin::Info BuiltinInfo[];
 
   static bool shouldUseInlineAtomic(const llvm::Triple &T) {
-if (T.isOSWindows())
-  return true;
-
-// On linux, binaries targeting old cpus call functions in libgcc to
-// perform atomic operations. The implementation in libgcc then calls into
-// the kernel which on armv6 and newer uses ldrex and strex. The net result
-// is that if we assume the kernel is at least as recent as the hardware,
-// it is safe to use atomic instructions on armv6 and newer.
-if (!T.isOSLinux() &&
-T.getOS() != llvm::Triple::FreeBSD &&
-T.getOS() != llvm::Triple::NetBSD &&
-T.getOS() != llvm::Triple::Bitrig)
-  return false;
 StringRef ArchName = T.getArchName();
 if (T.getArch() == llvm::Triple::arm ||
 T.getArch() == llvm::Triple::armeb) {
   StringRef VersionStr;
   if (ArchName.startswith("armv"))
-VersionStr = ArchName.substr(4);
+VersionStr = ArchName.substr(4, 1);
   else if (ArchName.startswith("armebv"))
-VersionStr = ArchName.substr(6);
+VersionStr = ArchName.substr(6, 1);
   else
 return false;
   unsigned Version;
@@ -3507,9 +3494,9 @@
T.getArch() == llvm::Triple::thumbeb);
 StringRef VersionStr;
 if (ArchName.startswith("thumbv"))
-  VersionStr = ArchName.substr(6);
+  VersionStr = ArchName.substr(6, 1);
 else if (ArchName.startswith("thumbebv"))
-  VersionStr = ArchName.substr(8);
+  VersionStr = ArchName.substr(8, 1);
 else
   return false;
 unsigned Version;
@@ -3854,6 +3841,13 @@
 if (!getCPUDefineSuffix(Name))
   return false;
 
+// Cortex M does not support 8 byte atomics, while general Thumb2 does.
+StringRef Profile = getCPUProfile(Name);
+if (Profile == "M" && MaxAtomicInlineWidth) {
+  MaxAtomicPromoteWidth = 32;
+  MaxAtomicInlineWidth = 32;
+}
+
 CPU = Name;
 return true;
   }
Index: test/CodeGen/arm-atomics-m.c
===
--- test/CodeGen/arm-atomics-m.c	(revision 0)
+++ test/CodeGen/arm-atomics-m.c	(working copy)
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=thumbv7m-none--eabi -target-cpu cortex-m3 | FileCheck %s
+
+int i;
+long long l;
+
+typedef enum memory_order {
+  memory_order_relaxed, memory_order_consume, memory_order_acquire,
+  memory_order_release, memory_order_acq_rel, memory_order_seq_cst
+} memory_order;
+
+void test_presence(void)
+{
+  // CHECK-LABEL: @test_presence
+  // CHECK: atomicrmw add i32* {{.*}} seq_cst
+  __atomic_fetch_add(&i, 1, memory_order_seq_cst);
+  // CHECK: atomicrmw sub i32* {{.*}} seq_cst
+  __atomic_fetch_sub(&i, 1, memory_order_seq_cst);
+  // CHECK: load atomic i32* {{.*}} seq_cst
+  int r;
+  __atomic_load(&i, &r, memory_order_seq_cst);
+  // CHECK: store atomic i32 {{.*}} seq_cst
+  r = 0;
+  __atomic_store(&i, &r, memory_order_seq_cst);
+
+  // CHECK: __atomic_fetch_add_8
+  __atomic_fetch_add(&l, 1, memory_order_seq_cst);
+  // CHECK: __atomic_fetch_sub_8
+  __atomic_fetch_sub(&l, 1, memory_order_seq_cst);
+  // CHECK: __atomic_load_8
+  long long rl;
+  __atomic_load(&l, &rl, memory_order_seq_cst);
+  // CHECK: __atomic_store_8
+  rl = 0;
+  __atomic_store(&l, &rl, memory_order_seq_cst);
+}
Index: test/CodeGen/arm-atomics-m0.c
===
--- test/CodeGen/arm-atomics-m0.c	(revision 0)
+++ test/CodeGen/arm-atomics-m0.c	(working copy)
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=thumbv6m-none--eabi -target-cpu cortex-m0 | FileCheck %s
+
+int i;
+long long l;
+
+typedef enum memory_order {
+  memory_order_relaxed, memory_order_consume, memory_order_acquire,
+  memory_order_release, memory_order_acq_rel, memory_order_seq_cst
+} memory_order;
+
+void test_presence(void)
+{
+  // CHECK-LABEL: @test_presence
+  // CHECK: __atomic_fetch_add_4
+  __atomic_fetch_add(&i, 1, memory_order_seq_cst);
+  // CHECK: __atomic_fetch_sub_4
+  __atomic_fetch_sub(&i, 1, memory_order_seq_cst);
+  // CHECK: __atomic_load_4
+  int r;
+  __atomic_load(&i, &r, memory_order_seq_cst);
+  // CHECK: __atomic_store_4
+  r = 0;
+  __atomic_store(&i, &r, memory_order_seq_cst);
+
+  // CHECK: __atomic_fetch_add_8
+  __atomic_fetch_add(&l, 1, memory_order_seq_cst);
+  // CHECK: __atomic_fetch_sub_8
+  __atomic_fetch_sub(&l, 1, memory_order_seq_cst);
+  // CHECK: __atomic_load_8
+  long long rl;
+  __atomic_load(&l, &rl, memory_order_seq_cst);
+  // CHECK: __atomic_store_8
+  rl = 0;
+  __atomic_s

Re: [PATCH] Improve error recovery around colon.

[Richard Smith]

Looks great, thanks!


Comment at: lib/Parse/ParseDecl.cpp:4531-4534
@@ -4531,4 +4530,6 @@
   if (getLangOpts().CPlusPlus &&
-  (Tok.is(tok::coloncolon) || Tok.is(tok::identifier) ||
-   Tok.is(tok::annot_cxxscope))) {
+  (Tok.is(tok::coloncolon) ||
+  (Tok.is(tok::identifier) && (NextToken().is(tok::coloncolon) ||
+   NextToken().is(tok::less))) ||
+  Tok.is(tok::annot_cxxscope))) {
 bool EnteringContext = D.getContext() == Declarator::FileContext ||

Please reindent this to make the precedence more obvious (or clang-format it). 
[Last 3 lines should be one space further to the right.]

http://reviews.llvm.org/D3653



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Allow more lookup of types in dependent base classes

[Richard Smith]

LGTM


Comment at: test/SemaTemplate/ms-lookup-template-base-classes.cpp:383
@@ +382,3 @@
+
+namespace lookup_in_function_contexts {
+template  struct A { typedef T NameFromBase; };

Do you have any tests here for lookup in late-parsed function bodies? (I expect 
that'll fail too, and probably shouldn't.)

http://reviews.llvm.org/D4237



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212551 - PR20227: materialize a temporary when dynamic_casting a class prvalue to a

[Richard Smith]

Author: rsmith
Date: Tue Jul  8 12:25:14 2014
New Revision: 212551

URL: http://llvm.org/viewvc/llvm-project?rev=212551&view=rev
Log:
PR20227: materialize a temporary when dynamic_casting a class prvalue to a
reference type.

Modified:
cfe/trunk/lib/Sema/SemaCast.cpp
cfe/trunk/test/CodeGenCXX/temporaries.cpp

Modified: cfe/trunk/lib/Sema/SemaCast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCast.cpp?rev=212551&r1=212550&r2=212551&view=diff
==
--- cfe/trunk/lib/Sema/SemaCast.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCast.cpp Tue Jul  8 12:25:14 2014
@@ -600,6 +600,11 @@ void CastOperation::CheckDynamicCast() {
 }
 SrcPointee = SrcType;
   } else {
+// If we're dynamic_casting from a prvalue to an rvalue reference, we need
+// to materialize the prvalue before we bind the reference to it.
+if (SrcExpr.get()->isRValue())
+  SrcExpr = new (Self.Context) MaterializeTemporaryExpr(
+  SrcType, SrcExpr.get(), /*IsLValueReference*/false);
 SrcPointee = SrcType;
   }
 
@@ -648,7 +653,7 @@ void CastOperation::CheckDynamicCast() {
   SrcExpr = ExprError();
   return;
 }
-
+
 Kind = CK_DerivedToBase;
 
 // If we are casting to or through a virtual base class, we need a
@@ -1156,6 +1161,9 @@ TryStaticReferenceDowncast(Sema &Self, E
 
   QualType DestPointee = DestReference->getPointeeType();
 
+  // FIXME: If the source is a prvalue, we should issue a warning (because the
+  // cast always has undefined behavior), and for AST consistency, we should
+  // materialize a temporary.
   return TryStaticDowncast(Self, 
Self.Context.getCanonicalType(SrcExpr->getType()), 
Self.Context.getCanonicalType(DestPointee), CStyle,

Modified: cfe/trunk/test/CodeGenCXX/temporaries.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/temporaries.cpp?rev=212551&r1=212550&r2=212551&view=diff
==
--- cfe/trunk/test/CodeGenCXX/temporaries.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/temporaries.cpp Tue Jul  8 12:25:14 2014
@@ -27,6 +27,21 @@ namespace PR16263 {
   // CHECK: @_ZN7PR162631uE = constant i32* {{.*}} @_ZGRN7PR162631uE_ {{.*}} 12
 }
 
+namespace PR20227 {
+  struct A { ~A(); };
+  struct B { virtual ~B(); };
+  struct C : B {};
+
+  A &&a = dynamic_cast(A{});
+  // CHECK: @_ZGRN7PR202271aE_ = private global
+
+  B &&b = dynamic_cast(dynamic_cast(C{}));
+  // CHECK: @_ZGRN7PR202271bE_ = private global
+
+  B &&c = static_cast(static_cast(C{}));
+  // CHECK: @_ZGRN7PR202271cE_ = private global
+}
+
 struct A {
   A();
   ~A();


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH, PowerPC] ABI fixes / improvements for powerpc64-linux

[Ulrich Weigand]

Hello,

I've been working to verify ABI compatibility between GCC and LLVM on
powerpc64-linux using the GCC ABI compatibility test suite.  While for the
most part, the compilers are of course compatible in the "usual" scenarios,
this testing uncovered a number of bugs in corner-case situations.  [ Some
of these are actually GCC bugs which I'll be addressing on that side.  ]

In LLVM, the main issues I found are fixed by the patches attached here.
There are three issues (which are somewhat independent, but the patches
build on top of each other so I'll send them all in one mail):

- "synthetic" (non-Altivec) vector types

LLVM currently does not correctly implement the ABI for passing non-Altivec
vector types (defined via attribute((vector_size))).  While there is no
"official" ABI for these in any case, it still would make sense to
implement the ad-hoc ABI as implemented by GCC for those types.  This is
done by the following patch:
(See attached file: diff-clang-synthvector)

- Alignment of arguments in the parameter save area

Certain arguments are supposed to be aligned to a 16-byte boundary in the
argument save area.  This affects vector types as well as aggregates that
have a 16-byte (or higher) alignment requirement.  LLVM currently
implements this alignment for vector types, but not for aggregates, and it
does not respect the alignment at all (even for vector types) when
accessing a variable argument list via va_arg.

Aggregates are passed using the "byval" mechanism, so in theory either
Clang or LLVM could compute the correct alignment required for an aggregate
parameter.  However, it seems preferable to do this in Clang, since it has
the more complete type information, and Clang needs the information anyway
in order to expand va_arg correctly.  So this is what the following patch
does.  As a result, every byval parameter will now carry an explicit
"align" attribute in the IR created by Clang (which I understand is
recommended anyway?).

(See attached file: diff-clang-structalign)

- Avoiding "byval" for aggregates passed in registers

This is not actually a bug fix, but more of a code-gen enhancement.
(However, it will become a required feature for the ELFv2 little-endian
ABI, which I hope to post patches for shortly.)

Aggregates are currently always passed using the "byval" method.  However,
the first 64 bytes will end up in registers anyway, so it would improve
code generation if the IR made use of registers explicit (instead of using
byval).  The following patch implements this.  The main issue here is that
we need to track how many registers will end up being used by the previous
arguments.  However, due to the linear layout of the parameter area in the
ppc64 ABI, this is reasonably straight-forward (and there is precedent of
many other architectures likewise tracking register usage in Clang).

One extra trick is that aggregates that need 16-byte alignment now have to
get an explicit padding type to skip a register if needed.  For this to
work we need to both track registers used by previous arguments, and need
to compute alignment in Clang as introduced in the prior patch (so that's
another reason to do it in the front-end).

(See attached file: diff-clang-structpass)



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU/Linux compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294

diff-clang-synthvector
Description: Binary data


diff-clang-structalign
Description: Binary data


diff-clang-structpass
Description: Binary data
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] -verify enhancement to support matching "any" line in included files

[David Blaikie]

Oh, that's fair. It'd be good to provide a comment in the test case
explaining this (the external use case), since I could imagine someone
coming back and thinking this is a bit silly to have for writing
internal test cases. (& hopefully we'll avoid proliferation of this
feature in internal test cases just by code review)

One thought on the code/design: would it be reasonable to, rather than
having the "MatchAllLines" flag, use an invalid ExpectedLoc? You might
still need a small-scoped "MatchAllLines" (I'd perhaps rename it to
"MatchAnyLine"?) due to the invalid ExpectedLoc used to determine
whether to report err_verify_missing_line, but after that you could
probably set ExpectedLoc to invalid and use that?

On Tue, Jul 8, 2014 at 1:55 AM, Andy Gibbs  wrote:
> Hi David,
>
> This patch is not primarily for clang's test-suite but for making the
> "-verify" feature more useful to outside use (it is such a useful feature
> already but not yet perfect!).
>
> We use "-verify", for example, to test our library code.  In many test-cases
> we test to ensure reasonable (consise, precise) error messages are generated
> when the library is used in invalid ways.  Therefore, a test-case may have
> many "expected-error/warning/note" lines that reference these header files.
> However, since the library is under development, the header files can change
> and this presents a big problem since every change can have a knock-on
> effect on all the test-cases that reference this header file (which means
> hundreds of files may need to be updated).
>
> The supplied patch rectifies this is in (I hope!) a clean way.  We've been
> using this patch for about a year -- I thought it time to see whether other
> users could benefit from it.
>
> The example in my earlier email using a system header was just a simple
> example to demonstrate the change.  Perhaps this is a better code snippet,
> using instead a library header:
>
> int(*j)(int) = FunctorTraits::CastToFunctionPointer();
> // expected-error@util/traits/FunctorTraits.h:* {{T does not supply a valid
> cast operator}}
> // expected-note@-2 {{requested here}}
>
> Regards,
>
> Andy
>
>
> - Original Message - From: "David Blaikie" 
> To: "Andy Gibbs" 
> Cc: "cfe-commits cfe" 
> Sent: Monday, July 07, 2014 10:33 PM
> Subject: Re: [PATCH] -verify enhancement to support matching "any" line in
> included files
>
>
>
>> We generally try not to test against system headers - such a test case
>> should just include a local file and then the line number would be
>> known.
>>
>> Is there a particular need to test some behavior against a system header?
>>
>> On Thu, Jul 3, 2014 at 6:32 AM, Andy Gibbs 
>> wrote:
>>>
>>> Hi,
>>>
>>> I have made an enhancement to the -verify function of clang to support
>>> matching diagnostics in included header files where the line number is
>>> not
>>> necessarily known (or constant).
>>>
>>> Currently, matching a diagnostic in an included file is done as in the
>>> following fragment:
>>>
>>>  // expected-warning@+2 {{incompatible}} expected-warning@+2 {{literal}}
>>>  // expected-note@stdio.h:359 {{here}}
>>>  printf(12);
>>>
>>> Problem is, the line number inside stdio.h is dependent on the system, so
>>> the attached patch provides support for substituting the line number for
>>> '*', as in:
>>>
>>>  // expected-note@stdio.h:* {{here}}
>>>
>>> so that the diagnostic is matched without the line number being known.
>>>
>>> I've intentially limited this feature to line numbers in external files
>>> only
>>> since the line numbers in the main source file should be always "known".
>>> While this change may not have an immediate and particular purpose for
>>> the
>>> clang test-suite itself, I personally feel it is a good and useful
>>> enhancement to -verify for people (like me!) who use this for testing
>>> 3rd-party library code.
>>>
>>> Please let me know if this has support/approval for being committed...
>>>
>>> Thanks
>>>
>>> Andy
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[clang-tools-extra] r212549 - As funny as it might look, this wasn't what I intended to test.

[Benjamin Kramer]

Author: d0k
Date: Tue Jul  8 11:42:54 2014
New Revision: 212549

URL: http://llvm.org/viewvc/llvm-project?rev=212549&view=rev
Log:
As funny as it might look, this wasn't what I intended to test.

Modified:
clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp

Modified: clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp?rev=212549&r1=212548&r2=212549&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp Tue Jul  8 
11:42:54 2014
@@ -15,19 +15,19 @@ using namespace llvm;
 void foo(const Twine &x);
 
 static Twine Moo = Twine("bark") + "bah";
-// CHECK-MASSAGES: twine variables are prone to use-after-free bugs
+// CHECK-MESSAGES: twine variables are prone to use-after-free bugs
 // CHECK-MESSAGES: note: FIX-IT applied suggested code changes
 // CHECK: static std::string Moo = (Twine("bark") + "bah").str();
 
 int main() {
   const Twine t = Twine("a") + "b" + Twine(42);
-// CHECK-MASSAGES: twine variables are prone to use-after-free bugs
+// CHECK-MESSAGES: twine variables are prone to use-after-free bugs
 // CHECK-MESSAGES: note: FIX-IT applied suggested code changes
 // CHECK: std::string t = (Twine("a") + "b" + Twine(42)).str();
   foo(Twine("a") + "b");
 
   Twine Prefix = false ? "__INT_FAST" : "__UINT_FAST";
-// CHECK-MASSAGES: twine variables are prone to use-after-free bugs
+// CHECK-MESSAGES: twine variables are prone to use-after-free bugs
 // CHECK-MESSAGES: note: FIX-IT applied suggested code changes
 // CHECK: const char * Prefix = false ? "__INT_FAST" : "__UINT_FAST";
 }


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r212546 - Use explicit if and restore lost FileCheck error code checking.

[Benjamin Kramer]

On Tue, Jul 8, 2014 at 6:41 PM, Alexander Kornienko  wrote:
> I assume, ensured this script still works by simulating a test failure?

Yep. Both message tests and fixit tests correctly fail.

- Ben
>
>
>
> On Tue, Jul 8, 2014 at 6:15 PM, Benjamin Kramer 
> wrote:
>>
>> Author: d0k
>> Date: Tue Jul  8 11:15:48 2014
>> New Revision: 212546
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=212546&view=rev
>> Log:
>> Use explicit if and restore lost FileCheck error code checking.
>>
>> Modified:
>> clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
>>
>> Modified: clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh?rev=212546&r1=212545&r2=212546&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
>> (original)
>> +++ clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh Tue
>> Jul  8 11:15:48 2014
>> @@ -8,5 +8,7 @@ TEMPORARY_FILE=$3.cpp
>>
>>  grep -Ev "// *[A-Z-]+:" ${INPUT_FILE} > ${TEMPORARY_FILE}
>>  clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
>> --std=c++11 > ${TEMPORARY_FILE}.msg 2>&1
>> -FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
>> -not grep CHECK-MESSAGES ${INPUT_FILE} || FileCheck
>> -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE} -check-prefix=CHECK-MESSAGES
>> +FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
>> || exit $?
>> +if grep CHECK-MESSAGES ${INPUT_FILE}; then
>> +  FileCheck -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE}
>> -check-prefix=CHECK-MESSAGES || exit $?
>> +fi
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r212546 - Use explicit if and restore lost FileCheck error code checking.

[Alexander Kornienko]

I assume, ensured this script still works by simulating a test failure?


On Tue, Jul 8, 2014 at 6:15 PM, Benjamin Kramer 
wrote:

> Author: d0k
> Date: Tue Jul  8 11:15:48 2014
> New Revision: 212546
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212546&view=rev
> Log:
> Use explicit if and restore lost FileCheck error code checking.
>
> Modified:
> clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
>
> Modified: clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh?rev=212546&r1=212545&r2=212546&view=diff
>
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> (original)
> +++ clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh Tue
> Jul  8 11:15:48 2014
> @@ -8,5 +8,7 @@ TEMPORARY_FILE=$3.cpp
>
>  grep -Ev "// *[A-Z-]+:" ${INPUT_FILE} > ${TEMPORARY_FILE}
>  clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
> --std=c++11 > ${TEMPORARY_FILE}.msg 2>&1
> -FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
> -not grep CHECK-MESSAGES ${INPUT_FILE} || FileCheck
> -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE} -check-prefix=CHECK-MESSAGES
> +FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
> || exit $?
> +if grep CHECK-MESSAGES ${INPUT_FILE}; then
> +  FileCheck -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE}
> -check-prefix=CHECK-MESSAGES || exit $?
> +fi
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] Modeling APIs in the Static Analyzer

[Gábor Horváth]

Hi there,

I am working on a system to model API calls in the Static Analyzer. The
main idea is to have C/C++ source files that contains definitions of
functions and methods, and they are parsed by Clang and used by the Static
Analyzer when the definition of a function or a method is in another
translation unit. This can help the analyzer to find more possible issues
when known APIs are modelled. (More details on my GSoC project page:
http://www.google-melange.com/gsoc/project/details/google/gsoc2014/xazax/5717271485874176
)

The patch I attached can parse a model file using the ASTContext of the
currently analyzed translation unit, so the model files do not need to be a
standalone translation units and they can be parsed quickly. Any review on
my current implementation is welcome. Because the error reporting is still
a work in progress and the path is not truncated properly yet (the parts
that are in a model file are not omitted) the test I included does not
pass. I will fix it as soon as possible, but in the meanwhile any comments
are welcome.

Thanks,
Gábor Horváth
Index: include/clang/Analysis/AnalysisContext.h
===
--- include/clang/Analysis/AnalysisContext.h	(revision 212534)
+++ include/clang/Analysis/AnalysisContext.h	(working copy)
@@ -17,8 +17,10 @@
 
 #include "clang/AST/Decl.h"
 #include "clang/Analysis/CFG.h"
+#include "clang/Analysis/CodeInjector.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/FoldingSet.h"
+#include "llvm/ADT/OwningPtr.h"
 #include "llvm/Support/Allocator.h"
 #include 
 
@@ -398,6 +400,10 @@
   ContextMap Contexts;
   LocationContextManager LocContexts;
   CFG::BuildOptions cfgBuildOptions;
+
+  /// Pointer to an interface that can provide function bodies for
+  /// declarations from external source
+  llvm::OwningPtr Injector;
   
   /// Flag to indicate whether or not bodies should be synthesized
   /// for well-known functions.
@@ -410,7 +416,8 @@
  bool addTemporaryDtors = false,
  bool synthesizeBodies = false,
  bool addStaticInitBranches = false,
- bool addCXXNewAllocator = true);
+ bool addCXXNewAllocator = true,
+ CodeInjector* injector = nullptr);
 
   ~AnalysisDeclContextManager();
 
Index: include/clang/Analysis/CodeInjector.h
===
--- include/clang/Analysis/CodeInjector.h	(revision 0)
+++ include/clang/Analysis/CodeInjector.h	(working copy)
@@ -0,0 +1,29 @@
+//===-- CodeInjector.h --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_CODEINJECTOR_H
+#define LLVM_CLANG_ANALYSIS_CODEINJECTOR_H
+
+namespace clang {
+
+class Stmt;
+class FunctionDecl;
+class ObjCMethodDecl;
+
+class CodeInjector {
+public:
+  CodeInjector();
+  virtual ~CodeInjector();
+
+  virtual Stmt *getBody(const FunctionDecl *D) = 0;
+  virtual Stmt *getBody(const ObjCMethodDecl *D) = 0;
+};
+}
+
+#endif
\ No newline at end of file
Index: include/clang/Frontend/FrontendAction.h
===
--- include/clang/Frontend/FrontendAction.h	(revision 212534)
+++ include/clang/Frontend/FrontendAction.h	(working copy)
@@ -34,6 +34,10 @@
 
 /// Abstract base class for actions which can be performed by the frontend.
 class FrontendAction {
+  /// Is this action invoked on a model file? Model files are incomplete
+  /// translation units that relies on type information from another translation
+  /// unit. Check ParseModelFileAction for details.
+  bool ModelFile;
   FrontendInputFile CurrentInput;
   std::unique_ptr CurrentASTUnit;
   CompilerInstance *Instance;
@@ -105,7 +109,11 @@
   /// @}
 
 public:
-  FrontendAction();
+  /// \brief Constructor
+  ///
+  /// \param modelFile determines whether the source files this action invoked
+  /// on should be treated as a model file. Defaults to false.
+  FrontendAction(bool modelFile = false);
   virtual ~FrontendAction();
 
   /// @name Compiler Instance Access
@@ -127,6 +135,11 @@
 return (bool)CurrentASTUnit;
   }
 
+  /// \brief Is this action responsible for parsing a model file?
+  bool isModelParsingAction() const {
+return ModelFile;
+  }
+
   const FrontendInputFile &getCurrentInput() const {
 return CurrentInput;
   }
@@ -222,6 +235,7 @@
   void ExecuteAction() override;
 
 public:
+  ASTFrontendAction(bool ModelFile = false) : FrontendAction(ModelFile) {}
   bool usesPreprocessorOnly() const override { return false; }
 };
 
Index: include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisMana

Re: [PATCH] Division by zero

[Jordan Rose]

On Jul 7, 2014, at 2:28 , Anders Rönnholm  wrote:

>>> We don't get into the if-case because we never get a Loc from Sval 
>>> therefore it always returns false and our tests are passed.
>>> 
>>> Optional L = S.getAs();
>>> if (!L)
>>>   return false;
>>> 
>> Um. Right, we shouldn't get a Loc at that point. But we don't need a Loc. We 
>> just need whatever NonLoc symbol is there, and we can check to see if that 
>> is 0. Why did we need a Loc again?
>> 
>> Anyway, we shouldn't have features that don't show up in the tests. I think 
>> this code was either trying to avoid emitting duplicate messages if the 
>> denominator is known to be 0 already (which won't happen because that's a 
>> fatal error), or trying to avoid adding the symbol to the map if it's known 
>> not to be 0 (which is not what it's doing now, or at least not what it says 
>> it's doing). The latter is kind of useful but it's just optimization.
>> 
>> Jordan
>> 
> Are you suggesting that we use NonLoc instead of Loc? Can we get an Sval from 
> NonLoc? We needed Loc to get sval from state instead of looping the exploded 
> node to find the range before the division.

Let's stop for a second. We want to check if the denominator's value is equal 
to 0. At this point in execution, the denominator expression is an rvalue, i.e. 
the integer value has already been loaded from the variable. That means the 
value of the denominator expression is going to be a NonLoc (because it 
represents an integer value rather than a location). Additionally, we don't 
need to load anything, because we're already past the point in analysis where 
the variable is loaded.

So if I'm right, you should be able to just take the denominator SVal as is, 
and feed it into the constraint manager if it's defined.

Jordan___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Adding 4 ASTMatchers: typedefDecl, isInMainFile, isInSystemFile, isInFileMatchingName

[Alexander Kornienko]

On Sun, Jun 29, 2014 at 10:46 PM, Hendrik v. P. 
wrote:

>
> Hi,
>
> last week, I uploaded a patch for being reviewed on phabricator (
> http://reviews.llvm.org/D4283). I'm just curios if I did it right and
> someone will ever take notice of it, or if I made some mistakes that will
> prevent you to review it and I should change in future.
>

Well, you should've added cfe-commits to cc: and ideally someone from the
maintainers of the relevant library to reviewers:. I'm cc-ing people who
can review your patch.


>
> Thank you in advance,
> Hendrik
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>


-- 
Alexander Kornienko | Software Engineer | ale...@google.com | Google
Germany, Munich
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[clang-tools-extra] r212546 - Use explicit if and restore lost FileCheck error code checking.

[Benjamin Kramer]

Author: d0k
Date: Tue Jul  8 11:15:48 2014
New Revision: 212546

URL: http://llvm.org/viewvc/llvm-project?rev=212546&view=rev
Log:
Use explicit if and restore lost FileCheck error code checking.

Modified:
clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh

Modified: clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh?rev=212546&r1=212545&r2=212546&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh (original)
+++ clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh Tue Jul  8 
11:15:48 2014
@@ -8,5 +8,7 @@ TEMPORARY_FILE=$3.cpp
 
 grep -Ev "// *[A-Z-]+:" ${INPUT_FILE} > ${TEMPORARY_FILE}
 clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" -- --std=c++11 
> ${TEMPORARY_FILE}.msg 2>&1
-FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
-not grep CHECK-MESSAGES ${INPUT_FILE} || FileCheck 
-input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE} -check-prefix=CHECK-MESSAGES
+FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace || 
exit $?
+if grep CHECK-MESSAGES ${INPUT_FILE}; then
+  FileCheck -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE} 
-check-prefix=CHECK-MESSAGES || exit $?
+fi


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r212540 - [clang-tidy] Address review comments for the Twine checker.

[Alexander Kornienko]

On Tue, Jul 8, 2014 at 5:04 PM, Benjamin Kramer  wrote:

> On Tue, Jul 8, 2014 at 5:58 PM, Alexander Kornienko 
> wrote:
> > Thanks! See one nit below.
> >
> > On Tue, Jul 8, 2014 at 4:41 PM, Benjamin Kramer <
> benny@googlemail.com>
> > wrote:
> >>
> >> Author: d0k
> >> Date: Tue Jul  8 10:41:20 2014
> >> New Revision: 212540
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=212540&view=rev
> >> Log:
> >> [clang-tidy] Address review comments for the Twine checker.
> >>
> >> - Remove unused includes.
> >> - Minor wording fix.
> >> - Added support to check for clang-tidy messages to
> >> check_clang_tidy_fix.sh
> >> = Updated test case.
> >>
> >> Modified:
> >> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> >> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
> >> clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> >> clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
> >>
> >> Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212540&r1=212539&r2=212540&view=diff
> >>
> >>
> ==
> >> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> (original)
> >> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul
>  8
> >> 10:41:20 2014
> >> @@ -11,7 +11,6 @@
> >>  #include "clang/AST/ASTContext.h"
> >>  #include "clang/ASTMatchers/ASTMatchers.h"
> >>  #include "clang/Lex/Lexer.h"
> >> -#include "llvm/Support/raw_ostream.h"
> >>
> >>  using namespace clang::ast_matchers;
> >>
> >> @@ -29,7 +28,7 @@ void TwineLocalCheck::registerMatchers(M
> >>  void TwineLocalCheck::check(const MatchFinder::MatchResult &Result) {
> >>const VarDecl *VD = Result.Nodes.getNodeAs("variable");
> >>auto Diag = diag(VD->getLocation(),
> >> -   "twine variables are prone to use after free bugs");
> >> +   "twine variables are prone to use-after-free bugs");
> >>
> >>// If this VarDecl has an initializer try to fix it.
> >>if (VD->hasInit()) {
> >>
> >> Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h?rev=212540&r1=212539&r2=212540&view=diff
> >>
> >>
> ==
> >> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h (original)
> >> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h Tue Jul  8
> >> 10:41:20 2014
> >> @@ -11,7 +11,6 @@
> >>  #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_LLVM_TWINE_LOCAL_CHECK_H
> >>
> >>  #include "../ClangTidy.h"
> >> -#include "llvm/Support/Regex.h"
> >>
> >>  namespace clang {
> >>  namespace tidy {
> >>
> >> Modified:
> clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh?rev=212540&r1=212539&r2=212540&view=diff
> >>
> >>
> ==
> >> --- clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> >> (original)
> >> +++ clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh Tue
> >> Jul  8 10:41:20 2014
> >> @@ -7,5 +7,6 @@ CHECK_TO_RUN=$2
> >>  TEMPORARY_FILE=$3.cpp
> >>
> >>  grep -Ev "// *[A-Z-]+:" ${INPUT_FILE} > ${TEMPORARY_FILE}
> >> -clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
> >> --std=c++11
> >> +clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
> >> --std=c++11 > ${TEMPORARY_FILE}.msg 2>&1
> >>  FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE}
> -strict-whitespace
> >> +not grep CHECK-MESSAGES ${INPUT_FILE} || FileCheck
> >> -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE}
> -check-prefix=CHECK-MESSAGES
> >
> >
> > Any reason to use "not X || Y" instead of "X && Y" or even "if X ; then
> Y ;
> > fi"?
>
> I care about the return value.


You're right. But it seems like we've started ignoring the return value of
the first FileCheck. We either need to use "bash -e" or add "|| exit $?".


> X && Y would return failure if X
> failed, I want it to succeed if X failed or Y passed so the other
> tests keep functioning.
>
> I guess an explicit if-then would be doable. Have to check how return
> values work when doing that.
>

They should work fine in ifs. In any case you could use explicit "exit".


>
> - Ben
>
> >
> >>
> >>
> >> Modified: clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp?rev=212540&r1=212539&r2=212540&view=diff
> >>
> >>
> ==
> >> --- clang-tools-extra/trunk/test/

r212544 - Turn some Twine locals into const char * variables.

[Benjamin Kramer]

Author: d0k
Date: Tue Jul  8 11:07:36 2014
New Revision: 212544

URL: http://llvm.org/viewvc/llvm-project?rev=212544&view=rev
Log:
Turn some Twine locals into const char * variables.

No functionality change, just stylistic cleanup. Change made by clang-tidy
and clang-format.

Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=212544&r1=212543&r2=212544&view=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Tue Jul  8 11:07:36 2014
@@ -223,7 +223,7 @@ static void DefineExactWidthIntType(Targ
   if (TypeWidth == 64)
 Ty = IsSigned ? TI.getInt64Type() : TI.getIntTypeByWidth(64, false);
 
-  Twine Prefix = IsSigned ? "__INT" : "__UINT";
+  const char *Prefix = IsSigned ? "__INT" : "__UINT";
 
   DefineType(Prefix + Twine(TypeWidth) + "_TYPE__", Ty, Builder);
 
@@ -244,7 +244,7 @@ static void DefineExactWidthIntTypeSize(
   if (TypeWidth == 64)
 Ty = IsSigned ? TI.getInt64Type() : TI.getIntTypeByWidth(64, false);
 
-  Twine Prefix = IsSigned ? "__INT" : "__UINT";
+  const char *Prefix = IsSigned ? "__INT" : "__UINT";
   DefineTypeSize(Prefix + Twine(TypeWidth) + "_MAX__", Ty, TI, Builder);
 }
 
@@ -255,7 +255,7 @@ static void DefineLeastWidthIntType(unsi
   if (Ty == TargetInfo::NoInt)
 return;
 
-  Twine Prefix = IsSigned ? "__INT_LEAST" : "__UINT_LEAST";
+  const char *Prefix = IsSigned ? "__INT_LEAST" : "__UINT_LEAST";
   DefineType(Prefix + Twine(TypeWidth) + "_TYPE__", Ty, Builder);
   DefineTypeSize(Prefix + Twine(TypeWidth) + "_MAX__", Ty, TI, Builder);
 }
@@ -268,7 +268,7 @@ static void DefineFastIntType(unsigned T
   if (Ty == TargetInfo::NoInt)
 return;
 
-  Twine Prefix = IsSigned ? "__INT_FAST" : "__UINT_FAST";
+  const char *Prefix = IsSigned ? "__INT_FAST" : "__UINT_FAST";
   DefineType(Prefix + Twine(TypeWidth) + "_TYPE__", Ty, Builder);
   DefineTypeSize(Prefix + Twine(TypeWidth) + "_MAX__", Ty, TI, Builder);
 }


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212545 - Update unit test for signature change.

[Benjamin Kramer]

Author: d0k
Date: Tue Jul  8 11:07:39 2014
New Revision: 212545

URL: http://llvm.org/viewvc/llvm-project?rev=212545&view=rev
Log:
Update unit test for signature change.

Modified:
cfe/trunk/unittests/Basic/FileManagerTest.cpp

Modified: cfe/trunk/unittests/Basic/FileManagerTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/FileManagerTest.cpp?rev=212545&r1=212544&r2=212545&view=diff
==
--- cfe/trunk/unittests/Basic/FileManagerTest.cpp (original)
+++ cfe/trunk/unittests/Basic/FileManagerTest.cpp Tue Jul  8 11:07:39 2014
@@ -51,8 +51,9 @@ public:
   }
 
   // Implement FileSystemStatCache::getStat().
-  virtual LookupResult getStat(const char *Path, FileData &Data, bool isFile,
-   vfs::File **F, vfs::FileSystem &FS) {
+  LookupResult getStat(const char *Path, FileData &Data, bool isFile,
+   std::unique_ptr *F,
+   vfs::FileSystem &FS) override {
 if (StatCalls.count(Path) != 0) {
   Data = StatCalls[Path];
   return CacheExists;


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] -verify enhancement to support matching "any" line in included files

[Jordan Rose]

The analyzer would get mild use out of this too; we have "system header 
simulators" shared across multiple files, and encoding line numbers in each 
file that uses the header is somewhat brittle when the header needs to change. 
Although I just realized that #line might be able to get around that...

Jordan


On Jul 8, 2014, at 1:55 , Andy Gibbs  wrote:

> Hi David,
> 
> This patch is not primarily for clang's test-suite but for making the 
> "-verify" feature more useful to outside use (it is such a useful feature 
> already but not yet perfect!).
> 
> We use "-verify", for example, to test our library code.  In many test-cases 
> we test to ensure reasonable (consise, precise) error messages are generated 
> when the library is used in invalid ways.  Therefore, a test-case may have 
> many "expected-error/warning/note" lines that reference these header files. 
> However, since the library is under development, the header files can change 
> and this presents a big problem since every change can have a knock-on effect 
> on all the test-cases that reference this header file (which means hundreds 
> of files may need to be updated).
> 
> The supplied patch rectifies this is in (I hope!) a clean way.  We've been 
> using this patch for about a year -- I thought it time to see whether other 
> users could benefit from it.
> 
> The example in my earlier email using a system header was just a simple 
> example to demonstrate the change.  Perhaps this is a better code snippet, 
> using instead a library header:
> 
> int(*j)(int) = FunctorTraits::CastToFunctionPointer();
> // expected-error@util/traits/FunctorTraits.h:* {{T does not supply a valid 
> cast operator}}
> // expected-note@-2 {{requested here}}
> 
> Regards,
> 
> Andy
> 
> 
> - Original Message - From: "David Blaikie" 
> To: "Andy Gibbs" 
> Cc: "cfe-commits cfe" 
> Sent: Monday, July 07, 2014 10:33 PM
> Subject: Re: [PATCH] -verify enhancement to support matching "any" line in 
> included files
> 
> 
>> We generally try not to test against system headers - such a test case
>> should just include a local file and then the line number would be
>> known.
>> 
>> Is there a particular need to test some behavior against a system header?
>> 
>> On Thu, Jul 3, 2014 at 6:32 AM, Andy Gibbs  wrote:
>>> Hi,
>>> 
>>> I have made an enhancement to the -verify function of clang to support
>>> matching diagnostics in included header files where the line number is not
>>> necessarily known (or constant).
>>> 
>>> Currently, matching a diagnostic in an included file is done as in the
>>> following fragment:
>>> 
>>> // expected-warning@+2 {{incompatible}} expected-warning@+2 {{literal}}
>>> // expected-note@stdio.h:359 {{here}}
>>> printf(12);
>>> 
>>> Problem is, the line number inside stdio.h is dependent on the system, so
>>> the attached patch provides support for substituting the line number for
>>> '*', as in:
>>> 
>>> // expected-note@stdio.h:* {{here}}
>>> 
>>> so that the diagnostic is matched without the line number being known.
>>> 
>>> I've intentially limited this feature to line numbers in external files only
>>> since the line numbers in the main source file should be always "known".
>>> While this change may not have an immediate and particular purpose for the
>>> clang test-suite itself, I personally feel it is a good and useful
>>> enhancement to -verify for people (like me!) who use this for testing
>>> 3rd-party library code.
>>> 
>>> Please let me know if this has support/approval for being committed...
>>> 
>>> Thanks
>>> 
>>> Andy
>>> 
>>> 
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r212535 - [clang-tidy] Add a little checker for Twine locals in LLVM.

[Alexander Kornienko]

On Tue, Jul 8, 2014 at 4:49 PM, Benjamin Kramer  wrote:

> On Tue, Jul 8, 2014 at 5:33 PM, Alexander Kornienko 
> wrote:
> > Thanks for writing the check! It would be better though, if you sent the
> > code for pre-commit review, especially as you are adding a new check.
>
> I'll keep this in mind for later commits, thanks. This one is really
> trivial though and only applies to LLVM.
>

I don't insist, but I'd appreciate if you sent clang-tidy patches for
pre-commit review.


>
> > Did you run the check over the whole LLVM/Clang source code? Could you
> share
> > the results? (Number of warnings and false-positive rate in a sample of a
> > few tens of instances.)
>
> 3 cases in LLVM, 2 of them real bugs. 4 in Clang, all harmless. Even
> though some of them are technically false positives I consider them
> all to be bad style. Twine is designed to be used in parameter lists
> *only*, let's keep it that way.
>
> > On Tue, Jul 8, 2014 at 3:32 PM, Benjamin Kramer <
> benny@googlemail.com>
> > wrote:
> >>
> >> Author: d0k
> >> Date: Tue Jul  8 09:32:17 2014
> >> New Revision: 212535
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=212535&view=rev
> >> Log:
> >> [clang-tidy] Add a little checker for Twine locals in LLVM.
> >>
> >> Those often cause use after free bugs and should be generally avoided.
> >> Technically it is safe to have a Twine with >=2 components in a variable
> >> but I don't think it is a good pattern to follow. The almost trivial
> >> checker
> >> comes with elaborated fix-it hints that turn the Twine into a
> std::string
> >> if necessary and otherwise fall back to the original type if the Twine
> >> is created from a single value.
> >>
> >> Added:
> >> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> >> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
> >> clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
> >> Modified:
> >> clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
> >> clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
> >>
> >> Modified: clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt?rev=212535&r1=212534&r2=212535&view=diff
> >>
> >>
> ==
> >> --- clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt (original)
> >> +++ clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt Tue Jul  8
> >> 09:32:17 2014
> >> @@ -4,6 +4,7 @@ add_clang_library(clangTidyLLVMModule
> >>IncludeOrderCheck.cpp
> >>LLVMTidyModule.cpp
> >>NamespaceCommentCheck.cpp
> >> +  TwineLocalCheck.cpp
> >>
> >>LINK_LIBS
> >>clangAST
> >>
> >> Modified: clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp?rev=212535&r1=212534&r2=212535&view=diff
> >>
> >>
> ==
> >> --- clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
> (original)
> >> +++ clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp Tue Jul
>  8
> >> 09:32:17 2014
> >> @@ -12,6 +12,7 @@
> >>  #include "../ClangTidyModuleRegistry.h"
> >>  #include "IncludeOrderCheck.h"
> >>  #include "NamespaceCommentCheck.h"
> >> +#include "TwineLocalCheck.h"
> >>
> >>  namespace clang {
> >>  namespace tidy {
> >> @@ -24,6 +25,9 @@ public:
> >>  CheckFactories.addCheckFactory(
> >>  "llvm-namespace-comment",
> >>  new ClangTidyCheckFactory());
> >> +CheckFactories.addCheckFactory(
> >> +"llvm-twine-local",
> >> +new ClangTidyCheckFactory());
> >>}
> >>  };
> >>
> >>
> >> Added: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212535&view=auto
> >>
> >>
> ==
> >> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (added)
> >> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul
>  8
> >> 09:32:17 2014
> >> @@ -0,0 +1,64 @@
> >> +//===--- TwineLocalCheck.cpp - clang-tidy
> >> -===//
> >> +//
> >> +// The LLVM Compiler Infrastructure
> >> +//
> >> +// This file is distributed under the University of Illinois Open
> Source
> >> +// License. See LICENSE.TXT for details.
> >> +//
> >>
> >>
> +//===--===//
> >> +
> >> +#include "TwineLocalCheck.h"
> >> +#include "clang/AST/ASTContext.h"
> >> +#include "clang/ASTMatchers/ASTMatchers.h"
> >> +#include "clang/Lex/Lexer.h"
> >> +#include "llvm/Support/raw_ostream.h"
> >
> >
> > Is this header needed?
>
> Nope.
>
> >
> >>
> >> +
> >> +using namespace cl

Re: [clang-tools-extra] r212540 - [clang-tidy] Address review comments for the Twine checker.

[Benjamin Kramer]

On Tue, Jul 8, 2014 at 5:58 PM, Alexander Kornienko  wrote:
> Thanks! See one nit below.
>
> On Tue, Jul 8, 2014 at 4:41 PM, Benjamin Kramer 
> wrote:
>>
>> Author: d0k
>> Date: Tue Jul  8 10:41:20 2014
>> New Revision: 212540
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=212540&view=rev
>> Log:
>> [clang-tidy] Address review comments for the Twine checker.
>>
>> - Remove unused includes.
>> - Minor wording fix.
>> - Added support to check for clang-tidy messages to
>> check_clang_tidy_fix.sh
>> = Updated test case.
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
>> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
>> clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
>> clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
>>
>> Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212540&r1=212539&r2=212540&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (original)
>> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul  8
>> 10:41:20 2014
>> @@ -11,7 +11,6 @@
>>  #include "clang/AST/ASTContext.h"
>>  #include "clang/ASTMatchers/ASTMatchers.h"
>>  #include "clang/Lex/Lexer.h"
>> -#include "llvm/Support/raw_ostream.h"
>>
>>  using namespace clang::ast_matchers;
>>
>> @@ -29,7 +28,7 @@ void TwineLocalCheck::registerMatchers(M
>>  void TwineLocalCheck::check(const MatchFinder::MatchResult &Result) {
>>const VarDecl *VD = Result.Nodes.getNodeAs("variable");
>>auto Diag = diag(VD->getLocation(),
>> -   "twine variables are prone to use after free bugs");
>> +   "twine variables are prone to use-after-free bugs");
>>
>>// If this VarDecl has an initializer try to fix it.
>>if (VD->hasInit()) {
>>
>> Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h?rev=212540&r1=212539&r2=212540&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h (original)
>> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h Tue Jul  8
>> 10:41:20 2014
>> @@ -11,7 +11,6 @@
>>  #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_LLVM_TWINE_LOCAL_CHECK_H
>>
>>  #include "../ClangTidy.h"
>> -#include "llvm/Support/Regex.h"
>>
>>  namespace clang {
>>  namespace tidy {
>>
>> Modified: clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh?rev=212540&r1=212539&r2=212540&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
>> (original)
>> +++ clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh Tue
>> Jul  8 10:41:20 2014
>> @@ -7,5 +7,6 @@ CHECK_TO_RUN=$2
>>  TEMPORARY_FILE=$3.cpp
>>
>>  grep -Ev "// *[A-Z-]+:" ${INPUT_FILE} > ${TEMPORARY_FILE}
>> -clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
>> --std=c++11
>> +clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
>> --std=c++11 > ${TEMPORARY_FILE}.msg 2>&1
>>  FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
>> +not grep CHECK-MESSAGES ${INPUT_FILE} || FileCheck
>> -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE} -check-prefix=CHECK-MESSAGES
>
>
> Any reason to use "not X || Y" instead of "X && Y" or even "if X ; then Y ;
> fi"?

I care about the return value. X && Y would return failure if X
failed, I want it to succeed if X failed or Y passed so the other
tests keep functioning.

I guess an explicit if-then would be doable. Have to check how return
values work when doing that.

- Ben

>
>>
>>
>> Modified: clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp?rev=212540&r1=212539&r2=212540&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
>> (original)
>> +++ clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp Tue Jul
>> 8 10:41:20 2014
>> @@ -1,7 +1,5 @@
>> -// RUN: grep -Ev "// *[A-Z-]+:" %s > %t.cpp
>> -// RUN: clang-tidy %t.cpp -checks='-*,llvm-twine-local' -fix -- > %t.msg
>> 2>&1
>> -// RUN: FileCheck -input-file=%t.cpp %s
>> -// RUN: FileCheck -input-file=%t.msg -check-prefix=CHECK-MESSAGES %s
>> +// RUN: $(dirname %s)/check_clang_tidy_fix.sh %s llvm-twine-local %t
>> +// REQUIRES: shell
>>
>>  namespace llvm {
>>  class Twine {
>> @@ -17,19 +15,19 @

Re: [clang-tools-extra] r212540 - [clang-tidy] Address review comments for the Twine checker.

[Alexander Kornienko]

Thanks! See one nit below.

On Tue, Jul 8, 2014 at 4:41 PM, Benjamin Kramer 
wrote:

> Author: d0k
> Date: Tue Jul  8 10:41:20 2014
> New Revision: 212540
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212540&view=rev
> Log:
> [clang-tidy] Address review comments for the Twine checker.
>
> - Remove unused includes.
> - Minor wording fix.
> - Added support to check for clang-tidy messages to check_clang_tidy_fix.sh
> = Updated test case.
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
> clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
>
> Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212540&r1=212539&r2=212540&view=diff
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (original)
> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul  8
> 10:41:20 2014
> @@ -11,7 +11,6 @@
>  #include "clang/AST/ASTContext.h"
>  #include "clang/ASTMatchers/ASTMatchers.h"
>  #include "clang/Lex/Lexer.h"
> -#include "llvm/Support/raw_ostream.h"
>
>  using namespace clang::ast_matchers;
>
> @@ -29,7 +28,7 @@ void TwineLocalCheck::registerMatchers(M
>  void TwineLocalCheck::check(const MatchFinder::MatchResult &Result) {
>const VarDecl *VD = Result.Nodes.getNodeAs("variable");
>auto Diag = diag(VD->getLocation(),
> -   "twine variables are prone to use after free bugs");
> +   "twine variables are prone to use-after-free bugs");
>
>// If this VarDecl has an initializer try to fix it.
>if (VD->hasInit()) {
>
> Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h?rev=212540&r1=212539&r2=212540&view=diff
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h (original)
> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h Tue Jul  8
> 10:41:20 2014
> @@ -11,7 +11,6 @@
>  #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_LLVM_TWINE_LOCAL_CHECK_H
>
>  #include "../ClangTidy.h"
> -#include "llvm/Support/Regex.h"
>
>  namespace clang {
>  namespace tidy {
>
> Modified: clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh?rev=212540&r1=212539&r2=212540&view=diff
>
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
> (original)
> +++ clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh Tue
> Jul  8 10:41:20 2014
> @@ -7,5 +7,6 @@ CHECK_TO_RUN=$2
>  TEMPORARY_FILE=$3.cpp
>
>  grep -Ev "// *[A-Z-]+:" ${INPUT_FILE} > ${TEMPORARY_FILE}
> -clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
> --std=c++11
> +clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" --
> --std=c++11 > ${TEMPORARY_FILE}.msg 2>&1
>  FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
> +not grep CHECK-MESSAGES ${INPUT_FILE} || FileCheck
> -input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE} -check-prefix=CHECK-MESSAGES
>

Any reason to use "not X || Y" instead of "X && Y" or even "if X ; then Y ;
fi"?


>
> Modified: clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp?rev=212540&r1=212539&r2=212540&view=diff
>
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp (original)
> +++ clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp Tue Jul
>  8 10:41:20 2014
> @@ -1,7 +1,5 @@
> -// RUN: grep -Ev "// *[A-Z-]+:" %s > %t.cpp
> -// RUN: clang-tidy %t.cpp -checks='-*,llvm-twine-local' -fix -- > %t.msg
> 2>&1
> -// RUN: FileCheck -input-file=%t.cpp %s
> -// RUN: FileCheck -input-file=%t.msg -check-prefix=CHECK-MESSAGES %s
> +// RUN: $(dirname %s)/check_clang_tidy_fix.sh %s llvm-twine-local %t
> +// REQUIRES: shell
>
>  namespace llvm {
>  class Twine {
> @@ -17,19 +15,19 @@ using namespace llvm;
>  void foo(const Twine &x);
>
>  static Twine Moo = Twine("bark") + "bah";
> -// CHECK-MASSAGES: twine variables are prone to use after free bugs
> +// CHECK-MASSAGES: twine variables are prone to use-after-free bugs
>  // CHECK-MESSAGES: note: FIX-IT applied suggested code changes
>  // CHECK: static std::string Moo = (Twine("bark") + "bah").str();
>
>  int main() {
>const Twine t = Twine("a") + "b" + Twine(42);
> 

r212541 - Improve memory ownership of vfs::Files in the FileSystemStatCache by using std::unique_ptr

[David Blaikie]

Author: dblaikie
Date: Tue Jul  8 10:46:02 2014
New Revision: 212541

URL: http://llvm.org/viewvc/llvm-project?rev=212541&view=rev
Log:
Improve memory ownership of vfs::Files in the FileSystemStatCache by using 
std::unique_ptr

Spotted after a memory leak (due to the complexities of manual memory
management) was fixed in 212466.

Modified:
cfe/trunk/include/clang/Basic/FileManager.h
cfe/trunk/include/clang/Basic/FileSystemStatCache.h
cfe/trunk/lib/Basic/FileManager.cpp
cfe/trunk/lib/Basic/FileSystemStatCache.cpp
cfe/trunk/lib/Frontend/CacheTokens.cpp
cfe/trunk/lib/Lex/PTHLexer.cpp

Modified: cfe/trunk/include/clang/Basic/FileManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=212541&r1=212540&r2=212541&view=diff
==
--- cfe/trunk/include/clang/Basic/FileManager.h (original)
+++ cfe/trunk/include/clang/Basic/FileManager.h Tue Jul  8 10:46:02 2014
@@ -172,7 +172,7 @@ class FileManager : public RefCountedBas
   std::unique_ptr StatCache;
 
   bool getStatValue(const char *Path, FileData &Data, bool isFile,
-vfs::File **F);
+std::unique_ptr *F);
 
   /// Add all ancestors of the given path (pointing to either a file
   /// or a directory) as virtual directories.

Modified: cfe/trunk/include/clang/Basic/FileSystemStatCache.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileSystemStatCache.h?rev=212541&r1=212540&r2=212541&view=diff
==
--- cfe/trunk/include/clang/Basic/FileSystemStatCache.h (original)
+++ cfe/trunk/include/clang/Basic/FileSystemStatCache.h Tue Jul  8 10:46:02 2014
@@ -69,7 +69,7 @@ public:
   /// implementation can optionally fill in \p F with a valid \p File object 
and
   /// the client guarantees that it will close it.
   static bool get(const char *Path, FileData &Data, bool isFile,
-  vfs::File **F, FileSystemStatCache *Cache,
+  std::unique_ptr *F, FileSystemStatCache *Cache,
   vfs::FileSystem &FS);
 
   /// \brief Sets the next stat call cache in the chain of stat caches.
@@ -87,11 +87,15 @@ public:
   FileSystemStatCache *takeNextStatCache() { return NextStatCache.release(); }
 
 protected:
+  // FIXME: The pointer here is a non-owning/optional reference to the
+  // unique_ptr. Optional&> might be nicer, but
+  // Optional needs some work to support references so this isn't possible yet.
   virtual LookupResult getStat(const char *Path, FileData &Data, bool isFile,
-   vfs::File **F, vfs::FileSystem &FS) = 0;
+   std::unique_ptr *F,
+   vfs::FileSystem &FS) = 0;
 
   LookupResult statChained(const char *Path, FileData &Data, bool isFile,
-   vfs::File **F, vfs::FileSystem &FS) {
+   std::unique_ptr *F, vfs::FileSystem &FS) 
{
 if (FileSystemStatCache *Next = getNextStatCache())
   return Next->getStat(Path, Data, isFile, F, FS);
 
@@ -116,7 +120,8 @@ public:
   iterator end() const { return StatCalls.end(); }
 
   LookupResult getStat(const char *Path, FileData &Data, bool isFile,
-   vfs::File **F, vfs::FileSystem &FS) override;
+   std::unique_ptr *F,
+   vfs::FileSystem &FS) override;
 };
 
 } // end namespace clang

Modified: cfe/trunk/lib/Basic/FileManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileManager.cpp?rev=212541&r1=212540&r2=212541&view=diff
==
--- cfe/trunk/lib/Basic/FileManager.cpp (original)
+++ cfe/trunk/lib/Basic/FileManager.cpp Tue Jul  8 10:46:02 2014
@@ -253,7 +253,7 @@ const FileEntry *FileManager::getFile(St
   // FIXME: This will reduce the # syscalls.
 
   // Nope, there isn't.  Check to see if the file exists.
-  vfs::File *F = nullptr;
+  std::unique_ptr F;
   FileData Data;
   if (getStatValue(InterndFileName, Data, true, openFile ? &F : nullptr)) {
 // There's no real file at the given path.
@@ -281,10 +281,6 @@ const FileEntry *FileManager::getFile(St
 if (DirInfo != UFE.Dir && Data.IsVFSMapped)
   UFE.Dir = DirInfo;
 
-// If the stat process opened the file, close it to avoid a FD leak.
-if (F)
-  delete F;
-
 return &UFE;
   }
 
@@ -297,7 +293,7 @@ const FileEntry *FileManager::getFile(St
   UFE.UniqueID = Data.UniqueID;
   UFE.IsNamedPipe = Data.IsNamedPipe;
   UFE.InPCH = Data.InPCH;
-  UFE.File.reset(F);
+  UFE.File = std::move(F);
   UFE.IsValid = true;
   return &UFE;
 }
@@ -453,7 +449,7 @@ getBufferForFile(StringRef Filename, std
 /// false if it's an existent real file.  If FileDescriptor is NULL,
 /// do directory look-up instead of file look-up.
 bool FileManager::getStatValue(const char 

Re: [clang-tools-extra] r212535 - [clang-tidy] Add a little checker for Twine locals in LLVM.

[Benjamin Kramer]

On Tue, Jul 8, 2014 at 5:33 PM, Alexander Kornienko  wrote:
> Thanks for writing the check! It would be better though, if you sent the
> code for pre-commit review, especially as you are adding a new check.

I'll keep this in mind for later commits, thanks. This one is really
trivial though and only applies to LLVM.

> Did you run the check over the whole LLVM/Clang source code? Could you share
> the results? (Number of warnings and false-positive rate in a sample of a
> few tens of instances.)

3 cases in LLVM, 2 of them real bugs. 4 in Clang, all harmless. Even
though some of them are technically false positives I consider them
all to be bad style. Twine is designed to be used in parameter lists
*only*, let's keep it that way.

> On Tue, Jul 8, 2014 at 3:32 PM, Benjamin Kramer 
> wrote:
>>
>> Author: d0k
>> Date: Tue Jul  8 09:32:17 2014
>> New Revision: 212535
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=212535&view=rev
>> Log:
>> [clang-tidy] Add a little checker for Twine locals in LLVM.
>>
>> Those often cause use after free bugs and should be generally avoided.
>> Technically it is safe to have a Twine with >=2 components in a variable
>> but I don't think it is a good pattern to follow. The almost trivial
>> checker
>> comes with elaborated fix-it hints that turn the Twine into a std::string
>> if necessary and otherwise fall back to the original type if the Twine
>> is created from a single value.
>>
>> Added:
>> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
>> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
>> clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
>> clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
>>
>> Modified: clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt?rev=212535&r1=212534&r2=212535&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt (original)
>> +++ clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt Tue Jul  8
>> 09:32:17 2014
>> @@ -4,6 +4,7 @@ add_clang_library(clangTidyLLVMModule
>>IncludeOrderCheck.cpp
>>LLVMTidyModule.cpp
>>NamespaceCommentCheck.cpp
>> +  TwineLocalCheck.cpp
>>
>>LINK_LIBS
>>clangAST
>>
>> Modified: clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp?rev=212535&r1=212534&r2=212535&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp (original)
>> +++ clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp Tue Jul  8
>> 09:32:17 2014
>> @@ -12,6 +12,7 @@
>>  #include "../ClangTidyModuleRegistry.h"
>>  #include "IncludeOrderCheck.h"
>>  #include "NamespaceCommentCheck.h"
>> +#include "TwineLocalCheck.h"
>>
>>  namespace clang {
>>  namespace tidy {
>> @@ -24,6 +25,9 @@ public:
>>  CheckFactories.addCheckFactory(
>>  "llvm-namespace-comment",
>>  new ClangTidyCheckFactory());
>> +CheckFactories.addCheckFactory(
>> +"llvm-twine-local",
>> +new ClangTidyCheckFactory());
>>}
>>  };
>>
>>
>> Added: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212535&view=auto
>>
>> ==
>> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (added)
>> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul  8
>> 09:32:17 2014
>> @@ -0,0 +1,64 @@
>> +//===--- TwineLocalCheck.cpp - clang-tidy
>> -===//
>> +//
>> +// The LLVM Compiler Infrastructure
>> +//
>> +// This file is distributed under the University of Illinois Open Source
>> +// License. See LICENSE.TXT for details.
>> +//
>>
>> +//===--===//
>> +
>> +#include "TwineLocalCheck.h"
>> +#include "clang/AST/ASTContext.h"
>> +#include "clang/ASTMatchers/ASTMatchers.h"
>> +#include "clang/Lex/Lexer.h"
>> +#include "llvm/Support/raw_ostream.h"
>
>
> Is this header needed?

Nope.

>
>>
>> +
>> +using namespace clang::ast_matchers;
>> +
>> +namespace clang {
>> +namespace tidy {
>> +
>> +TwineLocalCheck::TwineLocalCheck() {}
>> +
>> +void TwineLocalCheck::registerMatchers(MatchFinder *Finder) {
>> +  auto TwineType =
>> +  qualType(hasDeclaration(recordDecl(hasName("::llvm::Twine";
>> +  Finder->addMatcher(varDecl(hasType(TwineType)).bind("variable"), this);
>> +}
>> +
>> +void TwineLocalCheck::check(const MatchFinder::MatchResult &Result) {
>

[clang-tools-extra] r212540 - [clang-tidy] Address review comments for the Twine checker.

[Benjamin Kramer]

Author: d0k
Date: Tue Jul  8 10:41:20 2014
New Revision: 212540

URL: http://llvm.org/viewvc/llvm-project?rev=212540&view=rev
Log:
[clang-tidy] Address review comments for the Twine checker.

- Remove unused includes.
- Minor wording fix.
- Added support to check for clang-tidy messages to check_clang_tidy_fix.sh
= Updated test case.

Modified:
clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp

Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212540&r1=212539&r2=212540&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul  8 
10:41:20 2014
@@ -11,7 +11,6 @@
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Lex/Lexer.h"
-#include "llvm/Support/raw_ostream.h"
 
 using namespace clang::ast_matchers;
 
@@ -29,7 +28,7 @@ void TwineLocalCheck::registerMatchers(M
 void TwineLocalCheck::check(const MatchFinder::MatchResult &Result) {
   const VarDecl *VD = Result.Nodes.getNodeAs("variable");
   auto Diag = diag(VD->getLocation(),
-   "twine variables are prone to use after free bugs");
+   "twine variables are prone to use-after-free bugs");
 
   // If this VarDecl has an initializer try to fix it.
   if (VD->hasInit()) {

Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h?rev=212540&r1=212539&r2=212540&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h Tue Jul  8 
10:41:20 2014
@@ -11,7 +11,6 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_LLVM_TWINE_LOCAL_CHECK_H
 
 #include "../ClangTidy.h"
-#include "llvm/Support/Regex.h"
 
 namespace clang {
 namespace tidy {

Modified: clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh?rev=212540&r1=212539&r2=212540&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh (original)
+++ clang-tools-extra/trunk/test/clang-tidy/check_clang_tidy_fix.sh Tue Jul  8 
10:41:20 2014
@@ -7,5 +7,6 @@ CHECK_TO_RUN=$2
 TEMPORARY_FILE=$3.cpp
 
 grep -Ev "// *[A-Z-]+:" ${INPUT_FILE} > ${TEMPORARY_FILE}
-clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" -- --std=c++11
+clang-tidy ${TEMPORARY_FILE} -fix --checks="-*,${CHECK_TO_RUN}" -- --std=c++11 
> ${TEMPORARY_FILE}.msg 2>&1
 FileCheck -input-file=${TEMPORARY_FILE} ${INPUT_FILE} -strict-whitespace
+not grep CHECK-MESSAGES ${INPUT_FILE} || FileCheck 
-input-file=${TEMPORARY_FILE}.msg ${INPUT_FILE} -check-prefix=CHECK-MESSAGES

Modified: clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp?rev=212540&r1=212539&r2=212540&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp Tue Jul  8 
10:41:20 2014
@@ -1,7 +1,5 @@
-// RUN: grep -Ev "// *[A-Z-]+:" %s > %t.cpp
-// RUN: clang-tidy %t.cpp -checks='-*,llvm-twine-local' -fix -- > %t.msg 2>&1
-// RUN: FileCheck -input-file=%t.cpp %s
-// RUN: FileCheck -input-file=%t.msg -check-prefix=CHECK-MESSAGES %s
+// RUN: $(dirname %s)/check_clang_tidy_fix.sh %s llvm-twine-local %t
+// REQUIRES: shell
 
 namespace llvm {
 class Twine {
@@ -17,19 +15,19 @@ using namespace llvm;
 void foo(const Twine &x);
 
 static Twine Moo = Twine("bark") + "bah";
-// CHECK-MASSAGES: twine variables are prone to use after free bugs
+// CHECK-MASSAGES: twine variables are prone to use-after-free bugs
 // CHECK-MESSAGES: note: FIX-IT applied suggested code changes
 // CHECK: static std::string Moo = (Twine("bark") + "bah").str();
 
 int main() {
   const Twine t = Twine("a") + "b" + Twine(42);
-// CHECK-MASSAGES: twine variables are prone to use after free bugs
+// CHECK-MASSAGES: twine variables are prone to use-after-free bugs
 // CHECK-MESSAGES: note: FIX-IT applied suggested code changes
 // CHECK: std::string t = (Twine("a") + "b" + Twine(42)).str();
   foo(Twine("a") + "b");
 
   Twine Prefix = false ? "__INT_FAST" : "__UINT_FAST";
-// CHECK-MAS

Re: [clang-tools-extra] r212535 - [clang-tidy] Add a little checker for Twine locals in LLVM.

[Alexander Kornienko]

Thanks for writing the check! It would be better though, if you sent the
code for pre-commit review, especially as you are adding a new check.

Did you run the check over the whole LLVM/Clang source code? Could you
share the results? (Number of warnings and false-positive rate in a sample
of a few tens of instances.)

On Tue, Jul 8, 2014 at 3:32 PM, Benjamin Kramer 
wrote:

> Author: d0k
> Date: Tue Jul  8 09:32:17 2014
> New Revision: 212535
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212535&view=rev
> Log:
> [clang-tidy] Add a little checker for Twine locals in LLVM.
>
> Those often cause use after free bugs and should be generally avoided.
> Technically it is safe to have a Twine with >=2 components in a variable
> but I don't think it is a good pattern to follow. The almost trivial
> checker
> comes with elaborated fix-it hints that turn the Twine into a std::string
> if necessary and otherwise fall back to the original type if the Twine
> is created from a single value.
>
> Added:
> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
> clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
> Modified:
> clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
> clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
>
> Modified: clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt?rev=212535&r1=212534&r2=212535&view=diff
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt Tue Jul  8
> 09:32:17 2014
> @@ -4,6 +4,7 @@ add_clang_library(clangTidyLLVMModule
>IncludeOrderCheck.cpp
>LLVMTidyModule.cpp
>NamespaceCommentCheck.cpp
> +  TwineLocalCheck.cpp
>
>LINK_LIBS
>clangAST
>
> Modified: clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp?rev=212535&r1=212534&r2=212535&view=diff
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp (original)
> +++ clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp Tue Jul  8
> 09:32:17 2014
> @@ -12,6 +12,7 @@
>  #include "../ClangTidyModuleRegistry.h"
>  #include "IncludeOrderCheck.h"
>  #include "NamespaceCommentCheck.h"
> +#include "TwineLocalCheck.h"
>
>  namespace clang {
>  namespace tidy {
> @@ -24,6 +25,9 @@ public:
>  CheckFactories.addCheckFactory(
>  "llvm-namespace-comment",
>  new ClangTidyCheckFactory());
> +CheckFactories.addCheckFactory(
> +"llvm-twine-local",
> +new ClangTidyCheckFactory());
>}
>  };
>
>
> Added: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212535&view=auto
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (added)
> +++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul  8
> 09:32:17 2014
> @@ -0,0 +1,64 @@
> +//===--- TwineLocalCheck.cpp - clang-tidy
> -===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
>
> +//===--===//
> +
> +#include "TwineLocalCheck.h"
> +#include "clang/AST/ASTContext.h"
> +#include "clang/ASTMatchers/ASTMatchers.h"
> +#include "clang/Lex/Lexer.h"
> +#include "llvm/Support/raw_ostream.h"
>

Is this header needed?


> +
> +using namespace clang::ast_matchers;
> +
> +namespace clang {
> +namespace tidy {
> +
> +TwineLocalCheck::TwineLocalCheck() {}
> +
> +void TwineLocalCheck::registerMatchers(MatchFinder *Finder) {
> +  auto TwineType =
> +  qualType(hasDeclaration(recordDecl(hasName("::llvm::Twine";
> +  Finder->addMatcher(varDecl(hasType(TwineType)).bind("variable"), this);
> +}
> +
> +void TwineLocalCheck::check(const MatchFinder::MatchResult &Result) {
> +  const VarDecl *VD = Result.Nodes.getNodeAs("variable");
> +  auto Diag = diag(VD->getLocation(),
> +   "twine variables are prone to use after free bugs");
>

I'm not a native speaker, but "use-after-free" looks more correct to me.


> +
> +  // If this VarDecl has an initializer try to fix it.
> +  if (VD->hasInit()) {
> +// Peel away implicit constructors and casts so we can see the actual
> type
> +// of the initializer.
> +const Expr *C = VD->getInit();
> +while (isa(C))
> +  C = cast(C)->getArg(0)-

[libcxx] r212538 - Fix some failing tests for the standard containers. The tests were failing in 32-bit mode because they assumed that std::size_type and make_unsigned::type were always the

[Marshall Clow]

Author: marshall
Date: Tue Jul  8 10:19:40 2014
New Revision: 212538

URL: http://llvm.org/viewvc/llvm-project?rev=212538&view=rev
Log:
Fix some failing tests for the standard containers. The tests were failing in 
32-bit mode because they assumed that std::size_type and 
make_unsigned::type were always the same type. No change to libc++, 
just the tests.

Modified:
libcxx/trunk/test/containers/associative/map/types.pass.cpp
libcxx/trunk/test/containers/associative/multimap/types.pass.cpp
libcxx/trunk/test/containers/associative/multiset/types.pass.cpp
libcxx/trunk/test/containers/associative/set/types.pass.cpp

libcxx/trunk/test/containers/sequences/deque/deque.capacity/resize_size.pass.cpp

libcxx/trunk/test/containers/sequences/deque/deque.capacity/resize_size_value.pass.cpp
libcxx/trunk/test/containers/sequences/deque/types.pass.cpp
libcxx/trunk/test/containers/sequences/forwardlist/types.pass.cpp
libcxx/trunk/test/containers/unord/unord.map/types.pass.cpp
libcxx/trunk/test/containers/unord/unord.multimap/types.pass.cpp
libcxx/trunk/test/containers/unord/unord.multiset/types.pass.cpp
libcxx/trunk/test/containers/unord/unord.set/types.pass.cpp

Modified: libcxx/trunk/test/containers/associative/map/types.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/containers/associative/map/types.pass.cpp?rev=212538&r1=212537&r2=212538&view=diff
==
--- libcxx/trunk/test/containers/associative/map/types.pass.cpp (original)
+++ libcxx/trunk/test/containers/associative/map/types.pass.cpp Tue Jul  8 
10:19:40 2014
@@ -37,31 +37,34 @@
 int main()
 {
 {
-static_assert((std::is_same::key_type, int>::value), 
"");
-static_assert((std::is_same::mapped_type, 
double>::value), "");
-static_assert((std::is_same::value_type, 
std::pair >::value), "");
-static_assert((std::is_same::key_compare, 
std::less >::value), "");
-static_assert((std::is_same::allocator_type, 
std::allocator > >::value), "");
-static_assert((std::is_same::reference, 
std::pair&>::value), "");
-static_assert((std::is_same::const_reference, const 
std::pair&>::value), "");
-static_assert((std::is_same::pointer, 
std::pair*>::value), "");
-static_assert((std::is_same::const_pointer, const 
std::pair*>::value), "");
-static_assert((std::is_same::size_type, 
std::size_t>::value), "");
-static_assert((std::is_same::difference_type, 
std::ptrdiff_t>::value), "");
+typedef std::map C;
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same 
>::value), "");
+static_assert((std::is_same >::value), "");
+static_assert((std::is_same > >::value), "");
+static_assert((std::is_same&>::value), "");
+static_assert((std::is_same&>::value), "");
+static_assert((std::is_same*>::value), "");
+static_assert((std::is_same*>::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), 
"");
 }
 #if __cplusplus >= 201103L
 {
-static_assert((std::is_same, 
min_allocator>>::key_type, int>::value), "");
-static_assert((std::is_same, 
min_allocator>>::mapped_type, double>::value), "");
-static_assert((std::is_same, 
min_allocator>>::value_type, std::pair >::value), "");
-static_assert((std::is_same, 
min_allocator>>::key_compare, std::less 
>::value), "");
-static_assert((std::is_same, 
min_allocator>>::allocator_type, 
min_allocator > >::value), "");
-static_assert((std::is_same, 
min_allocator>>::reference, std::pair&>::value), "");
-static_assert((std::is_same, 
min_allocator>>::const_reference, const 
std::pair&>::value), "");
-static_assert((std::is_same, 
min_allocator>>::pointer, 
min_pointer>>::value), "");
-static_assert((std::is_same, 
min_allocator>>::const_pointer, min_pointer>>::value), "");
-static_assert((std::is_same, 
min_allocator>>::size_type, std::size_t>::value), 
"");
-static_assert((std::is_same, 
min_allocator>>::difference_type, 
std::ptrdiff_t>::value), "");
+typedef std::map, 
min_allocator>> C;
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same 
>::value), "");
+static_assert((std::is_same >::value), "");
+static_assert((std::is_same > >::value), "");
+static_assert((std::is_same&>::value), "");
+static_assert((std::is_same&>::value), "");
+static_assert((std::is_same>>::value), "");
+static_assert((std::is_same>>::value), "");
+//  min_allocator doesn't have a size_type, so one gets synthesized
+static_assert((std::is_same::type>::value), "");
+static_assert((std::is_same::value), 
"");
 }
 #endif
 }

Modified: libcxx/trunk/test/containers/associative/multimap/types.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/containers/associative/multima

Re: r212060 - Consider module depedencies when checking a preamble in libclang

[Ben Langmuir]

> On Jul 7, 2014, at 11:10 AM, Ulrich Weigand  wrote:
> 
> Ben Langmuir  wrote on 07.07.2014 19:03:33:
> 
>> I’ll fix the test to specify a unique module cache path.
> 
> Thanks, that will certainly fix the test case problem!
> 
>> In general, we use llvm::sys::path::system_temp_dir to create
>> the default module cache location.  On Darwin, we use
>> DARWIN_USER_CACHE_DIR, which is user-specific so this isn’t an
>> issue.  On Linux, we seem to honour the environment variable TMPDIR,
>> before falling back to /var/tmp. I don’t know if this is correct for
>> Linux; perhaps you know of a better way?
> 
> I'm not really an expert here ...
> 
> One option might be to include the user name in the temp directory
> name; I see for example
>   /var/tmp/kdecache-uweigand
> (owned by my uweigand user ID) on my desktop machine …

That seems fine to me, FWIW.  Do you feel like putting together a patch? Or I 
can do it when I have some time.

Ben

> 
> Bye,
> Ulrich


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[clang-tools-extra] r212535 - [clang-tidy] Add a little checker for Twine locals in LLVM.

[Benjamin Kramer]

Author: d0k
Date: Tue Jul  8 09:32:17 2014
New Revision: 212535

URL: http://llvm.org/viewvc/llvm-project?rev=212535&view=rev
Log:
[clang-tidy] Add a little checker for Twine locals in LLVM.

Those often cause use after free bugs and should be generally avoided.
Technically it is safe to have a Twine with >=2 components in a variable
but I don't think it is a good pattern to follow. The almost trivial checker
comes with elaborated fix-it hints that turn the Twine into a std::string
if necessary and otherwise fall back to the original type if the Twine
is created from a single value.

Added:
clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.h
clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp

Modified: clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt?rev=212535&r1=212534&r2=212535&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/llvm/CMakeLists.txt Tue Jul  8 09:32:17 
2014
@@ -4,6 +4,7 @@ add_clang_library(clangTidyLLVMModule
   IncludeOrderCheck.cpp
   LLVMTidyModule.cpp
   NamespaceCommentCheck.cpp
+  TwineLocalCheck.cpp
 
   LINK_LIBS
   clangAST

Modified: clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp?rev=212535&r1=212534&r2=212535&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/llvm/LLVMTidyModule.cpp Tue Jul  8 
09:32:17 2014
@@ -12,6 +12,7 @@
 #include "../ClangTidyModuleRegistry.h"
 #include "IncludeOrderCheck.h"
 #include "NamespaceCommentCheck.h"
+#include "TwineLocalCheck.h"
 
 namespace clang {
 namespace tidy {
@@ -24,6 +25,9 @@ public:
 CheckFactories.addCheckFactory(
 "llvm-namespace-comment",
 new ClangTidyCheckFactory());
+CheckFactories.addCheckFactory(
+"llvm-twine-local",
+new ClangTidyCheckFactory());
   }
 };
 

Added: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=212535&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Tue Jul  8 
09:32:17 2014
@@ -0,0 +1,64 @@
+//===--- TwineLocalCheck.cpp - clang-tidy 
-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "TwineLocalCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Lex/Lexer.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+
+TwineLocalCheck::TwineLocalCheck() {}
+
+void TwineLocalCheck::registerMatchers(MatchFinder *Finder) {
+  auto TwineType =
+  qualType(hasDeclaration(recordDecl(hasName("::llvm::Twine";
+  Finder->addMatcher(varDecl(hasType(TwineType)).bind("variable"), this);
+}
+
+void TwineLocalCheck::check(const MatchFinder::MatchResult &Result) {
+  const VarDecl *VD = Result.Nodes.getNodeAs("variable");
+  auto Diag = diag(VD->getLocation(),
+   "twine variables are prone to use after free bugs");
+
+  // If this VarDecl has an initializer try to fix it.
+  if (VD->hasInit()) {
+// Peel away implicit constructors and casts so we can see the actual type
+// of the initializer.
+const Expr *C = VD->getInit();
+while (isa(C))
+  C = cast(C)->getArg(0)->IgnoreParenImpCasts();
+
+SourceRange TypeRange =
+VD->getTypeSourceInfo()->getTypeLoc().getSourceRange();
+
+// A real Twine, turn it into a std::string.
+if (VD->getType()->getCanonicalTypeUnqualified() ==
+C->getType()->getCanonicalTypeUnqualified()) {
+  SourceLocation EndLoc = Lexer::getLocForEndOfToken(
+  VD->getInit()->getLocEnd(), 0, *Result.SourceManager,
+  Result.Context->getLangOpts());
+  Diag << FixItHint::CreateReplacement(TypeRange, "std::string")
+   << FixItHint::CreateInsertion(VD->getInit()->getLocStart(), "(")
+   << FixItHint::CreateInsertion(EndLoc, ").str()");
+} else {
+  // Just an implicit co

Re: r212125 - MS ABI: Reference MSVC RTTI from the VFTable

[Timur Iskhodzhanov]

... and let's move the discussion of the fix there too.

2014-07-08 17:15 GMT+04:00 Timur Iskhodzhanov :
> Filed
> http://llvm.org/bugs/show_bug.cgi?id=20244
> to track the progress.
>
> 2014-07-08 16:28 GMT+04:00 Timur Iskhodzhanov :
>> I'm trying to understand how to fix the ASan/Windows breakage wrt vftables.
>>
>> Here's what David told me on the r212138 thread:
>> 2014-07-08 4:39 GMT+04:00 David Majnemer :
>>> ASAN replaces one internal global with another. Because the new symbol
>>> isn't in a Comdat, it's alias isn't either.  This makes the alias a
>>> strong definition.
>>
>> After rethinking this a bit, I'm puzzled.
>> Not only we need to correctly link no-rtti with rtti-enabled TUs but we
>> should also handle asan vs no-asan TUs.
>> ASan increases the size of globals by adding redzones.
>> It looks like an internal GV for a vftable in a (asan enabled, no-rtti)
>> configuration will be *larger* than the same vftable in a
>> (no-asan,rtti-enabled) configuration and the linking process will cause bad
>> result.
>> That said, I think we have to disable instrumentation of vftables on Windows
>> as long as we want to support mixing rtti- with no-rtti TUs or asan with
>> no-asan TUs.
>> Are we on the same page here?
>>
>> If we agree that we can't add redzones to vftables, we should adjust
>> AddressSanitizerModule::ShouldInstrumentGlobal(GV) to handle this.
>> The problem is that those GVs are unnamed.
>> Is there a condition that's only true for the internal vftable GVs so I can
>> write an "if()"?
>> I think "if (G->hasComdat() && G->getLinkage() == InternalLinkage)" is a too
>> wide condition.
>> Or can we name these internal GVs somehow to make them easy to filter out?
>> E.g. "\02?_7blah"?
>>
>>
>> 2014-07-02 0:30 GMT+04:00 David Majnemer :
>>
>>> Author: majnemer
>>> Date: Tue Jul  1 15:30:31 2014
>>> New Revision: 212125
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=212125&view=rev
>>> Log:
>>> MS ABI: Reference MSVC RTTI from the VFTable
>>>
>>> The pointer for a class's RTTI data comes right before the VFTable but
>>> has no name.  To be properly compatible with this, we do the following:
>>> * Create a single GlobalVariable which holds the contents of the VFTable
>>>   _and_ the pointer to the RTTI data.
>>> * Create a GlobalAlias, with appropriate linkage/visibility, that points
>>>   just after the RTTI data pointer.  This ensures that the VFTable
>>>   symbol will always refer to VFTable data.
>>> * Create a Comdat with a "Largest" SelectionKind and stick the private
>>>   GlobalVariable in it.  By transitivity, the GlobalAlias will be a
>>>   member of the Comdat group.  Using "Largest" ensures that foreign
>>>   definitions without an RTTI data pointer will _not_ be chosen in the
>>>   final linked image.
>>>
>>> Whether or not we emit RTTI data depends on several things:
>>> * The -fno-rtti flag implies that we should never not emit a pointer to
>>>   RTTI data before the VFTable.
>>> * __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
>>>   available_externally GlobalVariable to provide a local definition of
>>>   the VFTable.  This means that we won't have any available_externally
>>>   definitions of things like complete object locators.  This is
>>>   acceptable because they are never directly referenced.
>>>
>>> To my knowledge, this completes the implementation of MSVC RTTI code
>>> generation.
>>>
>>> Further semantic work should be done to properly support /GR-.
>>>
>>> Modified:
>>> cfe/trunk/lib/AST/VTableBuilder.cpp
>>> cfe/trunk/lib/CodeGen/CGVTables.cpp
>>> cfe/trunk/lib/CodeGen/CGVTables.h
>>> cfe/trunk/lib/CodeGen/CodeGenModule.h
>>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>>> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>>> cfe/trunk/lib/CodeGen/MicrosoftRTTI.cpp
>>> cfe/trunk/test/CodeGenCXX/dllexport.cpp
>>>
>>> Modified: cfe/trunk/lib/AST/VTableBuilder.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=212125&r1=212124&r2=212125&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/AST/VTableBuilder.cpp (original)
>>> +++ cfe/trunk/lib/AST/VTableBuilder.cpp Tue Jul  1 15:30:31 2014
>>> @@ -2574,6 +2574,12 @@ public:
>>>
>>> MostDerivedClassLayout(Context.getASTRecordLayout(MostDerivedClass)),
>>>  WhichVFPtr(*Which),
>>>  Overriders(MostDerivedClass, CharUnits(), MostDerivedClass) {
>>> +// Only include the RTTI component if we know that we will provide a
>>> +// definition of the vftable.
>>> +if (Context.getLangOpts().RTTI &&
>>> +!MostDerivedClass->hasAttr())
>>> +  Components.push_back(VTableComponent::MakeRTTI(MostDerivedClass));
>>> +
>>>  LayoutVFTable();
>>>
>>>  if (Context.getLangOpts().DumpVTableLayouts)
>>> @@ -2915,7 +2921,8 @@ void VFTableBuilder::AddMethods(BaseSubo
>>>  // it requires return adjustment. Insert the method info for this
>>> m

Re: r212125 - MS ABI: Reference MSVC RTTI from the VFTable

[Timur Iskhodzhanov]

Filed
http://llvm.org/bugs/show_bug.cgi?id=20244
to track the progress.

2014-07-08 16:28 GMT+04:00 Timur Iskhodzhanov :
> I'm trying to understand how to fix the ASan/Windows breakage wrt vftables.
>
> Here's what David told me on the r212138 thread:
> 2014-07-08 4:39 GMT+04:00 David Majnemer :
>> ASAN replaces one internal global with another. Because the new symbol
>> isn't in a Comdat, it's alias isn't either.  This makes the alias a
>> strong definition.
>
> After rethinking this a bit, I'm puzzled.
> Not only we need to correctly link no-rtti with rtti-enabled TUs but we
> should also handle asan vs no-asan TUs.
> ASan increases the size of globals by adding redzones.
> It looks like an internal GV for a vftable in a (asan enabled, no-rtti)
> configuration will be *larger* than the same vftable in a
> (no-asan,rtti-enabled) configuration and the linking process will cause bad
> result.
> That said, I think we have to disable instrumentation of vftables on Windows
> as long as we want to support mixing rtti- with no-rtti TUs or asan with
> no-asan TUs.
> Are we on the same page here?
>
> If we agree that we can't add redzones to vftables, we should adjust
> AddressSanitizerModule::ShouldInstrumentGlobal(GV) to handle this.
> The problem is that those GVs are unnamed.
> Is there a condition that's only true for the internal vftable GVs so I can
> write an "if()"?
> I think "if (G->hasComdat() && G->getLinkage() == InternalLinkage)" is a too
> wide condition.
> Or can we name these internal GVs somehow to make them easy to filter out?
> E.g. "\02?_7blah"?
>
>
> 2014-07-02 0:30 GMT+04:00 David Majnemer :
>
>> Author: majnemer
>> Date: Tue Jul  1 15:30:31 2014
>> New Revision: 212125
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=212125&view=rev
>> Log:
>> MS ABI: Reference MSVC RTTI from the VFTable
>>
>> The pointer for a class's RTTI data comes right before the VFTable but
>> has no name.  To be properly compatible with this, we do the following:
>> * Create a single GlobalVariable which holds the contents of the VFTable
>>   _and_ the pointer to the RTTI data.
>> * Create a GlobalAlias, with appropriate linkage/visibility, that points
>>   just after the RTTI data pointer.  This ensures that the VFTable
>>   symbol will always refer to VFTable data.
>> * Create a Comdat with a "Largest" SelectionKind and stick the private
>>   GlobalVariable in it.  By transitivity, the GlobalAlias will be a
>>   member of the Comdat group.  Using "Largest" ensures that foreign
>>   definitions without an RTTI data pointer will _not_ be chosen in the
>>   final linked image.
>>
>> Whether or not we emit RTTI data depends on several things:
>> * The -fno-rtti flag implies that we should never not emit a pointer to
>>   RTTI data before the VFTable.
>> * __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
>>   available_externally GlobalVariable to provide a local definition of
>>   the VFTable.  This means that we won't have any available_externally
>>   definitions of things like complete object locators.  This is
>>   acceptable because they are never directly referenced.
>>
>> To my knowledge, this completes the implementation of MSVC RTTI code
>> generation.
>>
>> Further semantic work should be done to properly support /GR-.
>>
>> Modified:
>> cfe/trunk/lib/AST/VTableBuilder.cpp
>> cfe/trunk/lib/CodeGen/CGVTables.cpp
>> cfe/trunk/lib/CodeGen/CGVTables.h
>> cfe/trunk/lib/CodeGen/CodeGenModule.h
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>> cfe/trunk/lib/CodeGen/MicrosoftRTTI.cpp
>> cfe/trunk/test/CodeGenCXX/dllexport.cpp
>>
>> Modified: cfe/trunk/lib/AST/VTableBuilder.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=212125&r1=212124&r2=212125&view=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/VTableBuilder.cpp (original)
>> +++ cfe/trunk/lib/AST/VTableBuilder.cpp Tue Jul  1 15:30:31 2014
>> @@ -2574,6 +2574,12 @@ public:
>>
>> MostDerivedClassLayout(Context.getASTRecordLayout(MostDerivedClass)),
>>  WhichVFPtr(*Which),
>>  Overriders(MostDerivedClass, CharUnits(), MostDerivedClass) {
>> +// Only include the RTTI component if we know that we will provide a
>> +// definition of the vftable.
>> +if (Context.getLangOpts().RTTI &&
>> +!MostDerivedClass->hasAttr())
>> +  Components.push_back(VTableComponent::MakeRTTI(MostDerivedClass));
>> +
>>  LayoutVFTable();
>>
>>  if (Context.getLangOpts().DumpVTableLayouts)
>> @@ -2915,7 +2921,8 @@ void VFTableBuilder::AddMethods(BaseSubo
>>  // it requires return adjustment. Insert the method info for this
>> method.
>>  unsigned VBIndex =
>>  LastVBase ? VTables.getVBTableIndex(MostDerivedClass, LastVBase)
>> : 0;
>> -MethodInfo MI(VBIndex, Components.size());
>> +MethodInfo MI(VBIndex, Context.getLangO

Re: [PATCH, v2] ARM: fix inline atomic handling

[Tim Northover]

Hi Phoebe,

+// Cortex M does not support 8 byte atomics, while general Thumb2 does.
+StringRef Profile = getCPUProfile(Name);
+if (Profile == "M" && MaxAtomicInlineWidth) {
+  MaxAtomicPromoteWidth = 32;
+  MaxAtomicInlineWidth = 32;
+}

This seems like a fairly key point of the patch (it's what inspired
you to start working on this area isn't it?), but it's not tested; it
would be good to see some checks that the 64-bit case is handled as
expected.

Cheers.

Tim.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211216 - CodeGen: improve ms instrincics support

[Timur Iskhodzhanov]

2014-07-08 6:28 GMT+04:00 Saleem Abdulrasool :
> On Fri, Jun 20, 2014 at 1:38 PM, Reid Kleckner  wrote:
>>
>> Remember how I said it'd be OK if we provided
>> _InterlockedCompareExchangePointer on x86?  Well, doing that broke the
>> sanitizers.  Do 'check-asan' on 32-bit Windows to reproduce.
>>
>> This is the problematic code:
>> inline static void *_InterlockedCompareExchangePointer(
>> void *volatile *Destination,
>> void *Exchange, void *Comparand) {
>>   return reinterpret_cast(
>>   _InterlockedCompareExchange(
>>   reinterpret_cast(Destination),  // NOLINT
>>   reinterpret_cast(Exchange),   // NOLINT
>>   reinterpret_cast(Comparand)));// NOLINT
>> }
>
>
> Ugh, seems that my message never got sent, it remained in the drafts :-(.
> Thanks for submitting a fix for it Timur.  I had the following conflict
> which is why it never got addressed:
>
> I seem to be having issues building check-asan, as in missing the target
> :-(.

You should probably check out compiler to projects/

> However, since you were kind enough to provide the reduction of the
> issue, it really helps.
>
> Im conflicted on the best approach to solve this.  We could either
> a) filter this in FunctionDecl::getBuiltinID
> b) not provide this in ASAN.

I'm deferring the choice to Reid as I'm not up-to-date with the
builtins progress.

> AIUI, ASAN does require instrumentation of code, so it would not be possible
> to actually build ASAN enabled code reasonably with Visual Studio at the
> moment.

This is correct.

>  If I am mistaken on this point, Id love to know about that, and in
> that case, we could wrap this in a #if !defined(__clang__) check.
>
> Are there other similar builtins that we may have to isolate to specific
> platforms?  If so, it might be worth the effort to build up infrastructure
> to handle this generically.
>
>>
>>
>> On Wed, Jun 18, 2014 at 1:51 PM, Saleem Abdulrasool
>>  wrote:
>>>
>>> Author: compnerd
>>> Date: Wed Jun 18 15:51:10 2014
>>> New Revision: 211216
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=211216&view=rev
>>> Log:
>>> CodeGen: improve ms instrincics support
>>>
>>> Add support for _InterlockedCompareExchangePointer,
>>> _InterlockExchangePointer,
>>> _InterlockExchange.  These are available as a compiler intrinsic on ARM
>>> and x86.
>>> These are used directly by the Windows SDK headers without use of the
>>> intrin
>>> header.
>>>
>>> Added:
>>> cfe/trunk/test/CodeGen/ms-intrinsics.c
>>> Modified:
>>> cfe/trunk/include/clang/Basic/Builtins.def
>>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>>> cfe/trunk/lib/Headers/Intrin.h
>>>
>>> Modified: cfe/trunk/include/clang/Basic/Builtins.def
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=211216&r1=211215&r2=211216&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
>>> +++ cfe/trunk/include/clang/Basic/Builtins.def Wed Jun 18 15:51:10 2014
>>> @@ -683,9 +683,12 @@ LANGBUILTIN(__noop,   "v.",  "n", AL
>>>  LANGBUILTIN(__debugbreak, "v",   "n", ALL_MS_LANGUAGES)
>>>  LANGBUILTIN(__va_start,   "vc**.", "nt", ALL_MS_LANGUAGES)
>>>  LANGBUILTIN(_InterlockedCompareExchange, "LiLiD*LiLi", "n",
>>> ALL_MS_LANGUAGES)
>>> +LANGBUILTIN(_InterlockedCompareExchangePointer, "v*v*D*v*v*", "n",
>>> ALL_MS_LANGUAGES)
>>>  LANGBUILTIN(_InterlockedIncrement, "LiLiD*", "n", ALL_MS_LANGUAGES)
>>>  LANGBUILTIN(_InterlockedDecrement, "LiLiD*", "n", ALL_MS_LANGUAGES)
>>>  LANGBUILTIN(_InterlockedExchangeAdd, "LiLiD*Li", "n", ALL_MS_LANGUAGES)
>>> +LANGBUILTIN(_InterlockedExchangePointer, "v*v*D*v*", "n",
>>> ALL_MS_LANGUAGES)
>>> +LANGBUILTIN(_InterlockedExchange, "LiLiD*Li", "n", ALL_MS_LANGUAGES)
>>>
>>>  // C99 library functions
>>>  // C99 stdlib.h
>>>
>>> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=211216&r1=211215&r2=211216&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
>>> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Jun 18 15:51:10 2014
>>> @@ -1516,6 +1516,35 @@ RValue CodeGenFunction::EmitBuiltinExpr(
>>>  E->getArg(0), true);
>>>case Builtin::BI__noop:
>>>  return RValue::get(nullptr);
>>> +  case Builtin::BI_InterlockedExchange:
>>> +  case Builtin::BI_InterlockedExchangePointer:
>>> +return EmitBinaryAtomic(*this, llvm::AtomicRMWInst::Xchg, E);
>>> +  case Builtin::BI_InterlockedCompareExchangePointer: {
>>> +llvm::Type *RTy;
>>> +llvm::IntegerType *IntType =
>>> +  IntegerType::get(getLLVMContext(),
>>> +   getContext().getTypeSize(E->getType()));
>>> +llvm::Type *IntPtrType = IntType->getPointerTo();
>>> +
>>> +llvm::Value *Destination =
>>> +  Bu

[PATCH] Avoid definining more GCC specific predefined macros in clang-cl

[Ehsan Akhgari]

Hi hansw, rnk,

http://reviews.llvm.org/D4419

Files:
  lib/Frontend/InitPreprocessor.cpp
  test/Preprocessor/predefined-macros.c
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -481,7 +481,7 @@
   if (!LangOpts.GNUMode && !LangOpts.MSVCCompat)
 Builder.defineMacro("__STRICT_ANSI__");
 
-  if (LangOpts.CPlusPlus11)
+  if (!LangOpts.MSVCCompat && LangOpts.CPlusPlus11)
 Builder.defineMacro("__GXX_EXPERIMENTAL_CXX0X__");
 
   if (LangOpts.ObjC1) {
@@ -541,15 +541,15 @@
 
   if (!LangOpts.MSVCCompat && LangOpts.CXXExceptions)
 Builder.defineMacro("__EXCEPTIONS");
-  if (LangOpts.RTTI)
+  if (!LangOpts.MSVCCompat && LangOpts.RTTI)
 Builder.defineMacro("__GXX_RTTI");
   if (LangOpts.SjLjExceptions)
 Builder.defineMacro("__USING_SJLJ_EXCEPTIONS__");
 
   if (LangOpts.Deprecated)
 Builder.defineMacro("__DEPRECATED");
 
-  if (LangOpts.CPlusPlus) {
+  if (!LangOpts.MSVCCompat && LangOpts.CPlusPlus) {
 Builder.defineMacro("__GNUG__", "4");
 Builder.defineMacro("__GXX_WEAK__");
 Builder.defineMacro("__private_extern__", "extern");
@@ -746,36 +746,38 @@
   else
 Builder.defineMacro("__FINITE_MATH_ONLY__", "0");
 
-  if (LangOpts.GNUInline)
-Builder.defineMacro("__GNUC_GNU_INLINE__");
-  else
-Builder.defineMacro("__GNUC_STDC_INLINE__");
+  if (!LangOpts.MSVCCompat) {
+if (LangOpts.GNUInline)
+  Builder.defineMacro("__GNUC_GNU_INLINE__");
+else
+  Builder.defineMacro("__GNUC_STDC_INLINE__");
 
-  // The value written by __atomic_test_and_set.
-  // FIXME: This is target-dependent.
-  Builder.defineMacro("__GCC_ATOMIC_TEST_AND_SET_TRUEVAL", "1");
+// The value written by __atomic_test_and_set.
+// FIXME: This is target-dependent.
+Builder.defineMacro("__GCC_ATOMIC_TEST_AND_SET_TRUEVAL", "1");
 
-  // Used by libstdc++ to implement ATOMIC__LOCK_FREE.
-  unsigned InlineWidthBits = TI.getMaxAtomicInlineWidth();
+// Used by libstdc++ to implement ATOMIC__LOCK_FREE.
+unsigned InlineWidthBits = TI.getMaxAtomicInlineWidth();
 #define DEFINE_LOCK_FREE_MACRO(TYPE, Type) \
-  Builder.defineMacro("__GCC_ATOMIC_" #TYPE "_LOCK_FREE", \
-  getLockFreeValue(TI.get##Type##Width(), \
-   TI.get##Type##Align(), \
-   InlineWidthBits));
-  DEFINE_LOCK_FREE_MACRO(BOOL, Bool);
-  DEFINE_LOCK_FREE_MACRO(CHAR, Char);
-  DEFINE_LOCK_FREE_MACRO(CHAR16_T, Char16);
-  DEFINE_LOCK_FREE_MACRO(CHAR32_T, Char32);
-  DEFINE_LOCK_FREE_MACRO(WCHAR_T, WChar);
-  DEFINE_LOCK_FREE_MACRO(SHORT, Short);
-  DEFINE_LOCK_FREE_MACRO(INT, Int);
-  DEFINE_LOCK_FREE_MACRO(LONG, Long);
-  DEFINE_LOCK_FREE_MACRO(LLONG, LongLong);
-  Builder.defineMacro("__GCC_ATOMIC_POINTER_LOCK_FREE",
-  getLockFreeValue(TI.getPointerWidth(0),
-   TI.getPointerAlign(0),
-   InlineWidthBits));
+Builder.defineMacro("__GCC_ATOMIC_" #TYPE "_LOCK_FREE", \
+getLockFreeValue(TI.get##Type##Width(), \
+ TI.get##Type##Align(), \
+ InlineWidthBits));
+DEFINE_LOCK_FREE_MACRO(BOOL, Bool);
+DEFINE_LOCK_FREE_MACRO(CHAR, Char);
+DEFINE_LOCK_FREE_MACRO(CHAR16_T, Char16);
+DEFINE_LOCK_FREE_MACRO(CHAR32_T, Char32);
+DEFINE_LOCK_FREE_MACRO(WCHAR_T, WChar);
+DEFINE_LOCK_FREE_MACRO(SHORT, Short);
+DEFINE_LOCK_FREE_MACRO(INT, Int);
+DEFINE_LOCK_FREE_MACRO(LONG, Long);
+DEFINE_LOCK_FREE_MACRO(LLONG, LongLong);
+Builder.defineMacro("__GCC_ATOMIC_POINTER_LOCK_FREE",
+getLockFreeValue(TI.getPointerWidth(0),
+ TI.getPointerAlign(0),
+ InlineWidthBits));
 #undef DEFINE_LOCK_FREE_MACRO
+  }
 
   if (LangOpts.NoInlineDefine)
 Builder.defineMacro("__NO_INLINE__");
Index: test/Preprocessor/predefined-macros.c
===
--- test/Preprocessor/predefined-macros.c
+++ test/Preprocessor/predefined-macros.c
@@ -8,12 +8,14 @@
 // CHECK-MS: #define _M_IX86 600
 // CHECK-MS: #define _M_IX86_FP
 // CHECK-MS: #define _WIN32 1
-// CHECK-MS-NOT: #define __GNUC__
 // CHECK-MS-NOT: #define __STRICT_ANSI__
 // CHECK-MS-NOT: #define __i386__
 // CHECK-MS-NOT: #define __i486__
 // CHECK-MS-NOT: #define __i686__
 // CHECK-MS-NOT: #define __SSE__
+// CHECK-MS-NOT: GCC
+// CHECK-MS-NOT: GNU
+// CHECK-MS-NOT: GXX
 //
 // RUN: %clang_cc1 %s -E -dM -triple x86_64-pc-win32 -fms-extensions -fms-compatibility \
 // RUN: -fmsc-version=1300 -o - | FileCheck %s --check-prefix=CHECK-MS64
@@ -23,14 +25,16 @@
 // CHECK-MS64: #define _M_AMD64 1
 // CHECK-MS64: #define _M_X64 1
 // CHECK-MS64: #define _WIN64 1
-// CHECK-MS64-NOT: #define

Re: r212125 - MS ABI: Reference MSVC RTTI from the VFTable

[Timur Iskhodzhanov]

I'm trying to understand how to fix the ASan/Windows breakage wrt vftables.

Here's what David told me on the r212138 thread:
2014-07-08 4:39 GMT+04:00 David Majnemer :
> ASAN replaces one internal global with another. Because the new symbol
> isn't in a Comdat, it's alias isn't either.  This makes the alias a
> strong definition.

After rethinking this a bit, I'm puzzled.
Not only we need to correctly link no-rtti with rtti-enabled TUs but we
should also handle asan vs no-asan TUs.
ASan increases the size of globals by adding redzones.
It looks like an internal GV for a vftable in a (asan enabled, no-rtti)
configuration will be *larger* than the same vftable in a
(no-asan,rtti-enabled) configuration and the linking process will cause bad
result.
That said, I think we have to disable instrumentation of vftables on
Windows as long as we want to support mixing rtti- with no-rtti TUs or asan
with no-asan TUs.
Are we on the same page here?

If we agree that we can't add redzones to vftables, we should
adjust AddressSanitizerModule::ShouldInstrumentGlobal(GV) to handle this.
The problem is that those GVs are unnamed.
Is there a condition that's only true for the internal vftable GVs so I can
write an "if()"?
I think "if (G->hasComdat() && G->getLinkage() == InternalLinkage)" is a
too wide condition.
Or can we name these internal GVs somehow to make them easy to filter out?
 E.g. "\02?_7blah"?


2014-07-02 0:30 GMT+04:00 David Majnemer :

> Author: majnemer
> Date: Tue Jul  1 15:30:31 2014
> New Revision: 212125
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212125&view=rev
> Log:
> MS ABI: Reference MSVC RTTI from the VFTable
>
> The pointer for a class's RTTI data comes right before the VFTable but
> has no name.  To be properly compatible with this, we do the following:
> * Create a single GlobalVariable which holds the contents of the VFTable
>   _and_ the pointer to the RTTI data.
> * Create a GlobalAlias, with appropriate linkage/visibility, that points
>   just after the RTTI data pointer.  This ensures that the VFTable
>   symbol will always refer to VFTable data.
> * Create a Comdat with a "Largest" SelectionKind and stick the private
>   GlobalVariable in it.  By transitivity, the GlobalAlias will be a
>   member of the Comdat group.  Using "Largest" ensures that foreign
>   definitions without an RTTI data pointer will _not_ be chosen in the
>   final linked image.
>
> Whether or not we emit RTTI data depends on several things:
> * The -fno-rtti flag implies that we should never not emit a pointer to
>   RTTI data before the VFTable.
> * __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
>   available_externally GlobalVariable to provide a local definition of
>   the VFTable.  This means that we won't have any available_externally
>   definitions of things like complete object locators.  This is
>   acceptable because they are never directly referenced.
>
> To my knowledge, this completes the implementation of MSVC RTTI code
> generation.
>
> Further semantic work should be done to properly support /GR-.
>
> Modified:
> cfe/trunk/lib/AST/VTableBuilder.cpp
> cfe/trunk/lib/CodeGen/CGVTables.cpp
> cfe/trunk/lib/CodeGen/CGVTables.h
> cfe/trunk/lib/CodeGen/CodeGenModule.h
> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
> cfe/trunk/lib/CodeGen/MicrosoftRTTI.cpp
> cfe/trunk/test/CodeGenCXX/dllexport.cpp
>
> Modified: cfe/trunk/lib/AST/VTableBuilder.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=212125&r1=212124&r2=212125&view=diff
>
> ==
> --- cfe/trunk/lib/AST/VTableBuilder.cpp (original)
> +++ cfe/trunk/lib/AST/VTableBuilder.cpp Tue Jul  1 15:30:31 2014
> @@ -2574,6 +2574,12 @@ public:
>
>  MostDerivedClassLayout(Context.getASTRecordLayout(MostDerivedClass)),
>  WhichVFPtr(*Which),
>  Overriders(MostDerivedClass, CharUnits(), MostDerivedClass) {
> +// Only include the RTTI component if we know that we will provide a
> +// definition of the vftable.
> +if (Context.getLangOpts().RTTI &&
> +!MostDerivedClass->hasAttr())
> +  Components.push_back(VTableComponent::MakeRTTI(MostDerivedClass));
> +
>  LayoutVFTable();
>
>  if (Context.getLangOpts().DumpVTableLayouts)
> @@ -2915,7 +2921,8 @@ void VFTableBuilder::AddMethods(BaseSubo
>  // it requires return adjustment. Insert the method info for this
> method.
>  unsigned VBIndex =
>  LastVBase ? VTables.getVBTableIndex(MostDerivedClass, LastVBase)
> : 0;
> -MethodInfo MI(VBIndex, Components.size());
> +MethodInfo MI(VBIndex, Context.getLangOpts().RTTI ? Components.size()
> - 1
> +  :
> Components.size());
>
>  assert(!MethodInfoMap.count(MD) &&
> "Should not have method info for this method yet!");
>
> Modified: cfe/trunk

Re: r211342 - [OPENMP] Initial support for 'schedule' clause.

[Tobias Grosser]

On 20/06/2014 09:16, Alexey Bataev wrote:

Author: abataev
Date: Fri Jun 20 02:16:17 2014
New Revision: 211342

URL: http://llvm.org/viewvc/llvm-project?rev=211342&view=rev
Log:
[OPENMP] Initial support for 'schedule' clause.

Added:
 cfe/trunk/test/OpenMP/for_schedule_messages.cpp   (with props)
Modified:
 cfe/trunk/include/clang/AST/DataRecursiveASTVisitor.h
 cfe/trunk/include/clang/AST/OpenMPClause.h
 cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
 cfe/trunk/include/clang/Basic/OpenMPKinds.def
 cfe/trunk/include/clang/Basic/OpenMPKinds.h
 cfe/trunk/include/clang/Parse/Parser.h
 cfe/trunk/include/clang/Sema/Sema.h
 cfe/trunk/lib/AST/StmtPrinter.cpp
 cfe/trunk/lib/AST/StmtProfile.cpp
 cfe/trunk/lib/Basic/OpenMPKinds.cpp
 cfe/trunk/lib/Parse/ParseOpenMP.cpp
 cfe/trunk/lib/Sema/SemaOpenMP.cpp
 cfe/trunk/lib/Sema/TreeTransform.h
 cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
 cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
 cfe/trunk/test/OpenMP/for_ast_print.cpp
 cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/DataRecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DataRecursiveASTVisitor.h?rev=211342&r1=211341&r2=211342&view=diff
==
--- cfe/trunk/include/clang/AST/DataRecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/DataRecursiveASTVisitor.h Fri Jun 20 02:16:17 
2014
@@ -2344,6 +2344,13 @@ RecursiveASTVisitor::VisitOMPPr
  }

  template 
+bool
+RecursiveASTVisitor::VisitOMPScheduleClause(OMPScheduleClause *C) {
+  TraverseStmt(C->getChunkSize());
+  return true;
+}


I just got a coverity mail, which to my understanding warned that the 
return value of TraverseStmt() is not checked here. Looking at the other 
definitions in this file the uses of TraverseStmt() outside of OMP 
support are commonly guarded by the TRY_TO() macro. However, in the OMP 
related code the return value is always ignored. Is this a bug/problem?


To my understanding, several more cases miss a TRY_TO macro, and this 
function:


template 
template 
void RecursiveASTVisitor::VisitOMPClauseList(T *Node) {
  for (auto *I : Node->varlists())
TraverseStmt(I);
}

does not even have the possibility to return a boolean value.

Cheers,
Tobias

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r212138 - Driver: Handle /GR- in a compatible way with MSVC

[Timur Iskhodzhanov]

This is clearly related to r212125 rather than r212138 so let's continue on
the r212125 thread.


2014-07-08 13:01 GMT+04:00 Timur Iskhodzhanov :

> Can you clarify what you're suggesting?
> a) disable ASan instrumentation of vftables
> b) adjust the linkage of vftables to be ASan-friendly
> OR
> c) something else
>
>
> 2014-07-08 4:39 GMT+04:00 David Majnemer :
>
> ASAN replaces one internal global with another. Because the new symbol
>> isn't in a Comdat, it's alias isn't either.  This makes the alias a
>> strong definition.
>>
>> On Mon, Jul 7, 2014 at 9:43 AM, Timur Iskhodzhanov 
>> wrote:
>> > I think either this or r212125 broke "check-asan" and Chromium build
>> but it
>> > was hidden by another build failure (r211216).
>> >
>> > Can you please take a look at "TestCases/Windows/dll_cerr.cc" (or
>> Chromium
>> > failures) ?
>> >
>> >
>> > 2014-07-02 2:24 GMT+04:00 David Majnemer :
>> >
>> >> Author: majnemer
>> >> Date: Tue Jul  1 17:24:56 2014
>> >> New Revision: 212138
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=212138&view=rev
>> >> Log:
>> >> Driver: Handle /GR- in a compatible way with MSVC
>> >>
>> >> There are slight differences between /GR- and -fno-rtti which made
>> >> mapping one to the other inappropriate.
>> >>
>> >> -fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
>> >> information for the v-table.
>> >>
>> >> /GR- does not generate complete object locators and thus will not
>> >> reference them in vftables.  However, constructs like dynamic_cast and
>> >> typeid are permitted.
>> >>
>> >> This should bring our implementation of RTTI up to semantic parity with
>> >> MSVC modulo bugs.
>> >>
>> >> Added:
>> >> cfe/trunk/test/CodeGenCXX/microsoft-no-rtti-data.cpp
>> >> Modified:
>> >> cfe/trunk/include/clang/Basic/LangOptions.def
>> >> cfe/trunk/include/clang/Driver/CC1Options.td
>> >> cfe/trunk/include/clang/Driver/CLCompatOptions.td
>> >> cfe/trunk/lib/AST/VTableBuilder.cpp
>> >> cfe/trunk/lib/Basic/Targets.cpp
>> >> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>> >> cfe/trunk/lib/CodeGen/MicrosoftRTTI.cpp
>> >> cfe/trunk/lib/Driver/Tools.cpp
>> >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>> >> cfe/trunk/test/Driver/cl-fallback.c
>> >> cfe/trunk/test/Driver/cl-options.c
>> >>
>> >> Modified: cfe/trunk/include/clang/Basic/LangOptions.def
>> >> URL:
>> >>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=212138&r1=212137&r2=212138&view=diff
>> >>
>> >>
>> ==
>> >> --- cfe/trunk/include/clang/Basic/LangOptions.def (original)
>> >> +++ cfe/trunk/include/clang/Basic/LangOptions.def Tue Jul  1 17:24:56
>> 2014
>> >> @@ -84,6 +84,7 @@ LANGOPT(CXXExceptions , 1, 0, "C++ e
>> >>  LANGOPT(SjLjExceptions, 1, 0, "setjmp-longjump exception
>> handling")
>> >>  LANGOPT(TraditionalCPP, 1, 0, "traditional CPP emulation")
>> >>  LANGOPT(RTTI  , 1, 1, "run-time type information")
>> >> +LANGOPT(RTTIData  , 1, 1, "emit run-time type information
>> data")
>> >>  LANGOPT(MSBitfields   , 1, 0, "Microsoft-compatible structure
>> >> layout")
>> >>  LANGOPT(Freestanding, 1, 0, "freestanding implementation")
>> >>  LANGOPT(NoBuiltin , 1, 0, "disable builtin functions")
>> >>
>> >> Modified: cfe/trunk/include/clang/Driver/CC1Options.td
>> >> URL:
>> >>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=212138&r1=212137&r2=212138&view=diff
>> >>
>> >>
>> ==
>> >> --- cfe/trunk/include/clang/Driver/CC1Options.td (original)
>> >> +++ cfe/trunk/include/clang/Driver/CC1Options.td Tue Jul  1 17:24:56
>> 2014
>> >> @@ -484,6 +484,8 @@ def fobjc_subscripting_legacy_runtime :
>> >>HelpText<"Allow Objective-C array and dictionary subscripting in
>> legacy
>> >> runtime">;
>> >>  def vtordisp_mode_EQ : Joined<["-"], "vtordisp-mode=">,
>> >>HelpText<"Control vtordisp placement on win32 targets">;
>> >> +def fno_rtti_data : Flag<["-"], "fno-rtti-data">,
>> >> +  HelpText<"Control emission of RTTI data">;
>> >>
>> >>
>> >>
>> //===--===//
>> >>  // Header Search Options
>> >>
>> >> Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
>> >> URL:
>> >>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=212138&r1=212137&r2=212138&view=diff
>> >>
>> >>
>> ==
>> >> --- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
>> >> +++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Tue Jul  1
>> 17:24:56
>> >> 2014
>> >> @@ -58,8 +58,8 @@ def _SLASH_c : CLFlag<"c">, HelpText<"Co
>> >>  def _SLASH_D : CLJoinedOrSeparate<"D">, HelpText<"Define macro">,
>> >>MetaVarName<"">, Al

Re: [PATCH] gcc compatibility: silent -finline-limit=1234 & -finline-limit

[Joerg Sonnenberger]

I agree, the second approach sounds like the best way forward.

http://reviews.llvm.org/D4376



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [C++11] Support for capturing of variable length arrays in lambda expression.

[Alexey Bataev]

Richard, could please review this patch?
Best regards,
Alexey Bataev

http://reviews.llvm.org/D4368



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [OPENMP] Codegen for threadprivate variables

[Alexey Bataev]

John (rjmccall), could you please review this patch?
Best regards,
Alexey Bataev.

http://reviews.llvm.org/D4002



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r212524 - Move misplaced x86_32 ABI code

[Richard Sandiford]

Author: rsandifo
Date: Tue Jul  8 06:10:34 2014
New Revision: 212524

URL: http://llvm.org/viewvc/llvm-project?rev=212524&view=rev
Log:
Move misplaced x86_32 ABI code

r184166 added an X86_32 function in the middle of the SystemZ code.
The SystemZ port had been added only a couple of weeks earlier and
the original patch probably predated that.

No behavioral change intended.

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

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=212524&r1=212523&r2=212524&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Tue Jul  8 06:10:34 2014
@@ -1082,6 +1082,44 @@ llvm::Value *X86_32ABIInfo::EmitVAArg(ll
   return AddrTyped;
 }
 
+bool X86_32TargetCodeGenInfo::isStructReturnInRegABI(
+const llvm::Triple &Triple, const CodeGenOptions &Opts) {
+  assert(Triple.getArch() == llvm::Triple::x86);
+
+  switch (Opts.getStructReturnConvention()) {
+  case CodeGenOptions::SRCK_Default:
+break;
+  case CodeGenOptions::SRCK_OnStack:  // -fpcc-struct-return
+return false;
+  case CodeGenOptions::SRCK_InRegs:  // -freg-struct-return
+return true;
+  }
+
+  if (Triple.isOSDarwin())
+return true;
+
+  switch (Triple.getOS()) {
+  case llvm::Triple::AuroraUX:
+  case llvm::Triple::DragonFly:
+  case llvm::Triple::FreeBSD:
+  case llvm::Triple::OpenBSD:
+  case llvm::Triple::Bitrig:
+return true;
+  case llvm::Triple::Win32:
+switch (Triple.getEnvironment()) {
+case llvm::Triple::UnknownEnvironment:
+case llvm::Triple::Cygnus:
+case llvm::Triple::GNU:
+case llvm::Triple::MSVC:
+  return true;
+default:
+  return false;
+}
+  default:
+return false;
+  }
+}
+
 void X86_32TargetCodeGenInfo::SetTargetAttributes(const Decl *D,
   llvm::GlobalValue *GV,
 CodeGen::CodeGenModule &CGM) const 
{
@@ -4890,44 +4928,6 @@ llvm::Value *SystemZABIInfo::EmitVAArg(l
   return ResAddr;
 }
 
-bool X86_32TargetCodeGenInfo::isStructReturnInRegABI(
-const llvm::Triple &Triple, const CodeGenOptions &Opts) {
-  assert(Triple.getArch() == llvm::Triple::x86);
-
-  switch (Opts.getStructReturnConvention()) {
-  case CodeGenOptions::SRCK_Default:
-break;
-  case CodeGenOptions::SRCK_OnStack:  // -fpcc-struct-return
-return false;
-  case CodeGenOptions::SRCK_InRegs:  // -freg-struct-return
-return true;
-  }
-
-  if (Triple.isOSDarwin())
-return true;
-
-  switch (Triple.getOS()) {
-  case llvm::Triple::AuroraUX:
-  case llvm::Triple::DragonFly:
-  case llvm::Triple::FreeBSD:
-  case llvm::Triple::OpenBSD:
-  case llvm::Triple::Bitrig:
-return true;
-  case llvm::Triple::Win32:
-switch (Triple.getEnvironment()) {
-case llvm::Triple::UnknownEnvironment:
-case llvm::Triple::Cygnus:
-case llvm::Triple::GNU:
-case llvm::Triple::MSVC:
-  return true;
-default:
-  return false;
-}
-  default:
-return false;
-  }
-}
-
 ABIArgInfo SystemZABIInfo::classifyReturnType(QualType RetTy) const {
   if (RetTy->isVoidType())
 return ABIArgInfo::getIgnore();


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r212138 - Driver: Handle /GR- in a compatible way with MSVC

[Timur Iskhodzhanov]

Can you clarify what you're suggesting?
a) disable ASan instrumentation of vftables
b) adjust the linkage of vftables to be ASan-friendly
OR
c) something else


2014-07-08 4:39 GMT+04:00 David Majnemer :

> ASAN replaces one internal global with another. Because the new symbol
> isn't in a Comdat, it's alias isn't either.  This makes the alias a
> strong definition.
>
> On Mon, Jul 7, 2014 at 9:43 AM, Timur Iskhodzhanov 
> wrote:
> > I think either this or r212125 broke "check-asan" and Chromium build but
> it
> > was hidden by another build failure (r211216).
> >
> > Can you please take a look at "TestCases/Windows/dll_cerr.cc" (or
> Chromium
> > failures) ?
> >
> >
> > 2014-07-02 2:24 GMT+04:00 David Majnemer :
> >
> >> Author: majnemer
> >> Date: Tue Jul  1 17:24:56 2014
> >> New Revision: 212138
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=212138&view=rev
> >> Log:
> >> Driver: Handle /GR- in a compatible way with MSVC
> >>
> >> There are slight differences between /GR- and -fno-rtti which made
> >> mapping one to the other inappropriate.
> >>
> >> -fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
> >> information for the v-table.
> >>
> >> /GR- does not generate complete object locators and thus will not
> >> reference them in vftables.  However, constructs like dynamic_cast and
> >> typeid are permitted.
> >>
> >> This should bring our implementation of RTTI up to semantic parity with
> >> MSVC modulo bugs.
> >>
> >> Added:
> >> cfe/trunk/test/CodeGenCXX/microsoft-no-rtti-data.cpp
> >> Modified:
> >> cfe/trunk/include/clang/Basic/LangOptions.def
> >> cfe/trunk/include/clang/Driver/CC1Options.td
> >> cfe/trunk/include/clang/Driver/CLCompatOptions.td
> >> cfe/trunk/lib/AST/VTableBuilder.cpp
> >> cfe/trunk/lib/Basic/Targets.cpp
> >> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
> >> cfe/trunk/lib/CodeGen/MicrosoftRTTI.cpp
> >> cfe/trunk/lib/Driver/Tools.cpp
> >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> >> cfe/trunk/test/Driver/cl-fallback.c
> >> cfe/trunk/test/Driver/cl-options.c
> >>
> >> Modified: cfe/trunk/include/clang/Basic/LangOptions.def
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=212138&r1=212137&r2=212138&view=diff
> >>
> >>
> ==
> >> --- cfe/trunk/include/clang/Basic/LangOptions.def (original)
> >> +++ cfe/trunk/include/clang/Basic/LangOptions.def Tue Jul  1 17:24:56
> 2014
> >> @@ -84,6 +84,7 @@ LANGOPT(CXXExceptions , 1, 0, "C++ e
> >>  LANGOPT(SjLjExceptions, 1, 0, "setjmp-longjump exception handling")
> >>  LANGOPT(TraditionalCPP, 1, 0, "traditional CPP emulation")
> >>  LANGOPT(RTTI  , 1, 1, "run-time type information")
> >> +LANGOPT(RTTIData  , 1, 1, "emit run-time type information
> data")
> >>  LANGOPT(MSBitfields   , 1, 0, "Microsoft-compatible structure
> >> layout")
> >>  LANGOPT(Freestanding, 1, 0, "freestanding implementation")
> >>  LANGOPT(NoBuiltin , 1, 0, "disable builtin functions")
> >>
> >> Modified: cfe/trunk/include/clang/Driver/CC1Options.td
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=212138&r1=212137&r2=212138&view=diff
> >>
> >>
> ==
> >> --- cfe/trunk/include/clang/Driver/CC1Options.td (original)
> >> +++ cfe/trunk/include/clang/Driver/CC1Options.td Tue Jul  1 17:24:56
> 2014
> >> @@ -484,6 +484,8 @@ def fobjc_subscripting_legacy_runtime :
> >>HelpText<"Allow Objective-C array and dictionary subscripting in
> legacy
> >> runtime">;
> >>  def vtordisp_mode_EQ : Joined<["-"], "vtordisp-mode=">,
> >>HelpText<"Control vtordisp placement on win32 targets">;
> >> +def fno_rtti_data : Flag<["-"], "fno-rtti-data">,
> >> +  HelpText<"Control emission of RTTI data">;
> >>
> >>
> >>
> //===--===//
> >>  // Header Search Options
> >>
> >> Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=212138&r1=212137&r2=212138&view=diff
> >>
> >>
> ==
> >> --- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
> >> +++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Tue Jul  1
> 17:24:56
> >> 2014
> >> @@ -58,8 +58,8 @@ def _SLASH_c : CLFlag<"c">, HelpText<"Co
> >>  def _SLASH_D : CLJoinedOrSeparate<"D">, HelpText<"Define macro">,
> >>MetaVarName<"">, Alias;
> >>  def _SLASH_E : CLFlag<"E">, HelpText<"Preprocess to stdout">, Alias;
> >> -def _SLASH_GR : CLFlag<"GR">, HelpText<"Enable RTTI">, Alias;
> >> -def _SLASH_GR_ : CLFlag<"GR-">, HelpText<"Disable RTTI">,
> >> Alias;
> >> +def _SLASH_GR : CLFlag<"GR">, HelpText<"Enable

Re: [PATCH] -verify enhancement to support matching "any" line in included files

[Andy Gibbs]

Hi David,

This patch is not primarily for clang's test-suite but for making the 
"-verify" feature more useful to outside use (it is such a useful feature 
already but not yet perfect!).


We use "-verify", for example, to test our library code.  In many test-cases 
we test to ensure reasonable (consise, precise) error messages are generated 
when the library is used in invalid ways.  Therefore, a test-case may have 
many "expected-error/warning/note" lines that reference these header files. 
However, since the library is under development, the header files can change 
and this presents a big problem since every change can have a knock-on 
effect on all the test-cases that reference this header file (which means 
hundreds of files may need to be updated).


The supplied patch rectifies this is in (I hope!) a clean way.  We've been 
using this patch for about a year -- I thought it time to see whether other 
users could benefit from it.


The example in my earlier email using a system header was just a simple 
example to demonstrate the change.  Perhaps this is a better code snippet, 
using instead a library header:


int(*j)(int) = FunctorTraits::CastToFunctionPointer();
// expected-error@util/traits/FunctorTraits.h:* {{T does not supply a valid 
cast operator}}

// expected-note@-2 {{requested here}}

Regards,

Andy


- Original Message - 
From: "David Blaikie" 

To: "Andy Gibbs" 
Cc: "cfe-commits cfe" 
Sent: Monday, July 07, 2014 10:33 PM
Subject: Re: [PATCH] -verify enhancement to support matching "any" line in 
included files




We generally try not to test against system headers - such a test case
should just include a local file and then the line number would be
known.

Is there a particular need to test some behavior against a system header?

On Thu, Jul 3, 2014 at 6:32 AM, Andy Gibbs  
wrote:

Hi,

I have made an enhancement to the -verify function of clang to support
matching diagnostics in included header files where the line number is 
not

necessarily known (or constant).

Currently, matching a diagnostic in an included file is done as in the
following fragment:

 // expected-warning@+2 {{incompatible}} expected-warning@+2 {{literal}}
 // expected-note@stdio.h:359 {{here}}
 printf(12);

Problem is, the line number inside stdio.h is dependent on the system, so
the attached patch provides support for substituting the line number for
'*', as in:

 // expected-note@stdio.h:* {{here}}

so that the diagnostic is matched without the line number being known.

I've intentially limited this feature to line numbers in external files 
only

since the line numbers in the main source file should be always "known".
While this change may not have an immediate and particular purpose for 
the

clang test-suite itself, I personally feel it is a good and useful
enhancement to -verify for people (like me!) who use this for testing
3rd-party library code.

Please let me know if this has support/approval for being committed...

Thanks

Andy


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits





___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r212512 - Headers: conditionalise more declarations

[Alp Toker]

On 08/07/2014 08:46, Saleem Abdulrasool wrote:

Author: compnerd
Date: Tue Jul  8 00:46:04 2014
New Revision: 212512

URL: http://llvm.org/viewvc/llvm-project?rev=212512&view=rev
Log:
Headers: conditionalise more declarations

Protect MMX specific declarations under a __MMX__ guard.  This header can be
included on non-x86 architectures (e.g. ARM) which do not support the MMX ISA.
Use the preprocessor to prevent these declarations from being processed.

Added:
 cfe/trunk/test/Headers/arm-intrin.c
Modified:
 cfe/trunk/lib/Headers/Intrin.h

Modified: cfe/trunk/lib/Headers/Intrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=212512&r1=212511&r2=212512&view=diff
==
--- cfe/trunk/lib/Headers/Intrin.h (original)
+++ cfe/trunk/lib/Headers/Intrin.h Tue Jul  8 00:46:04 2014
@@ -41,12 +41,14 @@
  extern "C" {
  #endif
  
+#if defined(__MMX__)

  /* And the random ones that aren't in those files. */
  __m64 _m_from_float(float);
  __m64 _m_from_int(int _l);
  void _m_prefetch(void *);
  float _m_to_float(__m64);
  int _m_to_int(__m64 _M);
+#endif
  
  /* Other assorted instruction intrinsics. */

  void __addfsbyte(unsigned long, unsigned char);

Added: cfe/trunk/test/Headers/arm-intrin.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/arm-intrin.c?rev=212512&view=auto
==
--- cfe/trunk/test/Headers/arm-intrin.c (added)
+++ cfe/trunk/test/Headers/arm-intrin.c Tue Jul  8 00:46:04 2014
@@ -0,0 +1,6 @@
+// RUN: %clang -target armv7-windows -I %S/Inputs/include -Xclang -verify -E %s
+// expected-no-diagnostics
+
+typedef __SIZE_TYPE__ size_t;
+#include 
+


The commit message was great, but the test itself could do with a 
one-liner comment explaining what's being tested.


Alp.



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


--
http://www.nuanti.com
the browser experts

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] CodeGen: Properly null-check typeid expressions

[David Majnemer]

Hi rsmith,

Thoroughly check for a pointer dereference which yields a glvalue.  Look
through casts, comma operators, conditional operators, paren
expressions, etc.

http://reviews.llvm.org/D4416

Files:
  lib/CodeGen/CGExprCXX.cpp
  test/CodeGenCXX/typeid-should-throw.cpp

Index: lib/CodeGen/CGExprCXX.cpp
===
--- lib/CodeGen/CGExprCXX.cpp
+++ lib/CodeGen/CGExprCXX.cpp
@@ -1615,6 +1615,29 @@
   EmitBlock(DeleteEnd);
 }
 
+static bool isGLValueFromPointerDeref(const Expr *E) {
+  E = E->IgnoreParenCasts();
+
+  if (const auto *UO = dyn_cast(E))
+if (UO->getOpcode() == UO_Deref)
+  return true;
+
+  if (const auto *BO = dyn_cast(E))
+if (BO->getOpcode() == BO_Comma)
+  return isGLValueFromPointerDeref(BO->getRHS());
+
+  if (const auto *CO = dyn_cast(E))
+return isGLValueFromPointerDeref(CO->getTrueExpr()) ||
+   isGLValueFromPointerDeref(CO->getFalseExpr());
+
+  if (const auto *BCO = dyn_cast(E))
+if (const auto *OVE = dyn_cast(BCO->getTrueExpr()))
+  return isGLValueFromPointerDeref(OVE->getSourceExpr()) ||
+ isGLValueFromPointerDeref(BCO->getFalseExpr());
+
+  return false;
+}
+
 static llvm::Value *EmitTypeidFromVTable(CodeGenFunction &CGF, const Expr *E,
  llvm::Type *StdTypeInfoPtrTy) {
   // Get the vtable pointer.
@@ -1624,13 +1647,9 @@
   //   If the glvalue expression is obtained by applying the unary * operator 
to
   //   a pointer and the pointer is a null pointer value, the typeid expression
   //   throws the std::bad_typeid exception.
-  bool IsDeref = false;
-  if (const UnaryOperator *UO = dyn_cast(E->IgnoreParens()))
-if (UO->getOpcode() == UO_Deref)
-  IsDeref = true;
-
   QualType SrcRecordTy = E->getType();
-  if (CGF.CGM.getCXXABI().shouldTypeidBeNullChecked(IsDeref, SrcRecordTy)) {
+  if (CGF.CGM.getCXXABI().shouldTypeidBeNullChecked(
+  isGLValueFromPointerDeref(E), SrcRecordTy)) {
 llvm::BasicBlock *BadTypeidBlock =
 CGF.createBasicBlock("typeid.bad_typeid");
 llvm::BasicBlock *EndBlock = CGF.createBasicBlock("typeid.end");
Index: test/CodeGenCXX/typeid-should-throw.cpp
===
--- /dev/null
+++ test/CodeGenCXX/typeid-should-throw.cpp
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 %s -triple %itanium_abi_triple -Wno-unused-value -emit-llvm 
-o - | FileCheck %s
+namespace std {
+struct type_info;
+}
+
+struct A {
+  virtual ~A();
+};
+struct B : A {};
+
+void f1(A *x) { typeid(false, *x); }
+// CHECK-LABEL: define void @_Z2f1P1A
+// CHECK:   icmp eq {{.*}}, null
+// CHECK-NEXT:  br i1
+
+void f2(bool b, A *x, A *y) { typeid(b ? *x : *y); }
+// CHECK-LABEL: define void @_Z2f2bP1AS0_
+// CHECK:   icmp eq {{.*}}, null
+// CHECK-NEXT:  br i1
+
+void f3(bool b, A *x, A &y) { typeid(b ? *x : y); }
+// CHECK-LABEL: define void @_Z2f3bP1ARS_
+// CHECK:   icmp eq {{.*}}, null
+// CHECK-NEXT:  br i1
+
+void f4(bool b, A &x, A *y) { typeid(b ? x : *y); }
+// CHECK-LABEL: define void @_Z2f4bR1APS_
+// CHECK:   icmp eq {{.*}}, null
+// CHECK-NEXT:  br i1
+
+void f5(volatile A *x) { typeid(*x); }
+// CHECK-LABEL: define void @_Z2f5PV1A
+// CHECK:   icmp eq {{.*}}, null
+// CHECK-NEXT:  br i1
+
+void f6(A *x) { typeid((B &)*(B *)x); }
+// CHECK-LABEL: define void @_Z2f6P1A
+// CHECK:   icmp eq {{.*}}, null
+// CHECK-NEXT:  br i1
+
+void f7(A *x) { typeid((*x)); }
+// CHECK-LABEL: define void @_Z2f7P1A
+// CHECK:   icmp eq {{.*}}, null
+// CHECK-NEXT:  br i1
Index: lib/CodeGen/CGExprCXX.cpp
===
--- lib/CodeGen/CGExprCXX.cpp
+++ lib/CodeGen/CGExprCXX.cpp
@@ -1615,6 +1615,29 @@
   EmitBlock(DeleteEnd);
 }
 
+static bool isGLValueFromPointerDeref(const Expr *E) {
+  E = E->IgnoreParenCasts();
+
+  if (const auto *UO = dyn_cast(E))
+if (UO->getOpcode() == UO_Deref)
+  return true;
+
+  if (const auto *BO = dyn_cast(E))
+if (BO->getOpcode() == BO_Comma)
+  return isGLValueFromPointerDeref(BO->getRHS());
+
+  if (const auto *CO = dyn_cast(E))
+return isGLValueFromPointerDeref(CO->getTrueExpr()) ||
+   isGLValueFromPointerDeref(CO->getFalseExpr());
+
+  if (const auto *BCO = dyn_cast(E))
+if (const auto *OVE = dyn_cast(BCO->getTrueExpr()))
+  return isGLValueFromPointerDeref(OVE->getSourceExpr()) ||
+ isGLValueFromPointerDeref(BCO->getFalseExpr());
+
+  return false;
+}
+
 static llvm::Value *EmitTypeidFromVTable(CodeGenFunction &CGF, const Expr *E,
  llvm::Type *StdTypeInfoPtrTy) {
   // Get the vtable pointer.
@@ -1624,13 +1647,9 @@
   //   If the glvalue expression is obtained by applying the unary * operator to
   //   a pointer and the pointer is a null pointer value, the typeid expression
   //   throws the std::bad_typeid exception.
-  bool IsDeref = false;
-  if (const UnaryOperator *UO = dyn

Re: r212387 - Use non-intrusive refcounting for LangOptions

[Alp Toker]

On 06/07/2014 21:38, Nico Weber wrote:
On Sat, Jul 5, 2014 at 10:26 PM, Alp Toker > wrote:


Author: alp
Date: Sun Jul  6 00:26:07 2014
New Revision: 212387

URL: http://llvm.org/viewvc/llvm-project?rev=212387&view=rev
Log:
Use non-intrusive refcounting for LangOptions

This type is only refcounted in a couple of places so making
ownership explicit
improves clarity.

Modified:
cfe/trunk/include/clang/Basic/LangOptions.h
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/include/clang/Frontend/CompilerInvocation.h
cfe/trunk/lib/Frontend/ASTUnit.cpp

Modified: cfe/trunk/include/clang/Basic/LangOptions.h
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.h?rev=212387&r1=212386&r2=212387&view=diff

==
--- cfe/trunk/include/clang/Basic/LangOptions.h (original)
+++ cfe/trunk/include/clang/Basic/LangOptions.h Sun Jul  6
00:26:07 2014
@@ -19,7 +19,6 @@
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/ObjCRuntime.h"
 #include "clang/Basic/Visibility.h"
-#include "llvm/ADT/IntrusiveRefCntPtr.h"
 #include 

 namespace clang {
@@ -53,7 +52,7 @@ protected:

 /// \brief Keeps track of the various options that can be
 /// enabled, which controls the dialect of C or C++ that is accepted.
-class LangOptions : public RefCountedBase, public
LangOptionsBase {
+class LangOptions : public LangOptionsBase {
 public:
   typedef clang::Visibility Visibility;


Modified: cfe/trunk/include/clang/Frontend/ASTUnit.h
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/ASTUnit.h?rev=212387&r1=212386&r2=212387&view=diff

==
--- cfe/trunk/include/clang/Frontend/ASTUnit.h (original)
+++ cfe/trunk/include/clang/Frontend/ASTUnit.h Sun Jul  6 00:26:07
2014
@@ -83,7 +83,7 @@ public:
   };

 private:
-  IntrusiveRefCntPtr LangOpts;
+  std::shared_ptrLangOpts;
   IntrusiveRefCntPtr Diagnostics;
   IntrusiveRefCntPtr FileMgr;
   IntrusiveRefCntPtr SourceMgr;

Modified: cfe/trunk/include/clang/Frontend/CompilerInvocation.h
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CompilerInvocation.h?rev=212387&r1=212386&r2=212387&view=diff

==
--- cfe/trunk/include/clang/Frontend/CompilerInvocation.h (original)
+++ cfe/trunk/include/clang/Frontend/CompilerInvocation.h Sun Jul
 6 00:26:07 2014
@@ -52,9 +52,9 @@ bool ParseDiagnosticArgs(DiagnosticOptio
 class CompilerInvocationBase : public
RefCountedBase {
   void operator=(const CompilerInvocationBase &)
LLVM_DELETED_FUNCTION;

-protected:
+public:


Why make the fields public?


This makes the refcounted fields public to enable shared ownership in 
the few places it's necessary.


I chose this approach in preference to exposing the refcount via the 
existing accessors because we want to restrict most of clang to reading 
from the structure without adding a reference.


We could add new get*Reference() variants for each of the existing 
accesors but I'm not convinced it'd add any value, but would make it 
less clear which objects are holding the current reference and where 
ownership is being transferred from.


Alp.





   /// Options controlling the language variant.
-  IntrusiveRefCntPtr LangOpts;
+  std::shared_ptr LangOpts;

   /// Options controlling the target.
   IntrusiveRefCntPtr TargetOpts;
@@ -68,7 +68,6 @@ protected:
   /// Options controlling the preprocessor (aside from \#include
handling).
   IntrusiveRefCntPtr PreprocessorOpts;

-public:
   CompilerInvocationBase();
   ~CompilerInvocationBase();


Modified: cfe/trunk/lib/Frontend/ASTUnit.cpp
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/ASTUnit.cpp?rev=212387&r1=212386&r2=212387&view=diff

==
--- cfe/trunk/lib/Frontend/ASTUnit.cpp (original)
+++ cfe/trunk/lib/Frontend/ASTUnit.cpp Sun Jul  6 00:26:07 2014
@@ -1087,7 +1087,7 @@ bool ASTUnit::Parse(llvm::MemoryBuffer *
  "IR inputs not support here!");

   // Configure the various subsystems.
-  LangOpts = &Clang->getLangOpts();
+  LangOpts = Clang->getInvocation().LangOpts;
   FileSystemOpts = Clang->getFileSystemOpts();
   IntrusiveRefCntPtr VFS =
 createVFSFromCompilerInvocation(Clang->getInvocation(),
getDiagnostics());
@@ -1709,7 +1709,7 @@ void ASTUnit::transferASTDataFromCompile
   // Steal the created target, context, and preprocesso