Re: [PATCH] D11333: [libcxx] Add special warning flag detection logic to compiler.py

2015-08-26 Thread Jonathan Roelofs via cfe-commits
jroelofs added a comment.

the `addWarningFlagIfSupported` part of this patch LGTM.



Comment at: test/libcxx/compiler.py:88
@@ -87,1 +87,3 @@
 
+def compileString(self, source, out=None, flags=[], env=None, cwd=None):
+cmd = self.compileCmd('-', out, flags)

this looks unused to me.


Comment at: test/libcxx/compiler.py:105
@@ -98,1 +104,3 @@
 
+def compileLinkString(self, source, out=None, flags=[], env=None, 
cwd=None):
+cmd = self.compileLinkCmd('-', out, flags)

this looks unused to me.


http://reviews.llvm.org/D11333



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


Re: [PATCH] D12297: [libcxx] Fix most undefined behavior in list

2015-08-26 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

I like this because it localizes the weirdness into one routine `self`.
If we can't get D12999 applied due to ABI concerns, this will help a bunch.


http://reviews.llvm.org/D12297



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


Re: [PATCH] D11333: [libcxx] Add special warning flag detection logic to compiler.py

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

Those methods are currently unused but are you opposed to me adding them in 
this patch? They will be useful for compiling short tests to check for compiler 
features.


http://reviews.llvm.org/D11333



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


Re: [PATCH] D12299: [libcxx] ABI-Breaking Fix for ALL undefined behavior in list.

2015-08-26 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

So... what do we need to do to enumerate the ABI breakage of this patch?

I get that there's a couple of member variables that are changing type. Can 
they change (as a result of this patch) from a plain pointer to a fancy pointer 
(or vice versa)? Can they change size?  Is this a header-only change (probably) 
with no need to ship a new dylib?


http://reviews.llvm.org/D12299



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


[libcxx] r246069 - [libcxx] Add special warning flag detection logic to compiler.py

2015-08-26 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Aug 26 15:17:33 2015
New Revision: 246069

URL: http://llvm.org/viewvc/llvm-project?rev=246069view=rev
Log:
[libcxx] Add special warning flag detection logic to compiler.py

Summary: Detecting `-Wno-warning` flags can be tricky with GCC (See 
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html). This patch adds a 
special `addWarningFlagIfSupported(flag)` method to the test compiler object 
that can be used to add warning flags. The goal of this patch is to help get 
the test suite running with more warnings.

Reviewers: danalbert, jroelofs

Subscribers: cfe-commits

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

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

Modified: libcxx/trunk/test/libcxx/compiler.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/compiler.py?rev=246069r1=246068r2=246069view=diff
==
--- libcxx/trunk/test/libcxx/compiler.py (original)
+++ libcxx/trunk/test/libcxx/compiler.py Wed Aug 26 15:17:33 2015
@@ -161,3 +161,28 @@ class CXXCompiler(object):
 return True
 else:
 return False
+
+def addWarningFlagIfSupported(self, flag):
+
+addWarningFlagIfSupported - Add a warning flag if the compiler
+supports it. Unlike addCompileFlagIfSupported, this function detects
+when -Wno-warning flags are unsupported. If flag is a
+-Wno-warning GCC will not emit an unknown option diagnostic unless
+another error is triggered during compilation.
+
+assert isinstance(flag, str)
+if not flag.startswith('-Wno-'):
+return self.addCompileFlagIfSupported(flag)
+flags = ['-Werror', flag]
+cmd = self.compileCmd('-', os.devnull, flags)
+# Remove '-v' because it will cause the command line invocation
+# to be printed as part of the error output.
+# TODO(EricWF): Are there other flags we need to worry about?
+if '-v' in cmd:
+cmd.remove('-v')
+out, err, rc = lit.util.executeCommand(cmd, input='#error\n')
+assert rc != 0
+if flag in err:
+return False
+self.compile_flags += [flag]
+return True

Modified: libcxx/trunk/test/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/test/config.py?rev=246069r1=246068r2=246069view=diff
==
--- libcxx/trunk/test/libcxx/test/config.py (original)
+++ libcxx/trunk/test/libcxx/test/config.py Wed Aug 26 15:17:33 2015
@@ -574,16 +574,15 @@ class Configuration(object):
 '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER',
 '-Wall', '-Werror'
 ]
-self.cxx.addCompileFlagIfSupported('-Wno-attributes')
-if self.cxx.type == 'clang' or self.cxx.type == 'apple-clang':
-self.cxx.addCompileFlagIfSupported('-Wno-pessimizing-move')
-self.cxx.addCompileFlagIfSupported('-Wno-c++11-extensions')
-
self.cxx.addCompileFlagIfSupported('-Wno-user-defined-literals')
+self.cxx.addWarningFlagIfSupported('-Wno-attributes')
+self.cxx.addWarningFlagIfSupported('-Wno-pessimizing-move')
+self.cxx.addWarningFlagIfSupported('-Wno-c++11-extensions')
+self.cxx.addWarningFlagIfSupported('-Wno-user-defined-literals')
 std = self.get_lit_conf('std', None)
 if std in ['c++98', 'c++03']:
 # The '#define static_assert' provided by libc++ in C++03 mode
 # causes an unused local typedef whenever it is used.
-self.cxx.addCompileFlagIfSupported('-Wno-unused-local-typedef')
+self.cxx.addWarningFlagIfSupported('-Wno-unused-local-typedef')
 
 def configure_sanitizer(self):
 san = self.get_lit_conf('use_sanitizer', '').strip()


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


Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

In http://reviews.llvm.org/D12247#233323, @davidxl wrote:

 We certainly need a fix without breaking ABI. Is there a ABI conformance test 
 for libcxx?


To actually answer @davidxl's question: No. libc++ does not have an ABI test 
suite of any sort.


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

In http://reviews.llvm.org/D12247#233323, @davidxl wrote:

 We certainly need a fix without breaking ABI. Is there a ABI conformance test 
 for libcxx?


Well this patch definitely breaks the ABI. This was my attempt at fixing the 
problem in `std::function` that might not be ABI breaking..
https://gist.github.com/EricWF/3a35b140a66d4826a9d0.


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12369: [clang-format] Fix alignConsecutiveAssignments not working properly

2015-08-26 Thread Daniel Jasper via cfe-commits
djasper added a comment.

Adding Matt, the original author of the code. (also I don't have much time to 
review this or the other patch today, but will try to finish before the end of 
the week)


http://reviews.llvm.org/D12369



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


Re: [PATCH] D12344: ARM: Error out if float-ab=hard and abi=apcs-gnu on macho platforms

2015-08-26 Thread Akira Hatanaka via cfe-commits
ahatanak added a comment.

float-abi=hard has no effect on the backend code-generation if the ABI is APCS, 
meaning GPRs will be used to pass floating point arguments. This patch makes 
changes to the driver so that the error is detected in the front-end rather 
than silently ignoring the option in the backend.


http://reviews.llvm.org/D12344



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


r246054 - [ARM] Error out if float-ab=hard and abi=apcs-gnu on macho platforms.

2015-08-26 Thread Akira Hatanaka via cfe-commits
Author: ahatanak
Date: Wed Aug 26 14:00:11 2015
New Revision: 246054

URL: http://llvm.org/viewvc/llvm-project?rev=246054view=rev
Log:
[ARM] Error out if float-ab=hard and abi=apcs-gnu on macho platforms.

Error out if -mfloat-abi=hard or -mhard-float is specified on the command
line and the target ABI is APCS. Previously clang issued no warnings or
errors and just passed the option to the backend, which had no effect on
code generation for targets using APCS.

This commit corrects the patch commited in r245866, which didn't take into
account the fact that not all darwin targets use APCS.

rdar://problem/22257950

http://reviews.llvm.org/D12344

Added:
cfe/trunk/test/Driver/arm-float-abi.c
Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=246054r1=246053r2=246054view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Wed Aug 26 14:00:11 2015
@@ -563,6 +563,13 @@ static void checkARMCPUName(const Driver
 D.Diag(diag::err_drv_clang_unsupported)  A-getAsString(Args);
 }
 
+static bool useAAPCSForMachO(const llvm::Triple T) {
+  // The backend is hardwired to assume AAPCS for M-class processors, ensure
+  // the frontend matches that.
+  return T.getEnvironment() == llvm::Triple::EABI ||
+ T.getOS() == llvm::Triple::UnknownOS || isARMMProfile(T);
+}
+
 // Select the float ABI as determined by -msoft-float, -mhard-float, and
 // -mfloat-abi=.
 StringRef tools::arm::getARMFloatABI(const Driver D, const ArgList Args,
@@ -582,6 +589,13 @@ StringRef tools::arm::getARMFloatABI(con
 FloatABI = soft;
   }
 }
+
+// It is incorrect to select hard float ABI on MachO platforms if the ABI 
is
+// apcs-gnu.
+if (Triple.isOSBinFormatMachO()  !useAAPCSForMachO(Triple) 
+FloatABI == hard)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)  A-getAsString(Args)
+Triple.getArchName();
   }
 
   // If unspecified, choose the default based on the platform.
@@ -856,10 +870,7 @@ void Clang::AddARMTargetArgs(const ArgLi
   if (Arg *A = Args.getLastArg(options::OPT_mabi_EQ)) {
 ABIName = A-getValue();
   } else if (Triple.isOSBinFormatMachO()) {
-// The backend is hardwired to assume AAPCS for M-class processors, ensure
-// the frontend matches that.
-if (Triple.getEnvironment() == llvm::Triple::EABI ||
-Triple.getOS() == llvm::Triple::UnknownOS || isARMMProfile(Triple)) {
+if (useAAPCSForMachO(Triple)) {
   ABIName = aapcs;
 } else {
   ABIName = apcs-gnu;

Added: cfe/trunk/test/Driver/arm-float-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-float-abi.c?rev=246054view=auto
==
--- cfe/trunk/test/Driver/arm-float-abi.c (added)
+++ cfe/trunk/test/Driver/arm-float-abi.c Wed Aug 26 14:00:11 2015
@@ -0,0 +1,6 @@
+// RUN: not %clang %s -target armv7-apple-ios -mfloat-abi=hard 21 | 
FileCheck -check-prefix=ARMV7-ERROR %s
+// RUN: %clang %s -target armv7-apple-ios -mfloat-abi=softfp -### 21 | 
FileCheck -check-prefix=NOERROR %s
+// RUN: %clang %s -arch armv7 -target thumbv7-apple-darwin-eabi 
-mfloat-abi=hard -### 21 | FileCheck -check-prefix=NOERROR %s
+
+// ARMV7-ERROR: unsupported option '-mfloat-abi=hard' for target 'thumbv7'
+// NOERROR-NOT: unsupported option


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


Re: [PATCH] D11333: [libcxx] Add special warning flag detection logic to compiler.py

2015-08-26 Thread Jonathan Roelofs via cfe-commits
jroelofs added inline comments.


Comment at: test/libcxx/compiler.py:195
@@ +194,3 @@
+cmd.remove('-v')
+out, err, rc = lit.util.executeCommand(cmd, input='#error\n')
+assert rc != 0

... you could at least use `compileString` here.


http://reviews.llvm.org/D11333



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


Re: [PATCH] D12355: [libcxx] Optimize away unneeded length calculation in basic_string::compare(const char*)

2015-08-26 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

I think I'd rather see the call to `strcmp` and `wcscmp` in the char_traits 
class.


http://reviews.llvm.org/D12355



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


Re: [PATCH] D12355: [libcxx] Optimize away unneeded length calculation in basic_string::compare(const char*)

2015-08-26 Thread Benjamin Kramer via cfe-commits
bkramer added a subscriber: bkramer.
bkramer added a comment.

Won't this do the wrong thing for embedded '\0' in a std::string?

  std::string(hello\0world, 11).compare(hello)

should not return 0.


http://reviews.llvm.org/D12355



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


Re: [PATCH] D12355: [libcxx] Optimize away unneeded length calculation in basic_string::compare(const char*)

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

In http://reviews.llvm.org/D12355#233477, @bkramer wrote:

 Won't this do the wrong thing for embedded '\0' in a std::string?

   std::string(hello\0world, 11).compare(hello)
   

 should not return 0.


Woops. Yep that seems correct but it will sure hamper the possibility for 
optimization.


http://reviews.llvm.org/D12355



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


[libcxx] r246070 - [libcxx] Remove installation rules on Darwin when it would overwrite the system installation.

2015-08-26 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Aug 26 15:18:21 2015
New Revision: 246070

URL: http://llvm.org/viewvc/llvm-project?rev=246070view=rev
Log:
[libcxx] Remove installation rules on Darwin when it would overwrite the system 
installation.

Summary:
On Mac OS X overwriting `/usr/lib/libc++.dylib` can cause your computer to fail 
to boot. This patch tries to make it harder to do that accidentally. 

If `CMAKE_SYSTEM_NAME` is `Darwin` and `CMAKE_INSTALL_PREFIX` is `/usr` don't 
generate installation rules unless the user explicitly provides 
`LIBCXX_OVERRIDE_DARWIN_INSTALL=ON`. Note that `CMAKE_INSTALL_PREFIX` is always 
absolute so we don't need to worry about things like `/usr/../usr`.

Reviewers: mclow.lists, beanz, jroelofs

Subscribers: cfe-commits

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

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
libcxx/trunk/lib/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=246070r1=246069r2=246070view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Aug 26 15:18:21 2015
@@ -56,6 +56,7 @@ option(LIBCXX_INCLUDE_DOCS Build the li
 set(LIBCXX_LIBDIR_SUFFIX ${LLVM_LIBDIR_SUFFIX} CACHE STRING
 Define suffix of library directory name (32/64))
 option(LIBCXX_INSTALL_HEADERS Install the libc++ headers. ON)
+option(LIBCXX_INSTALL_LIBRARY Install the libc++ library. ON)
 option(LIBCXX_INSTALL_SUPPORT_HEADERS Install libc++ support headers. ON)
 
 # ABI Library options -
@@ -95,6 +96,23 @@ option(LIBCXX_GENERATE_COVERAGE Enable
 set(LIBCXX_COVERAGE_LIBRARY  CACHE STRING
 The Profile-rt library used to build with code coverage)
 
+# Don't allow a user to accidentally overwrite the system libc++ installation 
on Darwin.
+# If the user specifies -DCMAKE_INSTALL_PREFIX=/usr the install rules for 
libc++
+# will not be generated and a warning will be issued.
+option(LIBCXX_OVERRIDE_DARWIN_INSTALL Enable overwriting darwins libc++ 
installation. OFF)
+mark_as_advanced(LIBCXX_OVERRIDE_DARWIN_INSTALL) # Don't show this option by 
default.
+
+if (${CMAKE_SYSTEM_NAME} MATCHES Darwin AND NOT 
LIBCXX_OVERRIDE_DARWIN_INSTALL)
+  if (${CMAKE_INSTALL_PREFIX} STREQUAL /usr)
+message(WARNING Disabling libc++ install rules because installation would 

+overwrite the systems installation. Configure with 
+-DLIBCXX_OVERRIDE_DARWIN_INSTALL=ON to suppress this 
behaviour.)
+mark_as_advanced(CLEAR LIBCXX_OVERRIDE_DARWIN_INSTALL) # Show the override 
option.
+set(LIBCXX_INSTALL_HEADERS OFF)
+set(LIBCXX_INSTALL_LIBRARY OFF)
+  endif()
+endif()
+
 
#===
 # Check option configurations
 
#===

Modified: libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake?rev=246070r1=246069r2=246070view=diff
==
--- libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleLibCXXABI.cmake Wed Aug 26 15:18:21 2015
@@ -41,11 +41,13 @@ macro(setup_abi_lib abidefines abilib ab
 file(COPY ${incpath}/${fpath}
   DESTINATION ${CMAKE_BINARY_DIR}/include/${dstdir}
   )
-install(FILES ${CMAKE_BINARY_DIR}/include/${fpath}
-  DESTINATION include/c++/v1/${dstdir}
-  COMPONENT libcxx
-  PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  )
+if (LIBCXX_INSTALL_HEADERS)
+  install(FILES ${CMAKE_BINARY_DIR}/include/${fpath}
+DESTINATION include/c++/v1/${dstdir}
+COMPONENT libcxx
+PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
+)
+endif()
 list(APPEND abilib_headers ${CMAKE_BINARY_DIR}/include/${fpath})
   endif()
 endforeach()

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=246070r1=246069r2=246070view=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Wed Aug 26 15:18:21 2015
@@ -133,15 +133,18 @@ set_target_properties(cxx
 SOVERSION 1
   )
 
-install(TARGETS cxx
-  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
-  ARCHIVE DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
-  )
+if (LIBCXX_INSTALL_LIBRARY)
+  install(TARGETS cxx
+LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
+ARCHIVE DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT 

[PATCH] D12378: [OpenCL] Improve diagnostics detecting implicit vector conversion.

2015-08-26 Thread Alexey Bader via cfe-commits
bader created this revision.
bader added a subscriber: cfe-commits.

http://reviews.llvm.org/D12378

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaExpr.cpp
  test/SemaOpenCL/cond.cl

Index: test/SemaOpenCL/cond.cl
===
--- test/SemaOpenCL/cond.cl
+++ test/SemaOpenCL/cond.cl
@@ -84,7 +84,7 @@
 
 float2 ntest04(int2 C, int2 X, float2 Y)
 {
-  return C ? X : Y; // expected-error {{cannot convert between vector values 
of different size ('int2' (vector of 2 'int' values) and 'float2' (vector of 2 
'float' values))}}
+  return C ? X : Y; // expected-error {{implicit conversions between vector 
types ('int2' (vector of 2 'int' values) and 'float2' (vector of 2 'float' 
values)) are not permitted}}
 }
 
 float2 ntest05(int2 C, int2 X, float Y)
@@ -115,7 +115,7 @@
 
 char3 ntest10(char C, char3 X, char2 Y)
 {
-  return C ? X : Y; // expected-error {{cannot convert between vector values 
of different size ('char3' (vector of 3 'char' values) and 'char2' (vector of 2 
'char' values))}}
+  return C ? X : Y; // expected-error {{implicit conversions between vector 
types ('char3' (vector of 3 'char' values) and 'char2' (vector of 2 'char' 
values)) are not permitted}}
 }
 
 char3 ntest11(char2 C, char3 X, char Y)
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -7534,6 +7534,19 @@
 return QualType();
   }
 
+  // OpenCL V1.1 6.2.6.p1:
+  // If the operands are of more than one vector type, then an error shall
+  // occur. Implicit conversions between vector types are not permitted, per
+  // section 6.2.1.
+  if (getLangOpts().OpenCL 
+  RHSVecType  isaExtVectorType(RHSVecType) 
+  LHSVecType  isaExtVectorType(LHSVecType)) {
+assert(!Context.hasSameType(LHSType, RHSType));
+Diag(Loc, diag::err_opencl_implicit_vector_conversion)  LHSType
+RHSType;
+return QualType();
+  }
+
   // Otherwise, use the generic diagnostic.
   Diag(Loc, diag::err_typecheck_vector_not_convertable)
  LHSType  RHSType
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -7445,6 +7445,8 @@
   return value cannot be qualified with address space;
 def err_opencl_constant_no_init : Error
   variable in constant address space must be initialized;
+def err_opencl_implicit_vector_conversion : Error
+  implicit conversions between vector types (%0 and %1) are not permitted;
 } // end of sema category
 
 let CategoryName = OpenMP Issue in {


Index: test/SemaOpenCL/cond.cl
===
--- test/SemaOpenCL/cond.cl
+++ test/SemaOpenCL/cond.cl
@@ -84,7 +84,7 @@
 
 float2 ntest04(int2 C, int2 X, float2 Y)
 {
-  return C ? X : Y; // expected-error {{cannot convert between vector values of different size ('int2' (vector of 2 'int' values) and 'float2' (vector of 2 'float' values))}}
+  return C ? X : Y; // expected-error {{implicit conversions between vector types ('int2' (vector of 2 'int' values) and 'float2' (vector of 2 'float' values)) are not permitted}}
 }
 
 float2 ntest05(int2 C, int2 X, float Y)
@@ -115,7 +115,7 @@
 
 char3 ntest10(char C, char3 X, char2 Y)
 {
-  return C ? X : Y; // expected-error {{cannot convert between vector values of different size ('char3' (vector of 3 'char' values) and 'char2' (vector of 2 'char' values))}}
+  return C ? X : Y; // expected-error {{implicit conversions between vector types ('char3' (vector of 3 'char' values) and 'char2' (vector of 2 'char' values)) are not permitted}}
 }
 
 char3 ntest11(char2 C, char3 X, char Y)
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -7534,6 +7534,19 @@
 return QualType();
   }
 
+  // OpenCL V1.1 6.2.6.p1:
+  // If the operands are of more than one vector type, then an error shall
+  // occur. Implicit conversions between vector types are not permitted, per
+  // section 6.2.1.
+  if (getLangOpts().OpenCL 
+  RHSVecType  isaExtVectorType(RHSVecType) 
+  LHSVecType  isaExtVectorType(LHSVecType)) {
+assert(!Context.hasSameType(LHSType, RHSType));
+Diag(Loc, diag::err_opencl_implicit_vector_conversion)  LHSType
+RHSType;
+return QualType();
+  }
+
   // Otherwise, use the generic diagnostic.
   Diag(Loc, diag::err_typecheck_vector_not_convertable)
  LHSType  RHSType
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -7445,6 +7445,8 @@
   return value 

Re: [PATCH] D11553: [libcxx] Rewrite C++03 __invoke.

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF updated this revision to Diff 33235.
EricWF added a comment.

Address @mclow.lists note about consistency.


http://reviews.llvm.org/D11553

Files:
  include/__functional_base
  include/__functional_base_03
  include/functional
  test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.fail.cpp
  test/std/utilities/function.objects/refwrap/refwrap.helpers/ref_1.fail.cpp

Index: test/std/utilities/function.objects/refwrap/refwrap.helpers/ref_1.fail.cpp
===
--- test/std/utilities/function.objects/refwrap/refwrap.helpers/ref_1.fail.cpp
+++ test/std/utilities/function.objects/refwrap/refwrap.helpers/ref_1.fail.cpp
@@ -15,6 +15,8 @@
 
 // Don't allow binding to a temp
 
+// XFAIL: c++98, c++03
+
 #include functional
 
 struct A {};
Index: test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.fail.cpp
===
--- test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.fail.cpp
+++ test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.fail.cpp
@@ -13,6 +13,8 @@
 
 // reference_wrapper(T) = delete;
 
+// XFAIL: c++98, c++03
+
 #include functional
 #include cassert
 
Index: include/functional
===
--- include/functional
+++ include/functional
@@ -1262,22 +1262,102 @@
 #else
 
 template class _A0
+_LIBCPP_INLINE_VISIBILITY
 typename __invoke_return0type, _A0::type
 operator() (_A0 __a0) const {
 return __invoke(__f_, __a0);
 }
 
+template class _A0
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return0type, _A0 const::type
+operator() (_A0 const __a0) const {
+return __invoke(__f_, __a0);
+}
+
 template class _A0, class _A1
+_LIBCPP_INLINE_VISIBILITY
 typename __invoke_return1type, _A0, _A1::type
 operator() (_A0 __a0, _A1 __a1) const {
 return __invoke(__f_, __a0, __a1);
 }
 
+template class _A0, class _A1
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return1type, _A0 const, _A1::type
+operator() (_A0 const __a0, _A1 __a1) const {
+return __invoke(__f_, __a0, __a1);
+}
+
+template class _A0, class _A1
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return1type, _A0, _A1 const::type
+operator() (_A0 __a0, _A1 const __a1) const {
+return __invoke(__f_, __a0, __a1);
+}
+
+template class _A0, class _A1
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return1type, _A0 const, _A1 const::type
+operator() (_A0 const __a0, _A1 const __a1) const {
+return __invoke(__f_, __a0, __a1);
+}
+
 template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
 typename __invoke_return2type, _A0, _A1, _A2::type
 operator() (_A0 __a0, _A1 __a1, _A2 __a2) const {
 return __invoke(__f_, __a0, __a1, __a2);
 }
+
+template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return2type, _A0 const, _A1, _A2::type
+operator() (_A0 const __a0, _A1 __a1, _A2 __a2) const {
+return __invoke(__f_, __a0, __a1, __a2);
+}
+
+template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return2type, _A0, _A1 const, _A2::type
+operator() (_A0 __a0, _A1 const __a1, _A2 __a2) const {
+return __invoke(__f_, __a0, __a1, __a2);
+}
+
+template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return2type, _A0, _A1, _A2 const::type
+operator() (_A0 __a0, _A1 __a1, _A2 const __a2) const {
+return __invoke(__f_, __a0, __a1, __a2);
+}
+
+template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return2type, _A0 const, _A1 const, _A2::type
+operator() (_A0 const __a0, _A1 const __a1, _A2 __a2) const {
+return __invoke(__f_, __a0, __a1, __a2);
+}
+
+template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return2type, _A0 const, _A1, _A2 const::type
+operator() (_A0 const __a0, _A1 __a1, _A2 const __a2) const {
+return __invoke(__f_, __a0, __a1, __a2);
+}
+
+template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return2type, _A0, _A1 const, _A2 const::type
+operator() (_A0 __a0, _A1 const __a1, _A2 const __a2) const {
+return __invoke(__f_, __a0, __a1, __a2);
+}
+
+template class _A0, class _A1, class _A2
+_LIBCPP_INLINE_VISIBILITY
+typename __invoke_return2type, _A0 const, _A1 const, _A2 const::type
+operator() (_A0 const __a0, _A1 const __a1, _A2 const __a2) const {
+return __invoke(__f_, __a0, __a1, __a2);
+}
 #endif
 };
 
Index: include/__functional_base_03
===
--- include/__functional_base_03
+++ 

Re: [PATCH] D11553: [libcxx] Rewrite C++03 __invoke.

2015-08-26 Thread Marshall Clow via cfe-commits
mclow.lists added inline comments.


Comment at: include/__functional_base:521
@@ +520,3 @@
+operator() (_ArgTypes... __args) const {
+return __invoke(get(), _VSTD::forward_ArgTypes(__args)...);
+}

I know you didn't change this, but how did we get away with an `` w/o a 
`#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES` ?



http://reviews.llvm.org/D11553



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


Re: [PATCH] D11553: [libcxx] Rewrite C++03 __invoke.

2015-08-26 Thread Marshall Clow via cfe-commits
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.

Ok, I think this is good to go. Thanks, Eric.


http://reviews.llvm.org/D11553



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


Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

2015-08-26 Thread Serge Pavlov via cfe-commits
sepavloff added a subscriber: sepavloff.
sepavloff added a comment.

Ping.

Thanks,
--Serge


http://reviews.llvm.org/D11844



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


Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

2015-08-26 Thread Serge Pavlov via cfe-commits
Ping.

Thanks,
--Serge

2015-08-22 3:15 GMT+06:00 Sean Silva chisophu...@gmail.com:

 silvas added inline comments.

 
 Comment at: test/Modules/auto-module-import.m:89
 @@ +88,3 @@
 +  expected-error {{import of module
 'NoUmbrella.A' appears within function 'includeNotAtTopLevel'}} \
 +  expected-note {{consider marking the module
 as textual}}
 +}
 
 I think what this means is marking the *header* as textual. So I would
 suggest the wording consider marking the header as textual.


 http://reviews.llvm.org/D11844




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


Re: [PATCH] D11553: [libcxx] Rewrite C++03 __invoke.

2015-08-26 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

So far, this looks good. I'm going to apply it locally and futz with it.



Comment at: include/__functional_base_03:30
@@ +29,3 @@
+typedef _Ret _Bullet2;
+typedef _Ret type;
+};

Let's be consistent. :-)
 typedef _Bullet2 type;


http://reviews.llvm.org/D11553



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


Re: [PATCH] D12378: [OpenCL] Improve diagnostics detecting implicit vector conversion.

2015-08-26 Thread Pekka Jääskeläinen via cfe-commits
pekka.jaaskelainen added a subscriber: pekka.jaaskelainen.
pekka.jaaskelainen accepted this revision.
pekka.jaaskelainen added a reviewer: pekka.jaaskelainen.
pekka.jaaskelainen added a comment.
This revision is now accepted and ready to land.

Perhaps the assert() is unneccessary, but otherwise LGTM.


http://reviews.llvm.org/D12378



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


Re: [PATCH] D11333: [libcxx] Add special warning flag detection logic to compiler.py

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF updated this revision to Diff 33236.
EricWF added a comment.

