r300949 - [index] Take advantage of 'external_source_symbol' attribute for indexing purposes

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Fri Apr 21 00:42:46 2017
New Revision: 300949

URL: http://llvm.org/viewvc/llvm-project?rev=300949=rev
Log:
[index] Take advantage of 'external_source_symbol' attribute for indexing 
purposes

- Ignore decls marked as 'generated_declaration'
- Include the 'defined_in' in the USR for additional namespacing

Added:
cfe/trunk/test/Index/Core/external-source-symbol-attr.m
Modified:
cfe/trunk/include/clang/Index/USRGeneration.h
cfe/trunk/lib/Index/IndexDecl.cpp
cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp
cfe/trunk/lib/Index/IndexingContext.cpp
cfe/trunk/lib/Index/IndexingContext.h
cfe/trunk/lib/Index/USRGeneration.cpp

Modified: cfe/trunk/include/clang/Index/USRGeneration.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Index/USRGeneration.h?rev=300949=300948=300949=diff
==
--- cfe/trunk/include/clang/Index/USRGeneration.h (original)
+++ cfe/trunk/include/clang/Index/USRGeneration.h Fri Apr 21 00:42:46 2017
@@ -30,10 +30,13 @@ static inline StringRef getUSRSpacePrefi
 bool generateUSRForDecl(const Decl *D, SmallVectorImpl );
 
 /// \brief Generate a USR fragment for an Objective-C class.
-void generateUSRForObjCClass(StringRef Cls, raw_ostream );
+void generateUSRForObjCClass(StringRef Cls, raw_ostream ,
+ StringRef ExtSymbolDefinedIn = "");
 
 /// \brief Generate a USR fragment for an Objective-C class category.
-void generateUSRForObjCCategory(StringRef Cls, StringRef Cat, raw_ostream );
+void generateUSRForObjCCategory(StringRef Cls, StringRef Cat, raw_ostream ,
+StringRef ClsExtSymbolDefinedIn = "",
+StringRef CatExtSymbolDefinedIn = "");
 
 /// \brief Generate a USR fragment for an Objective-C instance variable.  The
 /// complete USR can be created by concatenating the USR for the
@@ -48,7 +51,12 @@ void generateUSRForObjCMethod(StringRef
 void generateUSRForObjCProperty(StringRef Prop, bool isClassProp, raw_ostream 
);
 
 /// \brief Generate a USR fragment for an Objective-C protocol.
-void generateUSRForObjCProtocol(StringRef Prot, raw_ostream );
+void generateUSRForObjCProtocol(StringRef Prot, raw_ostream ,
+StringRef ExtSymbolDefinedIn = "");
+
+/// Generate USR fragment for a global (non-nested) enum.
+void generateUSRForGlobalEnum(StringRef EnumName, raw_ostream ,
+  StringRef ExtSymbolDefinedIn = "");
 
 /// \brief Generate a USR for a macro, including the USR prefix.
 ///

Modified: cfe/trunk/lib/Index/IndexDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexDecl.cpp?rev=300949=300948=300949=diff
==
--- cfe/trunk/lib/Index/IndexDecl.cpp (original)
+++ cfe/trunk/lib/Index/IndexDecl.cpp Fri Apr 21 00:42:46 2017
@@ -14,6 +14,13 @@
 using namespace clang;
 using namespace index;
 
+#define TRY_DECL(D,CALL_EXPR)  
\
+  do { 
\
+if (!IndexCtx.shouldIndex(D)) return true; 
\
+if (!CALL_EXPR)
\
+  return false;
\
+  } while (0)
+
 #define TRY_TO(CALL_EXPR)  
\
   do { 
\
 if (!CALL_EXPR)
\
@@ -120,8 +127,7 @@ public:
D->getDeclContext(), 0);
 }
 
-if (!IndexCtx.handleDecl(D, MethodLoc, Roles, Relations))
-  return false;
+TRY_DECL(D, IndexCtx.handleDecl(D, MethodLoc, Roles, Relations));
 IndexCtx.indexTypeSourceInfo(D->getReturnTypeSourceInfo(), D);
 bool hasIBActionAndFirst = D->hasAttr();
 for (const auto *I : D->parameters()) {
@@ -153,8 +159,7 @@ public:
   }
 }
 
-if (!IndexCtx.handleDecl(D, Roles, Relations))
-  return false;
+TRY_DECL(D, IndexCtx.handleDecl(D, Roles, Relations));
 handleDeclarator(D);
 
 if (const CXXConstructorDecl *Ctor = dyn_cast(D)) {
@@ -189,16 +194,14 @@ public:
   }
 
   bool VisitVarDecl(const VarDecl *D) {
-if (!IndexCtx.handleDecl(D))
-  return false;
+TRY_DECL(D, IndexCtx.handleDecl(D));
 handleDeclarator(D);
 IndexCtx.indexBody(D->getInit(), D);
 return true;
   }
 
   bool VisitFieldDecl(const FieldDecl *D) {
-if (!IndexCtx.handleDecl(D))
-  return false;
+TRY_DECL(D, IndexCtx.handleDecl(D));
 handleDeclarator(D);
 if (D->isBitField())
   IndexCtx.indexBody(D->getBitWidth(), D);
@@ -212,8 +215,7 @@ public:
   // handled in VisitObjCPropertyImplDecl
   return true;
 }

r300948 - [index] For 'transparent' tag typedefs, ignore their tag reference

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Fri Apr 21 00:42:40 2017
New Revision: 300948

URL: http://llvm.org/viewvc/llvm-project?rev=300948=rev
Log:
[index] For 'transparent' tag typedefs, ignore their tag reference

Modified:
cfe/trunk/lib/Index/IndexDecl.cpp
cfe/trunk/test/Index/Core/index-source.m

Modified: cfe/trunk/lib/Index/IndexDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexDecl.cpp?rev=300948=300947=300948=diff
==
--- cfe/trunk/lib/Index/IndexDecl.cpp (original)
+++ cfe/trunk/lib/Index/IndexDecl.cpp Fri Apr 21 00:42:40 2017
@@ -231,10 +231,11 @@ public:
   }
 
   bool VisitTypedefNameDecl(const TypedefNameDecl *D) {
-if (!D->isTransparentTag())
+if (!D->isTransparentTag()) {
   if (!IndexCtx.handleDecl(D))
 return false;
-IndexCtx.indexTypeSourceInfo(D->getTypeSourceInfo(), D);
+  IndexCtx.indexTypeSourceInfo(D->getTypeSourceInfo(), D);
+}
 return true;
   }
 