Remove unused CompileString functions. The reason they can't be used to 
implement `addWarningFlagIfSupported` is because we have to fuss with the flags 
before invoking the compiler .


http://reviews.llvm.org/D11333

Files:
  test/libcxx/compiler.py
  test/libcxx/test/config.py

Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -574,16 +574,15 @@
 '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER',
 '-Wall', '-Werror'
 ]
-self.cxx.addCompileFlagIfSupported('-Wno-attributes')
-if self.cxx.type == 'clang' or self.cxx.type == 'apple-clang':
-self.cxx.addCompileFlagIfSupported('-Wno-pessimizing-move')
-self.cxx.addCompileFlagIfSupported('-Wno-c++11-extensions')
-
self.cxx.addCompileFlagIfSupported('-Wno-user-defined-literals')
+self.cxx.addWarningFlagIfSupported('-Wno-attributes')
+self.cxx.addWarningFlagIfSupported('-Wno-pessimizing-move')
+self.cxx.addWarningFlagIfSupported('-Wno-c++11-extensions')
+self.cxx.addWarningFlagIfSupported('-Wno-user-defined-literals')
 std = self.get_lit_conf('std', None)
 if std in ['c++98', 'c++03']:
 # The '#define static_assert' provided by libc++ in C++03 mode
 # causes an unused local typedef whenever it is used.
-self.cxx.addCompileFlagIfSupported('-Wno-unused-local-typedef')
+self.cxx.addWarningFlagIfSupported('-Wno-unused-local-typedef')
 
 def configure_sanitizer(self):
 san = self.get_lit_conf('use_sanitizer', '').strip()
Index: test/libcxx/compiler.py
===
--- test/libcxx/compiler.py
+++ test/libcxx/compiler.py
@@ -161,3 +161,28 @@
 return True
 else:
 return False
+
+def addWarningFlagIfSupported(self, flag):
+
+addWarningFlagIfSupported - Add a warning flag if the compiler
+supports it. Unlike addCompileFlagIfSupported, this function detects
+when -Wno-warning flags are unsupported. If flag is a
+-Wno-warning GCC will not emit an unknown option diagnostic unless
+another error is triggered during compilation.
+
+assert isinstance(flag, str)
+if not flag.startswith('-Wno-'):
+return self.addCompileFlagIfSupported(flag)
+flags = ['-Werror', flag]
+cmd = self.compileCmd('-', os.devnull, flags)
+# Remove '-v' because it will cause the command line invocation
+# to be printed as part of the error output.
+# TODO(EricWF): Are there other flags we need to worry about?
+if '-v' in cmd:
+cmd.remove('-v')
+out, err, rc = lit.util.executeCommand(cmd, input='#error\n')
+assert rc != 0
+if flag in err:
+return False
+self.compile_flags += [flag]
+return True


Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -574,16 +574,15 @@
 '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER',
 '-Wall', '-Werror'
 ]
-self.cxx.addCompileFlagIfSupported('-Wno-attributes')
-if self.cxx.type == 'clang' or self.cxx.type == 'apple-clang':
-self.cxx.addCompileFlagIfSupported('-Wno-pessimizing-move')
-self.cxx.addCompileFlagIfSupported('-Wno-c++11-extensions')
-self.cxx.addCompileFlagIfSupported('-Wno-user-defined-literals')
+self.cxx.addWarningFlagIfSupported('-Wno-attributes')
+self.cxx.addWarningFlagIfSupported('-Wno-pessimizing-move')
+self.cxx.addWarningFlagIfSupported('-Wno-c++11-extensions')
+self.cxx.addWarningFlagIfSupported('-Wno-user-defined-literals')
 std = self.get_lit_conf('std', None)
 if std in ['c++98', 'c++03']:
 # The '#define static_assert' provided by libc++ in C++03 mode
 # causes an unused local typedef whenever it is used.
-self.cxx.addCompileFlagIfSupported('-Wno-unused-local-typedef')
+self.cxx.addWarningFlagIfSupported('-Wno-unused-local-typedef')
 
 def configure_sanitizer(self):
 san = self.get_lit_conf('use_sanitizer', '').strip()
Index: test/libcxx/compiler.py
===
--- test/libcxx/compiler.py
+++ test/libcxx/compiler.py
@@ -161,3 +161,28 @@
 return True
 else:
 return False
+
+def addWarningFlagIfSupported(self, flag):
+
+addWarningFlagIfSupported - Add a warning flag if 

[PATCH] D12355: [libcxx] Optimize away unneeded length calculation in basic_string::compare(const char*)

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF created this revision.
EricWF added a reviewer: mclow.lists.
EricWF added a subscriber: cfe-commits.

This patch optimizes basic_string::compare to use strcmp when the default 
char_traits has been given.
See PR19900 for more information. https://llvm.org/bugs/show_bug.cgi?id=19900

http://reviews.llvm.org/D12355

Files:
  include/string

Index: include/string
===
--- include/string
+++ include/string
@@ -1123,6 +1123,27 @@
 return __murmur2_or_cityhashsize_t()(__p, (__e-__p)*sizeof(value_type));
 }
 
+
+template class _LHS, class _RHS
+inline _LIBCPP_INLINE_VISIBILITY
+int __do_string_compare(_LHS const __lhs, _RHS const __rhs) {
+return __lhs.compare(0, _LHS::npos, __rhs, 
_LHS::traits_type::length(__rhs));
+}
+
+template class _Allocator
+inline _LIBCPP_INLINE_VISIBILITY
+int __do_string_compare(const basic_stringchar, char_traitschar, 
_Allocator __lhs,
+const char* __rhs) {
+return _VSTD::strcmp(__lhs.data(), __rhs);
+}
+
+template class _Allocator
+inline _LIBCPP_INLINE_VISIBILITY
+int __do_string_compare(const basic_stringwchar_t, char_traitswchar_t, 
_Allocator __lhs,
+const wchar_t* __rhs) {
+return _VSTD::wcscmp(__lhs.data(), __rhs);
+}
+
 // basic_string
 
 templateclass _CharT, class _Traits, class _Allocator
@@ -3702,7 +3723,7 @@
 basic_string_CharT, _Traits, _Allocator::compare(const value_type* __s) 
const _NOEXCEPT
 {
 _LIBCPP_ASSERT(__s != nullptr, string::compare(): received nullptr);
-return compare(0, npos, __s, traits_type::length(__s));
+return __do_string_compare(*this, __s);
 }
 
 template class _CharT, class _Traits, class _Allocator


Index: include/string
===
--- include/string
+++ include/string
@@ -1123,6 +1123,27 @@
 return __murmur2_or_cityhashsize_t()(__p, (__e-__p)*sizeof(value_type));
 }
 
+
+template class _LHS, class _RHS
+inline _LIBCPP_INLINE_VISIBILITY
+int __do_string_compare(_LHS const __lhs, _RHS const __rhs) {
+return __lhs.compare(0, _LHS::npos, __rhs, _LHS::traits_type::length(__rhs));
+}
+
+template class _Allocator
+inline _LIBCPP_INLINE_VISIBILITY
+int __do_string_compare(const basic_stringchar, char_traitschar, _Allocator __lhs,
+const char* __rhs) {
+return _VSTD::strcmp(__lhs.data(), __rhs);
+}
+
+template class _Allocator
+inline _LIBCPP_INLINE_VISIBILITY
+int __do_string_compare(const basic_stringwchar_t, char_traitswchar_t, _Allocator __lhs,
+const wchar_t* __rhs) {
+return _VSTD::wcscmp(__lhs.data(), __rhs);
+}
+
 // basic_string
 
 templateclass _CharT, class _Traits, class _Allocator
@@ -3702,7 +3723,7 @@
 basic_string_CharT, _Traits, _Allocator::compare(const value_type* __s) const _NOEXCEPT
 {
 _LIBCPP_ASSERT(__s != nullptr, string::compare(): received nullptr);
-return compare(0, npos, __s, traits_type::length(__s));
+return __do_string_compare(*this, __s);
 }
 
 template class _CharT, class _Traits, class _Allocator
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D10599: [OPENMP 4.0] Initial support for '#pragma omp declare simd' directive.

2015-08-26 Thread Alexey Bataev via cfe-commits
ABataev updated this revision to Diff 33181.
ABataev marked 7 inline comments as done.
ABataev added a comment.

Update after review


http://reviews.llvm.org/D10599

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/DeclPrinter.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Parse/Parser.cpp
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_simd_ast_print.c
  test/OpenMP/declare_simd_ast_print.cpp
  test/OpenMP/declare_simd_messages.cpp

Index: lib/Parse/Parser.cpp
===
--- lib/Parse/Parser.cpp
+++ lib/Parse/Parser.cpp
@@ -656,8 +656,10 @@
   case tok::annot_pragma_opencl_extension:
 HandlePragmaOpenCLExtension();
 return DeclGroupPtrTy();
-  case tok::annot_pragma_openmp:
-return ParseOpenMPDeclarativeDirective();
+  case tok::annot_pragma_openmp: {
+AccessSpecifier AS = AS_none;
+return ParseOpenMPDeclarativeDirectiveWithExtDecl(AS, attrs);
+  }
   case tok::annot_pragma_ms_pointers_to_members:
 HandlePragmaMSPointersToMembers();
 return DeclGroupPtrTy();
Index: lib/Parse/ParseOpenMP.cpp
===
--- lib/Parse/ParseOpenMP.cpp
+++ lib/Parse/ParseOpenMP.cpp
@@ -31,6 +31,7 @@
   // E.g.: OMPD_for OMPD_simd === OMPD_for_simd
   // TODO: add other combined directives in topological order.
   const OpenMPDirectiveKind F[][3] = {
+  {OMPD_unknown /*declare*/, OMPD_simd, OMPD_declare_simd},
   {OMPD_unknown /*cancellation*/, OMPD_unknown /*point*/,
OMPD_cancellation_point},
   {OMPD_target, OMPD_unknown /*data*/, OMPD_target_data},
@@ -48,11 +49,12 @@
   for (unsigned i = 0; i  llvm::array_lengthof(F); ++i) {
 if (!Tok.isAnnotation()  DKind == OMPD_unknown) {
   TokenMatched =
-  (i == 0) 
-  !P.getPreprocessor().getSpelling(Tok).compare(cancellation);
-} else {
+  ((i == 0) 
+   !P.getPreprocessor().getSpelling(Tok).compare(declare)) ||
+  ((i == 1) 
+   !P.getPreprocessor().getSpelling(Tok).compare(cancellation));
+} else
   TokenMatched = DKind == F[i][0]  DKind != OMPD_unknown;
-}
 
 if (TokenMatched) {
   Tok = P.getPreprocessor().LookAhead(0);
@@ -64,12 +66,11 @@
 
   if (!TokenIsAnnotation  SDKind == OMPD_unknown) {
 TokenMatched =
-((i == 0) 
+((i == 1) 
  !P.getPreprocessor().getSpelling(Tok).compare(point)) ||
-((i == 1)  !P.getPreprocessor().getSpelling(Tok).compare(data));
-  } else {
+((i == 2)  !P.getPreprocessor().getSpelling(Tok).compare(data));
+  } else
 TokenMatched = SDKind == F[i][1]  SDKind != OMPD_unknown;
-  }
 
   if (TokenMatched) {
 P.ConsumeToken();
@@ -84,8 +85,16 @@
 ///
 ///   threadprivate-directive:
 /// annot_pragma_openmp 'threadprivate' simple-variable-list
+/// annot_pragma_omp_end
 ///
-Parser::DeclGroupPtrTy Parser::ParseOpenMPDeclarativeDirective() {
+///   declare-simd-directive:
+/// annot_pragma_openmp 'declare simd' {clause [,]}
+/// annot_pragma_omp_end
+/// function declaration/definition
+///
+Parser::DeclGroupPtrTy Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
+AccessSpecifier AS, ParsedAttributesWithRange Attrs,
+DeclSpec::TST TagType, Decl *TagDecl) {
   assert(Tok.is(tok::annot_pragma_openmp)  Not an OpenMP directive!);
   ParenBraceBracketBalancer BalancerRAIIObj(*this);
 
@@ -109,6 +118,50 @@
   return Actions.ActOnOpenMPThreadprivateDirective(Loc, Identifiers);
 }
 break;
+  case OMPD_declare_simd: {
+// The syntax is:
+// { #pragma omp declare simd }
+// function-declaration-or-definition
+//
+
+ConsumeToken();
+// The last seen token is annot_pragma_openmp_end - need to check for
+// extra tokens.
+if (Tok.isNot(tok::annot_pragma_openmp_end)) {
+  Diag(Tok, diag::warn_omp_extra_tokens_at_eol)
+   getOpenMPDirectiveName(OMPD_declare_simd);
+  if (!SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch))
+return DeclGroupPtrTy();
+}
+// Skip the last annot_pragma_openmp_end.
+ConsumeToken();
+
+DeclGroupPtrTy Ptr;
+if (Tok.is(tok::annot_pragma_openmp)) {
+  Ptr = ParseOpenMPDeclarativeDirectiveWithExtDecl(AS, Attrs, TagType,
+   TagDecl);
+} else {
+  // Here we expect to see some function declaration.
+  while (Tok.isNot(tok::r_brace)  !isEofOrEom()  !Ptr) {
+if (AS == AS_none) {
+  assert(TagType == DeclSpec::TST_unspecified);
+  MaybeParseCXX11Attributes(Attrs);
+  

r246021 - Remove dead code associated with parsing and setting ABI based on

2015-08-26 Thread Eric Christopher via cfe-commits
Author: echristo
Date: Wed Aug 26 02:01:33 2015
New Revision: 246021

URL: http://llvm.org/viewvc/llvm-project?rev=246021view=rev
Log:
Remove dead code associated with parsing and setting ABI based on
string name.

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

Modified: cfe/trunk/include/clang/Basic/TargetCXXABI.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetCXXABI.h?rev=246021r1=246020r2=246021view=diff
==
--- cfe/trunk/include/clang/Basic/TargetCXXABI.h (original)
+++ cfe/trunk/include/clang/Basic/TargetCXXABI.h Wed Aug 26 02:01:33 2015
@@ -282,9 +282,6 @@ public:
 llvm_unreachable(bad ABI kind);
   }
 
-  /// Try to parse an ABI name, returning false on error.
-  bool tryParse(llvm::StringRef name);
-
   friend bool operator==(const TargetCXXABI left, const TargetCXXABI right) {
 return left.getKind() == right.getKind();
   }

Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=246021r1=246020r2=246021view=diff
==
--- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
+++ cfe/trunk/include/clang/Basic/TargetInfo.h Wed Aug 26 02:01:33 2015
@@ -772,23 +772,6 @@ public:
 return false;
   }
 
-  /// \brief Use this specified C++ ABI.
-  ///
-  /// \return False on error (invalid C++ ABI name).
-  bool setCXXABI(llvm::StringRef name) {
-TargetCXXABI ABI;
-if (!ABI.tryParse(name)) return false;
-return setCXXABI(ABI);
-  }
-
-  /// \brief Set the C++ ABI to be used by this implementation.
-  ///
-  /// \return False on error (ABI not valid on this target)
-  virtual bool setCXXABI(TargetCXXABI ABI) {
-TheCXXABI = ABI;
-return true;
-  }
-
   /// \brief Enable or disable a specific target feature;
   /// the feature name must be valid.
   virtual void setFeatureEnabled(llvm::StringMapbool Features,

Modified: cfe/trunk/lib/Basic/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/TargetInfo.cpp?rev=246021r1=246020r2=246021view=diff
==
--- cfe/trunk/lib/Basic/TargetInfo.cpp (original)
+++ cfe/trunk/lib/Basic/TargetInfo.cpp Wed Aug 26 02:01:33 2015
@@ -650,18 +650,3 @@ bool TargetInfo::validateInputConstraint
 
   return true;
 }
-
-bool TargetCXXABI::tryParse(llvm::StringRef name) {
-  const Kind unknown = static_castKind(-1);
-  Kind kind = llvm::StringSwitchKind(name)
-.Case(arm, GenericARM)
-.Case(ios, iOS)
-.Case(itanium, GenericItanium)
-.Case(microsoft, Microsoft)
-.Case(mips, GenericMIPS)
-.Default(unknown);
-  if (kind == unknown) return false;
-
-  set(kind);
-  return true;
-}


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


r246020 - Remove a TODO that isn't going to get fixed in this way.

2015-08-26 Thread Eric Christopher via cfe-commits
Author: echristo
Date: Wed Aug 26 02:01:30 2015
New Revision: 246020

URL: http://llvm.org/viewvc/llvm-project?rev=246020view=rev
Log:
Remove a TODO that isn't going to get fixed in this way.

Modified:
cfe/trunk/lib/Basic/Targets.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=246020r1=246019r2=246020view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed Aug 26 02:01:30 2015
@@ -7579,9 +7579,6 @@ TargetInfo::CreateTargetInfo(Diagnostics
   return nullptr;
 
   // Add the features to the compile options.
-  //
-  // FIXME: If we are completely confident that we have the right set, we only
-  // need to pass the minuses.
   Opts-Features.clear();
   for (const auto F : Features)
 Opts-Features.push_back((F.getValue() ? + : -) + F.getKey().str());


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


Re: [PATCH] D10599: [OPENMP 4.0] Initial support for '#pragma omp declare simd' directive.

2015-08-26 Thread Alexey Bataev via cfe-commits
ABataev marked 7 inline comments as done.
ABataev added a comment.

Richard, thanks for the review!



Comment at: include/clang/Basic/Attr.td:2074-2078
@@ +2073,7 @@
+  let Documentation = [OMPDeclareSimdDocs];
+  let AdditionalMembers = [{
+  void printPrettyPragma(raw_ostream OS, const PrintingPolicy Policy) const {
+OS  \n;
+  }
+  }];
+}

rsmith wrote:
 What's this for?
This is required for proper AST printing of pragma. Without this additional 
member (this one is required for pragma attributes by attribute generation 
system) all pragmas will be printed in one line.


Comment at: include/clang/Basic/DiagnosticParseKinds.td:996-999
@@ -995,2 +995,6 @@
   expected identifier specifying the name of the 'omp critical' directive;
+def err_omp_single_decl_in_declare_simd : Error
+  single declaration is expected with 'declare simd' directive;
+def err_omp_decl_in_declare_simd : Error
+  function declaration is expected with 'declare simd' directive;
 

rsmith wrote:
 with - after, in both diagnstics.
Done, thanks.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7661
@@ -7660,1 +7660,3 @@
+def err_omp_function_expected : Error
+  '#pragma omp declare simd' can be applied to functions only;
 def err_omp_wrong_cancel_region : Error

rsmith wrote:
 can be applied to functions only - can only be applied to functions
Done


Comment at: lib/AST/DeclPrinter.cpp:214
@@ +213,3 @@
+  default:
+if (!PrintPragmas)
+  A-printPretty(Out, Policy);

rsmith wrote:
 It looks like we would no longer print attributes with pragma spelling for 
 non-function declarations after this change (but I don't think we have any 
 such pragmas at the moment). I don't want to ask you to write a bunch more 
 code here that you can't test, but can you add a FIXME somewhere in here to 
 add calls to print pragmas in more places?
Ok, will do.


Comment at: lib/Parse/ParseOpenMP.cpp:133
@@ +132,3 @@
+   getOpenMPDirectiveName(OMPD_declare_simd);
+  SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch);
+}

rsmith wrote:
 You should bail out if you don't actually find your desired token. If you 
 carry on without checking, your `ConsumeToken` call might consume the 
 `tok::eof` token or some similar bad thing.
Done, thanks.


Comment at: lib/Parse/ParseOpenMP.cpp:144-145
@@ +143,4 @@
+  // Here we expect to see some function declaration.
+  while (Tok.isNot(tok::r_brace)  !isEofOrEom() 
+ (!Ptr || Ptr.get().isNull())) {
+if (AS == AS_none) {

rsmith wrote:
 I find this loop slightly surprising: the cases where Parse*Declaration 
 return a null `DeclGroupPtrTy` are when they parsed some declaration-like 
 entity (such as a declaration-like pragma) but didn't create some declaration 
 to represent it.
 
 Do you really want to allow such things between your pragma and its 
 associated function? As an extreme case, you'd accept things like this:
 
   #pragma omp declare simd
   #pragma pack (...)
   ;
   public:
   __if_exists(foo) {
 int n;
   }
   int the_simd_function();
We need to be able to combine 'declare simd' pragma with other pragmas, for 
example:

  #pragma omp declare simd
  #pragma GCC visibility push(default)
  #pragma options align=packed
  #pragma omp declare simd
  #pragma GCC visibility pop
  int tadd(int b) { return x[b] + b; }

We should be able to accept such code. But I will reduce the number of allowed 
constructs.


Comment at: lib/Parse/ParseOpenMP.cpp:145
@@ +144,3 @@
+  while (Tok.isNot(tok::r_brace)  !isEofOrEom() 
+ (!Ptr || Ptr.get().isNull())) {
+if (AS == AS_none) {

rsmith wrote:
 Do you really need to check both `!Ptr` and `Ptr.get().isNull()` here? 
 Generally, the parser shouldn't really be calling `get()` on an `OpaquePtr` 
 -- these pointers are supposed to be opaque to the parser.
Ok, removed Ptr.get().isNull()


Comment at: lib/Parse/ParseOpenMP.cpp:162-168
@@ +161,9 @@
+}
+if (!Ptr.get().isSingleDecl())
+  Diag(Loc, diag::err_omp_single_decl_in_declare_simd);
+
+if (Ptr.get().isSingleDecl())
+  return Actions.ActOnOpenMPDeclareSimdDirective(Ptr.get().getSingleDecl(),
+ Loc);
+return Ptr;
+  }

rsmith wrote:
 I would suggest that you instead call `ActOnOpenMPDeclareSimdDirective` 
 unconditionally, pass in `Ptr` rather than its contained declaration, and 
 check for a single declaration in `Sema` -- this seems much more of a 
 semantic check than a syntactic one.
Ok, done


http://reviews.llvm.org/D10599



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


[libcxx] r246022 - Remove XFAIL in test. The bug causing it has been fixed.

2015-08-26 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Wed Aug 26 02:03:43 2015
New Revision: 246022

URL: http://llvm.org/viewvc/llvm-project?rev=246022view=rev
Log:
Remove XFAIL in test. The bug causing it has been fixed.

Modified:

libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.codecvt/locale.codecvt.members/wchar_t_out.pass.cpp

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.codecvt/locale.codecvt.members/wchar_t_out.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.codecvt/locale.codecvt.members/wchar_t_out.pass.cpp?rev=246022r1=246021r2=246022view=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.codecvt/locale.codecvt.members/wchar_t_out.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.ctype/locale.codecvt/locale.codecvt.members/wchar_t_out.pass.cpp
 Wed Aug 26 02:03:43 2015
@@ -15,11 +15,6 @@
 //const internT* from, const internT* from_end, const internT* 
from_next,
 //externT* to, externT* to_end, externT* to_next) const;
 
-// As of 24/Aug/2015 MSAN fails on this test because it doesn't provide an
-// interceptor for `wcrtomb` causing it to generate false positives.
-// TODO(EricWF) Remove this once D12311 lands.
-// XFAIL: msan
-
 #include locale
 #include string
 #include vector


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


Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread David Li via cfe-commits
davidxl added a subscriber: davidxl.
davidxl added a comment.

In libc++, placement new is used in many places.  When selecting the buffer 
size for the placed object, it uses the 'actual' size of the buffer including 
the padding bytes from alignment, instead of the declared of the buffer. As a 
result, the declared buffer size may be smaller than the target object.   Due 
to this mismatch, the compiler may see out of bound access of the buffer thus 
miscompile the program.

The purpose of the fix is to make the declared size == actual buffer size.


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12299: [libcxx] ABI-Breaking Fix for ALL undefined behavior in list.

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF updated this revision to Diff 33219.
EricWF added a comment.

Address failing test that @awi pointed out.


http://reviews.llvm.org/D12299

Files:
  include/list

Index: include/list
===
--- include/list
+++ include/list
@@ -191,21 +191,25 @@
 template class _Tp, class _VoidPtr
 struct __list_node_base
 {
-typedef typename __rebind_pointer_VoidPtr, __list_node_Tp, _VoidPtr ::type
-pointer;
 typedef typename __rebind_pointer_VoidPtr, __list_node_base::type
-__base_pointer;
-
-pointer __prev_;
-pointer __next_;
+__node_base_pointer;
+typedef typename __rebind_pointer_VoidPtr, __list_node_Tp, _VoidPtr ::type
+__node_pointer;
+__node_base_pointer __prev_;
+__node_base_pointer __next_;
 
 _LIBCPP_INLINE_VISIBILITY
-__list_node_base() : __prev_(__self()), __next_(__self()) {}
+__list_node_base() : __prev_(__as_base()), __next_(__as_base()) {}
 
 _LIBCPP_INLINE_VISIBILITY
-pointer __self()
+__node_base_pointer __as_base()
+{
+return pointer_traits__node_base_pointer::pointer_to(*this);
+}
+_LIBCPP_INLINE_VISIBILITY
+__node_pointer __as_node()
 {
-return static_castpointer(pointer_traits__base_pointer::pointer_to(*this));
+return static_cast__node_pointer(__as_base());
 }
 };
 
@@ -223,21 +227,21 @@
 template class _Tp, class _VoidPtr
 class _LIBCPP_TYPE_VIS_ONLY __list_iterator
 {
-typedef typename __rebind_pointer_VoidPtr, __list_node_Tp, _VoidPtr ::type
-__node_pointer;
+typedef typename __rebind_pointer_VoidPtr, __list_node_base_Tp, _VoidPtr ::type
+__node_base_pointer;
 
-__node_pointer __ptr_;
+__node_base_pointer __ptr_;
 
 #if _LIBCPP_DEBUG_LEVEL = 2
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p, const void* __c) _NOEXCEPT
+explicit __list_iterator(__node_base_pointer __p, const void* __c) _NOEXCEPT
 : __ptr_(__p)
 {
 __get_db()-__insert_ic(this, __c);
 }
 #else
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p) _NOEXCEPT : __ptr_(__p) {}
+explicit __list_iterator(__node_base_pointer __p) _NOEXCEPT : __ptr_(__p) {}
 #endif
 
 
@@ -295,7 +299,7 @@
 _LIBCPP_ASSERT(__get_const_db()-__dereferenceable(this),
Attempted to dereference a non-dereferenceable list::iterator);
 #endif
-return __ptr_-__value_;
+return __ptr_-__as_node()-__value_;
 }
 _LIBCPP_INLINE_VISIBILITY
 pointer operator-() const
@@ -304,7 +308,7 @@
 _LIBCPP_ASSERT(__get_const_db()-__dereferenceable(this),
Attempted to dereference a non-dereferenceable list::iterator);
 #endif
-return pointer_traitspointer::pointer_to(__ptr_-__value_);
+return pointer_traitspointer::pointer_to(__ptr_-__as_node()-__value_);
 }
 
 _LIBCPP_INLINE_VISIBILITY
@@ -346,21 +350,21 @@
 template class _Tp, class _VoidPtr
 class _LIBCPP_TYPE_VIS_ONLY __list_const_iterator
 {
-typedef typename __rebind_pointer_VoidPtr, __list_node_Tp, _VoidPtr ::type
-__node_pointer;
+typedef typename __rebind_pointer_VoidPtr, __list_node_base_Tp, _VoidPtr ::type
+__node_base_pointer;
 
-__node_pointer __ptr_;
+__node_base_pointer __ptr_;
 
 #if _LIBCPP_DEBUG_LEVEL = 2
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_const_iterator(__node_pointer __p, const void* __c) _NOEXCEPT
+explicit __list_const_iterator(__node_base_pointer __p, const void* __c) _NOEXCEPT
 : __ptr_(__p)
 {
 __get_db()-__insert_ic(this, __c);
 }
 #else
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_const_iterator(__node_pointer __p) _NOEXCEPT : __ptr_(__p) {}
+explicit __list_const_iterator(__node_base_pointer __p) _NOEXCEPT : __ptr_(__p) {}
 #endif
 
 templateclass, class friend class list;
@@ -422,7 +426,7 @@
 _LIBCPP_ASSERT(__get_const_db()-__dereferenceable(this),
Attempted to dereference a non-dereferenceable list::const_iterator);
 #endif
-return __ptr_-__value_;
+return __ptr_-__as_node()-__value_;
 }
 _LIBCPP_INLINE_VISIBILITY
 pointer operator-() const
@@ -431,7 +435,7 @@
 _LIBCPP_ASSERT(__get_const_db()-__dereferenceable(this),
Attempted to dereference a non-dereferenceable list::iterator);
 #endif
-return pointer_traitspointer::pointer_to(__ptr_-__value_);
+return pointer_traitspointer::pointer_to(__ptr_-__as_node()-__value_);
 }
 
 _LIBCPP_INLINE_VISIBILITY
@@ -511,7 +515,10 @@
 const __node_allocator __node_alloc() const _NOEXCEPT
 {return __size_alloc_.second();}
 
-static void __unlink_nodes(__node_pointer __f, __node_pointer __l) _NOEXCEPT;
+static void __unlink_nodes(__node_base_pointer __f, __node_base_pointer __l) _NOEXCEPT;
+static void 

LLVM buildmaster will be restarted tonight

2015-08-26 Thread Galina Kistanova via cfe-commits
Hello everyone,

LLVM buildmaster will be restarted after 6 PM Pacific time today.

Thanks

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


Re: [PATCH] D12362: [clang-format] Add support of consecutive declarations alignment

2015-08-26 Thread Beren Minor via cfe-commits
berenm updated this revision to Diff 33212.
berenm added a comment.

Added some test cases in combined usage with AlignConsecutiveAssignments.

The tests should pass with http://reviews.llvm.org/D12369 applied.


http://reviews.llvm.org/D12362

Files:
  include/clang/Format/Format.h
  lib/Format/Format.cpp
  lib/Format/WhitespaceManager.cpp
  lib/Format/WhitespaceManager.h
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -8631,6 +8631,174 @@
   Alignment);
 }
 
+TEST_F(FormatTest, AlignConsecutiveDeclarations) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AlignConsecutiveDeclarations = false;
+  verifyFormat(float const a = 5;\n
+   int oneTwoThree = 123;,
+   Alignment);
+  verifyFormat(int a = 5;\n
+   float const oneTwoThree = 123;,
+   Alignment);
+
+  Alignment.AlignConsecutiveDeclarations = true;
+  verifyFormat(float const a = 5;\n
+   int oneTwoThree = 123;,
+   Alignment);
+  verifyFormat(int a = method();\n
+   float const oneTwoThree = 133;,
+   Alignment);
+  verifyFormat(int i = 1, j = 10;\n
+   something = 2000;,
+   Alignment);
+  verifyFormat(something = 2000;\n
+   int i = 1, j = 10;\n,
+   Alignment);
+  verifyFormat(float  something = 2000;\n
+   double another = 911;\n
+   inti = 1, j = 10;\n
+   const int *oneMore = 1;\n
+   unsigned   i = 2;,
+   Alignment);
+  verifyFormat(float a = 5;\n
+   int   one = 1;\n
+   method();\n
+   const double   oneTwoThree = 123;\n
+   const unsigned int oneTwo = 12;,
+   Alignment);
+  verifyFormat(int  oneTwoThree{0}; // comment\n
+   unsigned oneTwo; // comment,
+   Alignment);
+  EXPECT_EQ(float const a = 5;\n
+\n
+int oneTwoThree = 123;,
+format(float const   a = 5;\n
+   \n
+   int   oneTwoThree= 123;,
+   Alignment));
+  EXPECT_EQ(float a = 5;\n
+int   one = 1;\n
+\n
+unsigned oneTwoThree = 123;,
+format(floata = 5;\n
+   int  one = 1;\n
+   \n
+   unsigned oneTwoThree = 123;,
+   Alignment));
+  EXPECT_EQ(float a = 5;\n
+int   one = 1;\n
+\n
+unsigned oneTwoThree = 123;\n
+int  oneTwo = 12;,
+format(floata = 5;\n
+   int one = 1;\n
+   \n
+   unsigned oneTwoThree = 123;\n
+   int oneTwo = 12;,
+   Alignment));
+  Alignment.AlignConsecutiveAssignments = true;
+  verifyFormat(float  something = 2000;\n
+   double another   = 911;\n
+   inti = 1, j = 10;\n
+   const int *oneMore = 1;\n
+   unsigned   i   = 2;,
+   Alignment);
+  verifyFormat(int  oneTwoThree = {0}; // comment\n
+   unsigned oneTwo  = 0;   // comment,
+   Alignment);
+  EXPECT_EQ(void SomeFunction(int parameter = 0) {\n
+  int const i   = 1;\n
+  int * j   = 2;\n
+  int   big = 1;\n
+\n
+  unsigned oneTwoThree = 123;\n
+  int  oneTwo  = 12;\n
+  method();\n
+  float k  = 2;\n
+  int   ll = 1;\n
+},
+format(void SomeFunction(int parameter= 0) {\n
+int const  i= 1;\n
+ int *j=2;\n
+int big  =  1;\n
+   \n
+   unsigned oneTwoThree  =123;\n
+   int oneTwo = 12;\n
+ method();\n
+   float k= 2;\n
+   int ll=1;\n
+   },
+   Alignment));
+  Alignment.AlignConsecutiveAssignments = false;
+  Alignment.AlignEscapedNewlinesLeft = true;
+  verifyFormat(#define A  \\\n
+ int    = 12; \\\n
+ float b = 23;\\\n
+ const int ccc = 234; \\\n
+ unsigned  dd = 2345;,
+   Alignment);
+  Alignment.AlignEscapedNewlinesLeft = false;
+  Alignment.ColumnLimit = 30;
+  verifyFormat(#define A\\\n
+ int    = 12;   \\\n
+ float b = 23;  \\\n
+ const int ccc = 234;   \\\n
+ int   dd = 2345;,
+   Alignment);
+  Alignment.ColumnLimit = 80;
+  

Re: [PATCH] D12369: [clang-format] Fix alignConsecutiveAssignments not working properly

2015-08-26 Thread Beren Minor via cfe-commits
berenm added a comment.

I'm not entirely sure of what was going on, so I rewrote the code a bit, and 
hopefully, more clearly.