Modified: cfe/trunk/test/Index/Core/index-source.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Core/index-source.m?rev=300948=300947=300948=diff
==
--- cfe/trunk/test/Index/Core/index-source.m (original)
+++ cfe/trunk/test/Index/Core/index-source.m Fri Apr 21 00:42:40 2017
@@ -353,7 +353,8 @@ typedef MyGenCls
 
 typedef NS_ENUM(AnotherEnum, int) {
 // CHECK-NOT: [[@LINE-1]]:17 | type-alias/C | AnotherEnum |
-// CHECK: [[@LINE-2]]:17 | enum/C | AnotherEnum | [[AnotherEnum_USR:.*]] | 
{{.*}} | Ref,RelCont | rel: 1
+// CHECK-NOT: [[@LINE-2]]:17 | {{.*}} | Ref
+// CHECK: [[@LINE-3]]:17 | enum/C | AnotherEnum | [[AnotherEnum_USR:.*]] | 
{{.*}} | Def | rel: 0
   AnotherEnumFirst = 0,
   AnotherEnumSecond = 1,
   AnotherEnumThird = 2,


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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar updated this revision to Diff 96097.
kuhar added a comment.

Minor change to success detection logic.


https://reviews.llvm.org/D32294

Files:
  clang-tidy/tool/run-clang-tidy.py

Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -34,6 +34,7 @@
 http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 """
 
+from __future__ import print_function
 import argparse
 import json
 import multiprocessing
@@ -45,14 +46,15 @@
 import sys
 import tempfile
 import threading
+import traceback
 
 
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
   while not os.path.isfile(os.path.join(result, path)):
 if os.path.realpath(result) == '/':
-  print 'Error: could not find compilation database.'
+  print('Error: could not find compilation database.')
   sys.exit(1)
 result += '../'
   return os.path.realpath(result)
@@ -87,14 +89,24 @@
   return start
 
 
+def check_clang_apply_replacements_binary(args):
+  """Checks if invoking supplied clang-apply-replacements binary works."""
+  try:
+subprocess.check_call([args.clang_apply_replacements_binary, '--version'])
+  except:
+print('Unable to run clang-apply-replacements. Is clang-apply-replacements '
+  'binary correctly specified?', file=sys.stderr)
+traceback.print_exc()
+sys.exit(1)
+
+
 def apply_fixes(args, tmpdir):
   """Calls clang-apply-fixes on a given directory. Deletes the dir when done."""
   invocation = [args.clang_apply_replacements_binary]
   if args.format:
 invocation.append('-format')
   invocation.append(tmpdir)
   subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
@@ -164,9 +176,9 @@
 if args.checks:
   invocation.append('-checks=' + args.checks)
 invocation.append('-')
-print subprocess.check_output(invocation)
+print(subprocess.check_output(invocation))
   except:
-print >>sys.stderr, "Unable to run clang-tidy."
+print("Unable to run clang-tidy.", file=sys.stderr)
 sys.exit(1)
 
   # Load the database and extract all files.
@@ -179,6 +191,7 @@
 
   tmpdir = None
   if args.fix:
+check_clang_apply_replacements_binary(args)
 tmpdir = tempfile.mkdtemp()
 
   # Build up a big regexy filter from all command line arguments.
@@ -204,14 +217,25 @@
   except KeyboardInterrupt:
 # This is a sad hack. Unfortunately subprocess goes
 # bonkers with ctrl-c and we start forking merrily.
-print '\nCtrl-C detected, goodbye.'
+print('\nCtrl-C detected, goodbye.')
 if args.fix:
   shutil.rmtree(tmpdir)
 os.kill(0, 9)
 
   if args.fix:
-print 'Applying fixes ...'
-apply_fixes(args, tmpdir)
+print('Applying fixes ...')
+successfully_applied = False
+
+try:
+  apply_fixes(args, tmpdir)
+  successfully_applied = True
+except:
+  print('Error applying fixes.\n', file=sys.stderr)
+  traceback.print_exc()
+
+shutil.rmtree(tmpdir)
+if not successfully_applied:
+  sys.exit(1)
 
 if __name__ == '__main__':
   main()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31739: Add markup for libc++ dylib availability

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini marked 5 inline comments as done.
mehdi_amini added inline comments.



Comment at: utils/libcxx/test/config.py:289
+def configure_availability(self):
+# FIXME doc
+self.with_availability = self.get_lit_bool('with_availability', False)

jroelofs wrote:
> Can you expand on what the FIXME here wants? Is there something that 
> AvailabilityMarkup.rst doesn't cover?
I wrote the FIXME before writing the doc. I added a link to the doc instead.



Comment at: utils/libcxx/test/config.py:316
+if self.with_availability:
+self.use_clang_verify = False
+return

jroelofs wrote:
> Why does the availability stuff clash with -verify?
The syntax verification phase isn't expecting too see compile errors from the 
availability.



Comment at: utils/libcxx/test/config.py:358
 
+def add_deployement_feature(self, feature):
+(arch, name, version) = self.config.deployment

arphaman wrote:
> Typo: `add_deployment_feature`
French style :)



Comment at: utils/libcxx/test/config.py:363
+self.config.available_features.add('%s=%s%s' % (feature, name, 
version))
+self.config.available_features.add('%s=%s%s' % (feature, name, 
version))
+

jroelofs wrote:
> This line, and the one above it are the same. Is that intentional?
No, just bad copy/paste :)



Comment at: utils/libcxx/test/config.py:387
+self.config.available_features.add(
+'with_system_cxx_lib=%s' % component)
 

jroelofs wrote:
> Is it worth filtering out `none` and `unknown`, as they're often repeated, 
> and you can't tell which part of the triple they came from?
> 
> Consider: `arm-none-linux-gnueabi` vs `arm-none-none-eabi`.
> 
> Or would it be better to include some marker in the features to say which 
> part of the triple it came from, eg:
> 
> ```
>   - with_system_cxx_lib=arch:arm
>   - with_system_cxx_lib=vendor:none
>   - with_system_cxx_lib=os:linux
>   - with_system_cxx_lib=sys:gnueabi
> ```
I like this idea! 
It seems like orthogonal to the availability introduced here, so it'd belong to 
a separate patch I think.


https://reviews.llvm.org/D31739



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

[PATCH] D32111: [modules] Attempt to fix PR31905 - #include "stddef.h" breaks module map search paths; causes redefinitions.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF planned changes to this revision.
EricWF added a comment.

I've got a better, actually correct, solution incoming.


https://reviews.llvm.org/D32111



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

[PATCH] D32147: [PR32479] Avoid newlib vasprintf, since it requires gnu extensions

[Eric Fiselier via Phabricator via cfe-commits]

EricWF resigned from this revision.
EricWF added a comment.

The bug relating to this patch was closed as WONTFIX.  This review should be 
closed.


https://reviews.llvm.org/D32147



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

[PATCH] D30805: [OpenCL] Add intel_reqd_sub_group_size attribute support

[Xiuli PAN via Phabricator via cfe-commits]

pxli168 added a comment.

@Anastasia is this test added OK?


https://reviews.llvm.org/D30805



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

[PATCH] D32269: [Driver] Add iSOFTLinux to GNU ToolChains X86Triple

[Leslie Zhai via Phabricator via cfe-commits]

xiangzhai updated this revision to Diff 96088.
xiangzhai added a comment.

Hi Richard,

Thanks for your review!

I updated my patch as you suggested: add some test coverage for these triples, 
and I run `make check-clang-driver` for verification, please point out my 
fault, thanks!

Regards,
Leslie Zhai


Repository:
  rL LLVM

https://reviews.llvm.org/D32269

Files:
  lib/Driver/ToolChains/Gnu.cpp
  test/Driver/linux-ld.c


Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -443,6 +443,14 @@
 // CHECK-BASIC-LIBCXX-C-LINK: "--sysroot=[[SYSROOT]]"
 // CHECK-BASIC-LIBCXX-C-LINK: "-L[[SYSROOT]]/usr/bin/../lib"
 //
+// Check iSOFTLinux v4.0 on x86
+// RUN: %clang %s -### -o %t.o 2>&1 --target=x86_64-isoft-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=x86_64-everest-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=x86_64-pure64-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=i686-isoft-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=i686-everest-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=i686-pure64-linux
+//
 // Test a very broken version of multiarch that shipped in Ubuntu 11.04.
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=i386-unknown-linux \
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1757,6 +1757,9 @@
   static const char *const X86_64LibDirs[] = {"/lib64", "/lib"};
   static const char *const X86_64Triples[] = {
   "x86_64-linux-gnu",   "x86_64-unknown-linux-gnu",
+  "x86_64-isoft-linux", "x86_64-isoft-linux-gnu",
+  "x86_64-everest-linux",   "x86_64-everest-linux-gnu",
+  "x86_64-pure64-linux","x86_64-pure64-linux-gnu",
   "x86_64-pc-linux-gnu","x86_64-redhat-linux6E",
   "x86_64-redhat-linux","x86_64-suse-linux",
   "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
@@ -1766,6 +1769,9 @@
   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
   static const char *const X86Triples[] = {
   "i686-linux-gnu",   "i686-pc-linux-gnu", "i486-linux-gnu",
+  "i686-isoft-linux", "i686-isoft-linux-gnu",
+  "i686-everest-linux",   "i686-everest-linux-gnu",
+  "i686-pure64-linux","i686-pure64-linux-gnu",
   "i386-linux-gnu",   "i386-redhat-linux6E",   "i686-redhat-linux",
   "i586-redhat-linux","i386-redhat-linux", "i586-suse-linux",
   "i486-slackware-linux", "i686-montavista-linux", "i686-linux-android",


Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -443,6 +443,14 @@
 // CHECK-BASIC-LIBCXX-C-LINK: "--sysroot=[[SYSROOT]]"
 // CHECK-BASIC-LIBCXX-C-LINK: "-L[[SYSROOT]]/usr/bin/../lib"
 //
+// Check iSOFTLinux v4.0 on x86
+// RUN: %clang %s -### -o %t.o 2>&1 --target=x86_64-isoft-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=x86_64-everest-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=x86_64-pure64-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=i686-isoft-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=i686-everest-linux
+// RUN: %clang %s -### -o %t.o 2>&1 --target=i686-pure64-linux
+//
 // Test a very broken version of multiarch that shipped in Ubuntu 11.04.
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=i386-unknown-linux \
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1757,6 +1757,9 @@
   static const char *const X86_64LibDirs[] = {"/lib64", "/lib"};
   static const char *const X86_64Triples[] = {
   "x86_64-linux-gnu",   "x86_64-unknown-linux-gnu",
+  "x86_64-isoft-linux", "x86_64-isoft-linux-gnu",
+  "x86_64-everest-linux",   "x86_64-everest-linux-gnu",
+  "x86_64-pure64-linux","x86_64-pure64-linux-gnu",
   "x86_64-pc-linux-gnu","x86_64-redhat-linux6E",
   "x86_64-redhat-linux","x86_64-suse-linux",
   "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
@@ -1766,6 +1769,9 @@
   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
   static const char *const X86Triples[] = {
   "i686-linux-gnu",   "i686-pc-linux-gnu", "i486-linux-gnu",
+  "i686-isoft-linux", "i686-isoft-linux-gnu",
+  "i686-everest-linux",   "i686-everest-linux-gnu",
+  "i686-pure64-linux","i686-pure64-linux-gnu",
   "i386-linux-gnu",   "i386-redhat-linux6E",   "i686-redhat-linux",
   "i586-redhat-linux","i386-redhat-linux", "i586-suse-linux",
   "i486-slackware-linux", "i686-montavista-linux", "i686-linux-android",
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[libcxx] r300944 - update XFAIL comments with more details

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 22:09:40 2017
New Revision: 300944

URL: http://llvm.org/viewvc/llvm-project?rev=300944=rev
Log:
update XFAIL comments with more details

Modified:
libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp

libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp

Modified: 
libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp?rev=300944=300943=300944=diff
==
--- libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp 
(original)
+++ libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp Thu 
Apr 20 22:09:40 2017
@@ -7,9 +7,8 @@
 //
 
//===--===//
 
-// There appears to be a bug in VerifyDiagnosticReporter on Windows that
-// causes -verify to not see the emitted warnings even though they are
-// actually getting omitted.
+// This test fails because diagnose_if doesn't emit all of the diagnostics
+// when -fdelayed-template-parsing is enabled, like it is on Windows.
 // XFAIL: LIBCXX-WINDOWS-FIXME
 
 // REQUIRES: verify-support, diagnose-if-support

Modified: 
libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp?rev=300944=300943=300944=diff
==
--- 
libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
 (original)
+++ 
libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
 Thu Apr 20 22:09:40 2017
@@ -7,8 +7,7 @@
 //
 
//===--===//
 
-// This test fails because the `from_bytes` call seems to result in a call
-// to 'abort()'
+// 'do_bytes' throws a std::range_error unexpectedly
 // XFAIL: LIBCXX-WINDOWS-FIXME
 
 // UNSUPPORTED: c++98, c++03


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

[PATCH] D30771: [analyzer] Teach the MallocChecker about Glib API for two arguments

[Leslie Zhai via Phabricator via cfe-commits]

xiangzhai updated this revision to Diff 96084.
xiangzhai added a comment.

Further reduce redundant code.


Repository:
  rL LLVM

https://reviews.llvm.org/D30771

Files:
  lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  test/Analysis/gmalloc.c

Index: test/Analysis/gmalloc.c
===
--- test/Analysis/gmalloc.c
+++ test/Analysis/gmalloc.c
@@ -13,6 +13,12 @@
 gpointer g_try_malloc(gsize n_bytes);
 gpointer g_try_malloc0(gsize n_bytes);
 gpointer g_try_realloc(gpointer mem, gsize n_bytes);
+gpointer g_malloc_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_malloc0_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_realloc_n(gpointer mem, gsize n_blocks, gsize n_block_bytes);
+gpointer g_try_malloc_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_try_malloc0_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_try_realloc_n(gpointer mem, gsize n_blocks, gsize n_block_bytes);
 void g_free(gpointer mem);
 gpointer g_memdup(gconstpointer mem, guint byte_size);
 
@@ -25,6 +31,12 @@
   gpointer g3 = g_try_malloc(n_bytes);
   gpointer g4 = g_try_malloc0(n_bytes);
   g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char));
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char));
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char));
 
   g_free(g1);
   g_free(g2);
@@ -38,6 +50,12 @@
   gpointer g3 = g_try_malloc(n_bytes);
   gpointer g4 = g_try_malloc0(n_bytes);
   g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char));
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char));
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char));
 
   g_free(g1);
   g_free(g2);
@@ -52,8 +70,100 @@
   gpointer g3 = g_try_malloc(n_bytes);
   gpointer g4 = g_try_malloc0(n_bytes);
   g3 = g_try_realloc(g3, n_bytes * 2); // expected-warning{{Potential leak of memory pointed to by 'g4'}}
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g6'}}
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g5'}}
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g8'}}
+
+  g_free(g1); // expected-warning{{Potential leak of memory pointed to by 'g7'}}
+  g_free(g2);
+  g_free(g3);
+}
+
+void f4() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g6'}}
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g5'}}
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g8'}}
+
+  g_free(g1); // expected-warning{{Potential leak of memory pointed to by 'g7'}}
+  g_free(g2);
+  g_free(g3);
+  g_free(g4);
+}
+
+void f5() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g6'}}
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char));
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g8'}}
+
+  g_free(g1); // expected-warning{{Potential leak of memory pointed to by 'g7'}}
+  g_free(g2);
+  g_free(g3);
+  g_free(g4);
+  g_free(g5);
+}
+
+void f6() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = 

[PATCH] D32333: [clang-tidy] Update IdentifierNamingCheck to remove extra leading/trailing underscores

[Jacob Bandes-Storch via Phabricator via cfe-commits]

jtbandes created this revision.

The goal of this change is to fix the following suboptimal replacements 
currently suggested by clang-tidy:

  // with MemberPrefix == "_"
  int __foo;  // accepted without complaint

  // with MemberPrefix == "m_"
  int _foo;
  ^~
  m__foo

I fixed this by

- updating `matchesStyle()` to reject names which have a leading underscore 
after a prefix has already been stripped, or a trailing underscore if a suffix 
has already been stripped;
- updating `fixupWithStyle()` to strip leading & trailing underscores before 
adding the user-defined prefix and suffix.

The replacements are now:

  // MemberPrefix == "_"
  int __foo;
  ^~
  _foo

  // MemberPrefix == "m_"
  int _foo;
  ^
  m_foo

Future improvements might elect to add .clang-tidy flags to improve what is 
being stripped. For instance, stripping `m_` could allow `m_foo` to be 
automatically replaced with `_foo`.


https://reviews.llvm.org/D32333

Files:
  clang-tidy/readability/IdentifierNamingCheck.cpp
  test/clang-tidy/readability-identifier-naming.cpp


Index: test/clang-tidy/readability-identifier-naming.cpp
===
--- test/clang-tidy/readability-identifier-naming.cpp
+++ test/clang-tidy/readability-identifier-naming.cpp
@@ -175,6 +175,9 @@
   int member2 = 2;
 // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for private 
member 'member2'
 // CHECK-FIXES: {{^}}  int __member2 = 2;{{$}}
+  int _memberWithExtraUnderscores_ = 42;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for private 
member '_memberWithExtraUnderscores_'
+// CHECK-FIXES: {{^}}  int __memberWithExtraUnderscores = 42;{{$}}
 
 private:
 int private_member = 3;
Index: clang-tidy/readability/IdentifierNamingCheck.cpp
===
--- clang-tidy/readability/IdentifierNamingCheck.cpp
+++ clang-tidy/readability/IdentifierNamingCheck.cpp
@@ -262,6 +262,13 @@
   else
 Matches = false;
 
+  // Ensure the name doesn't have any extra underscores beyond those specified
+  // in the prefix and suffix.
+  if (!Style.Prefix.empty() && Name.startswith("_"))
+Matches = false;
+  if (!Style.Suffix.empty() && Name.endswith("_"))
+Matches = false;
+
   if (Style.Case && !Matchers[static_cast(*Style.Case)].match(Name))
 Matches = false;
 
@@ -367,10 +374,12 @@
 static std::string
 fixupWithStyle(StringRef Name,
const IdentifierNamingCheck::NamingStyle ) {
-  return Style.Prefix +
- fixupWithCase(Name, Style.Case.getValueOr(
- IdentifierNamingCheck::CaseType::CT_AnyCase)) 
+
- Style.Suffix;
+  const std::string Fixed = fixupWithCase(
+  Name, 
Style.Case.getValueOr(IdentifierNamingCheck::CaseType::CT_AnyCase));
+  StringRef Mid = StringRef(Fixed).trim("_");
+  if (Mid.size() == 0)
+Mid = "_";
+  return (Style.Prefix + Mid + Style.Suffix).str();
 }
 
 static StyleKind findStyleKind(


Index: test/clang-tidy/readability-identifier-naming.cpp
===
--- test/clang-tidy/readability-identifier-naming.cpp
+++ test/clang-tidy/readability-identifier-naming.cpp
@@ -175,6 +175,9 @@
   int member2 = 2;
 // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for private member 'member2'
 // CHECK-FIXES: {{^}}  int __member2 = 2;{{$}}
+  int _memberWithExtraUnderscores_ = 42;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for private member '_memberWithExtraUnderscores_'
+// CHECK-FIXES: {{^}}  int __memberWithExtraUnderscores = 42;{{$}}
 
 private:
 int private_member = 3;
Index: clang-tidy/readability/IdentifierNamingCheck.cpp
===
--- clang-tidy/readability/IdentifierNamingCheck.cpp
+++ clang-tidy/readability/IdentifierNamingCheck.cpp
@@ -262,6 +262,13 @@
   else
 Matches = false;
 
+  // Ensure the name doesn't have any extra underscores beyond those specified
+  // in the prefix and suffix.
+  if (!Style.Prefix.empty() && Name.startswith("_"))
+Matches = false;
+  if (!Style.Suffix.empty() && Name.endswith("_"))
+Matches = false;
+
   if (Style.Case && !Matchers[static_cast(*Style.Case)].match(Name))
 Matches = false;
 
@@ -367,10 +374,12 @@
 static std::string
 fixupWithStyle(StringRef Name,
const IdentifierNamingCheck::NamingStyle ) {
-  return Style.Prefix +
- fixupWithCase(Name, Style.Case.getValueOr(
- IdentifierNamingCheck::CaseType::CT_AnyCase)) +
- Style.Suffix;
+  const std::string Fixed = fixupWithCase(
+  Name, Style.Case.getValueOr(IdentifierNamingCheck::CaseType::CT_AnyCase));
+  StringRef Mid = StringRef(Fixed).trim("_");
+  if (Mid.size() == 0)
+Mid = "_";
+  return (Style.Prefix + Mid + Style.Suffix).str();
 }
 
 static StyleKind findStyleKind(

[libcxx] r300942 - Mark exception_ptr tests as XFAIL on Windows for now

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 21:13:33 2017
New Revision: 300942

URL: http://llvm.org/viewvc/llvm-project?rev=300942=rev
Log:
Mark exception_ptr tests as XFAIL on Windows for now

Modified:

libcxx/trunk/test/std/language.support/support.exception/except.nested/assign.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_copy.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_default.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_nested.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/except.nested/throw_with_nested.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/propagation/current_exception.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/propagation/exception_ptr.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/propagation/make_exception_ptr.pass.cpp

libcxx/trunk/test/std/language.support/support.exception/propagation/rethrow_exception.pass.cpp

Modified: 
libcxx/trunk/test/std/language.support/support.exception/except.nested/assign.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/language.support/support.exception/except.nested/assign.pass.cpp?rev=300942=300941=300942=diff
==
--- 
libcxx/trunk/test/std/language.support/support.exception/except.nested/assign.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/language.support/support.exception/except.nested/assign.pass.cpp
 Thu Apr 20 21:13:33 2017
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// exception_ptr has not been implemented on Windows
+// XFAIL: LIBCXX-WINDOWS-FIXME
+
 // 
 
 // class nested_exception;

Modified: 
libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_copy.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_copy.pass.cpp?rev=300942=300941=300942=diff
==
--- 
libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_copy.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_copy.pass.cpp
 Thu Apr 20 21:13:33 2017
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// exception_ptr has not been implemented on Windows
+// XFAIL: LIBCXX-WINDOWS-FIXME
+
 // 
 
 // class nested_exception;

Modified: 
libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_default.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_default.pass.cpp?rev=300942=300941=300942=diff
==
--- 
libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_default.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/language.support/support.exception/except.nested/ctor_default.pass.cpp
 Thu Apr 20 21:13:33 2017
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// exception_ptr has not been implemented on Windows
+// XFAIL: LIBCXX-WINDOWS-FIXME
+
 // 
 
 // class nested_exception;

Modified: 
libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp?rev=300942=300941=300942=diff
==
--- 
libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp
 Thu Apr 20 21:13:33 2017
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// exception_ptr has not been implemented on Windows
+// XFAIL: LIBCXX-WINDOWS-FIXME
+
 // UNSUPPORTED: libcpp-no-exceptions
 // 
 
@@ -43,7 +46,7 @@ class C
 {
 public:
virtual ~C() {}
-   C * operator&() const { assert(false); } // should not be called
+   C * operator&() const { assert(false); return nullptr; } // should not 
be called
 };
 
 class D : private std::nested_exception {};

Modified: 
libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_nested.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/language.support/support.exception/except.nested/rethrow_nested.pass.cpp?rev=300942=300941=300942=diff

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Mehdi Amini via cfe-commits]

> On Apr 20, 2017, at 7:03 PM, Eric Fiselier  wrote:
> 
> 
> 
> On Thu, Apr 20, 2017 at 4:55 PM, Mehdi Amini  > wrote:
> 
>> On Apr 20, 2017, at 12:30 PM, Eric Fiselier > > wrote:
>> 
>> 
>> 
>> On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini > > wrote:
>> 
>>> On Apr 20, 2017, at 12:39 AM, Eric Fiselier >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini >> > wrote:
>>> What would be the status of these buildbots? Is it for your private usage? 
>>> 
>>> I intend for them to be public Windows buildbots for libc++.
>> 
>> 
>> I’m not sure it’d be OK to send blame email to contributors based on this 
>> though.
>> 
>> I don't see why not (at least once the bot is stable). Can you elaborate?
> 
> I don’t think there is a precedent for having a bot that does not checkout 
> from SVN and email using the canonical SVN revision number.
> 
> I understand share your concern about the emails using nonsensical git hashes 
> as opposed to SVN revision numbers.
> Apart from that I have no idea why the version control used by the CI 
> matters. It should have to effect on the build or the results.

I don’t know, but other people may have other concern that I don’t necessarily 
anticipate.. 

>  
> 
> So it does not seems like a given to me  (not that I’m against it) and would 
> require a discussion on the mailing-list first IMO.
> 
> We might as well continue having it now since it's been started. I'll 
> re-raise the issue in a month or so when the bot is
> actually stable enough to consider sending emails.

I think it deserve a separate thread to deal with this, so that the thread 
title help making sure no-one miss the discussion.

— 
Mehdi

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

[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

It looks like `__INTPTR_TYPE__` was introduced in r64495 in order to help 
define `intptr_t`, and then they diverged in r89237.

Changing `intptr_t` would change the mangling of symbols in libcxx, so that 
doesn't seem safe.  Is it safe to change `__INTPTR_TYPE__`?


https://reviews.llvm.org/D31856



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

[PATCH] D31778: [Modules] Implement ODR-like semantics for tag types in C/ObjC

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno updated this revision to Diff 96080.
bruno marked 2 inline comments as done.
bruno added a comment.

Update the patch after Richard's suggestions


https://reviews.llvm.org/D31778

Files:
  include/clang/AST/ASTStructuralEquivalence.h
  include/clang/Basic/DiagnosticASTKinds.td
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/ASTStructuralEquivalence.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseExpr.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaType.cpp
  test/Modules/Inputs/F.framework/Headers/F.h
  test/Modules/Inputs/F.framework/Modules/module.modulemap
  test/Modules/Inputs/F.framework/Modules/module.private.modulemap
  test/Modules/Inputs/F.framework/PrivateHeaders/NS.h
  test/Modules/elaborated-type-specifier-from-hidden-module.m
  test/Modules/redefinition-c-tagtypes.m

Index: test/Modules/redefinition-c-tagtypes.m
===
--- /dev/null
+++ test/Modules/redefinition-c-tagtypes.m
@@ -0,0 +1,48 @@
+// RUN: rm -rf %t.cache
+// RUN: %clang_cc1 -fsyntax-only %s -fmodules -fmodules-cache-path=%t.cache \
+// RUN:   -fimplicit-module-maps -F%S/Inputs -verify
+// RUN: %clang_cc1 -fsyntax-only %s -fmodules -fmodules-cache-path=%t.cache \
+// RUN:   -fimplicit-module-maps -F%S/Inputs -DCHANGE_TAGS -verify
+#include "F/F.h"
+
+#ifndef CHANGE_TAGS
+// expected-no-diagnostics
+#endif
+
+struct NS {
+  int a;
+#ifndef CHANGE_TAGS
+  int b;
+#else
+  int c; // expected-note {{field has name 'c' here}}
+  // expected-error@redefinition-c-tagtypes.m:12 {{type 'struct NS' has incompatible definitions}}
+  // expected-note@Inputs/F.framework/PrivateHeaders/NS.h:3 {{field has name 'b' here}}
+#endif
+};
+
+enum NSE {
+  FST = 22,
+#ifndef CHANGE_TAGS
+  SND = 43,
+#else
+  SND = 44, // expected-note {{enumerator 'SND' with value 44 here}}
+  // expected-error@redefinition-c-tagtypes.m:23 {{type 'enum NSE' has incompatible definitions}}
+  // expected-note@Inputs/F.framework/PrivateHeaders/NS.h:8 {{enumerator 'SND' with value 43 here}}
+#endif
+  TRD = 55
+};
+
+#define NS_ENUM(_type, _name) \
+  enum _name : _type _name;   \
+  enum _name : _type
+
+typedef NS_ENUM(int, NSMyEnum) {
+  MinX = 11,
+#ifndef CHANGE_TAGS
+  MinXOther = MinX,
+#else
+  MinXOther = TRD, // expected-note {{enumerator 'MinXOther' with value 55 here}}
+  // expected-error@redefinition-c-tagtypes.m:39 {{type 'enum NSMyEnum' has incompatible definitions}}
+  // expected-note@Inputs/F.framework/PrivateHeaders/NS.h:18 {{enumerator 'MinXOther' with value 11 here}}
+#endif
+};
Index: test/Modules/elaborated-type-specifier-from-hidden-module.m
===
--- test/Modules/elaborated-type-specifier-from-hidden-module.m
+++ test/Modules/elaborated-type-specifier-from-hidden-module.m
@@ -4,12 +4,11 @@
 @import ElaboratedTypeStructs.Empty; // The structs are now hidden.
 struct S1 *x;
 struct S2 *y;
-// FIXME: compatible definition should not be an error.
-struct S2 { int x; }; // expected-error {{redefinition}}
+struct S2 { int x; };
 struct S3 *z;
 // Incompatible definition.
-struct S3 { float y; }; // expected-error {{redefinition}}
-// expected-note@elaborated-type-structs.h:* 2 {{previous definition is here}}
+struct S3 { float y; }; // expected-error {{has incompatible definitions}} // expected-note {{field has name}}
+// expected-note@Inputs/elaborated-type-structs.h:3 {{field has name}}
 
 @import ElaboratedTypeStructs.Structs;
 
Index: test/Modules/Inputs/F.framework/PrivateHeaders/NS.h
===
--- /dev/null
+++ test/Modules/Inputs/F.framework/PrivateHeaders/NS.h
@@ -0,0 +1,19 @@
+struct NS {
+  int a;
+  int b;
+};
+
+enum NSE {
+  FST = 22,
+  SND = 43,
+  TRD = 55
+};
+
+#define NS_ENUM(_type, _name) \
+  enum _name : _type _name;   \
+  enum _name : _type
+
+typedef NS_ENUM(int, NSMyEnum) {
+  MinX = 11,
+  MinXOther = MinX,
+};
Index: test/Modules/Inputs/F.framework/Modules/module.private.modulemap
===
--- /dev/null
+++ test/Modules/Inputs/F.framework/Modules/module.private.modulemap
@@ -0,0 +1,7 @@
+module F.Private [system] {
+  explicit module NS {
+  header "NS.h"
+  export *
+  }
+  export *
+}
Index: test/Modules/Inputs/F.framework/Modules/module.modulemap
===
--- /dev/null
+++ test/Modules/Inputs/F.framework/Modules/module.modulemap
@@ -0,0 +1,7 @@
+framework module F [extern_c] [system] {
+  umbrella header "F.h"
+  module * {
+  export *
+  }
+  export *
+}
Index: test/Modules/Inputs/F.framework/Headers/F.h
===
--- /dev/null
+++ test/Modules/Inputs/F.framework/Headers/F.h
@@ -0,0 +1 @@
+// F.h
Index: lib/Sema/SemaType.cpp
===
--- 

[PATCH] D31778: [Modules] Implement ODR-like semantics for tag types in C/ObjC

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno marked 6 inline comments as done.
bruno added inline comments.



Comment at: lib/Parse/ParseDecl.cpp:4236-4237
 
   Sema::SkipBodyInfo SkipBody;
+  Sema::CheckCompatTagInfo CheckCompatTag;
   if (!Name && TUK == Sema::TUK_Definition && Tok.is(tok::l_brace) &&

rsmith wrote:
> Do we really need both of these? The new stuff seems to be a natural 
> extension of `SkipBodyInfo`, to say "parse it, check it's the same as the 
> previous definition, then throw the new one away".
No specific reason. I'll augment `SkipBodyInfo` with two new fields then (a) a 
flag for the check and (b) the new tag.



Comment at: lib/Sema/SemaExpr.cpp:2198-2209
+  if (R.isAmbiguous()) {
+if (!IgnorePrevDef)
+  return ExprError();
+// We already know that there's a hidden decl included in the lookup,
+// ignore it and only use the first found (the local) one...
+auto RF = R.makeFilter();
+NamedDecl *ND = R.getRepresentativeDecl();

rsmith wrote:
> This is gross. In order to make this work, you'd need to propagate the 
> `IgnorePrevDef` flag through the entire expression parsing machinery.
> 
> Instead of this, how about deferring making the old definition visible until 
> after you complete parsing the new one and do the structural comparison?
Thanks for pointing it out, I totally missed this approach. Your suggestion 
works and I'll change the patch accordingly. However, `IgnorePrevDef` still 
needs to be threaded in `ParseEnumBody` and `ActOnEnumConstant` in order to 
prevent the latter to emit `err_redefinition_of_enumerator`-like diagnostics.


https://reviews.llvm.org/D31778



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

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Eric Fiselier via cfe-commits]

On Thu, Apr 20, 2017 at 4:55 PM, Mehdi Amini  wrote:

>
> On Apr 20, 2017, at 12:30 PM, Eric Fiselier  wrote:
>
>
>
> On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini 
> wrote:
>
>>
>> On Apr 20, 2017, at 12:39 AM, Eric Fiselier  wrote:
>>
>>
>>
>> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini 
>> wrote:
>>
>>> What would be the status of these buildbots? Is it for your private
>>> usage?
>>>
>>
>> I intend for them to be public Windows buildbots for libc++.
>>
>>
>>
>> I’m not sure it’d be OK to send blame email to contributors based on this
>> though.
>>
>
> I don't see why not (at least once the bot is stable). Can you elaborate?
>
>
> I don’t think there is a precedent for having a bot that does not checkout
> from SVN and email using the canonical SVN revision number.
>

I understand share your concern about the emails using nonsensical git
hashes as opposed to SVN revision numbers.
Apart from that I have no idea why the version control used by the CI
matters. It should have to effect on the build or the results.


>
> So it does not seems like a given to me  (not that I’m against it) and
> would require a discussion on the mailing-list first IMO.
>

We might as well continue having it now since it's been started. I'll
re-raise the issue in a month or so when the bot is
actually stable enough to consider sending emails.


>
> —
> Mehdi
>
>
>
>
>
> /Eric
>
>
>> —
>> Mehdi
>>
>>
>>
>> Otherwise having “project' bots” using a non-official mirror may sound
>>> like a strange situation to me.
>>>
>>
>> I agree it isn't ideal, but when/if LLVM moves to github it will be
>> trivial to re-configure for the official repositories.
>> I considered a number of other ways to setup Appveyor but I concluded
>> this was the best/easiest way to do it.
>> The other options I considered for configuring Appveyor are:
>>
>> (1) Use the official LLVM github mirrors.
>>
>> This has the issue of requiring the implementation of custom Git
>> webhooks, which would require
>> modifying and maintaining changes to the existing LLVM Git
>> infrastructure, which in itself
>> would require getting access to the LLVM servers to make the changes.
>>
>> (2) Setup my own ever more unofficial github mirror
>>
>> This has all the same problems as using the existing github mirrors but
>> it requires
>> me to configure and maintain my own mirror, which is non-trivial.
>>
>> (3) Don't use Appveyor at all
>>
>> This requires finding Windows hardware to host the bots, which is the
>> main reason
>> I chose Appveyor to begin with. Even if hardware was available I would
>> prefer using
>> Appveyor since it provides more dominion over the environment than I think
>> donated hardware could.
>>
>> /Eric
>>
>>
>>> —
>>> Mehdi
>>>
>>> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev <
>>> llvm-...@lists.llvm.org> wrote:
>>>
>>> Adding cfe-dev list...
>>>
>>> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier  wrote:
>>>
 Hi Will,

 I would like to request collaborator permissions for the Libc++ github
 mirror.

 I plan to use the access to setup Appveyor buildbots for libc++. In
 order to do this I need to be listed as a collaborator on Github.

 The alternative to Github access would be setting up the correct
 webhooks for llvm.org/git/libcxx.git, but this seems harder to both do
 and maintain.

 /Eric

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

[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith updated this revision to Diff 96078.
dexonsmith added a comment.

Here's an updated patch that uses `__SIZE_MAX__` and also handles the other 
pointer-like integers.

However, the first three static asserts fail, because `intptr_t` and 
`__INTPTR_TYPE__` are different types (same for `uintptr_t` and 
`__UINTPTR_TYPE__`).


https://reviews.llvm.org/D31856

Files:
  clang/lib/Headers/stdint.h
  clang/test/Headers/stdint-typeof-PTR_MIN-PTR_MAX.cpp
  clang/test/Preprocessor/stdint.c

Index: clang/test/Preprocessor/stdint.c
===
--- clang/test/Preprocessor/stdint.c
+++ clang/test/Preprocessor/stdint.c
@@ -74,9 +74,9 @@
 // ARM:INT_FAST64_MAX_ 9223372036854775807LL
 // ARM:UINT_FAST64_MAX_ 18446744073709551615ULL
 //
-// ARM:INTPTR_MIN_ (-2147483647 -1)
-// ARM:INTPTR_MAX_ 2147483647
-// ARM:UINTPTR_MAX_ 4294967295U
+// ARM:INTPTR_MIN_ (-2147483647L -1)
+// ARM:INTPTR_MAX_ 2147483647L
+// ARM:UINTPTR_MAX_ 4294967295UL
 // ARM:PTRDIFF_MIN_ (-2147483647 -1)
 // ARM:PTRDIFF_MAX_ 2147483647
 // ARM:SIZE_MAX_ 4294967295U
@@ -289,9 +289,9 @@
 // MIPS:INT_FAST64_MAX_ 9223372036854775807LL
 // MIPS:UINT_FAST64_MAX_ 18446744073709551615ULL
 //
-// MIPS:INTPTR_MIN_ (-2147483647 -1)
-// MIPS:INTPTR_MAX_ 2147483647
-// MIPS:UINTPTR_MAX_ 4294967295U
+// MIPS:INTPTR_MIN_ (-2147483647L -1)
+// MIPS:INTPTR_MAX_ 2147483647L
+// MIPS:UINTPTR_MAX_ 4294967295UL
 // MIPS:PTRDIFF_MIN_ (-2147483647 -1)
 // MIPS:PTRDIFF_MAX_ 2147483647
 // MIPS:SIZE_MAX_ 4294967295U
@@ -710,12 +710,12 @@
 // PPC64-NETBSD:INT_FAST64_MAX_ 9223372036854775807LL
 // PPC64-NETBSD:UINT_FAST64_MAX_ 18446744073709551615ULL
 //
-// PPC64-NETBSD:INTPTR_MIN_ (-9223372036854775807LL -1)
-// PPC64-NETBSD:INTPTR_MAX_ 9223372036854775807LL
-// PPC64-NETBSD:UINTPTR_MAX_ 18446744073709551615ULL
-// PPC64-NETBSD:PTRDIFF_MIN_ (-9223372036854775807LL -1)
-// PPC64-NETBSD:PTRDIFF_MAX_ 9223372036854775807LL
-// PPC64-NETBSD:SIZE_MAX_ 18446744073709551615ULL
+// PPC64-NETBSD:INTPTR_MIN_ (-9223372036854775807L -1)
+// PPC64-NETBSD:INTPTR_MAX_ 9223372036854775807L
+// PPC64-NETBSD:UINTPTR_MAX_ 18446744073709551615UL
+// PPC64-NETBSD:PTRDIFF_MIN_ (-9223372036854775807L -1)
+// PPC64-NETBSD:PTRDIFF_MAX_ 9223372036854775807L
+// PPC64-NETBSD:SIZE_MAX_ 18446744073709551615UL
 //
 // PPC64-NETBSD:INTMAX_MIN_ (-9223372036854775807LL -1)
 // PPC64-NETBSD:INTMAX_MAX_ 9223372036854775807LL
@@ -818,12 +818,12 @@
 // PPC:INT_FAST64_MAX_ 9223372036854775807LL
 // PPC:UINT_FAST64_MAX_ 18446744073709551615ULL
 //
-// PPC:INTPTR_MIN_ (-2147483647 -1)
-// PPC:INTPTR_MAX_ 2147483647
-// PPC:UINTPTR_MAX_ 4294967295U
-// PPC:PTRDIFF_MIN_ (-2147483647 -1)
-// PPC:PTRDIFF_MAX_ 2147483647
-// PPC:SIZE_MAX_ 4294967295U
+// PPC:INTPTR_MIN_ (-2147483647L -1)
+// PPC:INTPTR_MAX_ 2147483647L
+// PPC:UINTPTR_MAX_ 4294967295UL
+// PPC:PTRDIFF_MIN_ (-2147483647L -1)
+// PPC:PTRDIFF_MAX_ 2147483647L
+// PPC:SIZE_MAX_ 4294967295UL
 //
 // PPC:INTMAX_MIN_ (-9223372036854775807LL -1)
 // PPC:INTMAX_MAX_ 9223372036854775807LL
Index: clang/test/Headers/stdint-typeof-PTR_MIN-PTR_MAX.cpp
===
--- /dev/null
+++ clang/test/Headers/stdint-typeof-PTR_MIN-PTR_MAX.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only %s
+#include 
+#include 
+
+static_assert(__is_same(__typeof__(INTPTR_MIN), intptr_t),
+  "INTPTR_MIN should be intptr_t");
+static_assert(__is_same(__typeof__(INTPTR_MAX), intptr_t),
+  "INTPTR_MAX should be intptr_t");
+static_assert(__is_same(__typeof__(UINTPTR_MAX), uintptr_t),
+  "UINTPTR_MAX should be uintptr_t");
+static_assert(__is_same(__typeof__(PTRDIFF_MIN), ptrdiff_t),
+  "PTRDIFF_MIN should be ptrdiff_t");
+static_assert(__is_same(__typeof__(PTRDIFF_MAX), ptrdiff_t),
+  "PTRDIFF_MAX should be ptrdiff_t");
+static_assert(__is_same(__typeof__(SIZE_MAX), size_t),
+  "SIZE_MAX should be size_t");
Index: clang/lib/Headers/stdint.h
===
--- clang/lib/Headers/stdint.h
+++ clang/lib/Headers/stdint.h
@@ -659,12 +659,12 @@
 /* C99 7.18.2.4 Limits of integer types capable of holding object pointers. */
 /* C99 7.18.3 Limits of other integer types. */
 
-#define  INTPTR_MIN  __INTN_MIN(__INTPTR_WIDTH__)
-#define  INTPTR_MAX  __INTN_MAX(__INTPTR_WIDTH__)
-#define UINTPTR_MAX __UINTN_MAX(__INTPTR_WIDTH__)
-#define PTRDIFF_MIN  __INTN_MIN(__PTRDIFF_WIDTH__)
-#define PTRDIFF_MAX  __INTN_MAX(__PTRDIFF_WIDTH__)
-#defineSIZE_MAX __UINTN_MAX(__SIZE_WIDTH__)
+#define  INTPTR_MIN  (-__INTPTR_MAX__-1)
+#define  INTPTR_MAX__INTPTR_MAX__
+#define UINTPTR_MAX   __UINTPTR_MAX__
+#define PTRDIFF_MIN (-__PTRDIFF_MAX__-1)
+#define PTRDIFF_MAX   __PTRDIFF_MAX__
+#defineSIZE_MAX  __SIZE_MAX__
 
 /* ISO9899:2011 7.20 (C11 Annex K): Define RSIZE_MAX if __STDC_WANT_LIB_EXT1__
  * is enabled. */

[libcxx] r300941 - XFAIL Windows test failures under test/libcxx

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 20:48:02 2017
New Revision: 300941

URL: http://llvm.org/viewvc/llvm-project?rev=300941=rev
Log:
XFAIL Windows test failures under test/libcxx

This patch XFAIL's a number of tests under test/libcxx when on Windows.
These failures need more investigation or patches to either Clang or libc++
but for now we don't want them to prevent the bot from going green.

Modified:
libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp

libcxx/trunk/test/libcxx/language.support/support.dynamic/new_faligned_allocation.sh.cpp

libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp
libcxx/trunk/test/libcxx/modules/clocale_exports.sh.cpp
libcxx/trunk/test/libcxx/modules/cstdint_exports.sh.cpp
libcxx/trunk/test/libcxx/modules/inttypes_h_exports.sh.cpp

libcxx/trunk/test/libcxx/thread/futures/futures.promise/set_exception.pass.cpp

libcxx/trunk/test/libcxx/thread/futures/futures.promise/set_exception_at_thread_exit.pass.cpp

libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_lock_guard.pass.cpp

libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_lock_unlock.pass.cpp

libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_missing_unlock.fail.cpp

libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_requires_capability.pass.cpp
libcxx/trunk/utils/libcxx/test/config.py

Modified: 
libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp?rev=300941=300940=300941=diff
==
--- libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp 
(original)
+++ libcxx/trunk/test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp Thu 
Apr 20 20:48:02 2017
@@ -7,6 +7,11 @@
 //
 
//===--===//
 
+// There appears to be a bug in VerifyDiagnosticReporter on Windows that
+// causes -verify to not see the emitted warnings even though they are
+// actually getting omitted.
+// XFAIL: LIBCXX-WINDOWS-FIXME
+
 // REQUIRES: verify-support, diagnose-if-support
 // UNSUPPORTED: libcpp-has-no-threads
 

Modified: 
libcxx/trunk/test/libcxx/language.support/support.dynamic/new_faligned_allocation.sh.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/language.support/support.dynamic/new_faligned_allocation.sh.cpp?rev=300941=300940=300941=diff
==
--- 
libcxx/trunk/test/libcxx/language.support/support.dynamic/new_faligned_allocation.sh.cpp
 (original)
+++ 
libcxx/trunk/test/libcxx/language.support/support.dynamic/new_faligned_allocation.sh.cpp
 Thu Apr 20 20:48:02 2017
@@ -10,6 +10,10 @@
 // test libc++'s implementation of align_val_t, and the relevent new/delete
 // overloads in all dialects when -faligned-allocation is present.
 
+// Libc++ defers to the underlying MSVC library to provide the new/delete
+// definitions, which does not yet provide aligned allocation
+// XFAIL: LIBCXX-WINDOWS-FIXME
+
 // REQUIRES: -faligned-allocation
 
 // RUN: %build -faligned-allocation
@@ -74,4 +78,4 @@ int main() {
 assert(typeid(std::align_val_t).name() == std::string("St11align_val_t"));
   }
 #endif
-}
\ No newline at end of file
+}

Modified: 
libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp?rev=300941=300940=300941=diff
==
--- 
libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
 (original)
+++ 
libcxx/trunk/test/libcxx/localization/locales/locale.convenience/conversions/conversions.string/ctor_move.pass.cpp
 Thu Apr 20 20:48:02 2017
@@ -7,6 +7,10 @@
 //
 
//===--===//
 
+// This test fails because the `from_bytes` call seems to result in a call
+// to 'abort()'
+// XFAIL: LIBCXX-WINDOWS-FIXME
+
 // UNSUPPORTED: c++98, c++03
 
 // 

Modified: libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp?rev=300941=300940=300941=diff
==
--- libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp (original)
+++ libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp Thu Apr 20 
20:48:02 2017
@@ -7,6 +7,10 @@
 //
 

[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

Hmm... presumably, this test should pass:

  $ ./bin/clang -nostdinc -isystem ./lib/clang/5.0.0/include -std=c++1z 
-fsyntax-only t.cpp
  t.cpp:3:1: error: static_assert failed
  static_assert(__is_same(intptr_t, __INTPTR_TYPE__));
  ^ 
  t.cpp:4:1: error: static_assert failed
  static_assert(__is_same(uintptr_t, __UINTPTR_TYPE__));
  ^ ~~
  2 errors generated.
  $ cat t.cpp 
  #include 
  
  static_assert(__is_same(intptr_t, __INTPTR_TYPE__));
  static_assert(__is_same(uintptr_t, __UINTPTR_TYPE__));

Discovered that it fails (at least for `-triple x86_64-apple-macosx10.12.0`) 
while writing tests for an improved patch that covers SIZE_MAX, 
PTRDIFF_MIN/MAX, UINTPTR_MAX, and INTPTR_MAX, since I was trying:

  static_assert(__is_same(__typeof__(INTPTR_MIN), intptr_t));
  static_assert(__is_same(__typeof__(INTPTR_MAX), intptr_t));
  static_assert(__is_same(__typeof__(UINTPTR_MAX), uintptr_t));
  static_assert(__is_same(__typeof__(PTRDIFF_MIN), ptrdiff_t));
  static_assert(__is_same(__typeof__(PTRDIFF_MAX), ptrdiff_t));
  static_assert(__is_same(__typeof__(SIZE_MAX), size_t));

and the first three assertions all failed.

Is `__INTPTR_TYPE__` correct, or is `intptr_t`?  Is it safe to fix the one 
that's wrong?


https://reviews.llvm.org/D31856



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

[PATCH] D32332: Add support for transparent overloadable functions in clang

[George Burgess IV via Phabricator via cfe-commits]

george.burgess.iv created this revision.

One of the common use-cases for the `overloadable` attribute is to create small
wrapper functions around an existing function that was previously not
overloadable. For example:

  // C Library v1
  void foo(int i);
  
  
  // C Library v2
  // Note the __asm__("foo"); it ensures that foo isn't mangled. Our docs state
  // that the mangling isn't stable, so we encourage users to either use __asm__
  // to force a stable name, or to only use overloads with internal linkage
  __attribute__((overloadable))
  int foo(int i) __asm__("foo");
  
  __attribute__((overloadable))
  static inline int foo(long l) {
assert(l <= INT_MAX && l >= INT_MIN && "Out of bounds number!");
return foo(l);
  }

"Library v2" is suboptimal for a few reasons:

- It can break existing code; if users added `int foo(int);` declarations to 
their code, upgrading to library v2 requires that the users either remove these 
declarations or add `__attribute__((overloadable))` to them.
- The `__asm__` name is both redundant and easy to typo (or forget to update, 
or ...).
- The `__asm__` name also makes it quite a bit more difficult to hide all of 
this behind a macro, since we need a different name for each function.

This patch aims to fix these usability challenges with the idea of transparent
function overloads.

For any `overloadable` function in C, one of the overloads is allowed to be
transparent. Transparency means that the name will not be mangled, and later
redeclarations of that particular overload don't require
`__attribute__((overloadable))`.

Users can make an overload transparent by using the `transparently_overloadable`
spelling of `overloadable`.

This also includes a bugfix for how we handled `overloadable` functions declared
inside functions. I can factor that out if that would make life easier. :)


https://reviews.llvm.org/D32332

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Sema/SemaDecl.cpp
  test/CodeGen/mangle-ms.c
  test/CodeGen/mangle.c
  test/CodeGenCXX/mangle-ms.cpp
  test/Sema/overloadable.c

Index: test/Sema/overloadable.c
===
--- test/Sema/overloadable.c
+++ test/Sema/overloadable.c
@@ -3,6 +3,9 @@
 int var __attribute__((overloadable)); // expected-error{{'overloadable' attribute only applies to functions}}
 void params(void) __attribute__((overloadable(12))); // expected-error {{'overloadable' attribute takes no arguments}}
 
+int var2 __attribute__((transparently_overloadable)); // expected-error{{'transparently_overloadable' attribute only applies to functions}}
+void params2(void) __attribute__((transparently_overloadable(12))); // expected-error {{'transparently_overloadable' attribute takes no arguments}}
+
 int *f(int) __attribute__((overloadable)); // expected-note 2{{previous overload of function is here}}
 float *f(float); // expected-error{{overloaded function 'f' must have the 'overloadable' attribute}}
 int *f(int); // expected-error{{redeclaration of 'f' must have the 'overloadable' attribute}} \
@@ -106,8 +109,8 @@
   void foo(char *c) __attribute__((overloadable));
   void (*ptr1)(void *) = 
   void (*ptr2)(char *) = 
-  void (*ambiguous)(int *) =  // expected-error{{initializing 'void (*)(int *)' with an expression of incompatible type ''}} expected-note@105{{candidate function}} expected-note@106{{candidate function}}
-  void *vp_ambiguous =  // expected-error{{initializing 'void *' with an expression of incompatible type ''}} expected-note@105{{candidate function}} expected-note@106{{candidate function}}
+  void (*ambiguous)(int *) =  // expected-error{{initializing 'void (*)(int *)' with an expression of incompatible type ''}} expected-note@-4{{candidate function}} expected-note@-3{{candidate function}}
+  void *vp_ambiguous =  // expected-error{{initializing 'void *' with an expression of incompatible type ''}} expected-note@-5{{candidate function}} expected-note@-4{{candidate function}}
 
   void (*specific1)(int *) = (void (*)(void *)) // expected-warning{{incompatible function pointer types initializing 'void (*)(int *)' with an expression of type 'void (*)(void *)'}}
   void *specific2 = (void (*)(void *))
@@ -117,8 +120,8 @@
   void disabled(char *c) __attribute__((overloadable, enable_if(1, "The function name lies.")));
   // To be clear, these should all point to the last overload of 'disabled'
   void (*dptr1)(char *c) = 
-  void (*dptr2)(void *c) =  // expected-warning{{incompatible pointer types initializing 'void (*)(void *)' with an expression of type ''}} expected-note@115{{candidate function made ineligible by enable_if}} expected-note@116{{candidate function made ineligible by enable_if}} expected-note@117{{candidate function has type mismatch at 1st parameter (expected 'void *' but has 'char *')}}
-  

Re: r300650 - [modules] Properly look up the owning module for an instantiation of a merged template.

[Richard Smith via cfe-commits]

Re-committed with fix in r300938.

On 20 April 2017 at 17:06, Richard Smith  wrote:

> On 18 April 2017 at 22:41, Chandler Carruth  wrote:
>
>> Reverted in r300658.
>>
>
> For posterity, the above has an off-by-one error, the revert was r300659.
>
>
>> On Tue, Apr 18, 2017 at 8:30 PM Chandler Carruth 
>> wrote:
>>
>>> Consider code like the following:
>>>
>>> ```
>>> #include 
>>>
>>> template 
>>> class MyAllocator : public std::allocator {
>>>  public:
>>>   typedef std::allocator Alloc;
>>>   typedef typename Alloc::pointer pointer;
>>>   typedef typename Alloc::size_type size_type;
>>>
>>>   MyAllocator() {}
>>>
>>>   template 
>>>   MyAllocator(const MyAllocator& x) : Alloc(x) {}
>>>
>>>   pointer allocate(size_type n,
>>>std::allocator::const_pointer /*hint*/ =
>>> nullptr) {
>>> void* p = malloc(n * sizeof(T));
>>> return static_cast(p);
>>>   }
>>>
>>>   void deallocate(pointer p, size_type) { free(p); }
>>>
>>>   template 
>>>   struct rebind {
>>> typedef MyAllocator other;
>>>   };
>>>
>>>  private:
>>>   template 
>>>   friend class MyAllocator;
>>> };
>>>
>>> std::shared_ptr x = std::allocate_shared(MyAllocator(),
>>> 0);
>>> ```
>>>
>>> This will fail to compile against libstdc++ 4.9's alloc_traits.h, when
>>> that header comes from a module, with an error message along the lines of:
>>> .../bits/alloc_traits.h:197:2: error: too few template arguments for
>>> class template '__alloctr_rebind'
>>> using rebind_alloc = typename __alloctr_rebind<_Alloc,
>>> _Tp>::__type;
>>>
>>> I think this is enough for you to debug, but let me know if not. I'm
>>> going to revert this temporarily to unbreak our modules builds using this
>>> version of libstdc++.
>>>
>>> On Tue, Apr 18, 2017 at 8:14 PM Chandler Carruth 
>>> wrote:
>>>
 This appears to break a pretty straightforward use of things like
 libstdc++'s __alloctr_rebind (undefined template with a default argument,
 specializations, etc):
 https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/libstd
 c++-v3/include/bits/alloc_traits.h#L58-L73

 At least, I'm getting errors from this. I'm working on a test case, but
 as usual, the test case may be... large.

 On Tue, Apr 18, 2017 at 6:49 PM Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Apr 18 20:36:43 2017
> New Revision: 300650
>
> URL: http://llvm.org/viewvc/llvm-project?rev=300650=rev
> Log:
> [modules] Properly look up the owning module for an instantiation of a
> merged template.
>
> When looking for the template instantiation pattern of a templated
> entity,
> consistently select the definition of the pattern if there is one.
> This means
> we'll pick the same owning module when we start instantiating a
> template that
> we'll later pick when determining which modules are visible during that
> instantiation.
>
> Modified:
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/AST/DeclCXX.cpp
> cfe/trunk/lib/Sema/SemaLookup.cpp
> cfe/trunk/test/Modules/Inputs/template-default-args/a.h
> cfe/trunk/test/Modules/template-default-args.cpp
>
> Modified: cfe/trunk/lib/AST/Decl.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.
> cpp?rev=300650=300649=300650=diff
> 
> ==
> --- cfe/trunk/lib/AST/Decl.cpp (original)
> +++ cfe/trunk/lib/AST/Decl.cpp Tue Apr 18 20:36:43 2017
> @@ -2251,6 +2251,13 @@ bool VarDecl::checkInitIsICE() const {
>return Eval->IsICE;
>  }
>
> +template
> +static DeclT *getDefinitionOrSelf(DeclT *D) {
> +  if (auto *Def = D->getDefinition())
> +return Def;
> +  return D;
> +}
> +
>  VarDecl *VarDecl::getTemplateInstantiationPattern() const {
>// If it's a variable template specialization, find the template or
> partial
>// specialization from which it was instantiated.
> @@ -2262,7 +2269,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>break;
>  VTD = NewVTD;
>}
> -  return VTD->getTemplatedDecl()->getDefinition();
> +  return getDefinitionOrSelf(VTD->getTemplatedDecl());
>  }
>  if (auto *VTPSD =
>  From.dyn_cast())
> {
> @@ -2271,7 +2278,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>break;
>  VTPSD = NewVTPSD;
>}
> -  return VTPSD->getDefinition();
> +  return getDefinitionOrSelf(VTPSD);
>  }
>}
>
> @@ -2280,23 +2287,18 @@ VarDecl *VarDecl::getTemplateInstantiati
>VarDecl *VD = getInstantiatedFromStaticDataMember();
>while (auto *NewVD = 

r300938 - [modules] Properly look up the owning module for an instantiation of a merged template.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Apr 20 20:15:13 2017
New Revision: 300938

URL: http://llvm.org/viewvc/llvm-project?rev=300938=rev
Log:
[modules] Properly look up the owning module for an instantiation of a merged 
template.

When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.

This reinstates r300650, reverted in r300659, with a fix for a regression
reported by Chandler after commit.

Modified:
cfe/trunk/lib/AST/Decl.cpp
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/test/Modules/Inputs/template-default-args/a.h
cfe/trunk/test/Modules/Inputs/template-default-args/d.h
cfe/trunk/test/Modules/template-default-args.cpp

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=300938=300937=300938=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Thu Apr 20 20:15:13 2017
@@ -2251,6 +2251,14 @@ bool VarDecl::checkInitIsICE() const {
   return Eval->IsICE;
 }
 
+template
+static DeclT *getDefinitionOrSelf(DeclT *D) {
+  assert(D);
+  if (auto *Def = D->getDefinition())
+return Def;
+  return D;
+}
+
 VarDecl *VarDecl::getTemplateInstantiationPattern() const {
   // If it's a variable template specialization, find the template or partial
   // specialization from which it was instantiated.
@@ -2262,7 +2270,7 @@ VarDecl *VarDecl::getTemplateInstantiati
   break;
 VTD = NewVTD;
   }
-  return VTD->getTemplatedDecl()->getDefinition();
+  return getDefinitionOrSelf(VTD->getTemplatedDecl());
 }
 if (auto *VTPSD =
 From.dyn_cast()) {
@@ -2271,7 +2279,7 @@ VarDecl *VarDecl::getTemplateInstantiati
   break;
 VTPSD = NewVTPSD;
   }
-  return VTPSD->getDefinition();
+  return getDefinitionOrSelf(VTPSD);
 }
   }
 
@@ -2280,23 +2288,18 @@ VarDecl *VarDecl::getTemplateInstantiati
   VarDecl *VD = getInstantiatedFromStaticDataMember();
   while (auto *NewVD = VD->getInstantiatedFromStaticDataMember())
 VD = NewVD;
-  return VD->getDefinition();
+  return getDefinitionOrSelf(VD);
 }
   }
 
   if (VarTemplateDecl *VarTemplate = getDescribedVarTemplate()) {
-
 while (VarTemplate->getInstantiatedFromMemberTemplate()) {
   if (VarTemplate->isMemberSpecialization())
 break;
   VarTemplate = VarTemplate->getInstantiatedFromMemberTemplate();
 }
 
-assert((!VarTemplate->getTemplatedDecl() ||
-!isTemplateInstantiation(getTemplateSpecializationKind())) &&
-   "couldn't find pattern for variable instantiation");
-
-return VarTemplate->getTemplatedDecl();
+return getDefinitionOrSelf(VarTemplate->getTemplatedDecl());
   }
   return nullptr;
 }
@@ -3198,9 +3201,12 @@ bool FunctionDecl::isTemplateInstantiati

 FunctionDecl *FunctionDecl::getTemplateInstantiationPattern() const {
   // Handle class scope explicit specialization special case.
-  if (getTemplateSpecializationKind() == TSK_ExplicitSpecialization)
-return getClassScopeSpecializationPattern();
-  
+  if (getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
+if (auto *Spec = getClassScopeSpecializationPattern())
+  return getDefinitionOrSelf(Spec);
+return nullptr;
+  }
+
   // If this is a generic lambda call operator specialization, its 
   // instantiation pattern is always its primary template's pattern
   // even if its primary template was instantiated from another 
@@ -3212,16 +3218,10 @@ FunctionDecl *FunctionDecl::getTemplateI
 
   if (isGenericLambdaCallOperatorSpecialization(
   dyn_cast(this))) {
-assert(getPrimaryTemplate() && "A generic lambda specialization must be "
-   "generated from a primary call operator "
-   "template");
-assert(getPrimaryTemplate()->getTemplatedDecl()->getBody() &&
-   "A generic lambda call operator template must always have a body - "
-   "even if instantiated from a prototype (i.e. as written) member "
-   "template");
-return getPrimaryTemplate()->getTemplatedDecl();
+assert(getPrimaryTemplate() && "not a generic lambda call operator?");
+return getDefinitionOrSelf(getPrimaryTemplate()->getTemplatedDecl());
   }
-  
+
   if (FunctionTemplateDecl *Primary = getPrimaryTemplate()) {
 while (Primary->getInstantiatedFromMemberTemplate()) {
   // If we have hit a point where the user provided a specialization of
@@ -3230,11 +3230,14 @@ FunctionDecl *FunctionDecl::getTemplateI
 break;
   Primary = Primary->getInstantiatedFromMemberTemplate();
 }
-

[PATCH] D32307: [libcxx] [test] Resolve everyone's favorite warning, unused local typedef

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal closed this revision.
BillyONeal added a comment.

Committed r300937


https://reviews.llvm.org/D32307



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

[libcxx] r300937 - Resolve unused local typedef warning in test.

[Billy Robert O'Neal III via cfe-commits]

Author: bion
Date: Thu Apr 20 20:10:04 2017
New Revision: 300937

URL: http://llvm.org/viewvc/llvm-project?rev=300937=rev
Log:
Resolve unused local typedef warning in test.

Modified:
libcxx/trunk/test/std/strings/basic.string/string.cons/T_size_size.pass.cpp

Modified: 
libcxx/trunk/test/std/strings/basic.string/string.cons/T_size_size.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/basic.string/string.cons/T_size_size.pass.cpp?rev=300937=300936=300937=diff
==
--- libcxx/trunk/test/std/strings/basic.string/string.cons/T_size_size.pass.cpp 
(original)
+++ libcxx/trunk/test/std/strings/basic.string/string.cons/T_size_size.pass.cpp 
Thu Apr 20 20:10:04 2017
@@ -63,7 +63,6 @@ void
 test(SV sv, unsigned pos, unsigned n, const typename S::allocator_type& a)
 {
 typedef typename S::traits_type T;
-typedef typename S::allocator_type A;
 if (pos <= sv.size())
 {
 S s2(sv, pos, n, a);


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

[PATCH] D32328: [analyzer] Fix assert in ExprEngine::processSwitch

[Alexander Shaposhnikov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300936: [analyzer] Fix assert in ExprEngine::processSwitch 
(authored by alexshap).

Changed prior to commit:
  https://reviews.llvm.org/D32328?vs=96060=96070#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32328

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
  cfe/trunk/test/Analysis/enum.cpp


Index: cfe/trunk/test/Analysis/enum.cpp
===
--- cfe/trunk/test/Analysis/enum.cpp
+++ cfe/trunk/test/Analysis/enum.cpp
@@ -24,3 +24,16 @@
 clang_analyzer_eval(j == 0); // expected-warning{{FALSE}}
   }
 }
+
+enum class EnumBool : bool {
+  F = false,
+  T = true
+};
+
+bool testNoCrashOnSwitchEnumBool(EnumBool E) {
+  switch (E) {
+  case EnumBool::F:
+return false;
+  }
+  return true;
+}
Index: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -1904,8 +1904,8 @@
 
 // Evaluate the LHS of the case value.
 llvm::APSInt V1 = Case->getLHS()->EvaluateKnownConstInt(getContext());
-assert(V1.getBitWidth() == getContext().getTypeSize(CondE->getType()));
-
+assert(V1.getBitWidth() == getContext().getIntWidth(CondE->getType()));
+
 // Get the RHS of the case, if it exists.
 llvm::APSInt V2;
 if (const Expr *E = Case->getRHS())


Index: cfe/trunk/test/Analysis/enum.cpp
===
--- cfe/trunk/test/Analysis/enum.cpp
+++ cfe/trunk/test/Analysis/enum.cpp
@@ -24,3 +24,16 @@
 clang_analyzer_eval(j == 0); // expected-warning{{FALSE}}
   }
 }
+
+enum class EnumBool : bool {
+  F = false,
+  T = true
+};
+
+bool testNoCrashOnSwitchEnumBool(EnumBool E) {
+  switch (E) {
+  case EnumBool::F:
+return false;
+  }
+  return true;
+}
Index: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -1904,8 +1904,8 @@
 
 // Evaluate the LHS of the case value.
 llvm::APSInt V1 = Case->getLHS()->EvaluateKnownConstInt(getContext());
-assert(V1.getBitWidth() == getContext().getTypeSize(CondE->getType()));
-
+assert(V1.getBitWidth() == getContext().getIntWidth(CondE->getType()));
+
 // Get the RHS of the case, if it exists.
 llvm::APSInt V2;
 if (const Expr *E = Case->getRHS())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r300936 - [analyzer] Fix assert in ExprEngine::processSwitch

[Alexander Shaposhnikov via cfe-commits]

Author: alexshap
Date: Thu Apr 20 20:05:26 2017
New Revision: 300936

URL: http://llvm.org/viewvc/llvm-project?rev=300936=rev
Log:
[analyzer] Fix assert in ExprEngine::processSwitch

This diff replaces getTypeSize(CondE->getType())) 
with getIntWidth(CondE->getType())) in ExprEngine::processSwitch.
These calls are not equivalent for bool, see ASTContext.cpp
Add a test case.

Test plan:
make check-clang-analysis
make check-clang

Differential revision: https://reviews.llvm.org/D32328

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
cfe/trunk/test/Analysis/enum.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp?rev=300936=300935=300936=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp Thu Apr 20 20:05:26 2017
@@ -1904,8 +1904,8 @@ void ExprEngine::processSwitch(SwitchNod
 
 // Evaluate the LHS of the case value.
 llvm::APSInt V1 = Case->getLHS()->EvaluateKnownConstInt(getContext());
-assert(V1.getBitWidth() == getContext().getTypeSize(CondE->getType()));
-
+assert(V1.getBitWidth() == getContext().getIntWidth(CondE->getType()));
+
 // Get the RHS of the case, if it exists.
 llvm::APSInt V2;
 if (const Expr *E = Case->getRHS())

Modified: cfe/trunk/test/Analysis/enum.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/enum.cpp?rev=300936=300935=300936=diff
==
--- cfe/trunk/test/Analysis/enum.cpp (original)
+++ cfe/trunk/test/Analysis/enum.cpp Thu Apr 20 20:05:26 2017
@@ -24,3 +24,16 @@ void testCasting(int i) {
 clang_analyzer_eval(j == 0); // expected-warning{{FALSE}}
   }
 }
+
+enum class EnumBool : bool {
+  F = false,
+  T = true
+};
+
+bool testNoCrashOnSwitchEnumBool(EnumBool E) {
+  switch (E) {
+  case EnumBool::F:
+return false;
+  }
+  return true;
+}


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

[libcxx] r300934 - Fix 'verify-support' available feature

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 19:43:07 2017
New Revision: 300934

URL: http://llvm.org/viewvc/llvm-project?rev=300934=rev
Log:
Fix 'verify-support' available feature

Modified:
libcxx/trunk/utils/libcxx/test/config.py

Modified: libcxx/trunk/utils/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/utils/libcxx/test/config.py?rev=300934=300933=300934=diff
==
--- libcxx/trunk/utils/libcxx/test/config.py (original)
+++ libcxx/trunk/utils/libcxx/test/config.py Thu Apr 20 19:43:07 2017
@@ -311,10 +311,10 @@ class Configuration(object):
 # NOTE: We do not test for the -verify flag directly because
 #   -verify will always exit with non-zero on an empty file.
 self.use_clang_verify = self.cxx.isVerifySupported()
-if self.use_clang_verify:
-self.config.available_features.add('verify-support')
 self.lit_config.note(
 "inferred use_clang_verify as: %r" % self.use_clang_verify)
+if self.use_clang_verify:
+self.config.available_features.add('verify-support')
 
 def configure_use_thread_safety(self):
 '''If set, run clang with -verify on failing tests.'''


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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In https://reviews.llvm.org/D24892#732243, @malcolm.parsons wrote:

> In https://reviews.llvm.org/D24892#732217, @alexfh wrote:
>
> > In https://reviews.llvm.org/D24892#723536, @malcolm.parsons wrote:
> >
> > > Is there any way for multiple checks to share an option?
> >
> >
> > There's OptionsView::getLocalOrGlobal. See how StrictMode option is read in 
> > ArgumentCommentCheck, for example.
>
>
> ArgumentCommentCheck uses getLocalOrGlobal, but 
> InefficientStringConcatenationCheck and SuspiciousEnumUsageCheck don't.
>  6 checks have an IncludeStyle option that isn't shared.
>  4 checks share a HeaderFileExtensions option, but with different defaults.


The right thing would be to fix these. I might get around to this, if nobody 
does this before me.


https://reviews.llvm.org/D24892



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

[PATCH] D32328: [analyzer] Fix assert in ExprEngine::processSwitch

[Alexander Shaposhnikov via Phabricator via cfe-commits]

alexshap added a comment.

Thanks, i do.


Repository:
  rL LLVM

https://reviews.llvm.org/D32328



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

[PATCH] D32328: [analyzer] Fix assert in ExprEngine::processSwitch

[Anna Zaks via Phabricator via cfe-commits]

zaks.anna added a comment.

Do you have commit access?


Repository:
  rL LLVM

https://reviews.llvm.org/D32328



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

[PATCH] D32328: [analyzer] Fix assert in ExprEngine::processSwitch

[Anna Zaks via Phabricator via cfe-commits]

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

Thank you!


Repository:
  rL LLVM

https://reviews.llvm.org/D32328



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added inline comments.



Comment at: clang-tidy/tool/run-clang-tidy.py:226
+print('Applying fixes ...')
+successfully_applied = True
+

` = False` here and ` = True` after `apply_fixes()` inside `try`.


https://reviews.llvm.org/D32294



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In https://reviews.llvm.org/D32294#732986, @Prazek wrote:

> In https://reviews.llvm.org/D32294#732861, @kuhar wrote:
>
> > After thinking about Piotr's comment, I think that a better way to perform 
> > the check would be te invoking clang-apply-replacements with `--version` 
> > and seeing if it fails even before running clang-tidy.
> >  This way it is possible to save a lot of time when run-clang-tidy.py is 
> > run on a big project and apply_fixes fails at the end.
> >
> > Let me know what you think about this approach.
>
>
> Sounds good to me!


+1


https://reviews.llvm.org/D32294



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Piotr Padlewski via Phabricator via cfe-commits]

Prazek added a comment.

In https://reviews.llvm.org/D32294#732861, @kuhar wrote:

> After thinking about Piotr's comment, I think that a better way to perform 
> the check would be te invoking clang-apply-replacements with `--version` and 
> seeing if it fails even before running clang-tidy.
>  This way it is possible to save a lot of time when run-clang-tidy.py is run 
> on a big project and apply_fixes fails at the end.
>
> Let me know what you think about this approach.


Sounds good to me!


https://reviews.llvm.org/D32294



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

[PATCH] D31561: cmath: Skip Libc for integral types in isinf, etc.

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

Marshall, are you fine with figuring this out in-tree?  Or should I revert to 
using `std::is_floating_point` for now?


https://reviews.llvm.org/D31561



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

r300894 - Enable leak sanitizer builds for darwin

[Francis Ricci via cfe-commits]

Author: fjricci
Date: Thu Apr 20 16:11:51 2017
New Revision: 300894

URL: http://llvm.org/viewvc/llvm-project?rev=300894=rev
Log:
Enable leak sanitizer builds for darwin

Summary:
Support for leak sanitizer on darwin has been added to
compiler-rt, this patch adds compiler support.

Reviewers: dexonsmith, compnerd

Subscribers: alekseyshl, kubamracek, cfe-commits

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
cfe/trunk/test/Driver/fsanitize.c
cfe/trunk/test/Driver/sanitizer-ld.c

Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=300894=300893=300894=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Thu Apr 20 16:11:51 2017
@@ -1035,6 +1035,8 @@ void DarwinClang::AddLinkRuntimeLibArgs(
   const SanitizerArgs  = getSanitizerArgs();
   if (Sanitize.needsAsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+  if (Sanitize.needsLsanRt())
+AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
   if (Sanitize.needsUbsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "ubsan");
   if (Sanitize.needsTsanRt())
@@ -1892,6 +1894,7 @@ SanitizerMask Darwin::getSupportedSaniti
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::Leak;
   if (isTargetMacOS()) {
 if (!isMacosxVersionLT(10, 9))
   Res |= SanitizerKind::Vptr;

Modified: cfe/trunk/test/Driver/fsanitize.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize.c?rev=300894=300893=300894=diff
==
--- cfe/trunk/test/Driver/fsanitize.c (original)
+++ cfe/trunk/test/Driver/fsanitize.c Thu Apr 20 16:11:51 2017
@@ -358,6 +358,27 @@
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 
'i386-pc-openbsd'
 
+// RUN: %clang -target x86_64-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-X86-64-DARWIN
+// CHECK-LSAN-X86-64-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-iossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-IOSSIMULATOR
+// CHECK-LSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-tvossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-TVOSSIMULATOR
+// CHECK-LSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-DARWIN
+// CHECK-LSAN-I386-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target arm-apple-ios -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LSAN-ARM-IOS
+// CHECK-LSAN-ARM-IOS-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-iossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-IOSSIMULATOR
+// CHECK-LSAN-I386-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-tvossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-TVOSSIMULATOR
+// CHECK-LSAN-I386-TVOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-cache-frag %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-working-set %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // CHECK-ESAN-X86: error: unsupported option '-fsanitize=efficiency-{{.*}}' 
for target 'i686--linux-gnu'

Modified: cfe/trunk/test/Driver/sanitizer-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/sanitizer-ld.c?rev=300894=300893=300894=diff
==
--- cfe/trunk/test/Driver/sanitizer-ld.c (original)
+++ cfe/trunk/test/Driver/sanitizer-ld.c Thu Apr 20 16:11:51 2017
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target 

Buildbot numbers for the week of 04/09/2017 - 04/15/2017

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 04/09/2017 -
04/15/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername | was_red
+-
 clang-x86_64-linux-selfhost-modules| 76:17:27
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan  | 52:20:18
 clang-lld-x86_64-2stage| 50:37:55
 clang-x86_64-linux-selfhost-modules-2  | 47:24:53
 sanitizer-ppc64le-linux| 42:59:32
 clang-cmake-thumbv7-a15-full-sh| 39:55:31
 clang-ppc64be-linux-multistage | 28:48:14
 clang-x64-ninja-win7   | 27:23:55
 clang-x86-windows-msvc2015 | 27:13:14
 clang-cmake-armv7-a15-selfhost-neon| 26:33:39
 clang-cmake-armv7-a15-selfhost | 24:38:47
 sanitizer-x86_64-linux-bootstrap   | 23:18:49
 clang-cmake-aarch64-lld| 23:12:21
 clang-ppc64le-linux-multistage | 23:10:30
 clang-with-lto-ubuntu  | 23:07:50
 clang-cmake-aarch64-full   | 22:25:25
 llvm-clang-x86_64-expensive-checks-win | 18:08:11
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast   | 18:07:41
 lldb-x86_64-ubuntu-14.04-android   | 16:30:53
 lldb-x86_64-darwin-13.4| 10:25:03
 lldb-x86_64-ubuntu-14.04-cmake | 10:01:41
 lldb-windows7-android  | 10:00:29
 clang-cmake-aarch64-39vma  | 08:42:25
 clang-cmake-aarch64-42vma  | 08:41:55
 clang-cmake-armv7-a15-full | 08:34:15
 sanitizer-x86_64-linux-autoconf| 07:43:05
 sanitizer-ppc64be-linux| 07:41:12
 perf-x86_64-penryn-O3  | 06:57:03
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 06:21:15
 perf-x86_64-penryn-O3-polly| 06:19:15
 clang-cmake-thumbv7-a15| 06:11:09
 clang-cmake-armv7-a15  | 06:11:02
 clang-hexagon-elf  | 06:05:43
 polly-arm-linux| 05:59:33
 llvm-hexagon-elf   | 05:59:32
 clang-cmake-aarch64-quick  | 05:59:09
 lld-x86_64-darwin13| 05:55:08
 perf-x86_64-penryn-O3-polly-fast   | 05:20:31
 clang-cmake-mips   | 05:10:18
 clang-cmake-mipsel | 04:53:45
 polly-amd64-linux  | 04:38:23
 clang-ppc64be-linux-lnt| 04:31:54
 lldb-x86_64-ubuntu-14.04-buildserver   | 03:35:44
 clang-ppc64le-linux| 03:30:42
 lldb-amd64-ninja-netbsd7   | 03:26:29
 llvm-sphinx-docs   | 03:21:14
 llvm-mips-linux| 03:21:02
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 02:48:01
 clang-ppc64le-linux-lnt| 02:47:56
 clang-ppc64be-linux| 02:41:03
 libcxx-libcxxabi-libunwind-arm-linux-noexceptions  | 02:38:34
 sanitizer-x86_64-linux-fast| 02:37:50
 lldb-x86-windows-msvc2015  | 02:28:17
 perf-x86_64-penryn-O3-polly-parallel-fast  | 02:21:54
 perf-x86_64-penryn-O3-polly-unprofitable   | 02:15:47
 lldb-amd64-ninja-freebsd11 | 02:05:38
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions  | 02:00:19
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 01:53:15
 sanitizer-windows  | 01:44:58
 clang-s390x-linux   

Buildbot numbers for the week of 04/02/2017 - 04/08/2017

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 04/02/2017 - 04/08/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername |  was_red
+--
 clang-x64-ninja-win7   | 131:11:54
 lldb-amd64-ninja-freebsd11 | 74:30:52
 lldb-x86_64-ubuntu-14.04-android   | 42:01:22
 sanitizer-windows  | 40:01:49
 clang-lld-x86_64-2stage| 30:53:01
 clang-with-lto-ubuntu  | 29:17:54
 sanitizer-x86_64-linux-autoconf| 25:11:10
 clang-s390x-linux  | 24:04:42
 clang-ppc64le-linux-lnt| 24:03:16
 clang-ppc64le-linux-multistage | 22:52:11
 lldb-x86_64-ubuntu-14.04-cmake | 21:35:51
 clang-ppc64be-linux-lnt| 16:00:25
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only  | 15:14:08
 perf-x86_64-penryn-O3  | 12:06:38
 clang-cmake-armv7-a15-selfhost | 11:04:31
 clang-cmake-mipsel | 10:49:21
 perf-x86_64-penryn-O3-polly| 10:36:54
 clang-x86-windows-msvc2015 | 09:25:23
 llvm-clang-x86_64-expensive-checks-win | 09:18:55
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast   | 09:01:11
 libcxx-libcxxabi-libunwind-aarch64-linux   | 08:43:12
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 08:20:05
 sanitizer-x86_64-linux-fast| 08:06:20
 sanitizer-ppc64be-linux| 08:02:19
 perf-x86_64-penryn-O3-polly-before-vectorizer  | 08:01:14
 clang-cmake-aarch64-full   | 07:06:55
 clang-cmake-armv7-a15-selfhost-neon| 06:53:09
 clang-cmake-mips   | 06:47:06
 sanitizer-x86_64-linux | 06:39:15
 perf-x86_64-penryn-O3-polly-parallel-fast  | 06:31:00
 sanitizer-x86_64-linux-bootstrap   | 06:24:43
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 06:05:44
 perf-x86_64-penryn-O3-polly-unprofitable   | 05:51:43
 llvm-mips-linux| 05:50:22
 clang-cmake-thumbv7-a15-full-sh| 05:41:46
 clang-ppc64be-linux-multistage | 05:33:48
 clang-cmake-aarch64-lld| 05:31:08
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 05:18:18
 perf-x86_64-penryn-O3-polly-fast   | 05:13:25
 polly-amd64-linux  | 05:05:36
 clang-native-arm-lnt   | 05:01:41
 clang-cmake-armv7-a15  | 04:56:45
 clang-cmake-aarch64-42vma  | 04:49:19
 libomp-gcc-x86_64-linux-debian | 04:24:54
 polly-arm-linux| 04:13:38
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan | 03:38:26
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan  | 03:37:44
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan  | 03:34:34
 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu | 03:30:54
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions  | 03:03:33
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z | 03:02:27
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 | 03:00:22
 clang-cmake-armv7-a15-full | 02:49:28
 lldb-windows7-android  | 02:45:27
 clang-cmake-thumbv7-a15| 02:45:26
 clang-x86_64-linux-selfhost-modules-2  | 02:41:11
 clang-ppc64le-linux| 02:35:20
 clang-cuda-build   | 02:31:10
 clang-cmake-aarch64-39vma  | 02:27:15
 clang-cmake-aarch64-quick 

Re: r300650 - [modules] Properly look up the owning module for an instantiation of a merged template.

[Richard Smith via cfe-commits]

On 18 April 2017 at 22:41, Chandler Carruth  wrote:

> Reverted in r300658.
>

For posterity, the above has an off-by-one error, the revert was r300659.


> On Tue, Apr 18, 2017 at 8:30 PM Chandler Carruth 
> wrote:
>
>> Consider code like the following:
>>
>> ```
>> #include 
>>
>> template 
>> class MyAllocator : public std::allocator {
>>  public:
>>   typedef std::allocator Alloc;
>>   typedef typename Alloc::pointer pointer;
>>   typedef typename Alloc::size_type size_type;
>>
>>   MyAllocator() {}
>>
>>   template 
>>   MyAllocator(const MyAllocator& x) : Alloc(x) {}
>>
>>   pointer allocate(size_type n,
>>std::allocator::const_pointer /*hint*/ =
>> nullptr) {
>> void* p = malloc(n * sizeof(T));
>> return static_cast(p);
>>   }
>>
>>   void deallocate(pointer p, size_type) { free(p); }
>>
>>   template 
>>   struct rebind {
>> typedef MyAllocator other;
>>   };
>>
>>  private:
>>   template 
>>   friend class MyAllocator;
>> };
>>
>> std::shared_ptr x = std::allocate_shared(MyAllocator(),
>> 0);
>> ```
>>
>> This will fail to compile against libstdc++ 4.9's alloc_traits.h, when
>> that header comes from a module, with an error message along the lines of:
>> .../bits/alloc_traits.h:197:2: error: too few template arguments for
>> class template '__alloctr_rebind'
>> using rebind_alloc = typename __alloctr_rebind<_Alloc,
>> _Tp>::__type;
>>
>> I think this is enough for you to debug, but let me know if not. I'm
>> going to revert this temporarily to unbreak our modules builds using this
>> version of libstdc++.
>>
>> On Tue, Apr 18, 2017 at 8:14 PM Chandler Carruth 
>> wrote:
>>
>>> This appears to break a pretty straightforward use of things like
>>> libstdc++'s __alloctr_rebind (undefined template with a default argument,
>>> specializations, etc):
>>> https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/
>>> libstdc++-v3/include/bits/alloc_traits.h#L58-L73
>>>
>>> At least, I'm getting errors from this. I'm working on a test case, but
>>> as usual, the test case may be... large.
>>>
>>> On Tue, Apr 18, 2017 at 6:49 PM Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: rsmith
 Date: Tue Apr 18 20:36:43 2017
 New Revision: 300650

 URL: http://llvm.org/viewvc/llvm-project?rev=300650=rev
 Log:
 [modules] Properly look up the owning module for an instantiation of a
 merged template.

 When looking for the template instantiation pattern of a templated
 entity,
 consistently select the definition of the pattern if there is one. This
 means
 we'll pick the same owning module when we start instantiating a
 template that
 we'll later pick when determining which modules are visible during that
 instantiation.

 Modified:
 cfe/trunk/lib/AST/Decl.cpp
 cfe/trunk/lib/AST/DeclCXX.cpp
 cfe/trunk/lib/Sema/SemaLookup.cpp
 cfe/trunk/test/Modules/Inputs/template-default-args/a.h
 cfe/trunk/test/Modules/template-default-args.cpp

 Modified: cfe/trunk/lib/AST/Decl.cpp
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/
 Decl.cpp?rev=300650=300649=300650=diff
 
 ==
 --- cfe/trunk/lib/AST/Decl.cpp (original)
 +++ cfe/trunk/lib/AST/Decl.cpp Tue Apr 18 20:36:43 2017
 @@ -2251,6 +2251,13 @@ bool VarDecl::checkInitIsICE() const {
return Eval->IsICE;
  }

 +template
 +static DeclT *getDefinitionOrSelf(DeclT *D) {
 +  if (auto *Def = D->getDefinition())
 +return Def;
 +  return D;
 +}
 +
  VarDecl *VarDecl::getTemplateInstantiationPattern() const {
// If it's a variable template specialization, find the template or
 partial
// specialization from which it was instantiated.
 @@ -2262,7 +2269,7 @@ VarDecl *VarDecl::getTemplateInstantiati
break;
  VTD = NewVTD;
}
 -  return VTD->getTemplatedDecl()->getDefinition();
 +  return getDefinitionOrSelf(VTD->getTemplatedDecl());
  }
  if (auto *VTPSD =
  From.dyn_cast()) {
 @@ -2271,7 +2278,7 @@ VarDecl *VarDecl::getTemplateInstantiati
break;
  VTPSD = NewVTPSD;
}
 -  return VTPSD->getDefinition();
 +  return getDefinitionOrSelf(VTPSD);
  }
}

 @@ -2280,23 +2287,18 @@ VarDecl *VarDecl::getTemplateInstantiati
VarDecl *VD = getInstantiatedFromStaticDataMember();
while (auto *NewVD = VD->getInstantiatedFromStaticDataMember())
  VD = NewVD;
 -  return VD->getDefinition();
 +  return getDefinitionOrSelf(VD);
  }
}

if (VarTemplateDecl *VarTemplate = getDescribedVarTemplate()) {
 -
  while 

[PATCH] D32329: [libc++abi] Disable libc++ extern templates project-wide

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
Herald added a subscriber: mgorny.

libc++abi can't depend on libc++, so disable extern templates in libc++
headers project-wide. This was previously done in cxa_demangle.cpp, but
I consider it more appropriate to do at the cmake level (since none of
libc++abi's source files can use libc++ extern templates).

I also think the _LIBCPP_NO_EXCEPTIONS in cxa_demangle.cpp is
suspicious, but I'm doing one thing at a time.


https://reviews.llvm.org/D32329

Files:
  CMakeLists.txt
  src/cxa_demangle.cpp


Index: src/cxa_demangle.cpp
===
--- src/cxa_demangle.cpp
+++ src/cxa_demangle.cpp
@@ -7,7 +7,6 @@
 //
 
//===--===//
 
-#define _LIBCPP_EXTERN_TEMPLATE(...)
 #define _LIBCPP_NO_EXCEPTIONS
 
 #include "__cxxabi_config.h"
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -453,6 +453,9 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 endif()
 
+# Prevent libc++abi from having library dependencies on libc++
+add_definitions(-D_LIBCPP_DISABLE_EXTERN_TEMPLATE)
+
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()


Index: src/cxa_demangle.cpp
===
--- src/cxa_demangle.cpp
+++ src/cxa_demangle.cpp
@@ -7,7 +7,6 @@
 //
 //===--===//
 
-#define _LIBCPP_EXTERN_TEMPLATE(...)
 #define _LIBCPP_NO_EXCEPTIONS
 
 #include "__cxxabi_config.h"
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -453,6 +453,9 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 endif()
 
+# Prevent libc++abi from having library dependencies on libc++
+add_definitions(-D_LIBCPP_DISABLE_EXTERN_TEMPLATE)
+
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r300921 - [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Apr 20 18:33:49 2017
New Revision: 300921

URL: http://llvm.org/viewvc/llvm-project?rev=300921=rev
Log:
[libc++] Default to vcruntime when targeting MSVC

Summary:
libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it
targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the
default ABI be vcruntime when targeting MSVC even if libc++abi is
present in the tree.

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

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=300921=300920=300921=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Thu Apr 20 18:33:49 2017
@@ -120,21 +120,19 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")


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

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300921: [libc++] Default to vcruntime when targeting MSVC 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D32320?vs=96055=96056#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32320

Files:
  libcxx/trunk/CMakeLists.txt


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 96055.
smeenai added a comment.

Reduce nesting (address comments)


https://reviews.llvm.org/D32320

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

Thanks for the review.  `__SIZE_MAX__` makes sense to me; and better even if 
not for the `#if` requirement.  I'll do that for both `SIZE_MAX` and 
`PTRDIFF_MAX` when I get a chance.




Comment at: clang/test/Preprocessor/stdint.c:1411
 // JOIN:PTRDIFF_MAX_ 2147483647
-// JOIN:SIZE_MAX_ 4294967295U
+// JOIN:SIZE_MAX_ ((unsigned a)4294967295U)
 // JOIN:INTMAX_MIN_ (-9223372036854775807LL -1)

rsmith wrote:
> Do we really define `__SIZE_TYPE__` to `unsigned a` for some target?
This testcase has a `#define int a` to confirm that we get `intmax_t` from our 
token pasting instead of `amax_t`.  `unsigned a` looks bogus, but I figure such 
a user is getting what they asked for.


https://reviews.llvm.org/D31856



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

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: CMakeLists.txt:119
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
+find_path(

EricWF wrote:
> Nit: I would rather see this be
> ```
> elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
> IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
> ```
> 
> That way we can avoid a level of nesting. 
Sounds good; will change before committing.


https://reviews.llvm.org/D32320



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

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Eric Fiselier via Phabricator via cfe-commits]

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

LGTM.




Comment at: CMakeLists.txt:119
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
+find_path(

Nit: I would rather see this be
```
elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
```

That way we can avoid a level of nesting. 


https://reviews.llvm.org/D32320



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

[PATCH] D32269: [Driver] Add iSOFTLinux to GNU ToolChains X86Triple

[Richard Smith via Phabricator via cfe-commits]

rsmith added a comment.

Please add some test coverage for these triples.


Repository:
  rL LLVM

https://reviews.llvm.org/D32269



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

[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

[Richard Smith via Phabricator via cfe-commits]

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

This is sadly not a correct change. The relevant requirements (C11 7.20.3/2) on 
these macros are:

> Each instance of these macros shall be replaced by a constant expression 
> suitable for use in `#if` preprocessing directives, and this expression shall 
> have the same type as would an expression that is an object of the 
> corresponding type converted according to the integer promotions.

The "suitable for use in `#if`" requirement means that you cannot use a cast, 
and must instead use a suitable numeric suffix.

Can we instead use `__SIZE_MAX__`? (And likewise for `ptrdiff_t` etc.)




Comment at: clang/test/Preprocessor/stdint.c:1411
 // JOIN:PTRDIFF_MAX_ 2147483647
-// JOIN:SIZE_MAX_ 4294967295U
+// JOIN:SIZE_MAX_ ((unsigned a)4294967295U)
 // JOIN:INTMAX_MIN_ (-9223372036854775807LL -1)

Do we really define `__SIZE_TYPE__` to `unsigned a` for some target?


https://reviews.llvm.org/D31856



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

[PATCH] D32231: [CMake] Enable ARM target in Fuchsia toolchain

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300917: [CMake] Enable ARM target in Fuchsia toolchain 
(authored by phosek).

Changed prior to commit:
  https://reviews.llvm.org/D32231?vs=95766=96048#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32231

Files:
  cfe/trunk/cmake/caches/Fuchsia-stage2.cmake


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -1,7 +1,7 @@
 # This file sets up a CMakeCache for the second stage of a Fuchsia toolchain
 # build.
 
-set(LLVM_TARGETS_TO_BUILD X86;AArch64 CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
@@ -36,6 +36,7 @@
 # Setup toolchain.
 set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "")
 set(LLVM_TOOLCHAIN_TOOLS
+  llc
   llvm-ar
   llvm-cov
   llvm-cxxfilt
@@ -49,6 +50,7 @@
   llvm-readobj
   llvm-size
   llvm-symbolizer
+  opt
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -1,7 +1,7 @@
 # This file sets up a CMakeCache for the second stage of a Fuchsia toolchain
 # build.
 
-set(LLVM_TARGETS_TO_BUILD X86;AArch64 CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
@@ -36,6 +36,7 @@
 # Setup toolchain.
 set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "")
 set(LLVM_TOOLCHAIN_TOOLS
+  llc
   llvm-ar
   llvm-cov
   llvm-cxxfilt
@@ -49,6 +50,7 @@
   llvm-readobj
   llvm-size
   llvm-symbolizer
+  opt
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r300919 - Use __CLANG_ATOMIC_TYPE_LOCK_FREE macros in `stdatomic.h`

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 18:07:38 2017
New Revision: 300919

URL: http://llvm.org/viewvc/llvm-project?rev=300919=rev
Log:
Use __CLANG_ATOMIC_TYPE_LOCK_FREE macros in `stdatomic.h`

Summary: This patch makes the header `stdatomic.h` work when 
`-fms-compatibility` is specified.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/Headers/stdatomic.h
cfe/trunk/test/Headers/stdatomic.c

Modified: cfe/trunk/lib/Headers/stdatomic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/stdatomic.h?rev=300919=300918=300919=diff
==
--- cfe/trunk/lib/Headers/stdatomic.h (original)
+++ cfe/trunk/lib/Headers/stdatomic.h Thu Apr 20 18:07:38 2017
@@ -40,16 +40,16 @@ extern "C" {
 
 /* 7.17.1 Introduction */
 
-#define ATOMIC_BOOL_LOCK_FREE   __GCC_ATOMIC_BOOL_LOCK_FREE
-#define ATOMIC_CHAR_LOCK_FREE   __GCC_ATOMIC_CHAR_LOCK_FREE
-#define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
-#define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
-#define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
-#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
-#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
-#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
-#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
+#define ATOMIC_BOOL_LOCK_FREE   __CLANG_ATOMIC_BOOL_LOCK_FREE
+#define ATOMIC_CHAR_LOCK_FREE   __CLANG_ATOMIC_CHAR_LOCK_FREE
+#define ATOMIC_CHAR16_T_LOCK_FREE   __CLANG_ATOMIC_CHAR16_T_LOCK_FREE
+#define ATOMIC_CHAR32_T_LOCK_FREE   __CLANG_ATOMIC_CHAR32_T_LOCK_FREE
+#define ATOMIC_WCHAR_T_LOCK_FREE__CLANG_ATOMIC_WCHAR_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __CLANG_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__CLANG_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __CLANG_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __CLANG_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__CLANG_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 

Modified: cfe/trunk/test/Headers/stdatomic.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/stdatomic.c?rev=300919=300918=300919=diff
==
--- cfe/trunk/test/Headers/stdatomic.c (original)
+++ cfe/trunk/test/Headers/stdatomic.c Thu Apr 20 18:07:38 2017
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c11 -E %s | FileCheck %s
+// RUN: %clang_cc1 -std=c11 -fms-compatibility -E %s | FileCheck %s
 #include 
 
 int bool_lock_free = ATOMIC_BOOL_LOCK_FREE;


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

r300917 - [CMake] Enable ARM target in Fuchsia toolchain

[Petr Hosek via cfe-commits]

Author: phosek
Date: Thu Apr 20 18:06:53 2017
New Revision: 300917

URL: http://llvm.org/viewvc/llvm-project?rev=300917=rev
Log:
[CMake] Enable ARM target in Fuchsia toolchain

This is still used by some users of Fuchsia toolchain. Also include
llc and opt which is useful for development and testing.

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

Modified:
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=300917=300916=300917=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Thu Apr 20 18:06:53 2017
@@ -1,7 +1,7 @@
 # This file sets up a CMakeCache for the second stage of a Fuchsia toolchain
 # build.
 
-set(LLVM_TARGETS_TO_BUILD X86;AArch64 CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
@@ -36,6 +36,7 @@ set(BUILTINS_aarch64-fuchsia-none_CMAKE_
 # Setup toolchain.
 set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "")
 set(LLVM_TOOLCHAIN_TOOLS
+  llc
   llvm-ar
   llvm-cov
   llvm-cxxfilt
@@ -49,6 +50,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-readobj
   llvm-size
   llvm-symbolizer
+  opt
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS


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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar updated this revision to Diff 96045.
kuhar added a comment.

After thinking about Piotr's comment, I think that a better way to perform the 
check would be te invoking clang-apply-replacements with `--version` and seeing 
if it fails even before running clang-tidy.
This way it is possible to save a lot of time when run-clang-tidy.py is run on 
a big project and apply_fixes fails at the end.

Let me know what you think about this approach.


https://reviews.llvm.org/D32294

Files:
  clang-tidy/tool/run-clang-tidy.py

Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -34,6 +34,7 @@
 http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 """
 
+from __future__ import print_function
 import argparse
 import json
 import multiprocessing
@@ -45,14 +46,15 @@
 import sys
 import tempfile
 import threading
+import traceback
 
 
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
   while not os.path.isfile(os.path.join(result, path)):
 if os.path.realpath(result) == '/':
-  print 'Error: could not find compilation database.'
+  print('Error: could not find compilation database.')
   sys.exit(1)
 result += '../'
   return os.path.realpath(result)
@@ -86,15 +88,24 @@
   start.append(f)
   return start
 
+def check_clang_apply_replacements_binary(args):
+  """Checks if invoking supplied clang-apply-replacements binary works."""
+  try:
+subprocess.check_call([args.clang_apply_replacements_binary, '--version'])
+  except:
+print('Unable to run clang-apply-replacements. Is clang-apply-replacements '
+  'binary correctly specified?', file=sys.stderr)
+traceback.print_exc()
+sys.exit(1)
+
 
 def apply_fixes(args, tmpdir):
   """Calls clang-apply-fixes on a given directory. Deletes the dir when done."""
   invocation = [args.clang_apply_replacements_binary]
   if args.format:
 invocation.append('-format')
   invocation.append(tmpdir)
   subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
@@ -164,9 +175,9 @@
 if args.checks:
   invocation.append('-checks=' + args.checks)
 invocation.append('-')
-print subprocess.check_output(invocation)
+print(subprocess.check_output(invocation))
   except:
-print >>sys.stderr, "Unable to run clang-tidy."
+print("Unable to run clang-tidy.", file=sys.stderr)
 sys.exit(1)
 
   # Load the database and extract all files.
@@ -179,6 +190,7 @@
 
   tmpdir = None
   if args.fix:
+check_clang_apply_replacements_binary(args)
 tmpdir = tempfile.mkdtemp()
 
   # Build up a big regexy filter from all command line arguments.
@@ -204,14 +216,25 @@
   except KeyboardInterrupt:
 # This is a sad hack. Unfortunately subprocess goes
 # bonkers with ctrl-c and we start forking merrily.
-print '\nCtrl-C detected, goodbye.'
+print('\nCtrl-C detected, goodbye.')
 if args.fix:
   shutil.rmtree(tmpdir)
 os.kill(0, 9)
 
   if args.fix:
-print 'Applying fixes ...'
-apply_fixes(args, tmpdir)
+print('Applying fixes ...')
+successfully_applied = True
+
+try:
+  apply_fixes(args, tmpdir)
+except:
+  successfully_applied = False
+  print('Error applying fixes.\n', file=sys.stderr)
+  traceback.print_exc()
+
+shutil.rmtree(tmpdir)
+if not successfully_applied:
+  sys.exit(1)
 
 if __name__ == '__main__':
   main()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32322: Use __CLANG_ATOMIC_TYPE_LOCK_FREE macros in `stdatomic.h`

[Eric Fiselier via Phabricator via cfe-commits]

EricWF created this revision.

This patch makes the header `stdatomic.h` work when `-fms-compatibility` is 
specified.


https://reviews.llvm.org/D32322

Files:
  lib/Headers/stdatomic.h
  test/Headers/stdatomic.c


Index: test/Headers/stdatomic.c
===
--- test/Headers/stdatomic.c
+++ test/Headers/stdatomic.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c11 -E %s | FileCheck %s
+// RUN: %clang_cc1 -std=c11 -fms-compatibility -E %s | FileCheck %s
 #include 
 
 int bool_lock_free = ATOMIC_BOOL_LOCK_FREE;
Index: lib/Headers/stdatomic.h
===
--- lib/Headers/stdatomic.h
+++ lib/Headers/stdatomic.h
@@ -40,16 +40,16 @@
 
 /* 7.17.1 Introduction */
 
-#define ATOMIC_BOOL_LOCK_FREE   __GCC_ATOMIC_BOOL_LOCK_FREE
-#define ATOMIC_CHAR_LOCK_FREE   __GCC_ATOMIC_CHAR_LOCK_FREE
-#define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
-#define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
-#define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
-#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
-#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
-#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
-#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
+#define ATOMIC_BOOL_LOCK_FREE   __CLANG_ATOMIC_BOOL_LOCK_FREE
+#define ATOMIC_CHAR_LOCK_FREE   __CLANG_ATOMIC_CHAR_LOCK_FREE
+#define ATOMIC_CHAR16_T_LOCK_FREE   __CLANG_ATOMIC_CHAR16_T_LOCK_FREE
+#define ATOMIC_CHAR32_T_LOCK_FREE   __CLANG_ATOMIC_CHAR32_T_LOCK_FREE
+#define ATOMIC_WCHAR_T_LOCK_FREE__CLANG_ATOMIC_WCHAR_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __CLANG_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__CLANG_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __CLANG_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __CLANG_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__CLANG_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 


Index: test/Headers/stdatomic.c
===
--- test/Headers/stdatomic.c
+++ test/Headers/stdatomic.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c11 -E %s | FileCheck %s
+// RUN: %clang_cc1 -std=c11 -fms-compatibility -E %s | FileCheck %s
 #include 
 
 int bool_lock_free = ATOMIC_BOOL_LOCK_FREE;
Index: lib/Headers/stdatomic.h
===
--- lib/Headers/stdatomic.h
+++ lib/Headers/stdatomic.h
@@ -40,16 +40,16 @@
 
 /* 7.17.1 Introduction */
 
-#define ATOMIC_BOOL_LOCK_FREE   __GCC_ATOMIC_BOOL_LOCK_FREE
-#define ATOMIC_CHAR_LOCK_FREE   __GCC_ATOMIC_CHAR_LOCK_FREE
-#define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
-#define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
-#define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
-#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
-#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
-#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
-#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
+#define ATOMIC_BOOL_LOCK_FREE   __CLANG_ATOMIC_BOOL_LOCK_FREE
+#define ATOMIC_CHAR_LOCK_FREE   __CLANG_ATOMIC_CHAR_LOCK_FREE
+#define ATOMIC_CHAR16_T_LOCK_FREE   __CLANG_ATOMIC_CHAR16_T_LOCK_FREE
+#define ATOMIC_CHAR32_T_LOCK_FREE   __CLANG_ATOMIC_CHAR32_T_LOCK_FREE
+#define ATOMIC_WCHAR_T_LOCK_FREE__CLANG_ATOMIC_WCHAR_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __CLANG_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__CLANG_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __CLANG_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __CLANG_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__CLANG_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 96043.
EricWF added a comment.

- Address inline comments.


https://reviews.llvm.org/D32265

Files:
  lib/Frontend/InitPreprocessor.cpp
  test/Preprocessor/init.c
  test/Sema/atomic-ops.c

Index: test/Sema/atomic-ops.c
===
--- test/Sema/atomic-ops.c
+++ test/Sema/atomic-ops.c
@@ -7,19 +7,29 @@
 struct S { char c[3]; };
 
 _Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == __CLANG_ATOMIC_BOOL_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == __CLANG_ATOMIC_CHAR_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == __CLANG_ATOMIC_CHAR16_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == __CLANG_ATOMIC_CHAR32_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == __CLANG_ATOMIC_WCHAR_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == __CLANG_ATOMIC_SHORT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == __CLANG_ATOMIC_INT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == __CLANG_ATOMIC_LONG_LOCK_FREE, "");
 #ifdef __i386__
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 1, "");
 #else
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 2, "");
 #endif