Comment at: lib/Format/WhitespaceManager.cpp:218
@@ -217,3 +229,1 @@
-  bool AlignedAssignment = false;
-  int PreviousShift = 0;
   for (unsigned i = Start; i != End; ++i) {

What was the purpose of `PreviousShift`?


Comment at: lib/Format/WhitespaceManager.cpp:229
@@ -228,3 +244,3 @@
 assert(Shift = 0);
-Changes[i].Spaces += Shift;
 if (i + 1 != Changes.size())

Why shifting by `Shift` //and then// also by `PreviousShift`?


http://reviews.llvm.org/D12369



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


r246040 - Change Native Client x86 usr include and link path to match SDK expectations

2015-08-26 Thread Derek Schuff via cfe-commits
Author: dschuff
Date: Wed Aug 26 12:14:08 2015
New Revision: 246040

URL: http://llvm.org/viewvc/llvm-project?rev=246040view=rev
Log:
Change Native Client x86 usr include and link path to match SDK expectations

GNU multilib style uses x86_64-nacl/include and x86_64-nacl/usr/include
but the SDK expects i686-nacl/usr/include for its files. Change the driver
to use this.

Fixes https://code.google.com/p/nativeclient/issues/detail?id=4108

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

Modified:
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/test/Driver/nacl-direct.c

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=246040r1=246039r2=246040view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Wed Aug 26 12:14:08 2015
@@ -2328,7 +2328,7 @@ NaClToolChain::NaClToolChain(const Drive
   switch (Triple.getArch()) {
   case llvm::Triple::x86: {
 file_paths.push_back(FilePath + x86_64-nacl/lib32);
-file_paths.push_back(FilePath + x86_64-nacl/usr/lib32);
+file_paths.push_back(FilePath + i686-nacl/usr/lib);
 prog_paths.push_back(ProgPath + x86_64-nacl/bin);
 file_paths.push_back(ToolPath + i686-nacl);
 break;
@@ -2380,12 +2380,21 @@ void NaClToolChain::AddClangSystemInclud
 
   SmallString128 P(D.Dir + /../);
   switch (getTriple().getArch()) {
+  case llvm::Triple::x86:
+// x86 is special because multilib style uses x86_64-nacl/include for libc
+// headers but the SDK wants i686-nacl/usr/include. The other architectures
+// have the same substring.
+llvm::sys::path::append(P, i686-nacl/usr/include);
+addSystemInclude(DriverArgs, CC1Args, P.str());
+llvm::sys::path::remove_filename(P);
+llvm::sys::path::remove_filename(P);
+llvm::sys::path::remove_filename(P);
+llvm::sys::path::append(P, x86_64-nacl/include);
+addSystemInclude(DriverArgs, CC1Args, P.str());
+return;
   case llvm::Triple::arm:
 llvm::sys::path::append(P, arm-nacl/usr/include);
 break;
-  case llvm::Triple::x86:
-llvm::sys::path::append(P, x86_64-nacl/usr/include);
-break;
   case llvm::Triple::x86_64:
 llvm::sys::path::append(P, x86_64-nacl/usr/include);
 break;

Modified: cfe/trunk/test/Driver/nacl-direct.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/nacl-direct.c?rev=246040r1=246039r2=246040view=diff
==
--- cfe/trunk/test/Driver/nacl-direct.c (original)
+++ cfe/trunk/test/Driver/nacl-direct.c Wed Aug 26 12:14:08 2015
@@ -9,7 +9,7 @@
 // CHECK-I686: -target-cpu pentium4
 // CHECK-I686: -resource-dir foo
 // CHECK-I686: -internal-isystem foo{{/|}}include
-// CHECK-I686: -internal-isystem 
{{.*}}{{/|}}..{{/|}}x86_64-nacl{{/|}}usr{{/|}}include
+// CHECK-I686: -internal-isystem 
{{.*}}{{/|}}..{{/|}}i686-nacl{{/|}}usr{{/|}}include
 // CHECK-I686: -internal-isystem 
{{.*}}{{/|}}..{{/|}}x86_64-nacl{{/|}}include
 // CHECK-I686: as{{(.exe)?}} --32
 // CHECK-I686: ld{{(.exe)?}}
@@ -17,7 +17,7 @@
 // CHECK-I686: -m elf_i386_nacl
 // CHECK-I686: -static
 // CHECK-I686: -L{{.*}}{{/|}}..{{/|}}x86_64-nacl{{/|}}lib32
-// CHECK-I686: 
-L{{.*}}{{/|}}..{{/|}}x86_64-nacl{{/|}}usr{{/|}}lib32
+// CHECK-I686: 
-L{{.*}}{{/|}}..{{/|}}i686-nacl{{/|}}usr{{/|}}lib
 // CHECK-I686: -Lfoo{{/|}}lib{{/|}}i686-nacl
 // CHECK-I686-NOT: -lpthread
 //
@@ -118,7 +118,7 @@
 // CHECK-I686-CXX: -resource-dir foo
 // CHECK-I686-CXX: -internal-isystem 
{{.*}}{{/|}}..{{/|}}x86_64-nacl{{/|}}include{{/|}}c++{{/|}}v1
 // CHECK-I686-CXX: -internal-isystem foo{{/|}}include
-// CHECK-I686-CXX: -internal-isystem 
{{.*}}{{/|}}..{{/|}}x86_64-nacl{{/|}}usr{{/|}}include
+// CHECK-I686-CXX: -internal-isystem 
{{.*}}{{/|}}..{{/|}}i686-nacl{{/|}}usr{{/|}}include
 // CHECK-I686-CXX: -internal-isystem 
{{.*}}{{/|}}..{{/|}}x86_64-nacl{{/|}}include
 // CHECK-I686-CXX: -lpthread
 


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


Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread David Li via cfe-commits
davidxl added a comment.

We certainly need a fix without breaking ABI. Is there a ABI conformance test 
for libcxx?


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12359: New warning -Wnonconst-parameter when a pointer parameter can be const

2015-08-26 Thread Stephan Bergmann via cfe-commits
sberg added a subscriber: sberg.
sberg added a comment.

causes false positive for

  char * f(char *);
  char * g(char * p) { return f(p); }


http://reviews.llvm.org/D12359



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


Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

I think I'm starting to understand but I think the correct fix for this would 
be to fix function so that:

1. It aligns its buffer by alignof(void*).
2. It doesn't stick over-aligned types in the small object buffer.

Point two can probably be done without an ABI break, but point one will break 
the ABI.


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12370: Fix another LoopConvert fail.

2015-08-26 Thread Alexander Kornienko via cfe-commits
alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG


http://reviews.llvm.org/D12370



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


[PATCH] D12368: Add a clang release note about raising the minimum Windows version for the next major release

2015-08-26 Thread Greg Bedwell via cfe-commits
gbedwell created this revision.
gbedwell added reviewers: hans, rnk, aaron.ballman.
gbedwell added a subscriber: cfe-commits.

This is a clang release note to match the LLVM release note in D12367.

As we're planning on raising the minimum Windows version to Windows 7 for LLVM 
3.8 as per this discussion (there have been no objections I'm aware of so far 
even after advertising the discussion in LLVM weekly):
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-July/087993.html
I'd like to add a release note to mention this fact. 

http://reviews.llvm.org/D12368

Files:
  docs/ReleaseNotes.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -243,6 +243,12 @@
   boolean constants and simplifies them to use the appropriate boolean
   expression directly (``if (x == true) ... - if (x)``, etc.)
 
+Last release which will run on Windows XP and Windows Vista
+---
+
+This is expected to the be the last major release of Clang that will support
+running on Windows XP and Windows Vista.  For the next major release the
+minimum Windows version requirement will be Windows 7.
 
 Additional Information
 ==


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -243,6 +243,12 @@
   boolean constants and simplifies them to use the appropriate boolean
   expression directly (``if (x == true) ... - if (x)``, etc.)
 
+Last release which will run on Windows XP and Windows Vista
+---
+
+This is expected to the be the last major release of Clang that will support
+running on Windows XP and Windows Vista.  For the next major release the
+minimum Windows version requirement will be Windows 7.
 
 Additional Information
 ==
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D12362: [clang-format] Add support of consecutive declarations alignment

2015-08-26 Thread Beren Minor via cfe-commits
berenm added a comment.

Actually, I think there is a bug in the assignment alignment code. Even without 
this patch, this code doesn't align properly:

  int oneTwoThree = 123;
  int oneTwo  = 12;
  method();

I don't think I completely understand the assignment alignment code, and that's 
why mine is slightly rewritten. I will open another request for fixes in the 
assignment alignment code.



Comment at: unittests/Format/FormatTest.cpp:8619
@@ -8618,1 +8618,3 @@
 
+TEST_F(FormatTest, AlignConsecutiveDeclarations) {
+  FormatStyle Alignment = getLLVMStyle();

djasper wrote:
 This needs tests that check what happens if both declarations and assignments 
 are aligned.
Indeed, I will add such tests.


http://reviews.llvm.org/D12362



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


r246037 - [ASTMatchers] Add type matcher for SubstTemplateTypeParmType.

2015-08-26 Thread Samuel Benzaquen via cfe-commits
Author: sbenza
Date: Wed Aug 26 11:15:59 2015
New Revision: 246037

URL: http://llvm.org/viewvc/llvm-project?rev=246037view=rev
Log:
[ASTMatchers] Add type matcher for SubstTemplateTypeParmType.

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=246037r1=246036r2=246037view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Wed Aug 26 11:15:59 2015
@@ -3936,6 +3936,20 @@ AST_MATCHER_P(ElaboratedType, namesType,
   return InnerMatcher.matches(Node.getNamedType(), Finder, Builder);
 }
 
+/// \brief Matches types that represent the result of substituting a type for a
+/// template type parameter.
+///
+/// Given
+/// \code
+///   template typename T
+///   void F(T t) {
+/// int i = 1 + t;
+///   }
+/// \code
+///
+/// \c substTemplateTypeParmType() matches the type of 't' but not '1'
+AST_TYPE_MATCHER(SubstTemplateTypeParmType, substTemplateTypeParmType);
+
 /// \brief Matches declarations whose declaration context, interpreted as a
 /// Decl, matches \c InnerMatcher.
 ///

Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=246037r1=246036r2=246037view=diff
==
--- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Wed Aug 26 11:15:59 2015
@@ -327,6 +327,7 @@ RegistryMaps::RegistryMaps() {
   REGISTER_MATCHER(stmt);
   REGISTER_MATCHER(stringLiteral);
   REGISTER_MATCHER(substNonTypeTemplateParmExpr);
+  REGISTER_MATCHER(substTemplateTypeParmType);
   REGISTER_MATCHER(switchCase);
   REGISTER_MATCHER(switchStmt);
   REGISTER_MATCHER(templateArgument);

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=246037r1=246036r2=246037view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Wed Aug 26 11:15:59 2015
@@ -4331,6 +4331,18 @@ TEST(ElaboratedTypeNarrowing, namesType)
 elaboratedType(elaboratedType(namesType(typedefType());
 }
 
+TEST(TypeMatching, MatchesSubstTemplateTypeParmType) {
+  const std::string code = template typename T
+   int F() {
+ return 1 + T();
+   }
+   int i = Fint();;
+  EXPECT_FALSE(matches(code, binaryOperator(hasLHS(
+ 
expr(hasType(substTemplateTypeParmType()));
+  EXPECT_TRUE(matches(code, binaryOperator(hasRHS(
+expr(hasType(substTemplateTypeParmType()));
+}
+
 TEST(NNS, MatchesNestedNameSpecifiers) {
   EXPECT_TRUE(matches(namespace ns { struct A {}; } ns::A a;,
   nestedNameSpecifier()));


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


[PATCH] D12370: Fix another LoopConvert fail.

2015-08-26 Thread Angel Garcia via cfe-commits
angelgarcia created this revision.
angelgarcia added a reviewer: alexfh.
angelgarcia added subscribers: cfe-commits, klimek.

Prevent LoopConvert from taking as alias anything that comes from a random 
member function call.

http://reviews.llvm.org/D12370

Files:
  clang-tidy/modernize/LoopConvertUtils.cpp
  test/clang-tidy/modernize-loop-convert-extra.cpp

Index: test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- test/clang-tidy/modernize-loop-convert-extra.cpp
+++ test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -207,11 +207,17 @@
   for (dependentint::iterator it = dep.begin(), e = dep.end(); it != e; 
++it) {
 printf(%d\n, *it);
 const int idx = other[0];
+unsigned othersize = other.size();
   }
-  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto  elem : dep)
   // CHECK-FIXES-NEXT: printf(%d\n, elem);
   // CHECK-FIXES-NEXT: const int idx = other[0];
+  // CHECK-FIXES-NEXT: unsigned othersize = other.size();
+
+  for (int i = 0, e = dep.size(); i != e; ++i) {
+int idx = other.at(i);
+  }
 }
 
 } // namespace NamingAlias
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -368,8 +368,14 @@
 break;
   }
 
-  case Stmt::CXXMemberCallExprClass:
-return true;
+  case Stmt::CXXMemberCallExprClass: {
+const auto *MemCall = castCXXMemberCallExpr(Init);
+if (MemCall-getMethodDecl()-getName() == at) {
+  assert(MemCall-getNumArgs() == 1);
+  return isIndexInSubscriptExpr(MemCall-getArg(0), IndexVar);
+}
+return false;
+  }
 
   default:
 break;


Index: test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- test/clang-tidy/modernize-loop-convert-extra.cpp
+++ test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -207,11 +207,17 @@
   for (dependentint::iterator it = dep.begin(), e = dep.end(); it != e; ++it) {
 printf(%d\n, *it);
 const int idx = other[0];
+unsigned othersize = other.size();
   }
-  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto  elem : dep)
   // CHECK-FIXES-NEXT: printf(%d\n, elem);
   // CHECK-FIXES-NEXT: const int idx = other[0];
+  // CHECK-FIXES-NEXT: unsigned othersize = other.size();
+
+  for (int i = 0, e = dep.size(); i != e; ++i) {
+int idx = other.at(i);
+  }
 }
 
 } // namespace NamingAlias
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -368,8 +368,14 @@
 break;
   }
 
-  case Stmt::CXXMemberCallExprClass:
-return true;
+  case Stmt::CXXMemberCallExprClass: {
+const auto *MemCall = castCXXMemberCallExpr(Init);
+if (MemCall-getMethodDecl()-getName() == at) {
+  assert(MemCall-getNumArgs() == 1);
+  return isIndexInSubscriptExpr(MemCall-getArg(0), IndexVar);
+}
+return false;
+  }
 
   default:
 break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r246039 - Fix another LoopConvert fail.

2015-08-26 Thread Angel Garcia Gomez via cfe-commits
Author: angelgarcia
Date: Wed Aug 26 12:08:24 2015
New Revision: 246039

URL: http://llvm.org/viewvc/llvm-project?rev=246039view=rev
Log:
Fix another LoopConvert fail.

Summary: Prevent LoopConvert from taking as alias anything that comes from a 
random member function call.

Reviewers: alexfh

Subscribers: klimek, cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp?rev=246039r1=246038r2=246039view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp Wed Aug 
26 12:08:24 2015
@@ -368,8 +368,14 @@ static bool isAliasDecl(const Decl *TheD
 break;
   }
 
-  case Stmt::CXXMemberCallExprClass:
-return true;
+  case Stmt::CXXMemberCallExprClass: {
+const auto *MemCall = castCXXMemberCallExpr(Init);
+if (MemCall-getMethodDecl()-getName() == at) {
+  assert(MemCall-getNumArgs() == 1);
+  return isIndexInSubscriptExpr(MemCall-getArg(0), IndexVar);
+}
+return false;
+  }
 
   default:
 break;

Modified: 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp?rev=246039r1=246038r2=246039view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp 
Wed Aug 26 12:08:24 2015
@@ -207,11 +207,17 @@ void refs_and_vals() {
   for (dependentint::iterator it = dep.begin(), e = dep.end(); it != e; 
++it) {
 printf(%d\n, *it);
 const int idx = other[0];
+unsigned othersize = other.size();
   }
-  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto  elem : dep)
   // CHECK-FIXES-NEXT: printf(%d\n, elem);
   // CHECK-FIXES-NEXT: const int idx = other[0];
+  // CHECK-FIXES-NEXT: unsigned othersize = other.size();
+
+  for (int i = 0, e = dep.size(); i != e; ++i) {
+int idx = other.at(i);
+  }
 }
 
 } // namespace NamingAlias


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


[PATCH] D12381: [Static Analyzer] Merge the Objective-C Generics Checker into Dynamic Type Propagation checker.

2015-08-26 Thread Gábor Horváth via cfe-commits
xazax.hun created this revision.
xazax.hun added reviewers: krememek, zaks.anna, jordan_rose, dcoughlin.
xazax.hun added a subscriber: cfe-commits.

This patch merged the functionality from ObjCGenericsChecker into 
DynamicTypePropagation checker.
Note that the Generics Checker can still be turned on or off individually but 
this only affects whether diagnostics are generated or not.
There is no intended functional change in this patch.

Rationale:
This is a refactoring that makes some collaboration between the 
ObjCGenericsChecker and DynamicTypePropagation checker possible.
The final goal (which will be achieved by some followup patches) is to use the 
reasoning of ObjCGenericsChecker about generics to infer dynamic type for 
objects.

Lets consider the following scenario:
id object = arrayOfStrings.firstObject;

Here the DynamicTypePropagation checker can not infer any dynamic type 
information because the static type of the arrayOfStrings.firstObject 
expression is id when arrayOfStrings is not annotated. However the generics 
checker might be able to infer an upper bound (NSString *) for the same 
expression from the usage of the symbol. 

In a follow up patch when the DynamicTypePropagation checker fails to infer the 
dynamic type for an object, we would fall back to the inference of the generics 
checker, because it may have additional information.

Impact:

When an exact type is inferred as a dynamic type (this happens when the 
allocation was visible by the analyzer), method calls on that object will be 
devirtualized (inlined).
When the allocation is not visible but an upper bound can be inferred, there 
will be a path split on method calls. On one path the method will be inlined 
(when a body is available) on the other, there will be no inlining. 
There are some heuristic cases, where an upper bound is treated as an exact 
type.

The expected effect of the follow up patch is that, upper bound can be inferred 
more frequently. Due to cross translation unit limits, this might not change 
the inlining behavior significantly. However there are other advantages. 
Utilizing this dynamic type information, a generic type checker could be 
implemented trivially which could catch errors like:

id object = myNSNumber;
NSString *myString = object;

Why not keep the Generics checker and the dynamic type propagation as 
completely separate checks?

One of the problem is that, right now both checkers infer type information from 
casts. In order to be able to fallback to the type inference of Generics 
checker when the type inference of dynamic type propagation failed, the 
Generics checker should assume that the dynamic type propagation is done 
already by the time its callback is invoked. Since there is no way to specify 
ordering between the checkers right now, the only way to do it correctly is to 
merge two checks into one checker.

What do you think?

http://reviews.llvm.org/D12381

Files:
  lib/StaticAnalyzer/Checkers/CMakeLists.txt
  lib/StaticAnalyzer/Checkers/Checkers.td
  lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
  lib/StaticAnalyzer/Checkers/ObjCGenericsChecker.cpp
  test/Analysis/generics.m

Index: test/Analysis/generics.m
===
--- test/Analysis/generics.m
+++ test/Analysis/generics.m
@@ -418,7 +418,7 @@
 // CHECK:keydescription/keystringIncompatible pointer types assigning to apos;NSArraylt;NSNumber *gt; *apos; from apos;NSArraylt;NSString *gt; *apos;/string
 // CHECK:keycategory/keystringCore Foundation/Objective-C/string
 // CHECK:keytype/keystringGenerics/string
-// CHECK:keycheck_name/keystringalpha.osx.cocoa.ObjCGenerics/string
+// CHECK:keycheck_name/keystringcore.DynamicTypePropagation/string
 // CHECK:   keyissue_context_kind/keystringfunction/string
 // CHECK:   keyissue_context/keystringincompatibleTypesErased/string
 // CHECK:   keyissue_hash/keystring2/string
@@ -528,7 +528,7 @@
 // CHECK:keydescription/keystringIncompatible pointer types assigning to apos;NSString *apos; from apos;NSNumber *apos;/string
 // CHECK:keycategory/keystringCore Foundation/Objective-C/string
 // CHECK:keytype/keystringGenerics/string
-// CHECK:keycheck_name/keystringalpha.osx.cocoa.ObjCGenerics/string
+// CHECK:keycheck_name/keystringcore.DynamicTypePropagation/string
 // CHECK:   keyissue_context_kind/keystringfunction/string
 // CHECK:   keyissue_context/keystringincompatibleTypesErased/string
 // CHECK:   keyissue_hash/keystring3/string
@@ -672,7 +672,7 @@
 // CHECK:keydescription/keystringIncompatible pointer types assigning to apos;NSArraylt;NSNumber *gt; *apos; from apos;NSArraylt;NSString *gt; *apos;/string
 // CHECK:keycategory/keystringCore Foundation/Objective-C/string
 // CHECK:keytype/keystringGenerics/string
-// CHECK:keycheck_name/keystringalpha.osx.cocoa.ObjCGenerics/string
+// CHECK:keycheck_name/keystringcore.DynamicTypePropagation/string
 // CHECK:   

Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

In http://reviews.llvm.org/D12247#233595, @yiranwang wrote:

 In http://reviews.llvm.org/D12247#233349, @EricWF wrote:

  In http://reviews.llvm.org/D12247#233323, @davidxl wrote:
 
   We certainly need a fix without breaking ABI. Is there a ABI conformance 
   test for libcxx?
 
 
  Well this patch definitely breaks the ABI. This was my attempt at fixing 
  the problem in `std::function` that might not be ABI breaking..
   https://gist.github.com/EricWF/3a35b140a66d4826a9


 I think following your thought, we should abandon the usage of 
 aligned_storage in function totally. Instead, just say void 
 *__buf_[3];, and check alignment_of _Fp (can be arbitrarily big, but usually 
 small), and sizeof the two to guard use of __buf_. The alignment bump to 16 
 by aligned_storage on AARCH64 is not what we want, performance wise.


Sort of. I wouldn't abandon the use of `aligned_storage` in function but I 
would change it from `aligned_storage3*sizeof(void*)::type` to 
`aligned_storage3*sizeof(void*), alignof(void*)::type`. That would have 
eventually the same behavior your describing.

The reason that I haven't made that change is that it is ABI breaking.

 Also, such kind of change need to applied for some more places, at least in 
 libc++, such like libcxx/include/future


Yes it would.


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12313: Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

2015-08-26 Thread Richard Smith via cfe-commits
rsmith added inline comments.


Comment at: include/clang/Basic/Builtins.def:1249-1255
@@ +1248,9 @@
+BUILTIN(__builtin_nontemporal_store, v., t)
+BUILTIN(__builtin_nontemporal_store_1, vcc*., )
+BUILTIN(__builtin_nontemporal_store_2, vss*., )
+BUILTIN(__builtin_nontemporal_store_4, vii*., )
+BUILTIN(__builtin_nontemporal_store_8, vLLiLLi*., )
+BUILTIN(__builtin_nontemporal_store_16, vLLLiLLLi*., )
+BUILTIN(__builtin_nontemporal_store_f, vff*., )
+BUILTIN(__builtin_nontemporal_store_d, vdd*., )
+

Do we need these typed versions?


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:6198-6203
@@ +6197,8 @@
+  address argument to nontemporal builtin must be a pointer (%0 invalid);
+def err_nontemporal_builtin_must_be_pointer_intfltptr : Error
+  address argument to nontemporal builtin must be a pointer to integer, float 

+  or pointer (%0 invalid);
+def err_nontemporal_builtin_pointer_size : Error
+  address argument to nontemporal builtin must be a pointer to 1,2,4,8 or 16 
+  byte type (%0 invalid);
+

Nontemporal loads and stores of, say, vector types seem useful, but I can 
understand if you want to restrict the complexity of the CodeGen changes here.


Comment at: lib/CodeGen/CGBuiltin.cpp:128-129
@@ +127,4 @@
+  // Convert the type of the pointer to a pointer to the stored type.
+  Value *BC = CGF.Builder.CreateBitCast(
+  Address, llvm::PointerType::getUnqual(ValueTy), cast);
+  StoreInst *SI = CGF.Builder.CreateStore(Val, BC);

You should pass `Val` through `EmitToMemory` first to widen `bool` from `i1` to 
`i8`.


Comment at: lib/CodeGen/CGBuiltin.cpp:149
@@ +148,3 @@
+  LI-setAlignment(Align);
+  return LI;
+}

Likewise, you should pass this though `EmitFromMemory`.


Comment at: lib/Sema/SemaChecking.cpp:2235-2241
@@ +2234,9 @@
+
+  // Ensure that we have at least one argument to do type inference from.
+  if (TheCall-getNumArgs()  numArgs) {
+Diag(TheCall-getLocEnd(), diag::err_typecheck_call_too_few_args_at_least)
+ 0  1  TheCall-getNumArgs()
+ TheCall-getCallee()-getSourceRange();
+return ExprError();
+  }
+

You should also reject calls with too many arguments here. Maybe just call 
`checkArgCount(*this, TheCall, numArgs)`?


Comment at: lib/Sema/SemaChecking.cpp:2275-2357
@@ +2274,85 @@
+
+#define BUILTIN_ROW(x) 
\
+  { Builtin::BI##x##_1, Builtin::BI##x##_2, Builtin::BI##x##_4,
\
+Builtin::BI##x##_8, Builtin::BI##x##_16,   
\
+Builtin::BI##x##_f, Builtin::BI##x##_d }
+
+  static const unsigned BuiltinIndices[][7] = {
+  BUILTIN_ROW(__builtin_nontemporal_store),
+  BUILTIN_ROW(__builtin_nontemporal_load)
+  };
+#undef BUILTIN_ROW
+
+  // Determine the index of the size.
+  unsigned SizeIndex;
+  if (ValType-isFloatingType()) {
+switch (Context.getTypeSizeInChars(ValType).getQuantity()) {
+case 4: SizeIndex = 5; break;
+case 8: SizeIndex = 6; break;
+default:
+  Diag(DRE-getLocStart(), diag::err_nontemporal_builtin_pointer_size)
+   AddressArg-getType()  AddressArg-getSourceRange();
+  return ExprError();
+}
+  } else {
+switch (Context.getTypeSizeInChars(ValType).getQuantity()) {
+case 1: SizeIndex = 0; break;
+case 2: SizeIndex = 1; break;
+case 4: SizeIndex = 2; break;
+case 8: SizeIndex = 3; break;
+case 16: SizeIndex = 4; break;
+default:
+  Diag(DRE-getLocStart(), diag::err_nontemporal_builtin_pointer_size)
+   AddressArg-getType()  AddressArg-getSourceRange();
+  return ExprError();
+}
+  }
+  // Get the decl for the concrete builtin from this, we can tell what the
+  // concrete integer type we should convert to is.
+  unsigned NewBuiltinID = BuiltinIndices[isStore ? 0 : 1][SizeIndex];
+  const char *NewBuiltinName = Context.BuiltinInfo.getName(NewBuiltinID);
+
+  // Perform builtin lookup to avoid redeclaring it.
+  DeclarationName DN(Context.Idents.get(NewBuiltinName));
+  LookupResult Res(*this, DN, DRE-getLocStart(), LookupOrdinaryName);
+  LookupName(Res, TUScope, /*AllowBuiltinCreation=*/true);
+  assert(Res.getFoundDecl());
+  FunctionDecl *NewBuiltinDecl = dyn_castFunctionDecl(Res.getFoundDecl());
+  if (!NewBuiltinDecl)
+return ExprError();
+
+  // For stores convert the value (the first argument) to the type of the
+  // pointer (the second argument).
+  if (isStore) {
+ExprResult Arg = TheCall-getArg(0);
+InitializedEntity Entity = InitializedEntity::InitializeParameter(
+Context, ValType, /*consume*/ false);
+Arg = PerformCopyInitialization(Entity, SourceLocation(), Arg);
+if (Arg.isInvalid())
+  return ExprError();
+
+TheCall-setArg(0, Arg.get());
+  }
+
+  ASTContext Context = this-getASTContext();
+
+  // Create a new DeclRefExpr 

Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Yiran Wang via cfe-commits
yiranwang added a comment.

In http://reviews.llvm.org/D12247#233349, @EricWF wrote:

 In http://reviews.llvm.org/D12247#233323, @davidxl wrote:

  We certainly need a fix without breaking ABI. Is there a ABI conformance 
  test for libcxx?


 Well this patch definitely breaks the ABI. This was my attempt at fixing the 
 problem in `std::function` that might not be ABI breaking..
  https://gist.github.com/EricWF/3a35b140a66d4826a9


I think following your thought, we should abandon the usage of 
aligned_storage in function totally. Instead, just say void *__buf_[3];, 
and check alignment_of _Fp (can be arbitrarily big, but usually small), and 
sizeof the two to guard use of __buf_. The alignment bump to 16 by 
aligned_storage on AARCH64 is not what we want, performance wise.

Also, such kind of change need to applied for some more places, at least in 
libc++, such like libcxx/include/future


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Yiran Wang via cfe-commits
yiranwang added a comment.

some more explanation of last comment.
For most architecture sizeof(function) is 4*sizeof(void *), but it is 
6*sizeof(void*) on AARCH64/LINUX, which does not sound so great as there are 
padding of 2*sizeof(void*) bytes.


http://reviews.llvm.org/D12247



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


Re: [PATCH] D12355: [libcxx] Optimize away unneeded length calculation in basic_string::compare(const char*)

2015-08-26 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

In http://reviews.llvm.org/D12355#233477, @bkramer wrote:

 Won't this do the wrong thing for embedded '\0' in a std::string?

   std::string(hello\0world, 11).compare(hello)
   

 should not return 0.


Good point; I think that pretty much kills this proposed change.


http://reviews.llvm.org/D12355



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


r246083 - [X86][SSE] Add _mm_undefined_* intrinsics

2015-08-26 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Wed Aug 26 16:17:12 2015
New Revision: 246083

URL: http://llvm.org/viewvc/llvm-project?rev=246083view=rev
Log:
[X86][SSE] Add _mm_undefined_* intrinsics

Added missing SSE/AVX 'undefined' intrinsics (PR24040):

_mm_undefined_pd, _mm_undefined_ps + _mm_undefined_si128
_mm256_undefined_pd, _mm256_undefined_ps + _mm256_undefined_si256
_mm512_undefined, _mm512_undefined_ps, _mm512_undefined_pd + 
_mm512_undefined_epi32

Added builtin intrinsicss:

__builtin_ia32_undef128, __builtin_ia32_undef256 + __builtin_ia32_undef512

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

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/lib/Headers/avxintrin.h
cfe/trunk/lib/Headers/emmintrin.h
cfe/trunk/lib/Headers/xmmintrin.h
cfe/trunk/test/CodeGen/avx-builtins.c
cfe/trunk/test/CodeGen/avx512f-builtins.c
cfe/trunk/test/CodeGen/sse-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=246083r1=246082r2=246083view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Wed Aug 26 16:17:12 2015
@@ -30,6 +30,12 @@
 // can use it?
 BUILTIN(__builtin_cpu_supports, bcC*, nc)
 
+// Undefined Values
+//
+TARGET_BUILTIN(__builtin_ia32_undef128, V2d, nc, )
+TARGET_BUILTIN(__builtin_ia32_undef256, V4d, nc, )
+TARGET_BUILTIN(__builtin_ia32_undef512, V8d, nc, )
+
 // 3DNow!
 //
 TARGET_BUILTIN(__builtin_ia32_femms, v, , 3dnow)

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=246083r1=246082r2=246083view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Aug 26 16:17:12 2015
@@ -6047,6 +6047,10 @@ Value *CodeGenFunction::EmitX86BuiltinEx
 Value *F = CGM.getIntrinsic(Intrinsic::prefetch);
 return Builder.CreateCall(F, {Address, RW, Locality, Data});
   }
+  case X86::BI__builtin_ia32_undef128:
+  case X86::BI__builtin_ia32_undef256:
+  case X86::BI__builtin_ia32_undef512:
+return UndefValue::get(ConvertType(E-getType()));
   case X86::BI__builtin_ia32_vec_init_v8qi:
   case X86::BI__builtin_ia32_vec_init_v4hi:
   case X86::BI__builtin_ia32_vec_init_v2si:

Modified: cfe/trunk/lib/Headers/avx512fintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h?rev=246083r1=246082r2=246083view=diff
==
--- cfe/trunk/lib/Headers/avx512fintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512fintrin.h Wed Aug 26 16:17:12 2015
@@ -57,6 +57,30 @@ _mm512_setzero_si512(void)
   return (__m512i)(__v8di){ 0, 0, 0, 0, 0, 0, 0, 0 };
 }
 
+static __inline__ __m512d __DEFAULT_FN_ATTRS
+_mm512_undefined_pd()
+{
+  return (__m512d)__builtin_ia32_undef512();
+}
+
+static __inline__ __m512 __DEFAULT_FN_ATTRS
+_mm512_undefined()
+{
+  return (__m512)__builtin_ia32_undef512();
+}
+
+static __inline__ __m512 __DEFAULT_FN_ATTRS
+_mm512_undefined_ps()
+{
+  return (__m512)__builtin_ia32_undef512();
+}
+
+static __inline__ __m512i __DEFAULT_FN_ATTRS
+_mm512_undefined_epi32()
+{
+  return (__m512i)__builtin_ia32_undef512();
+}
+
 static __inline __m512i __DEFAULT_FN_ATTRS
 _mm512_maskz_set1_epi32(__mmask16 __M, int __A)
 {

Modified: cfe/trunk/lib/Headers/avxintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avxintrin.h?rev=246083r1=246082r2=246083view=diff
==
--- cfe/trunk/lib/Headers/avxintrin.h (original)
+++ cfe/trunk/lib/Headers/avxintrin.h Wed Aug 26 16:17:12 2015
@@ -900,6 +900,24 @@ _mm256_stream_ps(float *__p, __m256 __a)
 }
 
 /* Create vectors */
+static __inline__ __m256d __DEFAULT_FN_ATTRS
+_mm256_undefined_pd()
+{
+  return (__m256d)__builtin_ia32_undef256();
+}
+
+static __inline__ __m256 __DEFAULT_FN_ATTRS
+_mm256_undefined_ps()
+{
+  return (__m256)__builtin_ia32_undef256();
+}
+
+static __inline__ __m256i __DEFAULT_FN_ATTRS
+_mm256_undefined_si256()
+{
+  return (__m256i)__builtin_ia32_undef256();
+}
+
 static __inline __m256d __DEFAULT_FN_ATTRS
 _mm256_set_pd(double __a, double __b, double __c, double __d)
 {

Modified: cfe/trunk/lib/Headers/emmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/emmintrin.h?rev=246083r1=246082r2=246083view=diff
==
--- cfe/trunk/lib/Headers/emmintrin.h (original)
+++ cfe/trunk/lib/Headers/emmintrin.h Wed Aug 26 16:17:12 2015
@@ -523,6 +523,12 @@ _mm_loadl_pd(__m128d __a, double const *
 }
 
 static __inline__ __m128d 

Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

In http://reviews.llvm.org/D12247#233717, @yiranwang wrote:

 Hi Eric,

 Could you please explain a bit more what is broken specifically? As we can 
 see, sizeof(), _Len, and _Align, and alignof() of aligned_storage are all 
 not changed.


That's correct. At the risk of sounding like a broken record those fields have 
not changed because doing so would break the ABI. Instead my patch fixes the 
issue your seeing by simply not using __buf_ unless its the correct size and 
correctly aligned.

The alignment is the important part. Previously we didn't check if `Fn` was 
alignment compatible with `__buf_`.


http://reviews.llvm.org/D12247



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


r246099 - DI: Update DISubprogram testcases after LLVM r246098

2015-08-26 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Wed Aug 26 17:50:48 2015
New Revision: 246099

URL: http://llvm.org/viewvc/llvm-project?rev=246099view=rev
Log:
DI: Update DISubprogram testcases after LLVM r246098

Modified:
cfe/trunk/test/CodeGen/debug-info-scope-file.c
cfe/trunk/test/CodeGenCXX/PR20038.cpp
cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
cfe/trunk/test/CodeGenCXX/debug-info-windows-dtor.cpp
cfe/trunk/test/CodeGenCXX/debug-info.cpp
cfe/trunk/test/CodeGenCXX/debug-lambda-expressions.cpp
cfe/trunk/test/CodeGenCXX/linetable-fnbegin.cpp
cfe/trunk/test/CodeGenCXX/linetable-virtual-variadic.cpp
cfe/trunk/test/CodeGenObjC/arc-linetable.m
cfe/trunk/test/CodeGenObjC/debug-info-blocks.m

Modified: cfe/trunk/test/CodeGen/debug-info-scope-file.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info-scope-file.c?rev=246099r1=246098r2=246099view=diff
==
--- cfe/trunk/test/CodeGen/debug-info-scope-file.c (original)
+++ cfe/trunk/test/CodeGen/debug-info-scope-file.c Wed Aug 26 17:50:48 2015
@@ -5,8 +5,8 @@
 
 // CHECK: ret void, !dbg [[F1_LINE:![0-9]*]]
 // CHECK: ret void, !dbg [[F2_LINE:![0-9]*]]
-// CHECK: [[F1:![0-9]*]] = !DISubprogram(name: f1,{{.*}} isDefinition: true
-// CHECK: [[F2:![0-9]*]] = !DISubprogram(name: f2,{{.*}} isDefinition: true
+// CHECK: [[F1:![0-9]*]] = distinct !DISubprogram(name: f1,{{.*}} 
isDefinition: true
+// CHECK: [[F2:![0-9]*]] = distinct !DISubprogram(name: f2,{{.*}} 
isDefinition: true
 // CHECK: [[F1_LINE]] = !DILocation({{.*}}, scope: [[F1]])
 // CHECK: [[F2_LINE]] = !DILocation({{.*}}, scope: [[F2]])
 

Modified: cfe/trunk/test/CodeGenCXX/PR20038.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/PR20038.cpp?rev=246099r1=246098r2=246099view=diff
==
--- cfe/trunk/test/CodeGenCXX/PR20038.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/PR20038.cpp Wed Aug 26 17:50:48 2015
@@ -6,8 +6,8 @@ struct C {
 extern bool b;
 // CHECK: call {{.*}}, !dbg [[DTOR_CALL1_LOC:![0-9]*]]
 // CHECK: call {{.*}}, !dbg [[DTOR_CALL2_LOC:![0-9]*]]
-// CHECK: [[FUN1:.*]] = !DISubprogram(name: fun1,{{.*}} isDefinition: true
-// CHECK: [[FUN2:.*]] = !DISubprogram(name: fun2,{{.*}} isDefinition: true
+// CHECK: [[FUN1:.*]] = distinct !DISubprogram(name: fun1,{{.*}} 
isDefinition: true
+// CHECK: [[FUN2:.*]] = distinct !DISubprogram(name: fun2,{{.*}} 
isDefinition: true
 // CHECK: [[DTOR_CALL1_LOC]] = !DILocation(line: [[@LINE+1]], scope: [[FUN1]])
 void fun1() { b  (C(), 1); }
 // CHECK: [[DTOR_CALL2_LOC]] = !DILocation(line: [[@LINE+1]], scope: [[FUN2]])

Modified: cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp?rev=246099r1=246098r2=246099view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp Wed Aug 26 17:50:48 2015
@@ -67,10 +67,10 @@ void B::func_fwd() {}
 // CHECK: [[BAR:![0-9]+]] = !DICompositeType(tag: DW_TAG_structure_type, name: 
bar,
 // CHECK-SAME:   line: 6
 // CHECK-SAME:   DIFlagFwdDecl
-// CHECK: [[F1:![0-9]+]] = !DISubprogram(name: f1,{{.*}} line: 4
+// CHECK: [[F1:![0-9]+]] = distinct !DISubprogram(name: f1,{{.*}} line: 4
 // CHECK-SAME:   isDefinition: true
-// CHECK: [[FUNC:![0-9]+]] = !DISubprogram(name: func,{{.*}} isDefinition: 
true
-// CHECK: [[FUNC_FWD:![0-9]+]] = !DISubprogram(name: func_fwd,{{.*}} line: 
47,{{.*}} isDefinition: true
+// CHECK: [[FUNC:![0-9]+]] = distinct !DISubprogram(name: func,{{.*}} 
isDefinition: true
+// CHECK: [[FUNC_FWD:![0-9]+]] = distinct !DISubprogram(name: 
func_fwd,{{.*}} line: 47,{{.*}} isDefinition: true
 // CHECK: [[I:![0-9]+]] = !DIGlobalVariable(name: i,{{.*}} scope: [[NS]],
 // CHECK: [[VAR_FWD:![0-9]+]] = !DIGlobalVariable(name: var_fwd,{{.*}} 
scope: [[NS]],
 // CHECK-SAME:line: 44

Modified: cfe/trunk/test/CodeGenCXX/debug-info-windows-dtor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-windows-dtor.cpp?rev=246099r1=246098r2=246099view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-windows-dtor.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-windows-dtor.cpp Wed Aug 26 17:50:48 
2015
@@ -18,5 +18,5 @@ template struct ABint;
 // CHECK: call {{.*}}@\01??_G?$AB@H@@UAEPAXI@Z({{.*}}) #{{[0-9]*}}, !dbg 
[[THUNK_LOC:![0-9]*]]
 // CHECK-LABEL: define
 
-// CHECK: [[THUNK_VEC_DEL_DTOR:![0-9]*]] = !DISubprogram({{.*}}function: 
{{.*}}@\01??_E?$AB@H@@W3AEPAXI@Z
+// CHECK: [[THUNK_VEC_DEL_DTOR:![0-9]*]] = distinct 
!DISubprogram({{.*}}function: 

Re: [PATCH] __attribute__((enable_if)) and non-overloaded member functions

2015-08-26 Thread Ettore Speziale via cfe-commits
Forward to the right ML:

 Sorry about the extreme delay. This patch slipped through the cracks, and I 
 only noticed it again when searching my email for enable_if. Committed in 
 r245985! In the future, please feel free to continue pinging weekly!
 
 NP, thank you for committing the patch.
 
 Unfortunately it contains a little error in the case of no candidate has been 
 found. For instance consider the following test case:
 
 struct Incomplete;
 
 struct X {
 void hidden_by_argument_conversion(Incomplete n, int m = 0) 
 __attribute((enable_if(m == 10, chosen when 'm' is ten)));
 };
 
 x.hidden_by_argument_conversion(10);
 
 I would expect to get an error about Incomplete, as the compiler cannot 
 understand how to convert 10 into an instance of Incomplete. However right 
 now the enable_if diagnostic is emitted, thus masking the more useful message 
 about Incomplete.
 
 The attached patch solved the problem by delaying the point where the 
 enable_if diagnostic is issued.
 
 Thanks,
 Ettore Speziale




enable_if.diff
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D12368: Add a clang release note about raising the minimum Windows version for the next major release

2015-08-26 Thread Hans Wennborg via cfe-commits
hans added a comment.

Committed in r246090.


http://reviews.llvm.org/D12368



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


Re: [PATCH] D12368: Add a clang release note about raising the minimum Windows version for the next major release

2015-08-26 Thread Hans Wennborg via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL246090: Add a clang release note about raising the minimum 
Windows version for the… (authored by hans).

Changed prior to commit:
  http://reviews.llvm.org/D12368?vs=33208id=33255#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12368

Files:
  cfe/branches/release_37/docs/ReleaseNotes.rst

Index: cfe/branches/release_37/docs/ReleaseNotes.rst
===
--- cfe/branches/release_37/docs/ReleaseNotes.rst
+++ cfe/branches/release_37/docs/ReleaseNotes.rst
@@ -247,6 +247,12 @@
   boolean constants and simplifies them to use the appropriate boolean
   expression directly (``if (x == true) ... - if (x)``, etc.)
 
+Last release which will run on Windows XP and Windows Vista
+---
+
+This is expected to the be the last major release of Clang that will support
+running on Windows XP and Windows Vista.  For the next major release the
+minimum Windows version requirement will be Windows 7.
 
 Additional Information
 ==


Index: cfe/branches/release_37/docs/ReleaseNotes.rst
===
--- cfe/branches/release_37/docs/ReleaseNotes.rst
+++ cfe/branches/release_37/docs/ReleaseNotes.rst
@@ -247,6 +247,12 @@
   boolean constants and simplifies them to use the appropriate boolean
   expression directly (``if (x == true) ... - if (x)``, etc.)
 
+Last release which will run on Windows XP and Windows Vista
+---
+
+This is expected to the be the last major release of Clang that will support
+running on Windows XP and Windows Vista.  For the next major release the
+minimum Windows version requirement will be Windows 7.
 
 Additional Information
 ==
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D12385: Generating Assumption loads fix

2015-08-26 Thread Piotr Padlewski via cfe-commits
Prazek created this revision.
Prazek added reviewers: rsmith, majnemer, rjmccall.
Prazek added a subscriber: cfe-commits.

It wasn't always safe to generate assumption loads. Last time build failed on 
linking of classes like FenceInst because
it didn't introduce any new virtual function, and it had implicit virtual 
destructor.

http://reviews.llvm.org/D12385

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CGVTables.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenCXX/template-instantiation.cpp
  test/CodeGenCXX/thunks.cpp
  test/CodeGenCXX/vtable-assume-load.cpp
  test/CodeGenCXX/vtable-available-externally.cpp

Index: test/CodeGenCXX/vtable-available-externally.cpp
===
--- test/CodeGenCXX/vtable-available-externally.cpp
+++ test/CodeGenCXX/vtable-available-externally.cpp
@@ -184,8 +184,8 @@
 }  // Test8
 
 namespace Test9 {
-// all virtual functions are outline, so we can assume that it will
-// be generated in translation unit where foo is defined
+// All virtual functions are outline, so we can assume that it will
+// be generated in translation unit where foo is defined.
 // CHECK-TEST9-DAG: @_ZTVN5Test91AE = available_externally unnamed_addr constant
 // CHECK-TEST9-DAG: @_ZTVN5Test91BE = available_externally unnamed_addr constant
 struct A {
@@ -217,23 +217,23 @@
 };
 void A::foo() {}
 
-// Because key function is inline we will generate vtable as linkonce_odr
+// Because key function is inline we will generate vtable as linkonce_odr.
 // CHECK-TEST10-DAG: @_ZTVN6Test101DE = linkonce_odr unnamed_addr constant
 struct D : A {
   void bar();
 };
 inline void D::bar() {}
 
-// because B has outline key function then we can refer to
+// Because B has outline all virtual functions, we can refer to them.
 // CHECK-TEST10-DAG: @_ZTVN6Test101BE = available_externally unnamed_addr constant
 struct B : A {
   void foo();
   void bar();
 };
 
 // C's key function (car) is outline, but C has inline virtual function so we
 // can't guarantee that we will be able to refer to bar from name
-// so (at the moment) we can't emit vtable available_externally
+// so (at the moment) we can't emit vtable available_externally.
 // CHECK-TEST10-DAG: @_ZTVN6Test101CE = external unnamed_addr constant
 struct C : A {
   void bar() {}   // defined in body - not key function
@@ -365,4 +365,3 @@
 }
 }
 
-
Index: test/CodeGenCXX/vtable-assume-load.cpp
===
--- test/CodeGenCXX/vtable-assume-load.cpp
+++ test/CodeGenCXX/vtable-assume-load.cpp
@@ -6,7 +6,9 @@
 // RUN: FileCheck --check-prefix=CHECK3 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK4 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK-MS --input-file=%t.ms.ll %s
-
+// RUN: FileCheck --check-prefix=CHECK6 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK7 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK8 --input-file=%t.ll %s
 namespace test1 {
 
 struct A {
@@ -150,17 +152,17 @@
 }
 } // test4
 
-namespace test5 {
+namespace testMS {
 
 struct __declspec(novtable) S {
   virtual void foo();
 };
 
 void g(S s) { s.foo(); }
 
 // if struct has novtable specifier, then we can't generate assumes
-// CHECK-MS-LABEL: define void @\01?test@test5@@YAXXZ()
-// CHECK-MS: call x86_thiscallcc %struct.test5::S* @\01??0S@test5@@QAE@XZ(
+// CHECK-MS-LABEL: define void @\01?test@testMS@@YAXXZ()
+// CHECK-MS: call x86_thiscallcc %struct.testMS::S* @\01??0S@testMS@@QAE@XZ(
 // CHECK-MS-NOT: @llvm.assume
 // CHECK-MS-LABEL: }
 
@@ -170,3 +172,123 @@
 }
 
 } // test5
+
+namespace test6 {
+// CHECK6: @_ZTVN5test61AE = external
+struct A {
+  A();
+  virtual void foo();
+  virtual ~A() {}
+};
+struct B : A {
+  B();
+};
+// Because A's vtable is external, it's safe to generate assumption loads.
+// CHECK6-LABEL: define void @_ZN5test61gEv()
+// CHECK6: call void @_ZN5test61AC1Ev(
+// CHECK6: call void @llvm.assume(
+
+// We can't emit assumption loads for B, because if we would refer to vtable
+// it would refer to functions that will not be able to find (like implicit
+// inline destructor).
+
+// CHECK6-LABEL:   call void @_ZN5test61BC1Ev(
+// CHECK6-NOT: call void @llvm.assume(
+// CHECK6-LABEL: }
+void g() {
+  A *a = new A;
+  B *b = new B;
+}
+
+}
+
+namespace test7 {
+// Because A's key function is defined here, vtable is generated in this TU
+// CHECK7: @_ZTVN5test71AE = unnamed_addr constant
+struct A {
+  A();
+  virtual void foo();
+  virtual void bar();
+};
+void A::foo() {}
+
+// CHECK7-LABEL: define void @_ZN5test71gEv()
+// CHECK7: call void @_ZN5test71AC1Ev(
+// CHECK7: call void @llvm.assume(
+// CHECK7-LABEL: }
+void g() {
+  A *a = new A();
+  a-bar();
+}
+}
+
+namespace test8 {
+
+struct A {
+  virtual void foo();
+  virtual void bar();
+};
+
+// CHECK8-DAG: @_ZTVN5test81BE = available_externally unnamed_addr constant
+struct 

Re: [PATCH] D12375: [PATCH] Relax parse ordering rules for attributes

2015-08-26 Thread Aaron Ballman via cfe-commits
On Wed, Aug 26, 2015 at 4:30 PM, Richard Smith rich...@metafoo.co.uk wrote:
 On Wed, Aug 26, 2015 at 11:27 AM, Aaron Ballman aaron.ball...@gmail.com
 wrote:

 aaron.ballman created this revision.
 aaron.ballman added reviewers: rsmith, hans.
 aaron.ballman added a subscriber: cfe-commits.

 PR24559 brings up a long-standing issue in Clang where attribute order
 with differing syntax impacts whether a parse will succeed or fail with poor
 diagnostics. For instance:

 struct __attribute__((lockable)) __declspec(dllexport) S { }; // ok
 struct __declspec(dllexport) __attribute__((lockable)) T { }; // error
 about declaring anonymous structs and a warning about declarations not
 declaring anything

 When you consider attributes as extraneous semantic information to attach
 to entities, ordering of the attributes really should not matter between the
 various attribute syntaxes we support -- they all serve the same purpose.

 This patch begins to address the issue by providing a
 MaybeParseAttributes() function accepting a mask of what attribute syntaxes
 are allowed and parses the various syntaxes in a loop.

 However, this patch is not complete, as the test cases for function
 attributes currently fail for the C++11-style attributes.

 [[noreturn]] __attribute__((cdecl)) __declspec(dllexport) void f();

 In this case, the [[noreturn]] is parsed as part of the top-level
 declaration, while the GNU and declspec attributes are parsed as part of the
 declaration specifier, and everything is accepted.

 __attribute__((cdecl)) [[noreturn]] __declspec(dllexport) void f();

 In this case, nothing is parsed as part of the top-level declaration, and
 everything is parsed as part of the declaration specifier. However, the C++
 attribute is prohibited from appearing on a declaration specifier and so is
 diagnosed.

 That seems like pedantically correct behavior to me. C++ attributes at the
 start of the declaration appertain to the declared entities; C++ attributes
 after a decl-specifier, declarator, or id-expression appertain to that
 decl-specifier, declarator, or entity. Conversely, a GNU attribute or MS
 attribute (in this position) is a decl-specifier.

I agree with that assessment, thank you for reminding me that C++
attributes can apply to decl-specifiers. I still find it unsatisfying
from a usability perspective at the same time. While the GNU or MS
attribute in that position is a decl-specifier, it's also an
attribute. Do we want users thinking about what position an attribute
needs to be in to not be a decl-specifier? Then again, any reordering
we allow now would be really painful to deal with for anyone
(including the standards body) who wants an attribute to appertain to
the decl-specifier.

 I don't think that these cases are fundamentally different from this
 perspective:

 [[noreturn]] inline void f();
 [[noreturn]] __attribute__((gnu_inline)) void f();

 inline [[noreturn]] void f(); // ill-formed
 __attribute__((gnu_inline)) [[noreturn]] void f(); // ill-formed?

 Rejecting the last of these cases may not seem especially user-friendly, but
 we should do everything we can to avoid C++11 attributes becoming the morass
 of syntactic soup that __attribute__ has become.

That's definitely true and compelling, and I agree that we need to
tread more lightly than I was. Perhaps a different solution isn't to
allow arbitrary orders, but to instead provide a fixit suggesting the
correct (whatever that means with all these vendor extensions being
used at once) ordering. However, such a mechanism would still require
us to be able to parse funky orders in order to slide things around to
where they should be (and would make it really hard to have a C++
attribute apply to a decl-specifier), so that idea may be problematic
and time consuming too.

 (Also, I'd note that allowing reordering of C++11 and GNU attributes is not
 GCC-compatible; our current permitted ordering is intended to be GCC
 compatible. If we go ahead with your patch, you should at least add a
 -Wgcc-compat warning for it.)

If I understand correctly, it seems like __attribute__ and __declspec
should always be interchangeable, while [[]] should never be (and I
have no ideas on Microsoft [] attributes as there's no grammar, but I
could research this)? If that's the case, I can provide a modified
patch and some good test cases with comments explaining what's going
on.

Thanks!

~Aaron


 I think ParseDeclarationSpecifiers() needs to accept a
 ParsedAttributesWithRange object representing the top-level declaration
 attributes, and the parser needs to attach the C++ attributes to it up until
 we the first non-attribute token is found. But I'm not 100% certain that's
 the right approach.

 Before taking the process further, I was wondering about two things:

 1) Is the direction with MaybeParseAttributes() an acceptable approach?
 2) If it is, is it reasonable to commit that, and work on the
 ParseDeclarationSpecifiers() portion in a follow-up commit?

 

Re: [PATCH] D12375: [PATCH] Relax parse ordering rules for attributes

2015-08-26 Thread Richard Smith via cfe-commits
On Wed, Aug 26, 2015 at 1:55 PM, Aaron Ballman aaron.ball...@gmail.com
wrote:

 On Wed, Aug 26, 2015 at 4:30 PM, Richard Smith rich...@metafoo.co.uk
 wrote:
  On Wed, Aug 26, 2015 at 11:27 AM, Aaron Ballman aaron.ball...@gmail.com
 
  wrote:
 
  aaron.ballman created this revision.
  aaron.ballman added reviewers: rsmith, hans.
  aaron.ballman added a subscriber: cfe-commits.
 
  PR24559 brings up a long-standing issue in Clang where attribute order
  with differing syntax impacts whether a parse will succeed or fail with
 poor
  diagnostics. For instance:
 
  struct __attribute__((lockable)) __declspec(dllexport) S { }; // ok
  struct __declspec(dllexport) __attribute__((lockable)) T { }; // error
  about declaring anonymous structs and a warning about declarations not
  declaring anything
 
  When you consider attributes as extraneous semantic information to
 attach
  to entities, ordering of the attributes really should not matter
 between the
  various attribute syntaxes we support -- they all serve the same
 purpose.
 
  This patch begins to address the issue by providing a
  MaybeParseAttributes() function accepting a mask of what attribute
 syntaxes
  are allowed and parses the various syntaxes in a loop.
 
  However, this patch is not complete, as the test cases for function
  attributes currently fail for the C++11-style attributes.
 
  [[noreturn]] __attribute__((cdecl)) __declspec(dllexport) void f();
 
  In this case, the [[noreturn]] is parsed as part of the top-level
  declaration, while the GNU and declspec attributes are parsed as part
 of the
  declaration specifier, and everything is accepted.
 
  __attribute__((cdecl)) [[noreturn]] __declspec(dllexport) void f();
 
  In this case, nothing is parsed as part of the top-level declaration,
 and
  everything is parsed as part of the declaration specifier. However, the
 C++
  attribute is prohibited from appearing on a declaration specifier and
 so is
  diagnosed.
 
  That seems like pedantically correct behavior to me. C++ attributes at
 the
  start of the declaration appertain to the declared entities; C++
 attributes
  after a decl-specifier, declarator, or id-expression appertain to that
  decl-specifier, declarator, or entity. Conversely, a GNU attribute or MS
  attribute (in this position) is a decl-specifier.

 I agree with that assessment, thank you for reminding me that C++
 attributes can apply to decl-specifiers. I still find it unsatisfying
 from a usability perspective at the same time. While the GNU or MS
 attribute in that position is a decl-specifier, it's also an
 attribute. Do we want users thinking about what position an attribute
 needs to be in to not be a decl-specifier?


In an ideal world, we'd get people to stop using the non-C++11 attribute
syntaxes entirely -- then the problem would not arise :)

Then again, any reordering
 we allow now would be really painful to deal with for anyone
 (including the standards body) who wants an attribute to appertain to
 the decl-specifier.

  I don't think that these cases are fundamentally different from this
  perspective:
 
  [[noreturn]] inline void f();
  [[noreturn]] __attribute__((gnu_inline)) void f();
 
  inline [[noreturn]] void f(); // ill-formed
  __attribute__((gnu_inline)) [[noreturn]] void f(); // ill-formed?
 
  Rejecting the last of these cases may not seem especially user-friendly,
 but
  we should do everything we can to avoid C++11 attributes becoming the
 morass
  of syntactic soup that __attribute__ has become.

 That's definitely true and compelling, and I agree that we need to
 tread more lightly than I was. Perhaps a different solution isn't to
 allow arbitrary orders, but to instead provide a fixit suggesting the
 correct (whatever that means with all these vendor extensions being
 used at once) ordering. However, such a mechanism would still require
 us to be able to parse funky orders in order to slide things around to
 where they should be (and would make it really hard to have a C++
 attribute apply to a decl-specifier), so that idea may be problematic
 and time consuming too.


It'd be good to at least diagnose these attribute order issues better, even
if we can't easily provide a fix-it hint or recover elegantly.

 (Also, I'd note that allowing reordering of C++11 and GNU attributes is
 not
  GCC-compatible; our current permitted ordering is intended to be GCC
  compatible. If we go ahead with your patch, you should at least add a
  -Wgcc-compat warning for it.)

 If I understand correctly, it seems like __attribute__ and __declspec
 should always be interchangeable, while [[]] should never be (and I
 have no ideas on Microsoft [] attributes as there's no grammar, but I
 could research this)? If that's the case, I can provide a modified
 patch and some good test cases with comments explaining what's going
 on.


That sounds like a good approach to me. It also matches MinGW behavior as I
recall it (one of __declspec and __attribute__ is #defined to 

[PATCH] D12379: Fix the bugs in the mapDiagnosticRanges (Still in progress)

2015-08-26 Thread Zhengkai Wu via cfe-commits
zhengkai created this revision.
zhengkai added a reviewer: rtrieu.
zhengkai added a subscriber: cfe-commits.

Use a new algorithm to find map back the ranges to its spelling locations.

But the function is not working properly either, and it breaks a test.

In the last case in the test file 
/llvm/tools/clang/test/Misc/caret-diags-macros.c,
it underlined the wrong range. This is reported as a bug in 
https://llvm.org/bugs/show_bug.cgi?id=24592.

The methods which are used to map back the source locations in the macro 
expansions are questionable in the SourceManager Class.

http://reviews.llvm.org/D12379

Files:
  lib/Frontend/DiagnosticRenderer.cpp
  test/Index/fix-its.m
  test/Misc/caret-diags-macros.c
  test/Misc/serialized-diags.c

Index: test/Misc/serialized-diags.c
===
--- test/Misc/serialized-diags.c
+++ test/Misc/serialized-diags.c
@@ -55,7 +55,6 @@
 // CHECK: Range: {{.*[/\\]}}serialized-diags.c:22:3 {{.*[/\\]}}serialized-diags.c:22:6
 // CHECK: Range: {{.*[/\\]}}serialized-diags.c:22:13 {{.*[/\\]}}serialized-diags.c:22:18
 // CHECK: +-{{.*[/\\]}}serialized-diags.c:20:15: note: expanded from macro 'false' []
-// CHECK: +-Range: {{.*[/\\]}}serialized-diags.c:22:3 {{.*[/\\]}}serialized-diags.c:22:6
 // CHECK: +-Range: {{.*[/\\]}}serialized-diags.c:20:15 {{.*[/\\]}}serialized-diags.c:20:16
 // CHECK: +-{{.*[/\\]}}serialized-diags.c:19:1: note: 'taz' declared here []
 // CHECK: {{.*[/\\]}}serialized-diags.h:5:7: warning: incompatible integer to pointer conversion initializing 'char *' with an expression of type 'int' [-Wint-conversion]
Index: test/Misc/caret-diags-macros.c
===
--- test/Misc/caret-diags-macros.c
+++ test/Misc/caret-diags-macros.c
@@ -16,9 +16,6 @@
 void bar() {
   C(1);
   // CHECK: {{.*}}:17:5: warning: expression result unused
-  // CHECK: {{.*}}:15:16: note: expanded from macro 'C'
-  // CHECK: {{.*}}:14:16: note: expanded from macro 'B'
-  // CHECK: {{.*}}:13:14: note: expanded from macro 'A'
 }
 
 // rdar://7597492
@@ -41,48 +38,45 @@
 
 void test() {
   macro_args3(11);
-  // CHECK: {{.*}}:43:15: warning: expression result unused
+  // CHECK: {{.*}}:40:15: warning: expression result unused
   // Also check that the 'caret' printing agrees with the location here where
   // its easy to FileCheck.
   // CHECK-NEXT:  macro_args3(11);
   // CHECK-NEXT: {{^  \^~}}
-  // CHECK: {{.*}}:36:36: note: expanded from macro 'macro_args3'
-  // CHECK: {{.*}}:35:36: note: expanded from macro 'macro_args2'
-  // CHECK: {{.*}}:34:24: note: expanded from macro 'macro_args1'
 
   macro_many_args3(
 1,
 2,
 3);
-  // CHECK: {{.*}}:55:5: warning: expression result unused
-  // CHECK: {{.*}}:40:55: note: expanded from macro 'macro_many_args3'
-  // CHECK: {{.*}}:39:55: note: expanded from macro 'macro_many_args2'
-  // CHECK: {{.*}}:38:35: note: expanded from macro 'macro_many_args1'
+  // CHECK: {{.*}}:49:5: warning: expression result unused
+  // CHECK: {{.*}}:37:55: note: expanded from macro 'macro_many_args3'
+  // CHECK: {{.*}}:36:55: note: expanded from macro 'macro_many_args2'
+  // CHECK: {{.*}}:35:35: note: expanded from macro 'macro_many_args1'
 
   macro_many_args3(
 1,
 M2,
 3);
-  // CHECK: {{.*}}:64:5: warning: expression result unused
+  // CHECK: {{.*}}:58:5: warning: expression result unused
   // CHECK: {{.*}}:4:12: note: expanded from macro 'M2'
-  // CHECK: {{.*}}:40:55: note: expanded from macro 'macro_many_args3'
-  // CHECK: {{.*}}:39:55: note: expanded from macro 'macro_many_args2'
-  // CHECK: {{.*}}:38:35: note: expanded from macro 'macro_many_args1'
+  // CHECK: {{.*}}:37:55: note: expanded from macro 'macro_many_args3'
+  // CHECK: {{.*}}:36:55: note: expanded from macro 'macro_many_args2'
+  // CHECK: {{.*}}:35:35: note: expanded from macro 'macro_many_args1'
 
   macro_many_args3(
 1,
 macro_args2(22),
 3);
-  // CHECK: {{.*}}:74:17: warning: expression result unused
+  // CHECK: {{.*}}:68:17: warning: expression result unused
   // This caret location needs to be printed *inside* a different macro's
   // arguments.
   // CHECK-NEXT:macro_args2(22),
   // CHECK-NEXT: {{^\^~}}
-  // CHECK: {{.*}}:35:36: note: expanded from macro 'macro_args2'
-  // CHECK: {{.*}}:34:24: note: expanded from macro 'macro_args1'
-  // CHECK: {{.*}}:40:55: note: expanded from macro 'macro_many_args3'
-  // CHECK: {{.*}}:39:55: note: expanded from macro 'macro_many_args2'
-  // CHECK: {{.*}}:38:35: note: expanded from macro 'macro_many_args1'
+  // CHECK: {{.*}}:32:36: note: expanded from macro 'macro_args2'
+  // CHECK: {{.*}}:31:24: note: expanded from macro 'macro_args1'
+  // CHECK: {{.*}}:37:55: note: expanded from macro 'macro_many_args3'
+  // CHECK: {{.*}}:36:55: note: expanded from macro 'macro_many_args2'
+  // CHECK: {{.*}}:35:35: note: expanded from macro 'macro_many_args1'
 }
 
 

Re: [PATCH] D11740: ABI versioning macros for libc++

2015-08-26 Thread Evgeniy Stepanov via cfe-commits
eugenis removed rL LLVM as the repository for this revision.
eugenis updated this revision to Diff 33246.
eugenis added a comment.

Introduced cmake options for specifying the desired ABI version.
ABI version affects library soname and include path (include/c++/vN).
Baked ABI version into the headers (autogenerated __config_version) so that, 
ex. with -I/usr/include/c++/v2 you get major abi version=2 w/o additional -D 
settings.

Clang support for selecting vN include path is coming as a separate change.


http://reviews.llvm.org/D11740

Files:
  CMakeLists.txt
  docs/Abi.rst
  docs/BuildingLibcxx.rst
  include/CMakeLists.txt
  include/__config
  include/__config_version.cmake
  include/string
  lib/CMakeLists.txt

Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -129,8 +129,8 @@
 COMPILE_FLAGS ${LIBCXX_COMPILE_FLAGS}
 LINK_FLAGS${LIBCXX_LINK_FLAGS}
 OUTPUT_NAME   c++
-VERSION   1.0
-SOVERSION 1
+VERSION   ${LIBCXX_ABI_MAJOR_VERSION}.${LIBCXX_ABI_MINOR_VERSION}
+SOVERSION ${LIBCXX_ABI_MAJOR_VERSION}
   )
 
 install(TARGETS cxx
Index: include/string
===
--- include/string
+++ include/string
@@ -1185,7 +1185,7 @@
 #pragma warning( pop )
 #endif // _LIBCPP_MSVC
 
-#ifdef _LIBCPP_ALTERNATE_STRING_LAYOUT
+#ifdef _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 template class _CharT, size_t = sizeof(_CharT)
 struct __padding
@@ -1198,7 +1198,7 @@
 {
 };
 
-#endif  // _LIBCPP_ALTERNATE_STRING_LAYOUT
+#endif  // _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 templateclass _CharT, class _Traits, class _Allocator
 class _LIBCPP_TYPE_VIS_ONLY basic_string
@@ -1234,7 +1234,7 @@
 
 private:
 
-#ifdef _LIBCPP_ALTERNATE_STRING_LAYOUT
+#ifdef _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 struct __long
 {
@@ -1294,7 +1294,7 @@
 value_type __data_[__min_cap];
 };
 
-#endif  // _LIBCPP_ALTERNATE_STRING_LAYOUT
+#endif  // _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 union __ulx{__long __lx; __short __lxx;};
 
@@ -1696,7 +1696,7 @@
 const allocator_type __alloc() const _NOEXCEPT
 {return __r_.second();}
 
-#ifdef _LIBCPP_ALTERNATE_STRING_LAYOUT
+#ifdef _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 _LIBCPP_INLINE_VISIBILITY
 void __set_short_size(size_type __s) _NOEXCEPT
@@ -1714,7 +1714,7 @@
 {return __r_.first().__s.__size_;}
 #   endif
 
-#else  // _LIBCPP_ALTERNATE_STRING_LAYOUT
+#else  // _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 _LIBCPP_INLINE_VISIBILITY
 void __set_short_size(size_type __s) _NOEXCEPT
@@ -1732,7 +1732,7 @@
 {return __r_.first().__s.__size_  1;}
 #   endif
 
-#endif  // _LIBCPP_ALTERNATE_STRING_LAYOUT
+#endif  // _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 _LIBCPP_INLINE_VISIBILITY
 void __set_long_size(size_type __s) _NOEXCEPT
Index: include/__config_version.cmake
===
--- include/__config_version.cmake
+++ include/__config_version.cmake
@@ -0,0 +1,19 @@
+// -*- C++ -*-
+//===--- __config_version -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef _LIBCPP_CONFIG_VERSION
+#define _LIBCPP_CONFIG_VERSION
+
+#define _LIBCPP_ABI_MAJOR_VERSION ${LIBCXX_ABI_MAJOR_VERSION}
+#define _LIBCPP_ABI_MINOR_VERSION ${LIBCXX_ABI_MINOR_VERSION}
+
+#define _LIBCPP_ABI_VERSION (_LIBCPP_ABI_MAJOR_VERSION * 100 + _LIBCPP_ABI_MINOR_VERSION)
+
+#endif
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -11,6 +11,8 @@
 #ifndef _LIBCPP_CONFIG
 #define _LIBCPP_CONFIG
 
+#include __config_version
+
 #if !defined(_MSC_VER) || defined(__clang__)
 #pragma GCC system_header
 #endif
@@ -23,12 +25,14 @@
 
 #define _LIBCPP_VERSION 3800
 
-#define _LIBCPP_ABI_VERSION 1
+#if _LIBCPP_ABI_VERSION = 200
+#define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
+#endif
 
 #define _LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y) _LIBCPP_X##_LIBCPP_Y
 #define _LIBCPP_CONCAT(_LIBCPP_X,_LIBCPP_Y) _LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y)
 
-#define _LIBCPP_NAMESPACE _LIBCPP_CONCAT(__,_LIBCPP_ABI_VERSION)
+#define _LIBCPP_NAMESPACE _LIBCPP_CONCAT(__,_LIBCPP_ABI_MAJOR_VERSION)
 
 
 #ifndef __has_attribute
@@ -230,9 +234,10 @@
 
 #if defined(__clang__)
 
-#if defined(__APPLE__)  !defined(__i386__)  !defined(__x86_64__) \
-!defined(__arm__)
-#define _LIBCPP_ALTERNATE_STRING_LAYOUT
+#if (defined(__APPLE__)  !defined(__i386__)  !defined(__x86_64__)\
+ !defined(__arm__)) || \
+defined(_LIBCPP_ALTERNATE_STRING_LAYOUT)
+#define 

Fwd: [PATCH] __attribute__((enable_if)) and non-overloaded member functions

2015-08-26 Thread Nick Lewycky via cfe-commits
-- lists.llvm.org

-- Forwarded message --
From: Ettore Speziale speziale.ett...@gmail.com
Date: 26 August 2015 at 14:35
Subject: Re: [PATCH] __attribute__((enable_if)) and non-overloaded member
functions
To: Nick Lewycky nlewy...@google.com
Cc: llvm cfe cfe-comm...@cs.uiuc.edu


Hello,

 Sorry about the extreme delay. This patch slipped through the cracks, and
I only noticed it again when searching my email for enable_if. Committed in
r245985! In the future, please feel free to continue pinging weekly!

NP, thank you for committing the patch.

Unfortunately it contains a little error in the case of no candidate has
been found. For instance consider the following test case:

struct Incomplete;

struct X {
void hidden_by_argument_conversion(Incomplete n, int m = 0)
__attribute((enable_if(m == 10, chosen when 'm' is ten)));
};

x.hidden_by_argument_conversion(10);

I would expect to get an error about Incomplete, as the compiler cannot
understand how to convert 10 into an instance of Incomplete. However right
now the enable_if diagnostic is emitted, thus masking the more useful
message about Incomplete.

The attached patch solved the problem by delaying the point where the
enable_if diagnostic is issued.

Thanks,
Ettore Speziale


enable_if.diff
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r246088 - [ms-inline-asm] Add field access to MS inline asm identifier lookup

2015-08-26 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Wed Aug 26 16:57:20 2015
New Revision: 246088

URL: http://llvm.org/viewvc/llvm-project?rev=246088view=rev
Log:
[ms-inline-asm] Add field access to MS inline asm identifier lookup

Now we can parse code like this:
  struct A {
int field;
  };
  int f(A o) {
__asm mov eax, o.field
  }

Fixes PR19117.

Added:
cfe/trunk/test/CodeGenCXX/ms-inline-asm-fields.cpp
cfe/trunk/test/SemaCXX/ms-inline-asm.cpp
Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseStmtAsm.cpp
cfe/trunk/lib/Sema/SemaStmtAsm.cpp
cfe/trunk/test/CodeGen/ms-inline-asm.c

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=246088r1=246087r2=246088view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Wed Aug 26 16:57:20 2015
@@ -3375,6 +3375,10 @@ public:
bool IsUnevaluatedContext);
   bool LookupInlineAsmField(StringRef Base, StringRef Member,
 unsigned Offset, SourceLocation AsmLoc);
+  ExprResult LookupInlineAsmVarDeclField(Expr *RefExpr, StringRef Member,
+ unsigned Offset,
+ llvm::InlineAsmIdentifierInfo Info,
+ SourceLocation AsmLoc);
   StmtResult ActOnMSAsmStmt(SourceLocation AsmLoc, SourceLocation LBraceLoc,
 ArrayRefToken AsmToks,
 StringRef AsmString,

Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=246088r1=246087r2=246088view=diff
==
--- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
+++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Wed Aug 26 16:57:20 2015
@@ -222,6 +222,25 @@ ExprResult Parser::ParseMSAsmIdentifier(
  /*AllowConstructorName=*/false,
  /*ObjectType=*/ParsedType(), TemplateKWLoc, Id);
 
+  // Perform the lookup.
+  ExprResult Result = Actions.LookupInlineAsmIdentifier(
+  SS, TemplateKWLoc, Id, Info, IsUnevaluatedContext);
+
+  // While the next two tokens are 'period' 'identifier', repeatedly parse it 
as
+  // a field access. We have to avoid consuming assembler directives that look
+  // like '.' 'else'.
+  while (Result.isUsable()  Tok.is(tok::period)) {
+Token IdTok = PP.LookAhead(0);
+if (IdTok.isNot(tok::identifier))
+  break;
+ConsumeToken(); // Consume the period.
+IdentifierInfo *Id = Tok.getIdentifierInfo();
+ConsumeToken(); // Consume the identifier.
+unsigned OffsetUnused;
+Result = Actions.LookupInlineAsmVarDeclField(
+Result.get(), Id-getName(), OffsetUnused, Info, Tok.getLocation());
+  }
+
   // Figure out how many tokens we are into LineToks.
   unsigned LineIndex = 0;
   if (Tok.is(EndOfStream)) {
@@ -254,9 +273,7 @@ ExprResult Parser::ParseMSAsmIdentifier(
   LineToks.pop_back();
   LineToks.pop_back();
 
-  // Perform the lookup.
-  return Actions.LookupInlineAsmIdentifier(SS, TemplateKWLoc, Id, Info,
-   IsUnevaluatedContext);
+  return Result;
 }
 
 /// Turn a sequence of our tokens back into a string that we can hand

Modified: cfe/trunk/lib/Sema/SemaStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaStmtAsm.cpp?rev=246088r1=246087r2=246088view=diff
==
--- cfe/trunk/lib/Sema/SemaStmtAsm.cpp (original)
+++ cfe/trunk/lib/Sema/SemaStmtAsm.cpp Wed Aug 26 16:57:20 2015
@@ -528,6 +528,17 @@ StmtResult Sema::ActOnGCCAsmStmt(SourceL
   return NS;
 }
 
+static void fillInlineAsmTypeInfo(const ASTContext Context, QualType T,
+  llvm::InlineAsmIdentifierInfo Info) {
+  // Compute the type size (and array length if applicable?).
+  Info.Type = Info.Size = Context.getTypeSizeInChars(T).getQuantity();
+  if (T-isArrayType()) {
+const ArrayType *ATy = Context.getAsArrayType(T);
+Info.Type = 
Context.getTypeSizeInChars(ATy-getElementType()).getQuantity();
+Info.Length = Info.Size / Info.Type;
+  }
+}
+
 ExprResult Sema::LookupInlineAsmIdentifier(CXXScopeSpec SS,
SourceLocation TemplateKWLoc,
UnqualifiedId Id,
@@ -575,13 +586,7 @@ ExprResult Sema::LookupInlineAsmIdentifi
 return ExprError();
   }
 
-  // Compute the type size (and array length if applicable?).
-  Info.Type = Info.Size = Context.getTypeSizeInChars(T).getQuantity();
-  if (T-isArrayType()) {
-const ArrayType *ATy = Context.getAsArrayType(T);
-Info.Type = 
Context.getTypeSizeInChars(ATy-getElementType()).getQuantity();
-  

[PATCH] D12382: Extend linux header search to find libc++ headers in c++/vN for any N.

2015-08-26 Thread Evgeniy Stepanov via cfe-commits
eugenis created this revision.
eugenis added reviewers: mclow.lists, EricWF, rsmith.
eugenis added a subscriber: cfe-commits.
eugenis set the repository for this revision to rL LLVM.

This goes with the ABI versioning support in libc++ in 
http://reviews.llvm.org/D11740

Repository:
  rL LLVM

http://reviews.llvm.org/D12382

Files:
  lib/Driver/ToolChains.cpp
  test/Driver/Inputs/basic_linux_libcxxv2_tree/usr/bin/.keep
  test/Driver/Inputs/basic_linux_libcxxv2_tree/usr/include/c++/v2/.keep
  test/Driver/Inputs/basic_linux_libcxxv2_tree/usr/lib/.keep
  test/Driver/linux-header-search.cpp

Index: test/Driver/linux-header-search.cpp
===
--- test/Driver/linux-header-search.cpp
+++ test/Driver/linux-header-search.cpp
@@ -26,6 +26,29 @@
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/bin/../include/c++/v1
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/local/include
 //
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
+// RUN: -target x86_64-unknown-linux-gnu \
+// RUN: -stdlib=libc++ \
+// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
+// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
+// RUN: --gcc-toolchain= \
+// RUN:   | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-SYSROOT %s
+// CHECK-BASIC-LIBCXXV2-SYSROOT: {{[^]*}}clang{{[^]*}} -cc1
+// CHECK-BASIC-LIBCXXV2-SYSROOT: -isysroot [[SYSROOT:[^]+]]
+// CHECK-BASIC-LIBCXXV2-SYSROOT: -internal-isystem 
[[SYSROOT]]/usr/include/c++/v2
+// CHECK-BASIC-LIBCXXV2-SYSROOT: -internal-isystem 
[[SYSROOT]]/usr/local/include
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
+// RUN: -target x86_64-unknown-linux-gnu \
+// RUN: -stdlib=libc++ \
+// RUN: -ccc-install-dir %S/Inputs/basic_linux_libcxxv2_tree/usr/bin \
+// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
+// RUN: --gcc-toolchain= \
+// RUN:   | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-INSTALL %s
+// CHECK-BASIC-LIBCXXV2-INSTALL: {{[^]*}}clang{{[^]*}} -cc1
+// CHECK-BASIC-LIBCXXV2-INSTALL: -isysroot [[SYSROOT:[^]+]]
+// CHECK-BASIC-LIBCXXV2-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/bin/../include/c++/v2
+// CHECK-BASIC-LIBCXXV2-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/local/include
+//
 // Test a very broken version of multiarch that shipped in Ubuntu 11.04.
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
 // RUN: -target i386-unknown-linux \
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3532,6 +3532,25 @@
   return true;
 }
 
+static std::string DetectLibcxxIncludePath(const std::string base) {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString = ;
+  for (llvm::sys::fs::directory_iterator LI(base, EC), LE; !EC  LI != LE;
+   LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI-path());
+int Version;
+if (VersionText[0] == 'v' 
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version  MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = VersionText;
+  }
+}
+  }
+  return MaxVersion ? base + / + MaxVersionString : ;
+}
+
 void Linux::AddClangCXXStdlibIncludeArgs(const ArgList DriverArgs,
  ArgStringList CC1Args) const {
   if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
@@ -3544,14 +3563,14 @@
 // The primary location is within the Clang installation.
 // FIXME: We shouldn't hard code 'v1' here to make Clang future proof 
to
 // newer ABI versions.
-getDriver().Dir + /../include/c++/v1,
+DetectLibcxxIncludePath(getDriver().Dir + /../include/c++),
 
 // We also check the system as for a long time this is the only place
 // Clang looked.
 // FIXME: We should really remove this. It doesn't make any sense.
-getDriver().SysRoot + /usr/include/c++/v1};
+DetectLibcxxIncludePath(getDriver().SysRoot + /usr/include/c++)};
 for (const auto IncludePath : LibCXXIncludePathCandidates) {
-  if (!llvm::sys::fs::exists(IncludePath))
+  if (IncludePath.empty() || !llvm::sys::fs::exists(IncludePath))
 continue;
   // Add the first candidate that exists.
   addSystemInclude(DriverArgs, CC1Args, IncludePath);


Index: test/Driver/linux-header-search.cpp
===
--- test/Driver/linux-header-search.cpp
+++ test/Driver/linux-header-search.cpp
@@ -26,6 +26,29 @@
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem [[SYSROOT]]/usr/bin/../include/c++/v1
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem [[SYSROOT]]/usr/local/include
 //
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
+// RUN: -target x86_64-unknown-linux-gnu \
+// RUN:  

Re: [PATCH] D12221: [RFC] Introduce `__attribute__((nontemporal))`.

2015-08-26 Thread Michael Zolotukhin via cfe-commits
mzolotukhin added a comment.

Hi,

I implemented builtin-based version in http://reviews.llvm.org/D12313 - could 
you please take a look?

Thanks,
Michael


http://reviews.llvm.org/D12221



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


Re: [PATCH] D12382: Extend linux header search to find libc++ headers in c++/vN for any N.

2015-08-26 Thread Evgeniy Stepanov via cfe-commits
eugenis marked 2 inline comments as done.
eugenis added a comment.

http://reviews.llvm.org/D12382



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


Re: [PATCH] D12382: Extend linux header search to find libc++ headers in c++/vN for any N.

2015-08-26 Thread Evgeniy Stepanov via cfe-commits
eugenis removed rL LLVM as the repository for this revision.
eugenis updated this revision to Diff 33259.

http://reviews.llvm.org/D12382

Files:
  lib/Driver/ToolChains.cpp
  test/Driver/Inputs/basic_linux_libcxxv2_tree/usr/bin/.keep
  test/Driver/Inputs/basic_linux_libcxxv2_tree/usr/include/c++/v2/.keep
  test/Driver/Inputs/basic_linux_libcxxv2_tree/usr/lib/.keep
  test/Driver/linux-header-search.cpp

Index: test/Driver/linux-header-search.cpp
===
--- test/Driver/linux-header-search.cpp
+++ test/Driver/linux-header-search.cpp
@@ -26,6 +26,29 @@
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/bin/../include/c++/v1
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/local/include
 //
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
+// RUN: -target x86_64-unknown-linux-gnu \
+// RUN: -stdlib=libc++ \
+// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
+// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
+// RUN: --gcc-toolchain= \
+// RUN:   | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-SYSROOT %s
+// CHECK-BASIC-LIBCXXV2-SYSROOT: {{[^]*}}clang{{[^]*}} -cc1
+// CHECK-BASIC-LIBCXXV2-SYSROOT: -isysroot [[SYSROOT:[^]+]]
+// CHECK-BASIC-LIBCXXV2-SYSROOT: -internal-isystem 
[[SYSROOT]]/usr/include/c++/v2
+// CHECK-BASIC-LIBCXXV2-SYSROOT: -internal-isystem 
[[SYSROOT]]/usr/local/include
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
+// RUN: -target x86_64-unknown-linux-gnu \
+// RUN: -stdlib=libc++ \
+// RUN: -ccc-install-dir %S/Inputs/basic_linux_libcxxv2_tree/usr/bin \
+// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
+// RUN: --gcc-toolchain= \
+// RUN:   | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-INSTALL %s
+// CHECK-BASIC-LIBCXXV2-INSTALL: {{[^]*}}clang{{[^]*}} -cc1
+// CHECK-BASIC-LIBCXXV2-INSTALL: -isysroot [[SYSROOT:[^]+]]
+// CHECK-BASIC-LIBCXXV2-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/bin/../include/c++/v2
+// CHECK-BASIC-LIBCXXV2-INSTALL: -internal-isystem 
[[SYSROOT]]/usr/local/include
+//
 // Test a very broken version of multiarch that shipped in Ubuntu 11.04.
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
 // RUN: -target i386-unknown-linux \
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3532,6 +3532,25 @@
   return true;
 }
 
+static std::string DetectLibcxxIncludePath(StringRef base) {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString = ;
+  for (llvm::sys::fs::directory_iterator LI(base, EC), LE; !EC  LI != LE;
+   LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI-path());
+int Version;
+if (VersionText[0] == 'v' 
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version  MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = VersionText;
+  }
+}
+  }
+  return MaxVersion ? (base + / + MaxVersionString).str() : ;
+}
+
 void Linux::AddClangCXXStdlibIncludeArgs(const ArgList DriverArgs,
  ArgStringList CC1Args) const {
   if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
@@ -3542,16 +3561,14 @@
   if (GetCXXStdlibType(DriverArgs) == ToolChain::CST_Libcxx) {
 const std::string LibCXXIncludePathCandidates[] = {
 // The primary location is within the Clang installation.
-// FIXME: We shouldn't hard code 'v1' here to make Clang future proof 
to
-// newer ABI versions.
-getDriver().Dir + /../include/c++/v1,
+DetectLibcxxIncludePath(getDriver().Dir + /../include/c++),
 
 // We also check the system as for a long time this is the only place
 // Clang looked.
 // FIXME: We should really remove this. It doesn't make any sense.
-getDriver().SysRoot + /usr/include/c++/v1};
+DetectLibcxxIncludePath(getDriver().SysRoot + /usr/include/c++)};
 for (const auto IncludePath : LibCXXIncludePathCandidates) {
-  if (!llvm::sys::fs::exists(IncludePath))
+  if (IncludePath.empty() || !llvm::sys::fs::exists(IncludePath))
 continue;
   // Add the first candidate that exists.
   addSystemInclude(DriverArgs, CC1Args, IncludePath);


Index: test/Driver/linux-header-search.cpp
===
--- test/Driver/linux-header-search.cpp
+++ test/Driver/linux-header-search.cpp
@@ -26,6 +26,29 @@
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem [[SYSROOT]]/usr/bin/../include/c++/v1
 // CHECK-BASIC-LIBCXX-INSTALL: -internal-isystem [[SYSROOT]]/usr/local/include
 //
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 21 \
+// RUN: -target x86_64-unknown-linux-gnu \
+// RUN: -stdlib=libc++ \
+// RUN: -ccc-install-dir 

[PATCH] D12359: New warning -Wnonconst-parameter when a pointer parameter can be const

2015-08-26 Thread Daniel Marjamäki via cfe-commits
danielmarjamaki created this revision.
danielmarjamaki added a subscriber: cfe-commits.

This is a new warning for Clang. It will warn when a pointer parameter can be 
const.

The design is inspired by the Wunused-parameter warning.

I have tested this on many debian packages. In 2151 projects there were 60834 
warnings. So in average there were ~30 warnings / project. Most of my 
dontwarn testcases are inspired by false positives I have seen and fixed. The 
false positive ratio is imho not bad right now but I will continue to look in 
the log to see if there are more false positives.


http://reviews.llvm.org/D12359

Files:
  include/clang/AST/DeclBase.h
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/Parse/ParseExpr.cpp
  lib/Parse/ParseStmt.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLambda.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTReaderDecl.cpp
  test/Sema/warn-nonconst-parameter.c
  test/SemaCXX/warn-nonconst-parameter.cpp

Index: test/SemaCXX/warn-nonconst-parameter.cpp
===
--- test/SemaCXX/warn-nonconst-parameter.cpp
+++ test/SemaCXX/warn-nonconst-parameter.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -fsyntax-only -Wnonconst-parameter -verify %s
+//
+// Test that -Wnonconst-parameter does not warn for virtual functions.
+//
+
+// expected-no-diagnostics
+
+class Base {
+public:
+  virtual int f(int*p);
+};
+
+
+class Derived /* : public Base */ {
+public:
+  virtual int f(int*p){return 0;}
+};
Index: test/Sema/warn-nonconst-parameter.c
===
--- test/Sema/warn-nonconst-parameter.c
+++ test/Sema/warn-nonconst-parameter.c
@@ -0,0 +1,89 @@
+// RUN: %clang_cc1 -fsyntax-only -Wnonconst-parameter -verify %s
+
+// Currently the -Wnonconst-parameter only warns about pointer arguments.
+//
+// It can be defined both that the data is const and that the pointer is const,
+// the -Wnonconst-parameter only checks if the data can be const-specified.
+//
+// It does not warn about pointers to records or function pointers.
+
+// Some external function where first argument is nonconst and second is const.
+void strcpy1(char *dest, const char *src);
+
+
+int warn1(int *p) { // expected-warning {{parameter 'p' can be const}}
+  return *p;
+}
+
+void warn2(int *first, int *last) { // expected-warning {{parameter 'last' can be const}}
+  *first = 0;
+  if (first  last) {} // - last can be const
+}
+
+void warn3(char *p) { // expected-warning {{parameter 'p' can be const}}
+  char buf[10];
+  strcpy1(buf, p);
+}
+
+int dontwarn1(const int *p) {
+  return *p;
+}
+
+void dontwarn2(int *p) {
+  *p = 0;
+}
+
+void dontwarn3(char *p) {
+  p[0] = 0;
+}
+
+void dontwarn4(int *p) {
+  int *q = p;
+  *q = 0;
+}
+
+void dontwarn5(float *p) {
+  int *q = (int *)p;
+}
+
+void dontwarn6(char *p) {
+  char *a, *b;
+  a = b = p;
+}
+
+void dontwarn7(int *p) {
+  int *i = p ? p : 0;
+}
+
+void dontwarn8(char *p) {
+  char *x;
+  x = (p ? p : );
+}
+
+void dontwarn9(int *p) {
+  ++(*p);
+}
+
+void dontwarn10(unsigned char *str, const unsigned int i) {
+unsigned char *p;
+for (p = str + i; *p; ) {}
+}
+
+void dontwarn11(char *p) {
+  strcpy1(p, abc);
+}
+
+void dontwarn12(char *p) {
+  strcpy1(p+2, abc);
+}
+
+// Don't warn about nonconst function pointers that can be const.
+void functionpointer(double f(double), int x) {
+  f(x);
+}
+
+// Don't warn about nonconst record pointers that can be const.
+struct XY { int x; int y; };
+int recordpointer(struct XY *xy) {
+  return xy-x;
+}
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl.cpp
+++ lib/Serialization/ASTReaderDecl.cpp
@@ -500,6 +500,7 @@
   D-setImplicit(Record[Idx++]);
   D-Used = Record[Idx++];
   D-setReferenced(Record[Idx++]);
+  D-setWritten();
   D-setTopLevelDeclInObjCContainer(Record[Idx++]);
   D-setAccess((AccessSpecifier)Record[Idx++]);
   D-FromASTFile = true;
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -3613,6 +3613,7 @@
 if (OldVar-isUsed(false))
   NewVar-setIsUsed();
 NewVar-setReferenced(OldVar-isReferenced());
+NewVar-setWritten();
   }
 
   // See if the old variable had a type-specifier that defined an anonymous tag.
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -466,6 +466,7 @@
  SourceLocation Loc,
  bool RefersToCapture = false) {
   D-setReferenced();
+  D-setWritten();
   D-markUsed(S.Context);
   return 

[PATCH] D12361: LoopConvert no longer take as alias references to other containers.

2015-08-26 Thread Angel Garcia via cfe-commits
angelgarcia created this revision.
angelgarcia added a reviewer: alexfh.
angelgarcia added subscribers: cfe-commits, klimek.

Fix a bug where modernize-loop-convert check would take as alias a reference to 
other containers. Add the pertinent test.

http://reviews.llvm.org/D12361

Files:
  clang-tidy/modernize/LoopConvertUtils.cpp
  test/clang-tidy/modernize-loop-convert-extra.cpp

Index: test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- test/clang-tidy/modernize-loop-convert-extra.cpp
+++ test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -202,6 +202,16 @@
   // CHECK-FIXES-NOT: MutableVal {{[a-z_]+}} =
   // CHECK-FIXES: {}
   // CHECK-FIXES-NEXT: alias.x = 0;
+
+  dependentint dep, other;
+  for (dependentint::iterator it = dep.begin(), e = dep.end(); it != e; 
++it) {
+printf(%d\n, *it);
+const int idx = other[0];
+  }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto  elem : dep)
+  // CHECK-FIXES-NEXT: printf(%d\n, elem);
+  // CHECK-FIXES-NEXT: const int idx = other[0];
 }
 
 } // namespace NamingAlias
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -363,7 +363,7 @@
   return isDereferenceOfOpCall(OpCall, IndexVar);
 if (OpCall-getOperator() == OO_Subscript) {
   assert(OpCall-getNumArgs() == 2);
-  return true;
+  return isIndexInSubscriptExpr(OpCall-getArg(1), IndexVar);
 }
 break;
   }