+_Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == __CLANG_ATOMIC_LLONG_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == __CLANG_ATOMIC_POINTER_LOCK_FREE, "");
 
 _Static_assert(__c11_atomic_is_lock_free(1), "");
 _Static_assert(__c11_atomic_is_lock_free(2), "");
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -8846,6 +8846,16 @@
 // WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY32-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9162,6 +9172,16 @@
 // WEBASSEMBLY64-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY64-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY64-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY64-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY64-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY64-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9637,3 +9657,36 @@
 // AVR:#define __WCHAR_MAX__ 32767
 // AVR:#define __WCHAR_TYPE__ int
 // AVR:#define __WINT_TYPE__ int
+
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple i686-windows-msvc -fms-compatibility < /dev/null \
+// RUN:  | FileCheck -match-full-lines -check-prefix MSVC-X32 %s
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple x86_64-windows-msvc -fms-compatibility < /dev/null \
+// RUN:  | FileCheck -match-full-lines -check-prefix MSVC-X64 %s
+
+// MSVC-X32:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// MSVC-X32-NEXT:#define 

r300914 - Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 17:53:57 2017
New Revision: 300914

URL: http://llvm.org/viewvc/llvm-project?rev=300914=rev
Log:
Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

Summary:
Libc++ currently implements the `ATOMIC__LOCK_FREE` macros using the 
`__GCC_ATOMIC__LOCK_FREE` macros. However these are not available when 
MSVC compatibility is enabled even though C11 `_Atomic` is.  This prevents 
libc++ from correctly implementing `ATOMIC__LOCK_FREE`.