Index: test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- test/clang-tidy/modernize-loop-convert-extra.cpp
+++ test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -202,6 +202,16 @@
   // CHECK-FIXES-NOT: MutableVal {{[a-z_]+}} =
   // CHECK-FIXES: {}
   // CHECK-FIXES-NEXT: alias.x = 0;
+
+  dependentint dep, other;
+  for (dependentint::iterator it = dep.begin(), e = dep.end(); it != e; ++it) {
+printf(%d\n, *it);
+const int idx = other[0];
+  }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto  elem : dep)
+  // CHECK-FIXES-NEXT: printf(%d\n, elem);
+  // CHECK-FIXES-NEXT: const int idx = other[0];
 }
 
 } // namespace NamingAlias
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -363,7 +363,7 @@
   return isDereferenceOfOpCall(OpCall, IndexVar);
 if (OpCall-getOperator() == OO_Subscript) {
   assert(OpCall-getNumArgs() == 2);
-  return true;
+  return isIndexInSubscriptExpr(OpCall-getArg(1), IndexVar);
 }
 break;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r246034 - LoopConvert no longer take as alias references to other containers.

2015-08-26 Thread Angel Garcia Gomez via cfe-commits
Author: angelgarcia
Date: Wed Aug 26 09:51:11 2015
New Revision: 246034