This patch adds an alternative spelling `__CLANG_ATOMIC__LOCK_FREE` that 
is enabled with `-fms-compatibility`.

Reviewers: rsmith, aaron.ballman, majnemer, zturner, compnerd, jfb, rnk

Reviewed By: rsmith

Subscribers: BillyONeal, smeenai, jfb, cfe-commits, dschuff

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

Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp
cfe/trunk/test/Preprocessor/init.c
cfe/trunk/test/Sema/atomic-ops.c

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=300914=300913=300914=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Thu Apr 20 17:53:57 2017
@@ -882,14 +882,16 @@ static void InitializePredefinedMacros(c
 // The value written by __atomic_test_and_set.
 // FIXME: This is target-dependent.
 Builder.defineMacro("__GCC_ATOMIC_TEST_AND_SET_TRUEVAL", "1");
+  }
 
+  auto addLockFreeMacros = [&](const llvm::Twine ) {
 // Used by libc++ and 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 DEFINE_LOCK_FREE_MACRO(TYPE, Type) 
\
+  Builder.defineMacro(Prefix + #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);
@@ -899,12 +901,15 @@ static void InitializePredefinedMacros(c
 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",
+Builder.defineMacro(Prefix + "POINTER_LOCK_FREE",
 getLockFreeValue(TI.getPointerWidth(0),
  TI.getPointerAlign(0),
  InlineWidthBits));
 #undef DEFINE_LOCK_FREE_MACRO
-  }
+  };
+  addLockFreeMacros("__CLANG_ATOMIC_");
+  if (!LangOpts.MSVCCompat)
+addLockFreeMacros("__GCC_ATOMIC_");
 
   if (LangOpts.NoInlineDefine)
 Builder.defineMacro("__NO_INLINE__");

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=300914=300913=300914=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Thu Apr 20 17:53:57 2017
@@ -8846,6 +8846,16 @@
 // WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY32-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9162,6 +9172,16 @@
 // WEBASSEMBLY64-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY64-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY64-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define 

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
Herald added a subscriber: mgorny.

libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it
targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the
default ABI be vcruntime when targeting MSVC even if libc++abi is
present in the tree.


https://reviews.llvm.org/D32320

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -113,27 +113,29 @@
 
 # Setup the default options if LIBCXX_CXX_ABI is not specified.
 if (LIBCXX_CXX_ABI STREQUAL "default")
-  find_path(
-LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
-cxxabi.h
-PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
-  ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
-NO_DEFAULT_PATH
-  )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_INTREE 1)
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
+find_path(
+  LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
+  cxxabi.h
+  PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
+${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
+  NO_DEFAULT_PATH
+)
+if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
   set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
+  set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  set(LIBCXX_CXX_ABI_INTREE 1)
 else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
+  if (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
+  else()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
+  endif()
 endif()
   endif()
 else()


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -113,27 +113,29 @@
 
 # Setup the default options if LIBCXX_CXX_ABI is not specified.
 if (LIBCXX_CXX_ABI STREQUAL "default")
-  find_path(
-LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
-cxxabi.h
-PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
-  ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
-NO_DEFAULT_PATH
-  )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_INTREE 1)
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
+find_path(
+  LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
+  cxxabi.h
+  PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
+${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
+  NO_DEFAULT_PATH
+)
+if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
   set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
+  set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  set(LIBCXX_CXX_ABI_INTREE 1)
 else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
+  if (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
+  else()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
+  endif()
 endif()
   endif()
 else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Mehdi Amini via cfe-commits]

> On Apr 20, 2017, at 12:30 PM, Eric Fiselier  wrote:
> 
> 
> 
> On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini  > wrote:
> 
>> On Apr 20, 2017, at 12:39 AM, Eric Fiselier > > wrote:
>> 
>> 
>> 
>> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini > > wrote:
>> What would be the status of these buildbots? Is it for your private usage? 
>> 
>> I intend for them to be public Windows buildbots for libc++.
> 
> 
> I’m not sure it’d be OK to send blame email to contributors based on this 
> though.
> 
> I don't see why not (at least once the bot is stable). Can you elaborate?

I don’t think there is a precedent for having a bot that does not checkout from 
SVN and email using the canonical SVN revision number.

So it does not seems like a given to me  (not that I’m against it) and would 
require a discussion on the mailing-list first IMO.

— 
Mehdi




>  
> /Eric
> 
> 
> — 
> Mehdi
> 
> 
>> 
>> Otherwise having “project' bots” using a non-official mirror may sound like 
>> a strange situation to me.
>> 
>> I agree it isn't ideal, but when/if LLVM moves to github it will be trivial 
>> to re-configure for the official repositories.
>> I considered a number of other ways to setup Appveyor but I concluded this 
>> was the best/easiest way to do it.
>> The other options I considered for configuring Appveyor are:
>> 
>> (1) Use the official LLVM github mirrors.
>>  
>> This has the issue of requiring the implementation of custom Git webhooks, 
>> which would require
>> modifying and maintaining changes to the existing LLVM Git infrastructure, 
>> which in itself
>> would require getting access to the LLVM servers to make the changes.
>> 
>> (2) Setup my own ever more unofficial github mirror 
>> 
>> This has all the same problems as using the existing github mirrors but it 
>> requires
>> me to configure and maintain my own mirror, which is non-trivial.
>> 
>> (3) Don't use Appveyor at all
>> 
>> This requires finding Windows hardware to host the bots, which is the main 
>> reason
>> I chose Appveyor to begin with. Even if hardware was available I would 
>> prefer using
>> Appveyor since it provides more dominion over the environment than I think
>> donated hardware could.
>> 
>> /Eric
>> 
>> 
>> — 
>> Mehdi
>> 
>>> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev 
>>> > wrote:
>>> 
>>> Adding cfe-dev list...
>>> 
>>> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier >> > wrote:
>>> Hi Will,
>>> 
>>> I would like to request collaborator permissions for the Libc++ github 
>>> mirror.
>>> 
>>> I plan to use the access to setup Appveyor buildbots for libc++. In order 
>>> to do this I need to be listed as a collaborator on Github. 
>>> 
>>> The alternative to Github access would be setting up the correct webhooks 
>>> for llvm.org/git/libcxx.git , but this 
>>> seems harder to both do and maintain.
>>> 
>>> /Eric
>>> 
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
>>> 
>> 
>> 
> 
> 

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

r300909 - Sema: protect against ObjC++ typo-correction failure

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Thu Apr 20 17:23:10 2017
New Revision: 300909

URL: http://llvm.org/viewvc/llvm-project?rev=300909=rev
Log:
Sema: protect against ObjC++ typo-correction failure

ObjC++ has two different types of "pointer" types (ObjCClassPointerType
and PointerType).  Both can be indirected through.  However, the former
is not a member expression.  Ensure that we do not try to rebuild the
MRE in that case.

Added:
cfe/trunk/test/SemaObjCXX/pr32725.mm
Modified:
cfe/trunk/lib/Sema/TreeTransform.h

Modified: cfe/trunk/lib/Sema/TreeTransform.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/TreeTransform.h?rev=300909=300908=300909=diff
==
--- cfe/trunk/lib/Sema/TreeTransform.h (original)
+++ cfe/trunk/lib/Sema/TreeTransform.h Thu Apr 20 17:23:10 2017
@@ -2220,6 +2220,9 @@ public:
 Base = BaseResult.get();
 QualType BaseType = Base->getType();
 
+if (isArrow && !BaseType->isPointerType())
+  return ExprError();
+
 // FIXME: this involves duplicating earlier analysis in a lot of
 // cases; we should avoid this when possible.
 LookupResult R(getSema(), MemberNameInfo, Sema::LookupMemberName);

Added: cfe/trunk/test/SemaObjCXX/pr32725.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjCXX/pr32725.mm?rev=300909=auto
==
--- cfe/trunk/test/SemaObjCXX/pr32725.mm (added)
+++ cfe/trunk/test/SemaObjCXX/pr32725.mm Thu Apr 20 17:23:10 2017
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx -fsyntax-only -verify -x 
objective-c++ %s -o /dev/null
+// REQUIRES: asserts
+
+struct objc_class {
+  unsigned long long bits;
+};
+typedef struct objc_class *Class;
+static void f(Class c) { (void)(c->bits & RW_HAS_OVERFLOW_REFCOUNT); }
+// expected-error@-1{{use of undeclared identifier 'RW_HAS_OVERFLOW_REFCOUNT}}


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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Richard Smith via Phabricator via cfe-commits]

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

I'm not thrilled about adding yet more predefined macros, but it really doesn't 
make sense for libc++ to depend on `__GCC_*` macros when targeting Windows, nor 
for these to be Windows-only, so let's do it.




Comment at: lib/Frontend/InitPreprocessor.cpp:910-912
+  addLockFreeMacros("__CLANG_ATOMIC");
+  if (!LangOpts.MSVCCompat)
+addLockFreeMacros("__GCC_ATOMIC");

I'd sink the `_` into the prefix too, but this looks fine either way.


https://reviews.llvm.org/D32265



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

r300908 - Parse: cleanup some bleeding whitespace

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Thu Apr 20 17:23:07 2017
New Revision: 300908

URL: http://llvm.org/viewvc/llvm-project?rev=300908=rev
Log:
Parse: cleanup some bleeding whitespace

Clean up some bleeding whitespace that I noticed.  NFC

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

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=300908=300907=300908=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Thu Apr 20 17:23:07 2017
@@ -339,7 +339,7 @@ Parser::ParseRHSOfBinaryExpression(ExprR
 ColonLoc = Tok.getLocation();
   }
 }