URL: http://llvm.org/viewvc/llvm-project?rev=246034view=rev
Log:
LoopConvert no longer take as alias references to other containers.

Summary: Fix a bug where modernize-loop-convert check would take as alias a 
reference to other containers. Add the pertinent test.

Reviewers: alexfh

Subscribers: klimek, cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp?rev=246034r1=246033r2=246034view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp Wed Aug 
26 09:51:11 2015
@@ -363,7 +363,7 @@ static bool isAliasDecl(const Decl *TheD
   return isDereferenceOfOpCall(OpCall, IndexVar);
 if (OpCall-getOperator() == OO_Subscript) {
   assert(OpCall-getNumArgs() == 2);
-  return true;
+  return isIndexInSubscriptExpr(OpCall-getArg(1), IndexVar);
 }
 break;
   }

Modified: 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp?rev=246034r1=246033r2=246034view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp 
Wed Aug 26 09:51:11 2015
@@ -202,6 +202,16 @@ void refs_and_vals() {
   // CHECK-FIXES-NOT: MutableVal {{[a-z_]+}} =
   // CHECK-FIXES: {}
   // CHECK-FIXES-NEXT: alias.x = 0;
+
+  dependentint dep, other;
+  for (dependentint::iterator it = dep.begin(), e = dep.end(); it != e; 
++it) {
+printf(%d\n, *it);
+const int idx = other[0];
+  }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto  elem : dep)
+  // CHECK-FIXES-NEXT: printf(%d\n, elem);
+  // CHECK-FIXES-NEXT: const int idx = other[0];
 }
 
 } // namespace NamingAlias


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


Re: [PATCH] D12362: [clang-format] Add support of consecutive declarations alignment

2015-08-26 Thread Daniel Jasper via cfe-commits
djasper added inline comments.


Comment at: unittests/Format/FormatTest.cpp:8619
@@ -8618,1 +8618,3 @@
 