-
+
 // Code completion for the right-hand side of an assignment expression
 // goes through a special hook that takes the left-hand side into account.
 if (Tok.is(tok::code_completion) && NextTokPrec == prec::Assignment) {
@@ -347,7 +347,7 @@ Parser::ParseRHSOfBinaryExpression(ExprR
   cutOffParsing();
   return ExprError();
 }
-
+
 // Parse another leaf here for the RHS of the operator.
 // ParseCastExpression works here because all RHS expressions in C have it
 // as a prefix, at least. However, in C++, an assignment-expression could
@@ -456,6 +456,7 @@ Parser::ParseRHSOfBinaryExpression(ExprR
   if (!getLangOpts().CPlusPlus)
 continue;
 }
+
 // Ensure potential typos aren't left undiagnosed.
 if (LHS.isInvalid()) {
   Actions.CorrectDelayedTyposInExpr(OrigLHS);


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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Piotr Padlewski via Phabricator via cfe-commits]

Prazek accepted this revision.
Prazek added a comment.

LGTM, but please leave the FIXME comment about the running of apply replacement


https://reviews.llvm.org/D32294



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

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Richard Smith via Phabricator via cfe-commits]

rsmith added a comment.

In https://reviews.llvm.org/D32199#732189, @hfinkel wrote:

> In https://reviews.llvm.org/D32199#731472, @rsmith wrote:
>
> > 1. C's "effective type" rule allows writes to set the type pretty much 
> > unconditionally, unless the storage is for a variable with a declared type
>
>
> To come back to this point: We don't really implement these rules now, and it 
> is not clear that we will. The problem here is that, if we take the 
> specification literally, then we can't use our current TBAA at all. The 
> problem is that if we have:
>
>   write x, !tbaa "int"
>   read x, !tbaa "int"
>   write x, !tbaa "float"
>   
>
> TBAA will currently tell us that the "float" write aliases with neither the 
> preceding read nor the preceding write.


Right, C's TBAA rules do not (in general) permit a store to be reordered before 
a memory operation of a different type, they only allow loads to be moved 
before stores. (Put another way, they do not tell you that pointers point to 
distinct memory locations, just that a stored value cannot be observed by a 
load of a different type.) You get the more general "distinct memory locations" 
result only for objects of a declared type.

C++ is similar, except that (because object lifetimes do not currently begin 
magically due to a store) you /can/ reorder stores past a memory operation of a 
different type if you know no object's lifetime began in between. (But 
currently we do not record all lifetime events in IR, so we can't do that 
today. Also, we may be about to lose the property that you can statically 
determine a small number of places that might start an object lifetime.)

> Also, a strict reading of C's access rules seems to rule out the premise 
> underlying our struct-path TBAA entirely. So long as I'm accessing a value 
> using a struct that has some member, including recursively, with that type, 
> then it's fine. The matching of the relative offsets is a sufficient, but not 
> necessary, condition for well-defined access. C++ has essentially the same 
> language (and, thus, potentially the same problem).

I agree this rule is garbage, but it's not as permissive as I think you're 
suggesting. The rule says that you can use an lvalue of struct type to access 
memory of struct field type. In C this happens during struct assignment, for 
instance. It does *not* permit using an lvalue of struct field type to access 
unrelated fields of the same struct. So C appears to allow this nonsense:

  char *p = malloc(8);
  *(int*)p = 0;
  *(int*)(p + 4) = 0;
  struct S {int n; float f;} s = *(struct S*)p; // use lvalue of type `struct 