+TEST_F(FormatTest, AlignConsecutiveDeclarations) {
+  FormatStyle Alignment = getLLVMStyle();

This needs tests that check what happens if both declarations and assignments 
are aligned.


Comment at: unittests/Format/FormatTest.cpp:8703
@@ +8702,3 @@
+  verifyFormat(#define A  

+   \\\n
+ int    = 12; 


Reduce Alignment.ColumnLimit so that tests don't need line-wraps.


http://reviews.llvm.org/D12362



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


Re: [PATCH] D11468: [Static Analyzer] The first implementation of nullability checker.

2015-08-26 Thread Gábor Horváth via cfe-commits
xazax.hun updated this revision to Diff 33239.
xazax.hun added a comment.

- Fine tuned the heuristics for cocoa APIs.
- Only track nullable and contradicted nullability for symbols. Use the 
rest statically.
- Cleanups.


http://reviews.llvm.org/D11468

Files:
  docs/analyzer/nullability.rst
  lib/StaticAnalyzer/Checkers/CMakeLists.txt
  lib/StaticAnalyzer/Checkers/Checkers.td
  lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
  test/Analysis/nullability.mm

Index: test/Analysis/nullability.mm
===
--- /dev/null
+++ test/Analysis/nullability.mm
@@ -0,0 +1,181 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,alpha.core.nullability -verify %s
+
+#define nil 0
+#define BOOL int
+
+@protocol NSObject
++ (id)alloc;
+- (id)init;
+@end
+
+@protocol NSCopying
+@end
+
+__attribute__((objc_root_class))
+@interface
+NSObjectNSObject
+@end
+
+@interface NSString : NSObjectNSCopying
+- (BOOL)isEqualToString : (NSString *_Nonnull)aString;
+- (NSString *)stringByAppendingString:(NSString *_Nonnull)aString;
+@end
+
+@interface TestObject : NSObject
+- (int *_Nonnull)returnsNonnull;
+- (int *_Nullable)returnsNullable;
+- (int *)returnsUnspecified;
+- (void)takesNonnull:(int *_Nonnull)p;
+- (void)takesNullable:(int *_Nullable)p;
+- (void)takesUnspecified:(int *)p;
+@property(readonly, strong) NSString *stuff;
+@end
+
+TestObject * getUnspecifiedTestObject();
+TestObject *_Nonnull getNonnullTestObject();
+TestObject *_Nullable getNullableTestObject();
+
+int getRandom();
+
+typedef struct Dummy { int val; } Dummy;
+
+void takesNullable(Dummy *_Nullable);
+void takesNonnull(Dummy *_Nonnull);
+void takesUnspecified(Dummy *);
+
+Dummy *_Nullable returnsNullable();
+Dummy *_Nonnull returnsNonnull();
+Dummy *returnsUnspecified();
+int *_Nullable returnsNullableInt();
+
+template typename T T *eraseNullab(T *p) { return p; }
+
+void testBasicRules() {
+  Dummy *p = returnsNullable();
+  int *ptr = returnsNullableInt();
+  // Make every dereference a different path to avoid sinks after errors.
+  switch (getRandom()) {
+  case 0: {
+Dummy r = *p; // expected-warning {{}}
+  } break;
+  case 1: {
+int b = p-val; // expected-warning {{}}
+  } break;
+  case 2: {
+int stuff = *ptr; // expected-warning {{}}
+  } break;
+  case 3:
+takesNonnull(p); // expected-warning {{}}
+break;
+  case 4: {
+Dummy d;
+takesNullable(d);
+Dummy dd(d);
+break;
+  }
+  // Here the copy constructor is called, so a reference is initialized with the
+  // value of p. No ImplicitNullDereference event will be dispatched for this
+  // case. A followup patch is expected to fix this in NonNullParamChecker.
+  default: { Dummy d = *p; } break; // No warning.
+  }
+  if (p) {
+takesNonnull(p);
+if (getRandom()) {
+  Dummy r = *p;
+} else {
+  int b = p-val;
+}
+  }
+  Dummy *q = 0;
+  if (getRandom()) {
+takesNullable(q);
+takesNonnull(q); // expected-warning {{}}
+  }
+  Dummy a;
+  Dummy *_Nonnull nonnull = a;
+  nonnull = q; // expected-warning {{}}
+  q = a;
+  takesNullable(q);
+  takesNonnull(q);
+}
+
+void testMultiParamChecking(Dummy *_Nonnull a, Dummy *_Nullable b,
+Dummy *_Nonnull c);
+
+void testArgumentTracking(Dummy *_Nonnull nonnull, Dummy *_Nullable nullable) {
+  Dummy *p = nullable;
+  Dummy *q = nonnull;
+  switch(getRandom()) {
+  case 1: nonnull = p; break; // expected-warning {{}}
+  case 2: p = 0; break;
+  case 3: q = p; break;
+  case 4: testMultiParamChecking(nonnull, nullable, nonnull); break;
+  case 5: testMultiParamChecking(nonnull, nonnull, nonnull); break;
+  case 6: testMultiParamChecking(nonnull, nullable, nullable); break; // expected-warning {{}}
+  case 7: testMultiParamChecking(nullable, nullable, nonnull); // expected-warning {{}}
+  case 8: testMultiParamChecking(nullable, nullable, nullable); // expected-warning {{}}
+  case 9: testMultiParamChecking((Dummy *_Nonnull)0, nullable, nonnull); break;
+  }
+}
+
+Dummy *_Nonnull testNullableReturn(Dummy *_Nullable a) {
+  Dummy *p = a;
+  return p; // expected-warning {{}}
+}
+
+Dummy *_Nonnull testNullReturn() {
+  Dummy *p = 0;
+  return p; // expected-warning {{}}
+}
+
+void testObjCMessageResultNullability() {
+  // The expected result: the most nullable of self and method return type.
+  TestObject *o = getUnspecifiedTestObject();
+  int *shouldBeNullable = [eraseNullab(getNullableTestObject()) returnsNonnull];
+  switch (getRandom()) {
+  case 0:
+// The core analyzer assumes that the receiver is non-null after a message
+// send. This is to avoid some false positives, and increase performance
+// but it also reduces the coverage and makes this checker unable to reason
+// about the nullness of the receiver. 
+[o takesNonnull:shouldBeNullable]; // No warning expected.
+break;
+  case 1:
+shouldBeNullable =
+[eraseNullab(getNullableTestObject()) returnsUnspecified];
+[o 

Re: [PATCH] D12385: Generating Assumption loads fix

2015-08-26 Thread Piotr Padlewski via cfe-commits
Prazek marked 3 inline comments as done.
Prazek added a comment.

http://reviews.llvm.org/D12385



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


r246128 - Pass in a cpu to initDefaultFeatures so that we can share this code

2015-08-26 Thread Eric Christopher via cfe-commits
Author: echristo
Date: Wed Aug 26 19:05:52 2015
New Revision: 246128

URL: http://llvm.org/viewvc/llvm-project?rev=246128view=rev
Log:
Pass in a cpu to initDefaultFeatures so that we can share this code
with multiple uses of feature map construction.

Note: We could make this a static function on TargetInfo if we
fix the x86 port needing to check the triple in an isolated case.

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

Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=246128r1=246127r2=246128view=diff
==
--- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
+++ cfe/trunk/include/clang/Basic/TargetInfo.h Wed Aug 26 19:05:52 2015
@@ -741,10 +741,9 @@ public:
   virtual void adjust(const LangOptions Opts);
 
   /// \brief Initialize the map with the default set of target features for the
-  /// CPU, ABI, and FPMath options - these should have already been set prior
-  /// to calling this function; this should include all legal feature strings 
on
-  /// the target.
-  virtual void initDefaultFeatures(llvm::StringMapbool Features) const {}
+  /// CPU this should include all legal feature strings on the target.
+  virtual void initDefaultFeatures(llvm::StringMapbool Features,
+   StringRef CPU) const {}
 
   /// \brief Get the ABI currently in use.
   virtual StringRef getABI() const { return StringRef(); }

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=246128r1=246127r2=246128view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed Aug 26 19:05:52 2015
@@ -863,7 +863,8 @@ public:
   void getTargetDefines(const LangOptions Opts,
 MacroBuilder Builder) const override;
 
-  void initDefaultFeatures(llvm::StringMapbool Features) const override;
+  void initDefaultFeatures(llvm::StringMapbool Features,
+   StringRef CPU) const override;
 
   bool handleTargetFeatures(std::vectorstd::string Features,
 DiagnosticsEngine Diags) override;
@@ -1262,7 +1263,8 @@ void PPCTargetInfo::getTargetDefines(con
   //   __NO_FPRS__
 }
 
-void PPCTargetInfo::initDefaultFeatures(llvm::StringMapbool Features) const 
{
+void PPCTargetInfo::initDefaultFeatures(llvm::StringMapbool Features,
+StringRef CPU) const {
   Features[altivec] = llvm::StringSwitchbool(CPU)
 .Case(7400, true)
 .Case(g4, true)
@@ -2372,7 +2374,8 @@ public:
   // initDefaultFeatures which calls this repeatedly.
   static void setFeatureEnabledImpl(llvm::StringMapbool Features,
 StringRef Name, bool Enabled);
-  void initDefaultFeatures(llvm::StringMapbool Features) const override;
+  void initDefaultFeatures(llvm::StringMapbool Features,
+   StringRef CPU) const override;
   bool hasFeature(StringRef Feature) const override;
   bool handleTargetFeatures(std::vectorstd::string Features,
 DiagnosticsEngine Diags) override;
@@ -2498,14 +2501,15 @@ bool X86TargetInfo::setFPMath(StringRef
   return false;
 }
 
-void X86TargetInfo::initDefaultFeatures(llvm::StringMapbool Features) const 
{
+void X86TargetInfo::initDefaultFeatures(llvm::StringMapbool Features,
+StringRef CPU) const {
   // FIXME: This *really* should not be here.
 
   // X86_64 always has SSE2.
   if (getTriple().getArch() == llvm::Triple::x86_64)
 setFeatureEnabledImpl(Features, sse2, true);
 
-  switch (CPU) {
+  switch (getCPUKind(CPU)) {
   case CK_Generic:
   case CK_i386:
   case CK_i486:
@@ -4375,7 +4379,8 @@ public:
   }
 
   // FIXME: This should be based on Arch attributes, not CPU names.
-  void initDefaultFeatures(llvm::StringMapbool Features) const override {
+  void initDefaultFeatures(llvm::StringMapbool Features,
+   StringRef CPU) const override {
 if (CPU == arm1136jf-s || CPU == arm1176jzf-s || CPU == mpcore)
   Features[vfp2] = true;
 else if (CPU == cortex-a8 || CPU == cortex-a9) {
@@ -5818,7 +5823,8 @@ public:
 
 return CPUKnown;
   }
-  void initDefaultFeatures(llvm::StringMapbool Features) const override {
+  void initDefaultFeatures(llvm::StringMapbool Features,
+   StringRef CPU) const override {
 if (CPU == zEC12)
   Features[transactional-execution] = true;
 if (CPU == z13) {
@@ -6185,7 +6191,8 @@ public:
 .Default(false);
   }
   const std::string getCPU() const { return CPU; }
-  void initDefaultFeatures(llvm::StringMapbool Features) const override {
+  void initDefaultFeatures(llvm::StringMapbool 

Re: [PATCH] D12366: Avoid unnecessarily storing vtable pointers in more destructor cases

2015-08-26 Thread Richard Smith via cfe-commits
rsmith added a subscriber: rsmith.


Comment at: lib/CodeGen/CGClass.cpp:1369-1382
@@ +1368,16 @@
+
+void VisitCallExpr(const Expr *E) {
+  Sensitive = true;
+}
+void VisitCXXTypeidExpr(const Expr *E) {
+  Sensitive = true;
+}
+void VisitExpr(const Expr *E) {
+  if (E-getStmtClass() == Stmt::CXXTypeidExprClass ||
+  E-getStmtClass() == Stmt::CXXDynamicCastExprClass) {
+Sensitive = true;
+  }
+  if (!Sensitive)
+Inherited::VisitExpr(E);
+}
+  };

This is not complete; you'll also need to at least consider atomic stores (that 
might store the `this` pointer and be picked up by another thread), the 
implicit call to `operator new` in a `CXXNewExpr` (which is not modeled as a 
`CallExpr`), implicit destructor calls (which aren't modeled in the AST at 
all), and probably a lot of other cases.

Maybe it would be simpler to store `undef` to the vptr immediately before 
calling the base class destructor, and let the LLVM optimization passes remove 
this vptr store as dead if it can prove the vptr is unused?


http://reviews.llvm.org/D12366



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


Re: [PATCH] D11468: [Static Analyzer] The first implementation of nullability checker.

2015-08-26 Thread Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL246105: [Static Analyzer] Checks to catch nullability 
related issues. (authored by xazax).

Changed prior to commit:
  http://reviews.llvm.org/D11468?vs=33239id=33267#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11468

Files:
  cfe/trunk/docs/analyzer/nullability.rst
  cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td
  cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
  cfe/trunk/test/Analysis/nullability.mm

Index: cfe/trunk/docs/analyzer/nullability.rst
===
--- cfe/trunk/docs/analyzer/nullability.rst
+++ cfe/trunk/docs/analyzer/nullability.rst
@@ -0,0 +1,92 @@
+
+Nullability Checks
+
+
+This document is a high level description of the nullablility checks.
+These checks intended to use the annotations that is described in this
+RFC: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-March/041798.html.
+
+Let's consider the following 2 categories:
+
+1) nullable
+
+
+If a pointer 'p' has a nullable annotation and no explicit null check or assert, we should warn in the following cases:
+- 'p' gets implicitly converted into nonnull pointer, for example, we are passing it to a function that takes a nonnull parameter.
+- 'p' gets dereferenced
+
+Taking a branch on nullable pointers are the same like taking branch on null unspecified pointers.
+
+Explicit cast from nullable to nonnul::
+
+__nullable id foo;
+id bar = foo;
+takesNonNull((_nonnull) bar); — should not warn here (backward compatibility hack)
+anotherTakesNonNull(bar); — would be great to warn here, but not necessary(*)
+
+Because bar corresponds to the same symbol all the time it is not easy to implement the checker that way the cast only suppress the first call but not the second. For this reason in the first implementation after a contradictory cast happens, I will treat bar as nullable unspecified, this way all of the warnings will be suppressed. Treating the symbol as nullable unspecified also has an advantage that in case the takesNonNull function body is being inlined, the will be no warning, when the symbol is dereferenced. In case I have time after the initial version I might spend additional time to try to find a more sophisticated solution, in which we would produce the second warning (*).
+ 
+2) nonnull
+
+
+- Dereferencing a nonnull, or sending message to it is ok.
+- Converting nonnull to nullable is Ok.
+- When there is an explicit cast from nonnull to nullable I will trust the cast (it is probable there for a reason, because this cast does not suppress any warnings or errors).
+- But what should we do about null checks?::
+
+__nonnull id takesNonnull(__nonnull id x) {
+if (x == nil) {
+// Defensive backward compatible code:
+
+return nil; - Should the analyzer cover this piece of code? Should we require the cast (__nonnull)nil?
+}
+
+}
+
+There are these directions:
+- We can either take the branch; this way the branch is analyzed
+	- Should we not warn about any nullability issues in that branch? Probably not, it is ok to break the nullability postconditions when the nullability preconditions are violated.
+- We can assume that these pointers are not null and we lose coverage with the analyzer. (This can be implemented either in constraint solver or in the checker itself.)
+
+Other Issues to keep in mind/take care of:
+Messaging:
+- Sending a message to a nullable pointer
+	- Even though the method might return a nonnull pointer, when it was sent to a nullable pointer the return type will be nullable.
+	- The result is nullable unless the receiver is known to be non null.
+- Sending a message to a unspecified or nonnull pointer
+	- If the pointer is not assumed to be nil, we should be optimistic and use the nullability implied by the method.
+- This will not happen automatically, since the AST will have null unspecified in this case.
+
+Inlining
+
+
+A symbol may need to be treated differently inside an inlined body. For example, consider these conversions from nonnull to nullable in presence of inlining::
+
+id obj = getNonnull();
+takesNullable(obj);
+takesNonnull(obj);
+
+void takesNullable(nullable id obj) {
+   obj-ivar // we should assume obj is nullable and warn here
+}
+   
+With no special treatment, when the takesNullable is inlined the analyzer will not warn when the obj symbol is dereferenced. One solution for this is to reanalyze takesNullable as a top level function to get possible violations. The alternative method, deducing nullability information from the arguments after inlining is not robust enough (for example there might be more parameters with different nullability, but in the given path the 

Re: [PATCH] D12385: Generating Assumption loads fix

2015-08-26 Thread Piotr Padlewski via cfe-commits
Prazek updated this revision to Diff 33269.

http://reviews.llvm.org/D12385

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CGVTables.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenCXX/template-instantiation.cpp
  test/CodeGenCXX/thunks.cpp
  test/CodeGenCXX/vtable-assume-load.cpp
  test/CodeGenCXX/vtable-available-externally.cpp

Index: test/CodeGenCXX/vtable-available-externally.cpp
===
--- test/CodeGenCXX/vtable-available-externally.cpp
+++ test/CodeGenCXX/vtable-available-externally.cpp
@@ -184,8 +184,8 @@
 }  // Test8
 
 namespace Test9 {
-// all virtual functions are outline, so we can assume that it will
-// be generated in translation unit where foo is defined
+// All virtual functions are outline, so we can assume that it will
+// be generated in translation unit where foo is defined.
 // CHECK-TEST9-DAG: @_ZTVN5Test91AE = available_externally unnamed_addr constant
 // CHECK-TEST9-DAG: @_ZTVN5Test91BE = available_externally unnamed_addr constant
 struct A {
@@ -217,23 +217,23 @@
 };
 void A::foo() {}
 
-// Because key function is inline we will generate vtable as linkonce_odr
+// Because key function is inline we will generate vtable as linkonce_odr.
 // CHECK-TEST10-DAG: @_ZTVN6Test101DE = linkonce_odr unnamed_addr constant
 struct D : A {
   void bar();
 };
 inline void D::bar() {}
 
-// because B has outline key function then we can refer to
+// Because B has outline all virtual functions, we can refer to them.
 // CHECK-TEST10-DAG: @_ZTVN6Test101BE = available_externally unnamed_addr constant
 struct B : A {
   void foo();
   void bar();
 };
 
 // C's key function (car) is outline, but C has inline virtual function so we
 // can't guarantee that we will be able to refer to bar from name
-// so (at the moment) we can't emit vtable available_externally
+// so (at the moment) we can't emit vtable available_externally.
 // CHECK-TEST10-DAG: @_ZTVN6Test101CE = external unnamed_addr constant
 struct C : A {
   void bar() {}   // defined in body - not key function
@@ -365,4 +365,3 @@
 }
 }
 
-
Index: test/CodeGenCXX/vtable-assume-load.cpp
===
--- test/CodeGenCXX/vtable-assume-load.cpp
+++ test/CodeGenCXX/vtable-assume-load.cpp
@@ -6,7 +6,9 @@
 // RUN: FileCheck --check-prefix=CHECK3 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK4 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK-MS --input-file=%t.ms.ll %s
-
+// RUN: FileCheck --check-prefix=CHECK6 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK7 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK8 --input-file=%t.ll %s
 namespace test1 {
 
 struct A {
@@ -150,23 +152,144 @@
 }
 } // test4
 
-namespace test5 {
+namespace testMS {
 
 struct __declspec(novtable) S {
   virtual void foo();
 };
 
 void g(S s) { s.foo(); }
 
 // if struct has novtable specifier, then we can't generate assumes
-// CHECK-MS-LABEL: define void @\01?test@test5@@YAXXZ()
-// CHECK-MS: call x86_thiscallcc %struct.test5::S* @\01??0S@test5@@QAE@XZ(
+// CHECK-MS-LABEL: define void @\01?test@testMS@@YAXXZ()
+// CHECK-MS: call x86_thiscallcc %struct.testMS::S* @\01??0S@testMS@@QAE@XZ(
 // CHECK-MS-NOT: @llvm.assume
 // CHECK-MS-LABEL: }
 
 void test() {
   S s;
   g(s);
 }
 
-} // test5
+} // testMS
+
+namespace test6 {
+// CHECK6: @_ZTVN5test61AE = external
+struct A {
+  A();
+  virtual void foo();
+  virtual ~A() {}
+};
+struct B : A {
+  B();
+};
+// Because A's vtable is external, it's safe to generate assumption loads.
+// CHECK6-LABEL: define void @_ZN5test61gEv()
+// CHECK6: call void @_ZN5test61AC1Ev(
+// CHECK6: call void @llvm.assume(
+
+// We can't emit assumption loads for B, because if we would refer to vtable
+// it would refer to functions that will not be able to find (like implicit
+// inline destructor).
+
+// CHECK6-LABEL:   call void @_ZN5test61BC1Ev(
+// CHECK6-NOT: call void @llvm.assume(
+// CHECK6-LABEL: }
+void g() {
+  A *a = new A;
+  B *b = new B;
+}
+
+}
+
+namespace test7 {
+// Because A's key function is defined here, vtable is generated in this TU
+// CHECK7: @_ZTVN5test71AE = unnamed_addr constant
+struct A {
+  A();
+  virtual void foo();
+  virtual void bar();
+};
+void A::foo() {}
+
+// CHECK7-LABEL: define void @_ZN5test71gEv()
+// CHECK7: call void @_ZN5test71AC1Ev(
+// CHECK7: call void @llvm.assume(
+// CHECK7-LABEL: }
+void g() {
+  A *a = new A();
+  a-bar();
+}
+}
+
+namespace test8 {
+
+struct A {
+  virtual void foo();
+  virtual void bar();
+};
+
+// CHECK8-DAG: @_ZTVN5test81BE = available_externally unnamed_addr constant
+struct B : A {
+  B();
+  void foo();
+  void bar();
+};
+
+// CHECK8-DAG: @_ZTVN5test81CE = linkonce_odr unnamed_addr constant
+struct C : A {
+  C();
+  void bar();
+  void foo() {}
+};
+inline void C::bar() {}
+
+// CHECK8-DAG: @_ZTVN5test81DE = external unnamed_addr 

[libcxx] r246113 - Creating release candidate rc4 from release_370 branch

2015-08-26 Thread Hans Wennborg via cfe-commits
Author: hans
Date: Wed Aug 26 18:34:53 2015
New Revision: 246113

URL: http://llvm.org/viewvc/llvm-project?rev=246113view=rev
Log:
Creating release candidate rc4 from release_370 branch

Added:
libcxx/tags/RELEASE_370/rc4/   (props changed)
  - copied from r246112, libcxx/branches/release_37/

Propchange: libcxx/tags/RELEASE_370/rc4/
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Wed Aug 26 18:34:53 2015
@@ -0,0 +1,2 @@
+/libcxx/branches/apple:136569-137939
+/libcxx/trunk:242377,242421,243530,243641,244003,244462


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


[libcxxabi] r246114 - Creating release candidate rc4 from release_370 branch

2015-08-26 Thread Hans Wennborg via cfe-commits
Author: hans
Date: Wed Aug 26 18:34:56 2015
New Revision: 246114

URL: http://llvm.org/viewvc/llvm-project?rev=246114view=rev
Log:
Creating release candidate rc4 from release_370 branch

Added:
libcxxabi/tags/RELEASE_370/rc4/   (props changed)
  - copied from r246113, libcxxabi/branches/release_37/

Propchange: libcxxabi/tags/RELEASE_370/rc4/
--
svn:mergeinfo = /libcxxabi/trunk:244004


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


[libunwind] r246120 - Creating release candidate rc4 from release_370 branch

2015-08-26 Thread Hans Wennborg via cfe-commits
Author: hans
Date: Wed Aug 26 18:35:14 2015
New Revision: 246120

URL: http://llvm.org/viewvc/llvm-project?rev=246120view=rev
Log:
Creating release candidate rc4 from release_370 branch

Added:
libunwind/tags/RELEASE_370/rc4/   (props changed)
  - copied from r246119, libunwind/branches/release_37/

Propchange: libunwind/tags/RELEASE_370/rc4/
--
svn:mergeinfo = /libunwind/trunk:242642,243073,244005,244237


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


[PATCH] D12389: Conditionalize X86 Darwin MaxVectorAlign on the presence of AVX.

2015-08-26 Thread Ahmed Bougacha via cfe-commits
ab created this revision.
ab added a reviewer: rjmccall.
ab added a subscriber: cfe-commits.

The long-overdue (sorry!) prequel to D10724.

http://reviews.llvm.org/D12389

Files:
  lib/Basic/Targets.cpp
  test/CodeGen/vector-alignment.c

Index: test/CodeGen/vector-alignment.c
===
--- test/CodeGen/vector-alignment.c
+++ test/CodeGen/vector-alignment.c
@@ -1,38 +1,51 @@
-// RUN: %clang_cc1 -w -triple x86_64-apple-darwin10 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -triple x86_64-apple-darwin10 \
+// RUN:  -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=SSE
+// RUN: %clang_cc1 -w -triple   i386-apple-darwin10 \
+// RUN:  -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=SSE
+// RUN: %clang_cc1 -w -triple x86_64-apple-darwin10 -target-feature +avx \
+// RUN:  -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=AVX
+// RUN: %clang_cc1 -w -triple   i386-apple-darwin10 -target-feature +avx \
+// RUN:  -emit-llvm -o - %s | FileCheck %s --check-prefix=ALL --check-prefix=AVX
 // rdar://11759609
 
 // At or below target max alignment with no aligned attribute should align based
 // on the size of vector.
 double __attribute__((vector_size(16))) v1;
-// CHECK: @v1 {{.*}}, align 16
+// SSE: @v1 {{.*}}, align 16
+// AVX: @v1 {{.*}}, align 16
 double __attribute__((vector_size(32))) v2;
-// CHECK: @v2 {{.*}}, align 32
+// SSE: @v2 {{.*}}, align 16
+// AVX: @v2 {{.*}}, align 32
 
 // Alignment above target max alignment with no aligned attribute should align
 // based on the target max.
 double __attribute__((vector_size(64))) v3;
-// CHECK: @v3 {{.*}}, align 32
+// SSE: @v3 {{.*}}, align 16
+// AVX: @v3 {{.*}}, align 32
 double __attribute__((vector_size(1024))) v4;
-// CHECK: @v4 {{.*}}, align 32
+// SSE: @v4 {{.*}}, align 16
+// AVX: @v4 {{.*}}, align 32
 
 // Aliged attribute should always override.
 double __attribute__((vector_size(16), aligned(16))) v5;
-// CHECK: @v5 {{.*}}, align 16
+// ALL: @v5 {{.*}}, align 16
 double __attribute__((vector_size(16), aligned(64))) v6;
-// CHECK: @v6 {{.*}}, align 64
+// ALL: @v6 {{.*}}, align 64
 double __attribute__((vector_size(32), aligned(16))) v7;
-// CHECK: @v7 {{.*}}, align 16
+// ALL: @v7 {{.*}}, align 16
 double __attribute__((vector_size(32), aligned(64))) v8;
-// CHECK: @v8 {{.*}}, align 64
+// ALL: @v8 {{.*}}, align 64
 
 // Check non-power of 2 widths.
 double __attribute__((vector_size(24))) v9;
-// CHECK: @v9 {{.*}}, align 32
+// SSE: @v9 {{.*}}, align 16
+// AVX: @v9 {{.*}}, align 32
 double __attribute__((vector_size(40))) v10;
-// CHECK: @v10 {{.*}}, align 32
+// SSE: @v10 {{.*}}, align 16
+// AVX: @v10 {{.*}}, align 32
 
 // Check non-power of 2 widths with aligned attribute.
 double __attribute__((vector_size(24), aligned(64))) v11;
-// CHECK: @v11 {{.*}}, align 64
+// ALL: @v11 {{.*}}, align 64
 double __attribute__((vector_size(80), aligned(16))) v12;
-// CHECK: @v12 {{.*}}, align 16
+// ALL: @v12 {{.*}}, align 16
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -3622,13 +3622,21 @@
 LongDoubleWidth = 128;
 LongDoubleAlign = 128;
 SuitableAlign = 128;
-MaxVectorAlign = 256;
 SizeType = UnsignedLong;
 IntPtrType = SignedLong;
 DataLayoutString = e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128;
 HasAlignMac68kSupport = true;
   }
 
+  bool handleTargetFeatures(std::vectorstd::string Features,
+DiagnosticsEngine Diags) override {
+if (!DarwinTargetInfoX86_32TargetInfo::handleTargetFeatures(Features,
+  Diags))
+  return false;
+// Now that we know if we have AVX, we can decide how to align vectors.
+MaxVectorAlign = getABI().startswith(avx) ? 256 : 128;
+return true;
+  }
 };
 
 // x86-32 Windows target
@@ -3979,13 +3987,22 @@
   DarwinX86_64TargetInfo(const llvm::Triple Triple)
   : DarwinTargetInfoX86_64TargetInfo(Triple) {
 Int64Type = SignedLongLong;
-MaxVectorAlign = 256;
 // The 64-bit iOS simulator uses the builtin bool type for Objective-C.
 llvm::Triple T = llvm::Triple(Triple);
 if (T.isiOS())
   UseSignedCharForObjCBool = false;
 DataLayoutString = e-m:o-i64:64-f80:128-n8:16:32:64-S128;
   }
+
+  bool handleTargetFeatures(std::vectorstd::string Features,
+DiagnosticsEngine Diags) override {
+if (!DarwinTargetInfoX86_64TargetInfo::handleTargetFeatures(Features,
+  Diags))
+  return false;
+// Now that we know if we have AVX, we can decide how to align vectors.
+MaxVectorAlign = getABI().startswith(avx) ? 256 : 128;
+return true;
+  }
 };
 
 class OpenBSDX86_64TargetInfo : public OpenBSDTargetInfoX86_64TargetInfo {

[PATCH] D12390: Also enable the avx/avx512 ABIs for i386, not just x86_64.

2015-08-26 Thread Ahmed Bougacha via cfe-commits
ab created this revision.
ab added a reviewer: rjmccall.
ab added a subscriber: cfe-commits.

One problem that came up in D12389 is that i386 doesn't know about the avx 
ABIs.  Judging by the commit that originally introduced the X86_64 check and 
the avx ABI (r145652), it was just unnecessary.

Because of that, we can't decide based on the ABI string only for i386.

The only effect this should have is that SimdDefaultAlign would previously 
always be 128 on i386, no matter the SSE level. We will now use a larger 
alignment, which seems desirable to me. I added i386 RUN lines to the OpenMP 
simd test.

I also moved the no-mmx check earlier, as I gather it's necessary for 
correctness with -mno-mmx (as opposed to the avx ABIs which make no 
difference other than SIMD/vector alignment on i386).

http://reviews.llvm.org/D12390

Files:
  lib/Basic/Targets.cpp
  test/OpenMP/simd_metadata.c

Index: test/OpenMP/simd_metadata.c
===
--- test/OpenMP/simd_metadata.c
+++ test/OpenMP/simd_metadata.c
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -emit-llvm %s -o - 
| FileCheck %s -check-prefix=CHECK -check-prefix=X86
 // RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature 
+avx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
 // RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature 
+avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK 
-check-prefix=X86-AVX512
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -emit-llvm %s -o - | 
FileCheck %s -check-prefix=CHECK -check-prefix=X86
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature +avx 
-emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature 
+avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK 
-check-prefix=X86-AVX512
 // RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -emit-llvm %s -o 
- | FileCheck %s -check-prefix=CHECK -check-prefix=PPC
 // RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -target-abi 
elfv1-qpx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK 
-check-prefix=PPC-QPX
 
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2308,13 +2308,13 @@
   bool handleTargetFeatures(std::vectorstd::string Features,
 DiagnosticsEngine Diags) override;
   StringRef getABI() const override {
-if (getTriple().getArch() == llvm::Triple::x86_64  SSELevel = AVX512F)
+if (getTriple().getArch() == llvm::Triple::x86 
+MMX3DNowLevel == NoMMX3DNow)
+  return no-mmx;
+else if (SSELevel = AVX512F)
   return avx512;
-else if (getTriple().getArch() == llvm::Triple::x86_64  SSELevel = AVX)
+else if (SSELevel = AVX)
   return avx;
-else if (getTriple().getArch() == llvm::Triple::x86 
- MMX3DNowLevel == NoMMX3DNow)
-  return no-mmx;
 return ;
   }
   bool setCPU(const std::string Name) override {


Index: test/OpenMP/simd_metadata.c
===
--- test/OpenMP/simd_metadata.c
+++ test/OpenMP/simd_metadata.c
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86
 // RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature +avx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
 // RUN: %clang_cc1 -fopenmp -triple x86_64-unknown-unknown -target-feature +avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX512
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature +avx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX
+// RUN: %clang_cc1 -fopenmp -triple i386-unknown-unknown -target-feature +avx512f -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=X86-AVX512
 // RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=PPC
 // RUN: %clang_cc1 -fopenmp -triple powerpc64-unknown-unknown -target-abi elfv1-qpx -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK -check-prefix=PPC-QPX
 
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2308,13 +2308,13 @@
   bool handleTargetFeatures(std::vectorstd::string Features,
 DiagnosticsEngine Diags) override;
   StringRef getABI() const override {
-if (getTriple().getArch() == llvm::Triple::x86_64  SSELevel = AVX512F)
+if 

Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

In http://reviews.llvm.org/D12247#231444, @yiranwang wrote:

 A test case is as following. It has to be build by GCC 4.9 -O3 (maybe or 
 later), with latest libc++, and for AARCH64+ANDROID target. 
  AARCH64 requires 128 bit alignment for aligned_storage and 64 bit pointers, 
 while gcc 4.9 alias analysis will do field-sensitive points-to analysis. But 
 this could happen for other ISA+ABI.
  The fundamental issue is that for this combination, std::function has member 
 __buf_ declared as 
  aligned_storage3*sizoef(void*)::type __buf_;
  Basically, it is
  aligned_storage24::type;
  This will generate aligned_storage of, _Len==24 and _Align==16;
  While std::function will use the __buf_ to sizeof(__buf_) bytes (at line 
 1593 and 1628 of functional), which is 32. Basically, the pointer to 
 tbool' will be stored at __buf_+24. 
  This is not a well defined memory area, and GCC alias analysis is going to 
 ignore the ESCAPE of address of tbool. Basically, the function 
 test_simple would always return false.

 #include functional
  extern void external_test(std::functionbool()fn);
  extern bool test_simple(){

   bool tbool = false;
   int a, b;
   external_test([a, b, tbool](){
 tbool = true;
 return true;
   });
   return tbool;

 }


What GCC flags do I need to build it in this configuration?


http://reviews.llvm.org/D12247



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


r246105 - [Static Analyzer] Checks to catch nullability related issues.

2015-08-26 Thread Gabor Horvath via cfe-commits
Author: xazax
Date: Wed Aug 26 18:17:43 2015
New Revision: 246105

URL: http://llvm.org/viewvc/llvm-project?rev=246105view=rev
Log:
[Static Analyzer] Checks to catch nullability related issues.

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

Added:
cfe/trunk/docs/analyzer/nullability.rst
cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
cfe/trunk/test/Analysis/nullability.mm
Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td

Added: cfe/trunk/docs/analyzer/nullability.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/analyzer/nullability.rst?rev=246105view=auto
==
--- cfe/trunk/docs/analyzer/nullability.rst (added)
+++ cfe/trunk/docs/analyzer/nullability.rst Wed Aug 26 18:17:43 2015
@@ -0,0 +1,92 @@
+
+Nullability Checks
+
+
+This document is a high level description of the nullablility checks.
+These checks intended to use the annotations that is described in this
+RFC: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-March/041798.html.
+
+Let's consider the following 2 categories:
+
+1) nullable
+
+
+If a pointer 'p' has a nullable annotation and no explicit null check or 
assert, we should warn in the following cases:
+- 'p' gets implicitly converted into nonnull pointer, for example, we are 
passing it to a function that takes a nonnull parameter.
+- 'p' gets dereferenced
+
+Taking a branch on nullable pointers are the same like taking branch on null 
unspecified pointers.
+
+Explicit cast from nullable to nonnul::
+
+__nullable id foo;
+id bar = foo;
+takesNonNull((_nonnull) bar); — should not warn here (backward 
compatibility hack)
+anotherTakesNonNull(bar); — would be great to warn here, but not 
necessary(*)
+
+Because bar corresponds to the same symbol all the time it is not easy to 
implement the checker that way the cast only suppress the first call but not 
the second. For this reason in the first implementation after a contradictory 
cast happens, I will treat bar as nullable unspecified, this way all of the 
warnings will be suppressed. Treating the symbol as nullable unspecified also 
has an advantage that in case the takesNonNull function body is being inlined, 
the will be no warning, when the symbol is dereferenced. In case I have time 
after the initial version I might spend additional time to try to find a more 
sophisticated solution, in which we would produce the second warning (*).
+ 
+2) nonnull
+
+
+- Dereferencing a nonnull, or sending message to it is ok.
+- Converting nonnull to nullable is Ok.
+- When there is an explicit cast from nonnull to nullable I will trust the 
cast (it is probable there for a reason, because this cast does not suppress 
any warnings or errors).
+- But what should we do about null checks?::
+
+__nonnull id takesNonnull(__nonnull id x) {
+if (x == nil) {
+// Defensive backward compatible code:
+
+return nil; - Should the analyzer cover this piece of code? 
Should we require the cast (__nonnull)nil?
+}
+
+}
+
+There are these directions:
+- We can either take the branch; this way the branch is analyzed
+   - Should we not warn about any nullability issues in that branch? 
Probably not, it is ok to break the nullability postconditions when the 
nullability preconditions are violated.
+- We can assume that these pointers are not null and we lose coverage with the 
analyzer. (This can be implemented either in constraint solver or in the 
checker itself.)
+
+Other Issues to keep in mind/take care of:
+Messaging:
+- Sending a message to a nullable pointer
+   - Even though the method might return a nonnull pointer, when it was 
sent to a nullable pointer the return type will be nullable.
+   - The result is nullable unless the receiver is known to be non null.
+- Sending a message to a unspecified or nonnull pointer
+   - If the pointer is not assumed to be nil, we should be optimistic and 
use the nullability implied by the method.
+- This will not happen automatically, since the AST will have null 
unspecified in this case.
+
+Inlining
+
+
+A symbol may need to be treated differently inside an inlined body. For 
example, consider these conversions from nonnull to nullable in presence of 
inlining::
+
+id obj = getNonnull();
+takesNullable(obj);
+takesNonnull(obj);
+
+void takesNullable(nullable id obj) {
+   obj-ivar // we should assume obj is nullable and warn here
+}
+   
+With no special treatment, when the takesNullable is inlined the analyzer will 
not warn when the obj symbol is dereferenced. One solution for this is to 
reanalyze takesNullable as a top level function to get possible violations. The 
alternative method, deducing nullability information 

Re: [PATCH] D12385: Generating Assumption loads fix

2015-08-26 Thread Richard Smith via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

LGTM with some comment tweaks.



Comment at: lib/CodeGen/CGClass.cpp:1861
@@ +1860,3 @@
+  // We also have to make sure if we can refer to vtable:
+  // - If vtable is external then it's safe to use it (for availabe_externally
+  //   CGVTables will make sure if it can emit it).

Typo availabe


Comment at: lib/CodeGen/CGClass.cpp:1863
@@ +1862,3 @@
+  //   CGVTables will make sure if it can emit it).
+  // - Otherwise we can refer to vtable if it's unused.
+  // FIXME: If vtable is used by ctor/dtor, we are always safe to refer to it.

unused - safe to speculatively emit


http://reviews.llvm.org/D12385



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


Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

2015-08-26 Thread Xinliang David Li via cfe-commits
On Wed, Aug 26, 2015 at 3:38 PM, Eric Fiselier e...@efcs.ca wrote:
 EricWF added a comment.

 In http://reviews.llvm.org/D12247#233717, @yiranwang wrote:

 Hi Eric,

 Could you please explain a bit more what is broken specifically? As we can 
 see, sizeof(), _Len, and _Align, and alignof() of aligned_storage are all 
 not changed.


 That's correct. At the risk of sounding like a broken record those fields 
 have not changed because doing so would break the ABI. Instead my patch fixes 
 the issue your seeing by simply not using __buf_ unless its the correct size 
 and correctly aligned.

This seems safe. The downside is that some cases which uses internal
buffer before now will use dynamic allocator which might have some
small performance and memory regression.

David


 The alignment is the important part. Previously we didn't check if `Fn` was 
 alignment compatible with `__buf_`.


 http://reviews.llvm.org/D12247



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


r246122 - Pull out cpu string - enum parsing for x86 as a separate function,

2015-08-26 Thread Eric Christopher via cfe-commits
Author: echristo
Date: Wed Aug 26 18:42:18 2015
New Revision: 246122

URL: http://llvm.org/viewvc/llvm-project?rev=246122view=rev
Log:
Pull out cpu string - enum parsing for x86 as a separate function,
this is going to see use shortly in unifying feature set construction.

Modified:
cfe/trunk/lib/Basic/Targets.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=246122r1=246121r2=246122view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed Aug 26 18:42:18 2015
@@ -2230,6 +2230,75 @@ class X86TargetInfo : public TargetInfo
 //@}
   } CPU;
 
+  CPUKind getCPUKind(StringRef CPU) {
+return llvm::StringSwitchCPUKind(CPU)
+.Case(i386, CK_i386)
+.Case(i486, CK_i486)
+.Case(winchip-c6, CK_WinChipC6)
+.Case(winchip2, CK_WinChip2)
+.Case(c3, CK_C3)
+.Case(i586, CK_i586)
+.Case(pentium, CK_Pentium)
+.Case(pentium-mmx, CK_PentiumMMX)
+.Case(i686, CK_i686)
+.Case(pentiumpro, CK_PentiumPro)
+.Case(pentium2, CK_Pentium2)
+.Case(pentium3, CK_Pentium3)
+.Case(pentium3m, CK_Pentium3M)
+.Case(pentium-m, CK_PentiumM)
+.Case(c3-2, CK_C3_2)
+.Case(yonah, CK_Yonah)
+.Case(pentium4, CK_Pentium4)
+.Case(pentium4m, CK_Pentium4M)
+.Case(prescott, CK_Prescott)
+.Case(nocona, CK_Nocona)
+.Case(core2, CK_Core2)
+.Case(penryn, CK_Penryn)
+.Case(bonnell, CK_Bonnell)
+.Case(atom, CK_Bonnell) // Legacy name.
+.Case(silvermont, CK_Silvermont)
+.Case(slm, CK_Silvermont) // Legacy name.
+.Case(nehalem, CK_Nehalem)
+.Case(corei7, CK_Nehalem) // Legacy name.
+.Case(westmere, CK_Westmere)
+.Case(sandybridge, CK_SandyBridge)
+.Case(corei7-avx, CK_SandyBridge) // Legacy name.
+.Case(ivybridge, CK_IvyBridge)
+.Case(core-avx-i, CK_IvyBridge) // Legacy name.
+.Case(haswell, CK_Haswell)
+.Case(core-avx2, CK_Haswell) // Legacy name.
+.Case(broadwell, CK_Broadwell)
+.Case(skylake, CK_Skylake)
+.Case(skx, CK_Skylake) // Legacy name.
+.Case(knl, CK_KNL)
+.Case(k6, CK_K6)
+.Case(k6-2, CK_K6_2)
+.Case(k6-3, CK_K6_3)
+.Case(athlon, CK_Athlon)
+.Case(athlon-tbird, CK_AthlonThunderbird)
+.Case(athlon-4, CK_Athlon4)
+.Case(athlon-xp, CK_AthlonXP)
+.Case(athlon-mp, CK_AthlonMP)
+.Case(athlon64, CK_Athlon64)
+.Case(athlon64-sse3, CK_Athlon64SSE3)
+.Case(athlon-fx, CK_AthlonFX)
+.Case(k8, CK_K8)
+.Case(k8-sse3, CK_K8SSE3)
+.Case(opteron, CK_Opteron)
+.Case(opteron-sse3, CK_OpteronSSE3)
+.Case(barcelona, CK_AMDFAM10)
+.Case(amdfam10, CK_AMDFAM10)
+.Case(btver1, CK_BTVER1)
+.Case(btver2, CK_BTVER2)
+.Case(bdver1, CK_BDVER1)
+.Case(bdver2, CK_BDVER2)
+.Case(bdver3, CK_BDVER3)
+.Case(bdver4, CK_BDVER4)
+.Case(x86-64, CK_x86_64)
+.Case(geode, CK_Geode)
+.Default(CK_Generic);
+  }
+
   enum FPMathKind {
 FP_Default,
 FP_SSE,
@@ -2318,72 +2387,7 @@ public:
 return ;
   }
   bool setCPU(const std::string Name) override {
-CPU = llvm::StringSwitchCPUKind(Name)
-  .Case(i386, CK_i386)
-  .Case(i486, CK_i486)
-  .Case(winchip-c6, CK_WinChipC6)
-  .Case(winchip2, CK_WinChip2)
-  .Case(c3, CK_C3)
-  .Case(i586, CK_i586)
-  .Case(pentium, CK_Pentium)
-  .Case(pentium-mmx, CK_PentiumMMX)
-  .Case(i686, CK_i686)
-  .Case(pentiumpro, CK_PentiumPro)
-  .Case(pentium2, CK_Pentium2)
-  .Case(pentium3, CK_Pentium3)
-  .Case(pentium3m, CK_Pentium3M)
-  .Case(pentium-m, CK_PentiumM)
-  .Case(c3-2, CK_C3_2)
-  .Case(yonah, CK_Yonah)
-  .Case(pentium4, CK_Pentium4)
-  .Case(pentium4m, CK_Pentium4M)
-  .Case(prescott, CK_Prescott)
-  .Case(nocona, CK_Nocona)
-  .Case(core2, CK_Core2)
-  .Case(penryn, CK_Penryn)
-  .Case(bonnell, CK_Bonnell)
-  .Case(atom, CK_Bonnell) // Legacy name.
-  .Case(silvermont, CK_Silvermont)
-  .Case(slm, CK_Silvermont) // Legacy name.
-  .Case(nehalem, CK_Nehalem)
-  .Case(corei7, CK_Nehalem) // Legacy name.
-  .Case(westmere, CK_Westmere)
-  .Case(sandybridge, CK_SandyBridge)
-  .Case(corei7-avx, CK_SandyBridge) // Legacy name.
-  .Case(ivybridge, CK_IvyBridge)
-  .Case(core-avx-i, CK_IvyBridge) // Legacy name.
-  .Case(haswell, CK_Haswell)
-  .Case(core-avx2, CK_Haswell) // Legacy name.
-  .Case(broadwell, CK_Broadwell)
-  .Case(skylake, CK_Skylake)
-  .Case(skx, CK_Skylake) // Legacy name.
-  .Case(knl, CK_KNL)
-  .Case(k6, CK_K6)
-  .Case(k6-2, CK_K6_2)
-  

Re: [PATCH] D12022: Refactored dtor sanitizing into EHScopeStack

2015-08-26 Thread Evgeniy Stepanov via cfe-commits
eugenis added a comment.

Richard, would you mind taking a look a this change?


http://reviews.llvm.org/D12022



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


Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

2015-08-26 Thread Anna Zaks via cfe-commits
zaks.anna requested changes to this revision.
zaks.anna added a comment.
This revision now requires changes to proceed.

I agree that the way the static analyzer handles loops with known bounds is 
quite bad and we loose coverage because of it, so this is definitely an 
important problem to solve!

I've briefly looked at the patch and the main problem is that while you reset 
the value of the counter variable, you do not change the values of the other 
variables. This will leave us in a state that is wrong and will likely lead to 
false positives and inconsistencies, avoiding which is extremely important.

A way this could be improved is by invalidating all the values that the loops 
effects, both the values on the stack and on the heap. (We could even start 
overly conservative and invalidate all the values in the state; setting the 
known values to unknown values.)


http://reviews.llvm.org/D12358



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


Re: [PATCH] D11740: ABI versioning macros for libc++

2015-08-26 Thread Evgeniy Stepanov via cfe-commits
eugenis added a comment.

 How long is a major and minor ABI version supported?


We don't want to bump major version too often, and we want to support both +1 
and -1 of the current major version, along with all possible minor versions.

 When is the major and minor ABI version bumped?


See Abi.rst for very brief description.

 How will maintaining multiple ABI versions affect code complexity and 
 maintainability?


I'm not sure how to answer this. Depends on the feature in question. The logic 
of selecting features based on the ABI version number should not cause any 
maintenance burden by itself.

 Should bumping the ABI major version bump the SO version?

  Should bumping the ABI major version change the include path from 
 include/c++/v1 to include/c++/v2? What kind of clang support do we need to do 
 this?


I've implemented both. We might not need this support now, but it could be 
useful at the point of v1-v2 migration.


http://reviews.llvm.org/D11740



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


[PATCH] D12384: Libc++abi: find libc++ headers w/o find_path

2015-08-26 Thread Evgeniy Stepanov via cfe-commits
eugenis created this revision.
eugenis added reviewers: EricWF, mclow.lists.
eugenis added a subscriber: cfe-commits.
eugenis set the repository for this revision to rL LLVM.

With http://reviews.llvm.org/D11740, libc++ headers can not be used from the 
libc++ source directly, because they include an auto-generated header with ABI 
version numbers.

This change makes libc++abi pick up the headers in the binary dir. Because of 
cmake inclusion order, those headers are not ready yet when libc++abi 
CMakeLists is executed, and can not be found with find_path. Hardcode the path 
to the headers instead.


Repository:
  rL LLVM

http://reviews.llvm.org/D12384

Files:
  CMakeLists.txt

Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -119,6 +119,7 @@
 set(LIBCXXABI_GCC_TOOLCHAIN  CACHE STRING GCC toolchain for cross 
compiling.)
 set(LIBCXXABI_SYSROOT  CACHE STRING Sysroot for cross compiling.)
 set(LIBCXXABI_LIBCXX_LIBRARY_PATH  CACHE STRING The path to libc++ 
library.)
+set(LIBCXX_ABI_MAJOR_VERSION 1 CACHE STRING Major ABI version of libc++.)
 
 # Default to building a shared library so that the default options still test
 # the libc++abi that is being built. There are two problems with testing a
@@ -133,15 +134,21 @@
   message(FATAL_ERROR libc++abi must be built as either a shared or static 
library.)
 endif()
 
-find_path(
-  LIBCXXABI_LIBCXX_INCLUDES
-  vector
-  PATHS ${LIBCXXABI_LIBCXX_INCLUDES}
-${LIBCXXABI_LIBCXX_PATH}/include
-${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBCXX_INCLUDES}
-${LLVM_MAIN_SRC_DIR}/projects/libcxx/include
-${LLVM_INCLUDE_DIR}/c++/v1
-  )
+if (NOT ${LLVM_MAIN_SRC_DIR} STREQUAL )
+  # When building as part of LLVM, libc++ headers will end up under
+  # ${CMAKE_BINARY_DIR}. They are not there yet, so we can not use find_path.
+  set(LIBCXXABI_LIBCXX_INCLUDES
+${CMAKE_BINARY_DIR}/include/c++/v${LIBCXX_ABI_MAJOR_VERSION})
+else()
+  find_path(
+LIBCXXABI_LIBCXX_INCLUDES
+vector
+PATHS ${LIBCXXABI_LIBCXX_INCLUDES}
+  ${CMAKE_BINARY_DIR}/include/c++/v${LIBCXX_ABI_MAJOR_VERSION}
+  ${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBCXX_INCLUDES}
+  ${LLVM_INCLUDE_DIR}/c++/v${LIBCXX_ABI_MAJOR_VERSION}
+)
+endif()
 
 set(LIBCXXABI_LIBCXX_INCLUDES ${LIBCXXABI_LIBCXX_INCLUDES} CACHE PATH
 Specify path to libc++ includes. FORCE)


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -119,6 +119,7 @@
 set(LIBCXXABI_GCC_TOOLCHAIN  CACHE STRING GCC toolchain for cross compiling.)
 set(LIBCXXABI_SYSROOT  CACHE STRING Sysroot for cross compiling.)
 set(LIBCXXABI_LIBCXX_LIBRARY_PATH  CACHE STRING The path to libc++ library.)
+set(LIBCXX_ABI_MAJOR_VERSION 1 CACHE STRING Major ABI version of libc++.)
 
 # Default to building a shared library so that the default options still test
 # the libc++abi that is being built. There are two problems with testing a
@@ -133,15 +134,21 @@
   message(FATAL_ERROR libc++abi must be built as either a shared or static library.)
 endif()
 
-find_path(
-  LIBCXXABI_LIBCXX_INCLUDES
-  vector
-  PATHS ${LIBCXXABI_LIBCXX_INCLUDES}
-${LIBCXXABI_LIBCXX_PATH}/include
-${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBCXX_INCLUDES}
-${LLVM_MAIN_SRC_DIR}/projects/libcxx/include
-${LLVM_INCLUDE_DIR}/c++/v1
-  )
+if (NOT ${LLVM_MAIN_SRC_DIR} STREQUAL )
+  # When building as part of LLVM, libc++ headers will end up under
+  # ${CMAKE_BINARY_DIR}. They are not there yet, so we can not use find_path.
+  set(LIBCXXABI_LIBCXX_INCLUDES
+${CMAKE_BINARY_DIR}/include/c++/v${LIBCXX_ABI_MAJOR_VERSION})
+else()
+  find_path(
+LIBCXXABI_LIBCXX_INCLUDES
+vector
+PATHS ${LIBCXXABI_LIBCXX_INCLUDES}
+  ${CMAKE_BINARY_DIR}/include/c++/v${LIBCXX_ABI_MAJOR_VERSION}
+  ${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBCXX_INCLUDES}
+  ${LLVM_INCLUDE_DIR}/c++/v${LIBCXX_ABI_MAJOR_VERSION}
+)
+endif()
 
 set(LIBCXXABI_LIBCXX_INCLUDES ${LIBCXXABI_LIBCXX_INCLUDES} CACHE PATH
 Specify path to libc++ includes. FORCE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r246094 - [ARM] Mark mcr/mrc builtin operands as required-immediate.

2015-08-26 Thread Ahmed Bougacha via cfe-commits
Author: ab
Date: Wed Aug 26 17:21:07 2015
New Revision: 246094

URL: http://llvm.org/viewvc/llvm-project?rev=246094view=rev
Log:
[ARM] Mark mcr/mrc builtin operands as required-immediate.

An early error message is better than the cannot select alternative.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsARM.def
cfe/trunk/test/CodeGen/builtins-arm.c
cfe/trunk/test/Sema/builtins-arm.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsARM.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsARM.def?rev=246094r1=246093r2=246094view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsARM.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsARM.def Wed Aug 26 17:21:07 2015
@@ -48,14 +48,14 @@ BUILTIN(__builtin_arm_vcvtr_f, ffi, n
 BUILTIN(__builtin_arm_vcvtr_d, fdi, nc)
 
 // Coprocessor
-BUILTIN(__builtin_arm_mcr, vUiUiUiUiUiUi, )
-BUILTIN(__builtin_arm_mcr2, vUiUiUiUiUiUi, )
-BUILTIN(__builtin_arm_mrc, UiUiUiUiUiUi, )
-BUILTIN(__builtin_arm_mrc2, UiUiUiUiUiUi, )
+BUILTIN(__builtin_arm_mcr, vUIiUIiUiUIiUIiUIi, )
+BUILTIN(__builtin_arm_mcr2, vUIiUIiUiUIiUIiUIi, )
+BUILTIN(__builtin_arm_mrc, UiUIiUIiUIiUIiUIi, )
+BUILTIN(__builtin_arm_mrc2, UiUIiUIiUIiUIiUIi, )
 BUILTIN(__builtin_arm_cdp, vUiUiUiUiUiUi, )
 BUILTIN(__builtin_arm_cdp2, vUiUiUiUiUiUi, )
-BUILTIN(__builtin_arm_mcrr, vUiUiUiUiUi, )
-BUILTIN(__builtin_arm_mcrr2, vUiUiUiUiUi, )
+BUILTIN(__builtin_arm_mcrr, vUIiUIiUiUiUIi, )
+BUILTIN(__builtin_arm_mcrr2, vUIiUIiUiUiUIi, )
 
 // CRC32
 BUILTIN(__builtin_arm_crc32b, UiUiUc, nc)

Modified: cfe/trunk/test/CodeGen/builtins-arm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm.c?rev=246094r1=246093r2=246094view=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm.c Wed Aug 26 17:21:07 2015
@@ -85,6 +85,44 @@ void prefetch(int i) {
 // CHECK: call {{.*}} @llvm.prefetch(i8* %{{.*}}, i32 1, i32 3, i32 0)
 }
 
+unsigned mrc() {
+  // CHECK: define i32 @mrc()
+  // CHECK: [[R:%.*]] = {{.*}} call i32 @llvm.arm.mrc(i32 15, i32 0, i32 13, 
i32 0, i32 3)
+  // CHECK-NEXT: ret i32 [[R]]
+  return __builtin_arm_mrc(15, 0, 13, 0, 3);
+}
+
+unsigned mrc2() {
+  // CHECK: define i32 @mrc2()
+  // CHECK: [[R:%.*]] = {{.*}} call i32 @llvm.arm.mrc2(i32 15, i32 0, i32 13, 
i32 0, i32 3)
+  // CHECK-NEXT: ret i32 [[R]]
+  return __builtin_arm_mrc2(15, 0, 13, 0, 3);
+}
+
+void mcr(unsigned a) {
+  // CHECK: define void @mcr(i32 [[A:%.*]])
+  // CHECK: call void @llvm.arm.mcr(i32 15, i32 0, i32 [[A]], i32 13, i32 0, 
i32 3)
+  __builtin_arm_mcr(15, 0, a, 13, 0, 3);
+}
+
+void mcr2(unsigned a) {
+  // CHECK: define void @mcr2(i32 [[A:%.*]])
+  // CHECK: call void @llvm.arm.mcr2(i32 15, i32 0, i32 [[A]], i32 13, i32 0, 
i32 3)
+  __builtin_arm_mcr2(15, 0, a, 13, 0, 3);
+}
+
+void mcrr(unsigned a, unsigned b) {
+  // CHECK: define void @mcrr(i32 [[A:%.*]], i32 [[B:%.*]])
+  // CHECK: call void @llvm.arm.mcrr(i32 15, i32 0, i32 [[A]], i32 [[B]], i32 
0)
+  __builtin_arm_mcrr(15, 0, a, b, 0);
+}
+
+void mcrr2(unsigned a, unsigned b) {
+  // CHECK: define void @mcrr2(i32 [[A:%.*]], i32 [[B:%.*]])
+  // CHECK: call void @llvm.arm.mcrr2(i32 15, i32 0, i32 [[A]], i32 [[B]], i32 
0)
+  __builtin_arm_mcrr2(15, 0, a, b, 0);
+}
+
 unsigned rsr() {
   // CHECK: [[V0:[%A-Za-z0-9.]+]] = {{.*}} call i32 
@llvm.read_register.i32(metadata !7)
   // CHECK-NEXT: ret i32 [[V0]]

Modified: cfe/trunk/test/Sema/builtins-arm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/builtins-arm.c?rev=246094r1=246093r2=246094view=diff
==
--- cfe/trunk/test/Sema/builtins-arm.c (original)
+++ cfe/trunk/test/Sema/builtins-arm.c Wed Aug 26 17:21:07 2015
@@ -46,3 +46,37 @@ void test4() {
 void test5() {
   __builtin_arm_dbg(16); // expected-error {{argument should be a value from 0 
to 15}}
 }
+
+void test6(int a, int b, int c) {
+  __builtin_arm_mrc( a, 0, 13, 0, 3); // expected-error {{argument to 
'__builtin_arm_mrc' must be a constant integer}}
+  __builtin_arm_mrc(15, a, 13, 0, 3); // expected-error {{argument to 
'__builtin_arm_mrc' must be a constant integer}}
+  __builtin_arm_mrc(15, 0,  a, 0, 3); // expected-error {{argument to 
'__builtin_arm_mrc' must be a constant integer}}
+  __builtin_arm_mrc(15, 0, 13, a, 3); // expected-error {{argument to 
'__builtin_arm_mrc' must be a constant integer}}
+  __builtin_arm_mrc(15, 0, 13, 0, a); // expected-error {{argument to 
'__builtin_arm_mrc' must be a constant integer}}
+
+  __builtin_arm_mrc2( a, 0, 13, 0, 3); // expected-error {{argument to 
'__builtin_arm_mrc2' must be a constant integer}}
+  __builtin_arm_mrc2(15, a, 13, 0, 3); // expected-error {{argument to 
'__builtin_arm_mrc2' must be a constant integer}}
+  __builtin_arm_mrc2(15, 0,  a, 0, 3); // 