S` to access object of effective type `int`, to initialize a `float`

but not this nonsense:

  float q = ((struct S*)p)->f; // ub, cannot use lvalue of type `float` to 
access object of effective type `int`

... which just means that we can't make much use of TBAA when emitting struct 
copies in C.

In C++, on the other hand, the rule is even more garbage, since there is no way 
to perform a memory access with a glvalue of class type. (The closest you get 
is that a defaulted union construction/assignment copies the object 
representation, but that's expressed in terms of copying a sequence of unsigned 
chars, and in any case those are member functions and so already require an 
object of the correct type to exist.) See wg21.link/cwg2051

> While I'd like the sanitizer to follow the rules, that's really useful only 
> to the extent that the compilers follow the rules. If the compilers are 
> making stronger assumptions, then I think that the sanitizer should also.

I agree.

>> If we want to follow the relevant language rules by default, that would 
>> suggest that "writes always set the type" should be enabled by default in C 
>> and disabled by default in C++. That may not be the right decision for other 
>> reasons, though. In C++, writes through union members and new-expressions 
>> should probably (re)set the type (do you have intrinsics the frontend can 
>> use to do so?).
> 
> Also, in C, memcpy gets to copy the type for a destination that does not have 
> declared types. It looks like the same is true for C++ for trivially-copyable 
> types. Is the first read/write sets the unknown type (i.e. memory from 
> malloc/calloc/memset, etc.) correct for C++ also?

As I recall, "store can create an object" is the broad direction that SG12 
agreed on for the cases where you have a pointer into a raw storage buffer 
(that is, a char array), and we want the low-level storage allocation functions 
to give us such a buffer.


https://reviews.llvm.org/D32199



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

[PATCH] D32313: [clang-tidy] Don't turn .push_back({1, 2}) into .emplace_back(1, 2) for pairs

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar created this revision.
kuhar added a project: clang-tools-extra.

This patch prevents modernize-use-emplace from changing push_backs of brace 
initialized pairs (`.push_back({1, 2})`) to `.emplace_back(1, 2)`.
Pair's constructor doesn't have any interesting logic and basically performs 
aggregate initialization. There also doesn't seem to be much win
in terms of making code more concise, thus is makes little sense to turn such 
push_back calls into emplace_backs.

The change is inspired by the recent discussion on changing and enforcing 
coding guidelines:
[llvm-dev] [cfe-dev] Modernizing LLVM Coding Style Guide andenforcing 
Clang-tidy
http://lists.llvm.org/pipermail/llvm-dev/2016-December/108559.html


https://reviews.llvm.org/D32313

Files:
  clang-tidy/modernize/UseEmplaceCheck.cpp
  clang-tidy/modernize/UseEmplaceCheck.h
  test/clang-tidy/modernize-use-emplace.cpp


Index: test/clang-tidy/modernize-use-emplace.cpp
===
--- test/clang-tidy/modernize-use-emplace.cpp
+++ test/clang-tidy/modernize-use-emplace.cpp
@@ -186,6 +186,11 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
   // CHECK-FIXES: v.emplace_back(1, 2);
 
+  v.push_back({1, 2});
+  v.push_back(std::pair{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(1, 2);
+
   GetPair g;
   v.push_back(g.getPair());
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
Index: clang-tidy/modernize/UseEmplaceCheck.h
===
--- clang-tidy/modernize/UseEmplaceCheck.h
+++ clang-tidy/modernize/UseEmplaceCheck.h
@@ -35,6 +35,7 @@
 private:
   std::vector ContainersWithPushBack;
   std::vector SmartPointers;
+  std::vector PairTypes;
 };
 
 } // namespace modernize
Index: clang-tidy/modernize/UseEmplaceCheck.cpp
===
--- clang-tidy/modernize/UseEmplaceCheck.cpp
+++ clang-tidy/modernize/UseEmplaceCheck.cpp
@@ -19,13 +19,16 @@
 "::std::vector; ::std::list; ::std::deque";
 static const auto DefaultSmartPointers =
 "::std::shared_ptr; ::std::unique_ptr; ::std::auto_ptr; ::std::weak_ptr";
+static const auto DefaultPairTypes = "::std::pair";
 
 UseEmplaceCheck::UseEmplaceCheck(StringRef Name, ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
   ContainersWithPushBack(utils::options::parseStringList(Options.get(
   "ContainersWithPushBack", DefaultContainersWithPushBack))),
   SmartPointers(utils::options::parseStringList(
-  Options.get("SmartPointers", DefaultSmartPointers))) {}
+  Options.get("SmartPointers", DefaultSmartPointers))),
+  PairTypes(utils::options::parseStringList(
+  Options.get("PairTypes", DefaultPairTypes))) {}
 
 void UseEmplaceCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus11)
@@ -72,11 +75,19 @@
   auto hasInitList = has(ignoringImplicit(initListExpr()));
   // FIXME: Discard 0/NULL (as nullptr), static inline const data members,
   // overloaded functions and template names.
+
+  // Ignore push_back({first, second}) for pair types (eg. std::pair).
+  auto isPairBraceInit = expr(allOf(cxxConstructExpr(hasDeclaration(
+  cxxConstructorDecl(ofClass(hasAnyName(SmallVector(
+  PairTypes.begin(), PairTypes.end())),
+unless(cxxTemporaryObjectExpr())),
+  unless(hasParent(implicitCastExpr(;
+
   auto soughtConstructExpr =
   cxxConstructExpr(
   unless(anyOf(isCtorOfSmartPtr, hasInitList, bitFieldAsArgument,
initializerListAsArgument, newExprAsArgument,
-   constructingDerived, isPrivateCtor)))
+   constructingDerived, isPrivateCtor, isPairBraceInit)))
   .bind("ctor");
   auto hasConstructExpr = has(ignoringImplicit(soughtConstructExpr));
 


Index: test/clang-tidy/modernize-use-emplace.cpp
===
--- test/clang-tidy/modernize-use-emplace.cpp
+++ test/clang-tidy/modernize-use-emplace.cpp
@@ -186,6 +186,11 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
   // CHECK-FIXES: v.emplace_back(1, 2);
 
+  v.push_back({1, 2});
+  v.push_back(std::pair{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(1, 2);
+
   GetPair g;
   v.push_back(g.getPair());
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
Index: clang-tidy/modernize/UseEmplaceCheck.h
===
--- clang-tidy/modernize/UseEmplaceCheck.h
+++ clang-tidy/modernize/UseEmplaceCheck.h
@@ -35,6 +35,7 @@
 private:
   std::vector ContainersWithPushBack;
   std::vector SmartPointers;
+  std::vector PairTypes;
 };
 
 } // namespace 

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

In https://reviews.llvm.org/D32265#731709, @jfb wrote:

> Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL 
> implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't seem to 
> have anything ? Presumably they'll have to do 
> *something*.


Our STL implements  entirely as a library feature (on top of the 
_InterlockedXxx intrinsics and alignas).


https://reviews.llvm.org/D32265



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

[PATCH] D30773: Make git-clang-format python 3 compatible

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 96025.
EricWF added a comment.

I've committed all but the `str` vs `byte` changes upstream.


https://reviews.llvm.org/D30773

Files:
  tools/clang-format/git-clang-format


Index: tools/clang-format/git-clang-format
===
--- tools/clang-format/git-clang-format
+++ tools/clang-format/git-clang-format
@@ -20,7 +20,7 @@
 For further details, run:  
  
 git clang-format -h
  

  
-Requires Python 2.7
  
+Requires Python 2.7 or Python 3
  
 """   
 
 from __future__ import print_function
@@ -258,7 +258,7 @@
   stdout, stderr = p.communicate()
   if p.returncode != 0:
 return None
-  return stdout.strip()
+  return convert_string(stdout.strip())
 
 
 def compute_diff_and_extract_lines(commits, files):
@@ -301,6 +301,7 @@
   list of line `Range`s."""
   matches = {}
   for line in patch_file:
+line = convert_string(line)
 match = re.search(r'^\+\+\+\ [^/]+/(.*)', line)
 if match:
   filename = match.group(1).rstrip('\r\n')
@@ -385,7 +386,7 @@
   with temporary_index_file():
 p = subprocess.Popen(cmd, stdin=subprocess.PIPE)
 for line in input_lines:
-  p.stdin.write('%s\0' % line)
+  p.stdin.write(to_bytes('%s\0' % line))
 p.stdin.close()
 if p.wait() != 0:
   die('`%s` failed' % ' '.join(cmd))
@@ -440,7 +441,7 @@
 die('`%s` failed' % ' '.join(clang_format_cmd))
   if git_show and git_show.wait() != 0:
 die('`%s` failed' % ' '.join(git_show_cmd))
-  return stdout.rstrip('\r\n')
+  return convert_string(stdout).rstrip('\r\n')
 
 
 @contextlib.contextmanager
@@ -527,6 +528,10 @@
   p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
stdin=subprocess.PIPE)
   stdout, stderr = p.communicate(input=stdin)
+
+  stdout = convert_string(stdout)
+  stderr = convert_string(stderr)
+
   if p.returncode == 0:
 if stderr:
   if verbose:
@@ -547,5 +552,26 @@
   sys.exit(2)
 
 
+def to_bytes(str_input):
+# Encode to UTF-8 to get binary data.
+if isinstance(str_input, bytes):
+return str_input
+return str_input.encode('utf-8')
+
+
+def to_string(bytes_input):
+if isinstance(bytes_input, str):
+return bytes_input
+return bytes_input.encode('utf-8')
+
+
+def convert_string(bytes_input):
+try:
+return to_string(bytes_input.decode('utf-8'))
+except AttributeError: # 'str' object has no attribute 'decode'.
+return str(bytes_input)
+except UnicodeError:
+return str(bytes_input)
+
 if __name__ == '__main__':
   main()


Index: tools/clang-format/git-clang-format
===
--- tools/clang-format/git-clang-format
+++ tools/clang-format/git-clang-format
@@ -20,7 +20,7 @@
 For further details, run:
 git clang-format -h  
  
-Requires Python 2.7  
+Requires Python 2.7 or Python 3  
 """   
 
 from __future__ import print_function
@@ -258,7 +258,7 @@
   stdout, stderr = p.communicate()
   if p.returncode != 0:
 return None
-  return stdout.strip()
+  return convert_string(stdout.strip())
 
 
 def compute_diff_and_extract_lines(commits, files):
@@ -301,6 +301,7 @@
   list of line `Range`s."""
   matches = {}
   for line in patch_file:
+line = convert_string(line)
 match = re.search(r'^\+\+\+\ [^/]+/(.*)', line)
 if match:
   filename = match.group(1).rstrip('\r\n')
@@ -385,7 +386,7 @@
   with temporary_index_file():
 p = subprocess.Popen(cmd, stdin=subprocess.PIPE)
 for line in input_lines:
-  p.stdin.write('%s\0' % line)
+  p.stdin.write(to_bytes('%s\0' % line))
 p.stdin.close()
 if p.wait() != 0:
   die('`%s` failed' % ' '.join(cmd))
@@ -440,7 +441,7 @@
 die('`%s` failed' % ' '.join(clang_format_cmd))
   if git_show and git_show.wait() != 0:
 die('`%s` failed' % ' '.join(git_show_cmd))
-  return stdout.rstrip('\r\n')
+  return convert_string(stdout).rstrip('\r\n')
 
 
 @contextlib.contextmanager
@@ -527,6 +528,10 @@
   p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
stdin=subprocess.PIPE)
   stdout, stderr = p.communicate(input=stdin)
+
+  stdout = convert_string(stdout)
+  stderr = convert_string(stderr)
+
   if p.returncode == 0:
 if stderr:
   if verbose:
@@ -547,5 +552,26 

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

(sorry for double post)

And of course since you folks don't care about supporting pre-Vista you 
probably also don't care about supporting Opterons from 2005, in which case 
you'd want unconditional cmpxchg16b on amd64 :). In our next major version I 
added a configuration macro `_STD_ATOMIC_ALWAYS_USE_CMPXCHG16B` users can set 
to ask for that.


https://reviews.llvm.org/D32265



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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

In https://reviews.llvm.org/D32265#732649, @jfb wrote:

> In https://reviews.llvm.org/D32265#731710, @EricWF wrote:
>
> > In https://reviews.llvm.org/D32265#731709, @jfb wrote:
> >
> > > Is it a goal to support Microsoft's STL with this? If so, how does MSVC's 
> > > STL implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't 
> > > seem to have anything ? Presumably they'll 
> > > have to do *something*.
> >
> >
> > The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on 
> > Windows using Clang. As you know libc++ currently uses the 
> > `__GCC_ATOMIC_FOO` macros, but those aren't available on Windows.
>
>
> OK so it's just a hygiene question of blanket-avoiding `__GCC_*` macros in 
> clang-ms mode, but using `__CLANG_*` macros are OK? That sounds fine then. 
> Would you all-out switch libc++ to use `__CLANG_*` then?


`__CLANG` macros are fine on libc++'s end; So as long as they're not uncouth 
for Clang it should be OK.

I would switch libc++ to do

  #ifdef __CLANG_ATOMIC_FOO
  # define ATOMIC_FOO __CLANG_ATOMIC_FOO
  # define ATOMIC_BAR __CLANG_ATOMIC_BAR
  #else
  # define ATOMIC_FOO __GCC_ATOMIC_FOO
  ...
  #endif



> 
> 
>> Also AFAIK MSVC leaves the implementation of atomics up to the library, not 
>> the frontend. So W/E MSVC's STL does it's likely not sane or desirable.
> 
> Wait what? How does that even work? This calls for a Twitter ping of Billy!




https://reviews.llvm.org/D32265



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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

In https://reviews.llvm.org/D32265#732657, @jfb wrote:

> It looks like Billy is going to do something somewhat similar when he 
> rewrites it: https://twitter.com/jfbastien/status/855168230918307840
>  For now it's kinda `#define IS_LOCK_FREE ¯\_(ツ)_/¯`


Note that my rewrite of our  didn't touch the XXX_IS_LOCK_FREE macros. 
All of those for both implementations are hardcoded to 2 since any piece of 
hardware we ever plan to support has lock free ops for all those. I did add 
conditional DCAS support for amd64 though in v.Next.

Billy3


https://reviews.llvm.org/D32265



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

r300895 - Fix Python 2 vs 3 incompatability with dict.items() vs iteritems()

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 16:23:58 2017
New Revision: 300895

URL: http://llvm.org/viewvc/llvm-project?rev=300895=rev
Log:
Fix Python 2 vs 3 incompatability with dict.items() vs iteritems()

Modified:
cfe/trunk/tools/clang-format/git-clang-format

Modified: cfe/trunk/tools/clang-format/git-clang-format
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/git-clang-format?rev=300895=300894=300895=diff
==
--- cfe/trunk/tools/clang-format/git-clang-format (original)
+++ cfe/trunk/tools/clang-format/git-clang-format Thu Apr 20 16:23:58 2017
@@ -345,8 +345,13 @@ def run_clang_format_and_save_to_tree(ch
   """Run clang-format on each file and save the result to a git tree.
 
   Returns the object ID (SHA-1) of the created tree."""
+  def iteritems(container):
+  try:
+  return container.iteritems() # Python 2
+  except AttributeError:
+  return container.items() # Python 3
   def index_info_generator():
-for filename, line_ranges in changed_lines.viewitems():
+for filename, line_ranges in iteritems(changed_lines):
   if revision:
 git_metadata_cmd = ['git', 'ls-tree',
 '%s:%s' % (revision, os.path.dirname(filename)),


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

[PATCH] D32192: Enable leak sanitizer builds for darwin

[Francis Ricci via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300894: Enable leak sanitizer builds for darwin (authored by 
fjricci).

Changed prior to commit:
  https://reviews.llvm.org/D32192?vs=95986=96019#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32192

Files:
  cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
  cfe/trunk/test/Driver/fsanitize.c
  cfe/trunk/test/Driver/sanitizer-ld.c


Index: cfe/trunk/test/Driver/sanitizer-ld.c
===
--- cfe/trunk/test/Driver/sanitizer-ld.c
+++ cfe/trunk/test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=safe-stack \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: cfe/trunk/test/Driver/fsanitize.c
===
--- cfe/trunk/test/Driver/fsanitize.c
+++ cfe/trunk/test/Driver/fsanitize.c
@@ -358,6 +358,27 @@
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 
'i386-pc-openbsd'
 
+// RUN: %clang -target x86_64-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-X86-64-DARWIN
+// CHECK-LSAN-X86-64-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-iossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-IOSSIMULATOR
+// CHECK-LSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-tvossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-TVOSSIMULATOR
+// CHECK-LSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-DARWIN
+// CHECK-LSAN-I386-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target arm-apple-ios -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LSAN-ARM-IOS
+// CHECK-LSAN-ARM-IOS-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-iossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-IOSSIMULATOR
+// CHECK-LSAN-I386-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-tvossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-TVOSSIMULATOR
+// CHECK-LSAN-I386-TVOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-cache-frag %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-working-set %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // CHECK-ESAN-X86: error: unsupported option '-fsanitize=efficiency-{{.*}}' 
for target 'i686--linux-gnu'
Index: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
@@ -1035,6 +1035,8 @@
   const SanitizerArgs  = getSanitizerArgs();
   if (Sanitize.needsAsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+  if (Sanitize.needsLsanRt())
+AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
   if (Sanitize.needsUbsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "ubsan");
   if (Sanitize.needsTsanRt())
@@ -1892,6 +1894,7 @@
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::Leak;
   if (isTargetMacOS()) {
 if (!isMacosxVersionLT(10, 9))
   Res |= SanitizerKind::Vptr;


Index: cfe/trunk/test/Driver/sanitizer-ld.c
===
--- cfe/trunk/test/Driver/sanitizer-ld.c
+++ cfe/trunk/test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck 

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

It looks like Billy is going to do something somewhat similar when he rewrites 
it: https://twitter.com/jfbastien/status/855168230918307840
For now it's kinda `#define IS_LOCK_FREE ¯\_(ツ)_/¯`


https://reviews.llvm.org/D32265



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

r300891 - Begin making git-clang-format python3 compatible.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 16:05:58 2017
New Revision: 300891

URL: http://llvm.org/viewvc/llvm-project?rev=300891=rev
Log:
Begin making git-clang-format python3 compatible.

This patch fixes most of the python3 incompatabilities
within git-clang-format while keeping the script python2 compatible.
There is still one remaining incompatability that prevents using Python3
which is the `str` vs `byte` type change. I plan to put those fixes
up for review separately.

This patch contains fixes for the following incompatabilities:

1) Use the new style Python3 `print` function. This requires importing
   __future__.print_function.

2) Fix incompatability between the Python3 octal prefix and the
   octal prefix Git uses.

3) Replace use of dict.iteritems() with dict.viewitems() because iteritems()
   has been removed in Python3. viewitems() reviews python 2.7 but that is
   also what the script is documented as requiring.

Modified:
cfe/trunk/tools/clang-format/git-clang-format

Modified: cfe/trunk/tools/clang-format/git-clang-format
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/git-clang-format?rev=300891=300890=300891=diff
==
--- cfe/trunk/tools/clang-format/git-clang-format (original)
+++ cfe/trunk/tools/clang-format/git-clang-format Thu Apr 20 16:05:58 2017
@@ -23,6 +23,7 @@ git clang-format -h
 Requires Python 2.7
  
 """   
 
+from __future__ import print_function
 import argparse
 import collections
 import contextlib
@@ -138,15 +139,15 @@ def main():
   if opts.verbose >= 1:
 ignored_files.difference_update(changed_lines)
 if ignored_files:
-  print 'Ignoring changes in the following files (wrong extension):'
+  print('Ignoring changes in the following files (wrong extension):')
   for filename in ignored_files:
-print '   ', filename
+print('%s' % filename)
 if changed_lines:
-  print 'Running clang-format on the following files:'
+  print('Running clang-format on the following files:')
   for filename in changed_lines:
-print '   ', filename
+print('%s' % filename)
   if not changed_lines:
-print 'no modified files to format'
+print('no modified files to format')
 return
   # The computed diff outputs absolute paths, so we must cd before accessing
   # those files.
@@ -163,20 +164,20 @@ def main():
  binary=opts.binary,
  style=opts.style)
   if opts.verbose >= 1:
-print 'old tree:', old_tree
-print 'new tree:', new_tree
+print('old tree: %s' % old_tree)
+print('new tree: %s' % new_tree)
   if old_tree == new_tree:
 if opts.verbose >= 0:
-  print 'clang-format did not modify any files'
+  print('clang-format did not modify any files')
   elif opts.diff:
 print_diff(old_tree, new_tree)
   else:
 changed_files = apply_changes(old_tree, new_tree, force=opts.force,
   patch_mode=opts.patch)
 if (opts.verbose >= 0 and not opts.patch) or opts.verbose >= 1:
-  print 'changed files:'
+  print('changed files:')
   for filename in changed_files:
-print '   ', filename
+print('%s' % filename)
 
 
 def load_git_config(non_string_options=None):
@@ -320,7 +321,7 @@ def filter_by_extension(dictionary, allo
   `allowed_extensions` must be a collection of lowercase file extensions,
   excluding the period."""
   allowed_extensions = frozenset(allowed_extensions)
-  for filename in dictionary.keys():
+  for filename in list(dictionary.keys()):
 base_ext = filename.rsplit('.', 1)
 if len(base_ext) == 1 or base_ext[1].lower() not in allowed_extensions:
   del dictionary[filename]
@@ -345,7 +346,7 @@ def run_clang_format_and_save_to_tree(ch
 
   Returns the object ID (SHA-1) of the created tree."""
   def index_info_generator():
-for filename, line_ranges in changed_lines.iteritems():
+for filename, line_ranges in changed_lines.viewitems():
   if revision:
 git_metadata_cmd = ['git', 'ls-tree',
 '%s:%s' % (revision, os.path.dirname(filename)),
@@ -356,6 +357,9 @@ def run_clang_format_and_save_to_tree(ch
 mode = oct(int(stdout.split()[0], 8))
   else:
 mode = oct(os.stat(filename).st_mode)
+  # Adjust python3 octal format so that it matches what git expects
+  if mode.startswith('0o'):
+  mode = '0' + mode[2:]
   blob_id = clang_format_to_blob(filename, line_ranges,
  revision=revision,
  binary=binary,
@@ -488,10 +492,10 @@ def apply_changes(old_tree, new_tree, fo
   if not force:
 unstaged_files = run('git', 'diff-files', '--name-status', *changed_files)
 if unstaged_files:
-  

[PATCH] D32291: [analyzer] Implement handling array subscript into null pointer, improve null dereference checks for array subscripts

[Gábor Horváth via Phabricator via cfe-commits]

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

LGTM!


https://reviews.llvm.org/D32291



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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In https://reviews.llvm.org/D32265#731710, @EricWF wrote:

> In https://reviews.llvm.org/D32265#731709, @jfb wrote:
>
> > Is it a goal to support Microsoft's STL with this? If so, how does MSVC's 
> > STL implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't 
> > seem to have anything ? Presumably they'll 
> > have to do *something*.
>
>
> The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on Windows 
> using Clang. As you know libc++ currently uses the `__GCC_ATOMIC_FOO` macros, 
> but those aren't available on Windows.


OK so it's just a hygiene question of blanket-avoiding `__GCC_*` macros in 
clang-ms mode, but using `__CLANG_*` macros are OK? That sounds fine then. 
Would you all-out switch libc++ to use `__CLANG_*` then?

> Also AFAIK MSVC leaves the implementation of atomics up to the library, not 
> the frontend. So W/E MSVC's STL does it's likely not sane or desirable.

Wait what? How does that even work? This calls for a Twitter ping of Billy!


https://reviews.llvm.org/D32265



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

[libcxx] r300881 - Fix comment and remove incorrect linker flags in test configuration

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 15:22:19 2017
New Revision: 300881

URL: http://llvm.org/viewvc/llvm-project?rev=300881=rev
Log:
Fix comment and remove incorrect linker flags in test configuration

Modified:
libcxx/trunk/utils/libcxx/test/config.py

Modified: libcxx/trunk/utils/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/utils/libcxx/test/config.py?rev=300881=300880=300881=diff
==
--- libcxx/trunk/utils/libcxx/test/config.py (original)
+++ libcxx/trunk/utils/libcxx/test/config.py Thu Apr 20 15:22:19 2017
@@ -414,7 +414,11 @@ class Configuration(object):
 if self.is_windows:
 self.config.available_features.add('windows')
 if self.cxx_stdlib_under_test == 'libc++':
-# LIBCXX-WINDOWS-FIXME is a
+# LIBCXX-WINDOWS-FIXME is the feature name used to XFAIL the
+# initial Windows failures until they can be properly diagnosed
+# and fixed. This allows easier detection of new test failures
+# and regressions. Note: New failures should not be suppressed
+# using this feature.
 self.config.available_features.add('LIBCXX-WINDOWS-FIXME')
 
 # Attempt to detect the glibc version by querying for __GLIBC__
@@ -482,8 +486,6 @@ class Configuration(object):
 self.cxx.flags += ['-m32']
 # Use verbose output for better errors
 self.cxx.flags += ['-v']
-if self.is_windows:
-self.cxx.link_flags += ['-Wl,-v']
 sysroot = self.get_lit_conf('sysroot')
 if sysroot:
 self.cxx.flags += ['--sysroot', sysroot]


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

[PATCH] D31709: [NFC] Refactor DiagnosticRenderer to use FullSourceLoc

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: include/clang/Basic/SourceLocation.h:336
 
+  bool hasManager() const { return SrcMgr != nullptr; }
   /// \pre This FullSourceLoc has an associated SourceManager.

SrcMgr is only non-null when the location is invalid, right? Can you do 
something like:
  bool hasManager() const {
bool R = SrcMgr != nullptr;
assert(R == isValid() && "FullSourceLoc has location but no manager");
return R;
  }



Comment at: lib/Basic/SourceLocation.cpp:25
 
+namespace clang {
 void PrettyStackTraceLoc::print(raw_ostream ) const {

This doesn't seem necessary, you aren't defining any free functions, right?



Comment at: lib/Frontend/DiagnosticRenderer.cpp:139
 void DiagnosticRenderer::emitStoredDiagnostic(StoredDiagnostic ) {
-  emitDiagnostic(Diag.getLocation(), Diag.getLevel(), Diag.getMessage(),
- Diag.getRanges(), Diag.getFixIts(),
- Diag.getLocation().isValid() ? 
().getManager()
-  : nullptr,
- );
+  emitDiagnostic(
+  Diag.getLocation().isValid()

I think `Diag.getLocation()` is already a FullSourceLoc, no need to check it.



Comment at: lib/Frontend/DiagnosticRenderer.cpp:512
   // Produce a stack of macro backtraces.
-  SmallVector LocationStack;
+  SmallVector LocationStack;
   unsigned IgnoredEnd = 0;

This seems inefficient, it wastes space on `SourceManager` pointers that will 
all be the same.


https://reviews.llvm.org/D31709



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

[PATCH] D29659: [OpenMP] Add flag for disabling the default generation of relocatable OpenMP target code for NVIDIA GPUs.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/Driver/ToolChains/Cuda.cpp:297
+  !Args.hasFlag(options::OPT_fnoopenmp_relocatable_target,
+options::OPT_fopenmp_relocatable_target, false))
 CmdArgs.push_back("-c");

1. Add a comment with the name of the parameter for `false` argument
2. Why not to use this logic:
```
Args.hasFlag(options::OPT_fopenmp_relocatable_target,
options::OPT_fnoopenmp_relocatable_target, true)
```
?


Repository:
  rL LLVM

https://reviews.llvm.org/D29659



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Alexander Kornienko via Phabricator via cfe-commits]

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

SGTM provided this continues to work with python 2.


https://reviews.llvm.org/D32294



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

[PATCH] D29658: [OpenMP] Customize CUDA-based tool chain selection

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

Tests?




Comment at: lib/Driver/Driver.cpp:556
   else {
-const ToolChain  = getToolChain(C.getInputArgs(), TT);
-C.addOffloadDeviceToolChain(, Action::OFK_OpenMP);
+const ToolChain *TC = nullptr;
+// CUDA toolchains have to be selected differently. They pair host

Seems to me you're not using this initial value, so it is better to leave this 
variable uninitialized


Repository:
  rL LLVM

https://reviews.llvm.org/D29658



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

[PATCH] D29904: [OpenMP] Prevent emission of exception handling code when using OpenMP to offload to NVIDIA devices.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev accepted this revision.
ABataev added a comment.

LG


Repository:
  rL LLVM

https://reviews.llvm.org/D29904



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

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



Comment at: clang-tidy/tool/run-clang-tidy.py:100
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)

kimgr wrote:
> alexfh wrote:
> > "Unable to run clang-apply-replacements" without any details seems to be 
> > far worse than just a default stack trace from an unhandled exception. At 
> > the very least add the message from the exception.
> I don't know what the general Python3 ambitions of this script is, but it 
> would be nice if the new code didn't use the Python2-only print style.
> 
> You can:
> 
> from __future__ import print_function
> 
> at the top of the file, and then use Python3-style print:
> 
> print("Unable to run clang-apply-replacements", file=sys.stderr)
Thanks for feedback. I changed the code to print suggestion about 
clang-apply-replacements and stack trace. Is there a better way to make it easy 
to debug?


https://reviews.llvm.org/D32294



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

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Eric Fiselier via cfe-commits]

On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini  wrote:

>
> On Apr 20, 2017, at 12:39 AM, Eric Fiselier  wrote:
>
>
>
> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini 
> wrote:
>
>> What would be the status of these buildbots? Is it for your private
>> usage?
>>
>
> I intend for them to be public Windows buildbots for libc++.
>
>
>
> I’m not sure it’d be OK to send blame email to contributors based on this
> though.
>

I don't see why not (at least once the bot is stable). Can you elaborate?

/Eric


> —
> Mehdi
>
>
>
> Otherwise having “project' bots” using a non-official mirror may sound
>> like a strange situation to me.
>>
>
> I agree it isn't ideal, but when/if LLVM moves to github it will be
> trivial to re-configure for the official repositories.
> I considered a number of other ways to setup Appveyor but I concluded this
> was the best/easiest way to do it.
> The other options I considered for configuring Appveyor are:
>
> (1) Use the official LLVM github mirrors.
>
> This has the issue of requiring the implementation of custom Git webhooks,
> which would require
> modifying and maintaining changes to the existing LLVM Git infrastructure,
> which in itself
> would require getting access to the LLVM servers to make the changes.
>
> (2) Setup my own ever more unofficial github mirror
>
> This has all the same problems as using the existing github mirrors but it
> requires
> me to configure and maintain my own mirror, which is non-trivial.
>
> (3) Don't use Appveyor at all
>
> This requires finding Windows hardware to host the bots, which is the main
> reason
> I chose Appveyor to begin with. Even if hardware was available I would
> prefer using
> Appveyor since it provides more dominion over the environment than I think
> donated hardware could.
>
> /Eric
>
>
>> —
>> Mehdi
>>
>> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>> Adding cfe-dev list...
>>
>> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier  wrote:
>>
>>> Hi Will,
>>>
>>> I would like to request collaborator permissions for the Libc++ github
>>> mirror.
>>>
>>> I plan to use the access to setup Appveyor buildbots for libc++. In
>>> order to do this I need to be listed as a collaborator on Github.
>>>
>>> The alternative to Github access would be setting up the correct
>>> webhooks for llvm.org/git/libcxx.git, but this seems harder to both do
>>> and maintain.
>>>
>>> /Eric
>>>
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar updated this revision to Diff 96001.
kuhar added a comment.

Use python3 printing. Move exception handling out of apply_fixes.

Now, the code prints the following on failure:

  Applying fixes ...
  Error applying fixes. Is clang-apply-replacements binary correctly specified?
  
  Traceback (most recent call last):
File 
"/home/kuhar/projects/llvm/tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py",
 line 217, in main
  apply_fixes(args, tmpdir)
File 
"/home/kuhar/projects/llvm/tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py",
 line 98, in apply_fixes
  subprocess.call(invocation)
File "/usr/lib/python2.7/subprocess.py", line 523, in call
  return Popen(*popenargs, **kwargs).wait()
File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
  errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
  raise child_exception
  OSError: [Errno 2] No such file or directory

I hope that suggesting problem with clang-apply-replacements binary and 
printing stack trace is more useful.


https://reviews.llvm.org/D32294

Files:
  clang-tidy/tool/run-clang-tidy.py


Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -34,6 +34,7 @@
 http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 """
 
+from __future__ import print_function
 import argparse
 import json
 import multiprocessing
@@ -45,14 +46,15 @@
 import sys
 import tempfile
 import threading
+import traceback
 
 
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
   while not os.path.isfile(os.path.join(result, path)):
 if os.path.realpath(result) == '/':
-  print 'Error: could not find compilation database.'
+  print('Error: could not find compilation database.')
   sys.exit(1)
 result += '../'
   return os.path.realpath(result)
@@ -94,7 +96,6 @@
 invocation.append('-format')
   invocation.append(tmpdir)
   subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
@@ -164,9 +165,9 @@
 if args.checks:
   invocation.append('-checks=' + args.checks)
 invocation.append('-')
-print subprocess.check_output(invocation)
+print(subprocess.check_output(invocation))
   except:
-print >>sys.stderr, "Unable to run clang-tidy."
+print("Unable to run clang-tidy.", file=sys.stderr)
 sys.exit(1)
 
   # Load the database and extract all files.
@@ -204,14 +205,22 @@
   except KeyboardInterrupt:
 # This is a sad hack. Unfortunately subprocess goes
 # bonkers with ctrl-c and we start forking merrily.
-print '\nCtrl-C detected, goodbye.'
+print('\nCtrl-C detected, goodbye.')
 if args.fix:
   shutil.rmtree(tmpdir)
 os.kill(0, 9)
 
   if args.fix:
-print 'Applying fixes ...'
-apply_fixes(args, tmpdir)
+print('Applying fixes ...')
+
+try:
+  apply_fixes(args, tmpdir)
+except:
+  print('Error applying fixes. Is clang-apply-replacements binary '
+'correctly specified?\n', file=sys.stderr)
+  traceback.print_exc()
+
+shutil.rmtree(tmpdir)
 
 if __name__ == '__main__':
   main()


Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -34,6 +34,7 @@
 http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 """
 
+from __future__ import print_function
 import argparse
 import json
 import multiprocessing
@@ -45,14 +46,15 @@
 import sys
 import tempfile
 import threading
+import traceback
 
 
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
   while not os.path.isfile(os.path.join(result, path)):
 if os.path.realpath(result) == '/':
-  print 'Error: could not find compilation database.'
+  print('Error: could not find compilation database.')
   sys.exit(1)
 result += '../'
   return os.path.realpath(result)
@@ -94,7 +96,6 @@
 invocation.append('-format')
   invocation.append(tmpdir)
   subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
@@ -164,9 +165,9 @@
 if args.checks:
   invocation.append('-checks=' + args.checks)
 invocation.append('-')
-print subprocess.check_output(invocation)
+print(subprocess.check_output(invocation))
   except:
-print >>sys.stderr, "Unable to run clang-tidy."
+print("Unable to run clang-tidy.", file=sys.stderr)
 sys.exit(1)
 
   # Load the database and extract all files.
@@ -204,14 +205,22 @@
   except KeyboardInterrupt:
 # This is a sad hack. Unfortunately subprocess goes
 # bonkers with ctrl-c and we start forking merrily.
-print '\nCtrl-C detected, 

r300873 - [Driver] Add a missing -no-canonical-prefixes to test.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Thu Apr 20 14:06:24 2017
New Revision: 300873

URL: http://llvm.org/viewvc/llvm-project?rev=300873=rev
Log:
[Driver] Add a missing -no-canonical-prefixes to test.

Modified:
cfe/trunk/test/Driver/avr-mmcu.c

Modified: cfe/trunk/test/Driver/avr-mmcu.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/avr-mmcu.c?rev=300873=300872=300873=diff
==
--- cfe/trunk/test/Driver/avr-mmcu.c (original)
+++ cfe/trunk/test/Driver/avr-mmcu.c Thu Apr 20 14:06:24 2017
@@ -1,5 +1,5 @@
 // A test for the propagation of the -mmcu option to -cc1 and -cc1as
 
-// RUN: %clang -### -target avr -mmcu=atmega328p -save-temps %s 2>&1 | 
FileCheck %s
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=atmega328p 
-save-temps %s 2>&1 | FileCheck %s
 // CHECK: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "atmega328p"
 // CHECK: clang{{.*}} "-cc1as" {{.*}} "-target-cpu" "atmega328p"


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

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D32199#732382, @rjmccall wrote:

> If you're going to try to enforce the declared type of memory, you'll also 
> need something like the C effective type rule to handle char buffers in C++.  
> As far as I can tell, it's not actually legal under the spec to cast an array 
> of chars to an arbitrary type and access it that way — you have to do 
> something to establish that there's an object of that type there first. 
>  If you memcpy'ed into that buffer from an object of the right type, that 
> would be sufficient to create a new formal object of that type, but I don't 
> see any way to sensibly apply that rule to e.g. the POSIX "read" function.  
> It seems to me that you at least need to have a rule saying that it's okay to 
> access a formal object of type char/char[] using an arbitrarily-typed l-value.


I agree. That's exactly what the current implementation does (I get that for 
free from our TBAA setup). I get this for free from the TBAA scheme because the 
current checks are symmetric (just like the TBAA checks in the optimizer). I 
had wondered whether this symmetry was an over-approximation in some cases, but 
perhaps it is not.


https://reviews.llvm.org/D32199



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

[PATCH] D32192: Enable leak sanitizer builds for darwin

[Francis Ricci via Phabricator via cfe-commits]

fjricci updated this revision to Diff 95986.
fjricci added a comment.

Add test cases


https://reviews.llvm.org/D32192

Files:
  lib/Driver/ToolChains/Darwin.cpp
  test/Driver/fsanitize.c
  test/Driver/sanitizer-ld.c


Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=safe-stack \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -358,6 +358,27 @@
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 
'i386-pc-openbsd'
 
+// RUN: %clang -target x86_64-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-X86-64-DARWIN
+// CHECK-LSAN-X86-64-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-iossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-IOSSIMULATOR
+// CHECK-LSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-tvossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-TVOSSIMULATOR
+// CHECK-LSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-DARWIN
+// CHECK-LSAN-I386-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target arm-apple-ios -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LSAN-ARM-IOS
+// CHECK-LSAN-ARM-IOS-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-iossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-IOSSIMULATOR
+// CHECK-LSAN-I386-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-tvossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-TVOSSIMULATOR
+// CHECK-LSAN-I386-TVOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-cache-frag %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-working-set %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // CHECK-ESAN-X86: error: unsupported option '-fsanitize=efficiency-{{.*}}' 
for target 'i686--linux-gnu'
Index: lib/Driver/ToolChains/Darwin.cpp
===
--- lib/Driver/ToolChains/Darwin.cpp
+++ lib/Driver/ToolChains/Darwin.cpp
@@ -1035,6 +1035,8 @@
   const SanitizerArgs  = getSanitizerArgs();
   if (Sanitize.needsAsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+  if (Sanitize.needsLsanRt())
+AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
   if (Sanitize.needsUbsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "ubsan");
   if (Sanitize.needsTsanRt())
@@ -1892,6 +1894,7 @@
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::Leak;
   if (isTargetMacOS()) {
 if (!isMacosxVersionLT(10, 9))
   Res |= SanitizerKind::Vptr;


Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=safe-stack 

[PATCH] D31972: Do not force the frame pointer by default for ARM EABI

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added inline comments.



Comment at: test/CodeGen/arm-fp-eabi.c:1
+// RUN: %clang %s -target arm-none-eabi -O2 -S -o nofp.s
+// RUN: not grep '.setfp' nofp.s

Instead of generating a .s file and looking for ".setfp", you can pass -### and 
check the presence or absence of -mdisable-fp-elim (see other tests in 
test/Driver).


https://reviews.llvm.org/D31972



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

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

If you're going to try to enforce the declared type of memory, you'll also need 
something like the C effective type rule to handle char buffers in C++.  As far 
as I can tell, it's not actually legal under the spec to cast an array of chars 
to an arbitrary type and access it that way — you have to do something to 
establish that there's an object of that type there first.  If you memcpy'ed 
into that buffer from an object of the right type, that would be sufficient to 
create a new formal object of that type, but I don't see any way to sensibly 
apply that rule to e.g. the POSIX "read" function.  It seems to me that you at 
least need to have a rule saying that it's okay to access a formal object of 
type char/char[] using an arbitrarily-typed l-value.


https://reviews.llvm.org/D32199



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

[PATCH] D32084: AMDGPU/GFX9: Set +fast-fmaf for >=gfx900 unless -cl-denorms-are-zero is set

[Konstantin Zhuravlyov via Phabricator via cfe-commits]

kzhuravl added a comment.

Ping.


https://reviews.llvm.org/D32084



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

[PATCH] D32301: Don't pass FPOpFusion::Strict to the backend

[Adam Nemet via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300858: Don't pass FPOpFusion::Strict to the backend 
(authored by anemet).

Changed prior to commit:
  https://reviews.llvm.org/D32301?vs=95979=95982#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32301

Files:
  cfe/trunk/lib/CodeGen/BackendUtil.cpp
  cfe/trunk/test/CodeGen/fp-contract-on-asm.c


Index: cfe/trunk/test/CodeGen/fp-contract-on-asm.c
===
--- cfe/trunk/test/CodeGen/fp-contract-on-asm.c
+++ cfe/trunk/test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -369,7 +369,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;


Index: cfe/trunk/test/CodeGen/fp-contract-on-asm.c
===
--- cfe/trunk/test/CodeGen/fp-contract-on-asm.c
+++ cfe/trunk/test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -369,7 +369,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r300858 - Don't pass FPOpFusion::Strict to the backend

[Adam Nemet via cfe-commits]

Author: anemet
Date: Thu Apr 20 12:09:35 2017
New Revision: 300858

URL: http://llvm.org/viewvc/llvm-project?rev=300858=rev
Log:
Don't pass FPOpFusion::Strict to the backend

This restores the behavior prior to D31167 where the code-gen default was
FPC_On which mapped to FPOpFusion::Standard.  After merging the FE
state (on/off) and the code-gen state (on/fast/off), the default became off to
match the front-end.

In other words, the front-end controls when to fuse along the language
standards and the backend shouldn't override this by splitting fused
intrinsics as FPOpFusion::Strict would imply.

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

Added:
cfe/trunk/test/CodeGen/fp-contract-on-asm.c
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=300858=300857=300858=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Thu Apr 20 12:09:35 2017
@@ -369,7 +369,9 @@ static void initTargetOptions(llvm::Targ
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;

Added: cfe/trunk/test/CodeGen/fp-contract-on-asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/fp-contract-on-asm.c?rev=300858=auto
==
--- cfe/trunk/test/CodeGen/fp-contract-on-asm.c (added)
+++ cfe/trunk/test/CodeGen/fp-contract-on-asm.c Thu Apr 20 12:09:35 2017
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}


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

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Mehdi Amini via cfe-commits]

> On Apr 20, 2017, at 12:39 AM, Eric Fiselier  wrote:
> 
> 
> 
> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini  > wrote:
> What would be the status of these buildbots? Is it for your private usage? 
> 
> I intend for them to be public Windows buildbots for libc++.


I’m not sure it’d be OK to send blame email to contributors based on this 
though.

— 
Mehdi


> 
> Otherwise having “project' bots” using a non-official mirror may sound like a 
> strange situation to me.
> 
> I agree it isn't ideal, but when/if LLVM moves to github it will be trivial 
> to re-configure for the official repositories.
> I considered a number of other ways to setup Appveyor but I concluded this 
> was the best/easiest way to do it.
> The other options I considered for configuring Appveyor are:
> 
> (1) Use the official LLVM github mirrors.
>  
> This has the issue of requiring the implementation of custom Git webhooks, 
> which would require
> modifying and maintaining changes to the existing LLVM Git infrastructure, 
> which in itself
> would require getting access to the LLVM servers to make the changes.
> 
> (2) Setup my own ever more unofficial github mirror 
> 
> This has all the same problems as using the existing github mirrors but it 
> requires
> me to configure and maintain my own mirror, which is non-trivial.
> 
> (3) Don't use Appveyor at all
> 
> This requires finding Windows hardware to host the bots, which is the main 
> reason
> I chose Appveyor to begin with. Even if hardware was available I would prefer 
> using
> Appveyor since it provides more dominion over the environment than I think
> donated hardware could.
> 
> /Eric
> 
> 
> — 
> Mehdi
> 
>> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev 
>> > wrote:
>> 
>> Adding cfe-dev list...
>> 
>> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier > > wrote:
>> Hi Will,
>> 
>> I would like to request collaborator permissions for the Libc++ github 
>> mirror.
>> 
>> I plan to use the access to setup Appveyor buildbots for libc++. In order to 
>> do this I need to be listed as a collaborator on Github. 
>> 
>> The alternative to Github access would be setting up the correct webhooks 
>> for llvm.org/git/libcxx.git , but this seems 
>> harder to both do and maintain.
>> 
>> /Eric
>> 
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
>> 
> 
> 

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

[PATCH] D32301: Don't pass FPOpFusion::Strict to the backend

[Hal Finkel via Phabricator via cfe-commits]

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

LGTM


https://reviews.llvm.org/D32301



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

[PATCH] D32301: Don't pass FPOpFusion::Strict to the backend

[Adam Nemet via Phabricator via cfe-commits]

anemet created this revision.

This restores the behavior prior to https://reviews.llvm.org/D31167 where the 
code-gen default was
FPC_On which mapped to FPOpFusion::Standard.  After merging the FE
state (on/off) and the code-gen state (on/fast/off), the default became off to
match the front-end.

In other words, the front-end controls when to fuse along the language
standards and the backend shouldn't override this by splitting fused
intrinsics as FPOpFusion::Strict would imply.


https://reviews.llvm.org/D32301

Files:
  lib/CodeGen/BackendUtil.cpp
  test/CodeGen/fp-contract-on-asm.c


Index: test/CodeGen/fp-contract-on-asm.c
===
--- /dev/null
+++ test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -372,7 +372,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;


Index: test/CodeGen/fp-contract-on-asm.c
===
--- /dev/null
+++ test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -372,7 +372,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin added inline comments.



Comment at: include/clang/AST/Decl.h:53
 class VarTemplateDecl;
+class CompilerInstance;
 

Is this needed? It seems like a layering violation.



Comment at: include/clang/AST/Mangle.h:59
+  // the static analyzer.
+  bool ShouldForceMangleProto;
 

I'm pretty worried about using C++ mangling for C functions. It doesn't ever 
seem appropriate to do so and it sounds like it is papering over problems with 
the design.

Some questions:
- How do you handle when two translation units have different C functions with 
the same type signatures? Is there a collision? This can arise because of 
two-level namespacing or when building multiple targets with the same CTU 
directory.
- How do you handle when a C function has the same signature as a C++ function. 
Is there a collision when you mangle the C function?


https://reviews.llvm.org/D30691



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Malcolm Parsons via Phabricator via cfe-commits]

malcolm.parsons added a comment.

In https://reviews.llvm.org/D24892#732217, @alexfh wrote:

> In https://reviews.llvm.org/D24892#723536, @malcolm.parsons wrote:
>
> > Is there any way for multiple checks to share an option?
>
>
> There's OptionsView::getLocalOrGlobal. See how StrictMode option is read in 
> ArgumentCommentCheck, for example.


ArgumentCommentCheck uses getLocalOrGlobal, but 
InefficientStringConcatenationCheck and SuspiciousEnumUsageCheck don't.
6 checks have an IncludeStyle option that isn't shared.
4 checks share a HeaderFileExtensions option, but with different defaults.


https://reviews.llvm.org/D24892



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

[PATCH] D32248: CodeGen: Cast alloca to expected address space

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: lib/CodeGen/CGDecl.cpp:1105-1119
+  // Alloca always returns a pointer in alloca address space, which may
+  // be different from the type defined by the language. For example,
+  // in C++ the auto variables are in the default address space. Therefore
+  // cast alloca to the expected address space when necessary.
+  auto Addr = address.getPointer();
+  auto AddrTy = cast(Addr->getType());
+  auto ExpectedAddrSpace = 
CGM.getTypes().getVariableType(D)->getAddressSpace();

yaxunl wrote:
> t-tye wrote:
> > Is any assert done to ensure that it is legal to address space cast from 
> > variable address space to expected address space? Presumably the language, 
> > by definition, will only be causing legal casts. For example from alloca 
> > address space to generic (which includes the alloca address space).
> > 
> > For OpenCL, can you explain how the local variable can have the constant 
> > address space and use an alloca for allocation? Wouldn't a constant address 
> > space mean it was static and so should not be using alloca? And if it is 
> > using an alloca, how can it then be accessed as if it was in constant 
> > address space?
> If the auto var has address space qualifier specified through 
> `__attribute__((address_space(n)))`, there is not much we can check in clang 
> since it is target dependent. We will just emit address space cast when 
> necessary and let the backend check the validity of the address space cast.
> 
> Otherwise, for OpenCL, we can assert the expected address space is default 
> (for OpenCL default address space in AST represents private address space in 
> source language) or constant. For other languages we can assert the expected 
> address space qualifier is default (no address space qualifier). It is not 
> convenient to further check whether the emitted LLVM address space cast 
> instruction is valid since it requires target specific information, therefore 
> such check is better deferred to the backend.
> 
> For OpenCL, currently automatic variable in constant address space is emitted 
> in private address space. For example, currently Clang does not diagnose the 
> following code
> 
> ```
> void f(global int* a) {
>   global int* constant p = a;
> }
> 
> ```
> Instead, it emits alloca for p, essentially treats it as `global int* const 
> p`. This seems to be a bug to me (or maybe we can call it a feature? since 
> there seems no better way to translate this to LLVM IR, or simply diagnose 
> this as an error). However, this is better addressed by another patch.

Hi Anastasia,

Any comments about the automatic variable in constant address space? Thanks.


https://reviews.llvm.org/D32248



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Kim Gräsman via Phabricator via cfe-commits]

kimgr added a comment.

Python 3 concern inline




Comment at: clang-tidy/tool/run-clang-tidy.py:100
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)

alexfh wrote:
> "Unable to run clang-apply-replacements" without any details seems to be far 
> worse than just a default stack trace from an unhandled exception. At the 
> very least add the message from the exception.
I don't know what the general Python3 ambitions of this script is, but it would 
be nice if the new code didn't use the Python2-only print style.

You can:

from __future__ import print_function

at the top of the file, and then use Python3-style print:

print("Unable to run clang-apply-replacements", file=sys.stderr)


https://reviews.llvm.org/D32294



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In https://reviews.llvm.org/D24892#723536, @malcolm.parsons wrote:

> The `modernize-use-default-member-init` check now has an option with the same 
> effect, but it is called `UseAssignment`.
>  We should use consistent option names.
>  Is there any way for multiple checks to share an option?


There's OptionsView::getLocalOrGlobal. See how StrictMode option is read in 
ArgumentCommentCheck, for example.


https://reviews.llvm.org/D24892



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