r246095 - DI: Clarify meaning of createTempFunctionFwdDecl() arg, NFC

2015-08-26 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Wed Aug 26 17:21:09 2015
New Revision: 246095

URL: http://llvm.org/viewvc/llvm-project?rev=246095view=rev
Log:
DI: Clarify meaning of createTempFunctionFwdDecl() arg, NFC

I stared at `false /*declaration*/` for quite some time before giving up
and checking the actual function to see what it meant.  Replacing with
`/* isDefinition = */ false` to save myself effort later.

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

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=246095r1=246094r2=246095view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Aug 26 17:21:09 2015
@@ -2386,7 +2386,7 @@ CGDebugInfo::getFunctionForwardDeclarati
   llvm::DISubprogram *SP = DBuilder.createTempFunctionFwdDecl(
   DContext, Name, LinkageName, Unit, Line,
   getOrCreateFunctionType(FD, FnType, Unit), !FD-isExternallyVisible(),
-  false /*declaration*/, 0, Flags, CGM.getLangOpts().Optimize, nullptr,
+  /* isDefinition = */ false, 0, Flags, CGM.getLangOpts().Optimize, 
nullptr,
   TParamsArray.get(), getFunctionDeclaration(FD));
   const FunctionDecl *CanonDecl = castFunctionDecl(FD-getCanonicalDecl());
   FwdDeclReplaceMap.emplace_back(std::piecewise_construct,


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


Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

2015-08-26 Thread Ted Kremenek via cfe-commits
krememek added a comment.

One thing about the tests passing: that's great, but that's obviously 
insufficient.  We probably have fewer tests showing that the analyzer can't 
handle something than tests that show it does handle something.

When a patch like this lands, which expands the analysis scope of the core 
analyzer, a few things are worth measuring:

(1) The impacted analysis time on a typical project.

(2) The impacted memory usage of the analyzer on a  typical project.

(3) Increased analysis coverage.  Are we covering more statements in practice?  
Etc.  Since that is the motivation of this patch, it would be good to benchmark 
it on some real code.

We should, as a community, start keeping track of such things for a few 
projects so we know whether or not experiments like these are objectively a 
real win.


http://reviews.llvm.org/D12358



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


Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

2015-08-26 Thread Ted Kremenek via cfe-commits
krememek added a comment.

In http://reviews.llvm.org/D12358#233983, @zaks.anna wrote:

 A way this could be improved is by invalidating all the values that the loops 
 effects, both the values on the stack and on the heap. (We could even start 
 overly conservative and invalidate all the values in the state; setting the 
 known values to unknown values.)


I worry that this would be far too conservative, and would introduce new false 
positives because of lost precision.

One unsound hack would be to analyze a loop once by unrolling, and then 
invalidate anything that was touched in the ProgramState during that loop 
iteration.  That invalidation could also be transitive, e.g. any subregions of 
touched state, etc.

Another, more principled hack, would be to look at all DeclRefExprs within a 
loop and invalidate all memory in the cone-of-influence of those variables 
(i.e., values they point to, etc.), but that's it.

Then there is the problem of called functions within the loop, as they won't be 
analyzed.  Those could interfere with the ability of a checker to do its job.

My recommendation is that we still unroll loops a couple times, getting full 
precision, and then employ a widening technique like the ones being discussed 
to allow the last loop iteration to act as the last one, but as a conservative 
over-approximation.


http://reviews.llvm.org/D12358



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


Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

2015-08-26 Thread Gábor Horváth via cfe-commits
xazax.hun added a comment.

A conservative solution should work.

But if we want to preserve some precision I think it should be possible to not 
to invalidate those values on the stack that are not effected by the loop. The 
hard problem here is that, it is impossible to reason about the heap without 
global knowledge, so if there is a pointer on the heap to a local variable that 
should be invalidated as well.

What do you think?


http://reviews.llvm.org/D12358



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


Re: [PATCH] D12278: [X86] Add MSVC-compatible intrinsics for clac, stac, lgdt and sgdt

2015-08-26 Thread Saleem Abdulrasool via cfe-commits
compnerd added inline comments.


Comment at: lib/Headers/Intrin.h:961
@@ +960,3 @@
+static __inline__ void __DEFAULT_FN_ATTRS _lgdt(void *__ptr) {
+  __builtin_ia32_lgdt(__ptr);
+}

mkuper wrote:
 compnerd wrote:
  Why does this need a builtin?  Is an inline assembly block using lgdt 
  insufficient for some reason?
 I think using a builtin is, generally, cleaner.
 I'm ok with using inline asm (and abandoning the LLVM part of the patch), if 
 that's the more popular option.
Yes, that is the preference in my experience.  Please do switch to the inline 
asm option.


http://reviews.llvm.org/D12278



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


Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

2015-08-26 Thread Ted Kremenek via cfe-commits

 On Aug 26, 2015, at 3:59 AM, Sean Eveson via cfe-commits 
 cfe-commits@lists.llvm.org wrote:
 
 We have been looking at the following problem, where any code after the 
 constant bound loop is not analyzed because of the limit on how many times 
 the same block is visited, as described in bugzillas #7638 and #23438. This 
 problem is of interest to us because we have identified significant bugs that 
 the checkers are not locating. We have been discussing a solution involving 
 ranges as a longer term project, but I would like to propose a patch to 
 improve the current implementation.

FWIW, I do think this is a great problem to work on.  It is easy to come up 
with solutions that work for specific examples but fall over on general code.  
I completely agree that failing to analyzing code after the loop is a major 
hole and lost opportunity to find bugs, but fixing that should not be at a 
tradeoff of a huge influx in false positives.  Some basic invalidation of 
values touched by the loop, which includes possibly invalidating checker state, 
will likely be necessary.  I think this is what Anna was getting to in her 
comment.___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

2015-08-26 Thread Ted Kremenek via cfe-commits
krememek added a comment.

FWIW, I do think this is a great problem to work on.  It is easy to come up 
with solutions that work for specific examples but fall over on general code.  
I completely agree that failing to analyzing code after the loop is a major 
hole and lost opportunity to find bugs, but fixing that should not be at a 
tradeoff of a huge influx in false positives.  Some basic invalidation of 
values touched by the loop, which includes possibly invalidating checker state, 
will likely be necessary.  I think this is what Anna was getting to in her 
comment.


http://reviews.llvm.org/D12358



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


  1   2   >