Re: [PATCH] D11757: Propagate SourceLocations through to get a Loc on float_cast_overflow

[Alexey Samsonov]

samsonov added a comment.

Thank you for working on this! This change looks good to me, but I'll let 
Richard say a final word.

Note that you would need to make a corresponding change in UBSan compiler-rt 
runtime. Also, this is an ABI-breaking change - e.g. shared objects built with 
older Clang will not work properly with new runtime. I would recommend you to 
add *some* diagnostic to ubsan runtime - e.g. if it tries to read 
SourceLocation from FloatCastOverflowData passed to handler, but it looks more 
like TypeDescriptor, than it would crash with a verbose message.


http://reviews.llvm.org/D11757



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

Re: r247618 - C11 _Bool bitfield diagnostic

[Alexey Samsonov via cfe-commits]

 char c;
>>>>>>>>>>  -  bool b : 10; // expected-warning {{size of bit-field
>>>>>>>>>>  'b' (10 bits) exceeds the size of its type}}
>>>>>>>>>>  +  bool b : 10; // expected-warning {{width of
>>>>>>>>>>  bit-field 'b' (10 bits) exceeds the width of its type}}
>>>>>>>>>>   };
>>>>>>>>>>
>>>>>>>>>>   // The warnings are emitted when the layout of the
>>>>>>>>>>  structs is computed, so we have to use them.
>>>>>>>>>>
>>>>>>>>>>  Modified: cfe/trunk/test/Misc/warning-flags.c
>>>>>>>>>>  URL:
>>>>>>>>>>  
>>>>>>>>>> *http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/warning-flags.c?rev=247618&r1=247617&r2=247618&view=diff*
>>>>>>>>>>  
>>>>>>>>>> <http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/warning-flags.c?rev=247618&r1=247617&r2=247618&view=diff>
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>> ==
>>>>>>>>>>  --- cfe/trunk/test/Misc/warning-flags.c (original)
>>>>>>>>>>  +++ cfe/trunk/test/Misc/warning-flags.c Mon Sep 14
>>>>>>>>>>  16:27:36 2015
>>>>>>>>>>  @@ -18,7 +18,7 @@ This test serves two purposes:
>>>>>>>>>>
>>>>>>>>>>   The list of warnings below should NEVER grow.  It
>>>>>>>>>>  should gradually shrink to 0.
>>>>>>>>>>
>>>>>>>>>>  -CHECK: Warnings without flags (92):
>>>>>>>>>>  +CHECK: Warnings without flags (90):
>>>>>>>>>>   CHECK-NEXT:   ext_excess_initializers
>>>>>>>>>>   CHECK-NEXT:
>>>>>>>>>>   ext_excess_initializers_in_char_array_initializer
>>>>>>>>>>   CHECK-NEXT:   ext_expected_semi_decl_list
>>>>>>>>>>  @@ -44,10 +44,8 @@ C

Re: [PATCH] D12840: [cfe-dev] Enabling ThreadSanitizer on PPC64(BE/LE) plarforms

[Alexey Samsonov via cfe-commits]

samsonov added a subscriber: samsonov.
samsonov accepted this revision.
samsonov added a reviewer: samsonov.
samsonov added a comment.

LGTM


http://reviews.llvm.org/D12840



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

Re: [PATCH] D13109: [sanitizer] Enable lsan for AArch64

[Alexey Samsonov via cfe-commits]

samsonov added a subscriber: samsonov.
samsonov accepted this revision.
samsonov added a reviewer: samsonov.
samsonov added a comment.
This revision is now accepted and ready to land.

OK to submit after compiler-rt support is submitted.


http://reviews.llvm.org/D13109



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

Re: [PATCH] D13122: Enable SafeStack on all Linux platforms

[Alexey Samsonov via cfe-commits]

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

LGTM


Repository:
  rL LLVM

http://reviews.llvm.org/D13122



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

Re: [PATCH] D13399: [CMake] Bug 14109 - CMake build for compiler-rt should use just-built clang

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: runtime/CMakeLists.txt:33
@@ -32,1 +32,3 @@
+  )
+set(cmake_3_4_USES_TERMINAL USES_TERMINAL 1)
   endif()

Should this also be named cmake_3_4_USES_TERMINAL_OPTIONS?


Comment at: runtime/CMakeLists.txt:40
@@ +39,3 @@
+  set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-stamps/)
+  set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-bins/)
+

This one is later re-defined from ExternalProject_Get_Property. Does it provide 
the same value there?


Comment at: runtime/CMakeLists.txt:42
@@ +41,3 @@
+
+  add_custom_target(compiler-rt-clear
+DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-cleared

Where do you use this target?


Comment at: runtime/CMakeLists.txt:47
@@ +46,3 @@
+OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-cleared
+DEPENDS clang llvm-config
+COMMAND ${CMAKE_COMMAND} -E remove_directory ${BINARY_DIR}

Why do you need these deps?


Comment at: runtime/CMakeLists.txt:71
@@ -49,2 +70,3 @@
+   -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
 INSTALL_COMMAND ""
 STEP_TARGETS configure build

Why did you remove -DCOMPILER_RT_ENABLE_WERROR=ON? I think it's fine to keep it 
enabled, as it's ok to ensure that ToT Clang builds ToT compiler-rt with no 
warnings.


http://reviews.llvm.org/D13399



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

Re: [PATCH] D11857: CFI: Introduce -fsanitize=cfi-icall flag.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Driver changes look good.


http://reviews.llvm.org/D11857



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

[PATCH] D12117: Replace __asan_set_error_exit_code() with __sanitizer_set_death_callback()

[Alexey Samsonov via cfe-commits]

samsonov created this revision.
samsonov added a reviewer: EricWF.
samsonov added a subscriber: cfe-commits.

We are going to remove the former soon.

http://reviews.llvm.org/D12117

Files:
  test/libcxx/containers/sequences/vector/asan.pass.cpp

Index: test/libcxx/containers/sequences/vector/asan.pass.cpp
===
--- test/libcxx/containers/sequences/vector/asan.pass.cpp
+++ test/libcxx/containers/sequences/vector/asan.pass.cpp
@@ -21,8 +21,11 @@
 #include "test_macros.h"
 
 #ifndef _LIBCPP_HAS_NO_ASAN
-extern "C" void __asan_set_error_exit_code(int);
+extern "C" void __sanitizer_set_death_callback(void (*callback)(void));
 
+void do_exit() {
+  exit(0);
+}
 
 int main()
 {
@@ -48,7 +51,7 @@
 assert(is_contiguous_container_asan_correct(v));
 }
 
-__asan_set_error_exit_code(0);
+__sanitizer_set_death_callback(do_exit);
 {
 typedef int T;
 typedef std::vector C;


Index: test/libcxx/containers/sequences/vector/asan.pass.cpp
===
--- test/libcxx/containers/sequences/vector/asan.pass.cpp
+++ test/libcxx/containers/sequences/vector/asan.pass.cpp
@@ -21,8 +21,11 @@
 #include "test_macros.h"
 
 #ifndef _LIBCPP_HAS_NO_ASAN
-extern "C" void __asan_set_error_exit_code(int);
+extern "C" void __sanitizer_set_death_callback(void (*callback)(void));
 
+void do_exit() {
+  exit(0);
+}
 
 int main()
 {
@@ -48,7 +51,7 @@
 assert(is_contiguous_container_asan_correct(v));
 }
 
-__asan_set_error_exit_code(0);
+__sanitizer_set_death_callback(do_exit);
 {
 typedef int T;
 typedef std::vector C;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12117: Replace __asan_set_error_exit_code() with __sanitizer_set_death_callback()

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Yes. Is this is an issue?


http://reviews.llvm.org/D12117



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

Re: [PATCH] D12117: Replace __asan_set_error_exit_code() with __sanitizer_set_death_callback()

[Alexey Samsonov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL245467: Replace __asan_set_error_exit_code() with 
__sanitizer_set_death_callback() (authored by samsonov).

Changed prior to commit:
  http://reviews.llvm.org/D12117?vs=32456&id=32572#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12117

Files:
  libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp

Index: libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp
===
--- libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp
+++ libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp
@@ -7,6 +7,8 @@
 //
 
//===--===//
 
+// UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5
+
 // 
 
 // reference operator[](size_type n);
@@ -21,8 +23,11 @@
 #include "test_macros.h"
 
 #ifndef _LIBCPP_HAS_NO_ASAN
-extern "C" void __asan_set_error_exit_code(int);
+extern "C" void __sanitizer_set_death_callback(void (*callback)(void));
 
+void do_exit() {
+  exit(0);
+}
 
 int main()
 {
@@ -48,7 +53,7 @@
 assert(is_contiguous_container_asan_correct(v));
 }
 
-__asan_set_error_exit_code(0);
+__sanitizer_set_death_callback(do_exit);
 {
 typedef int T;
 typedef std::vector C;


Index: libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp
===
--- libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp
+++ libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp
@@ -7,6 +7,8 @@
 //
 //===--===//
 
+// UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5
+
 // 
 
 // reference operator[](size_type n);
@@ -21,8 +23,11 @@
 #include "test_macros.h"
 
 #ifndef _LIBCPP_HAS_NO_ASAN
-extern "C" void __asan_set_error_exit_code(int);
+extern "C" void __sanitizer_set_death_callback(void (*callback)(void));
 
+void do_exit() {
+  exit(0);
+}
 
 int main()
 {
@@ -48,7 +53,7 @@
 assert(is_contiguous_container_asan_correct(v));
 }
 
-__asan_set_error_exit_code(0);
+__sanitizer_set_death_callback(do_exit);
 {
 typedef int T;
 typedef std::vector C;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r245467 - Replace __asan_set_error_exit_code() with __sanitizer_set_death_callback()

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Wed Aug 19 12:28:01 2015
New Revision: 245467

URL: http://llvm.org/viewvc/llvm-project?rev=245467&view=rev
Log:
Replace __asan_set_error_exit_code() with __sanitizer_set_death_callback()

Summary: We are going to remove the former soon.

Reviewers: EricWF

Subscribers: cfe-commits

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

Modified:
libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp

Modified: libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp?rev=245467&r1=245466&r2=245467&view=diff
==
--- libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp 
(original)
+++ libcxx/trunk/test/libcxx/containers/sequences/vector/asan.pass.cpp Wed Aug 
19 12:28:01 2015
@@ -7,6 +7,8 @@
 //
 
//===--===//
 
+// UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5
+
 // 
 
 // reference operator[](size_type n);
@@ -21,8 +23,11 @@
 #include "test_macros.h"
 
 #ifndef _LIBCPP_HAS_NO_ASAN
-extern "C" void __asan_set_error_exit_code(int);
+extern "C" void __sanitizer_set_death_callback(void (*callback)(void));
 
+void do_exit() {
+  exit(0);
+}
 
 int main()
 {
@@ -48,7 +53,7 @@ int main()
 assert(is_contiguous_container_asan_correct(v));
 }
 
-__asan_set_error_exit_code(0);
+__sanitizer_set_death_callback(do_exit);
 {
 typedef int T;
 typedef std::vector C;


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

Re: [PATCH] D12181: [sanitizer] Add -fsanitize-trap-function.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Please upload the patch with more context (see 
http://llvm.org/docs/Phabricator.html).



Comment at: tools/clang/include/clang/Driver/Options.td:610
@@ -608,1 +609,3 @@
+ Flags<[CC1Option, CoreOption]>,
+ HelpText<"Issue call to specified function 
rather than a trap instruction">;
 def fsanitize_undefined_trap_on_error : Flag<["-"], 
"fsanitize-undefined-trap-on-error">,

Fix the help text: Make trapping sanitizers issue a call to specified function 
rather than a trap instruction.


Comment at: tools/clang/include/clang/Frontend/CodeGenOptions.h:205
@@ +204,3 @@
+  /// If not an empty string, trap intrinsics are lowered to calls to this
+  /// function instead of to trap instructions.
+  std::string SanitizeTrapFuncName;

Fix the comment here as well.


Comment at: tools/clang/lib/CodeGen/CGExpr.cpp:2388
@@ +2387,3 @@
+  }
+  return EmitTrapCheck(Checked);
+}

This is confusing. So, you have the following behavior whenever you need to 
emit a check for `-fsanitize-trap=foo`:
  # Emit a call to `-fsanitize-trap-function`, if it's specified
  # Otherwise, emit a call to `-ftrap-function`, if it's specified
  # Otherwise, emit a trap instruction.

Do you really want it? Don't you need to skip (2) instead? If you do, you 
should carefully document it.




Comment at: tools/clang/lib/CodeGen/CGExpr.cpp:2415
@@ -2403,1 +2414,3 @@
 
+llvm::CallInst *CodeGenFunction::EmitSanitizeTrapCall(llvm::Intrinsic::ID 
IntrID) {
+  if (!CGM.getCodeGenOpts().SanitizeTrapFuncName.empty()) {

This function should not be needed.


Comment at: tools/clang/lib/CodeGen/CGExpr.cpp:2422
@@ -2404,1 +2421,3 @@
+
 llvm::CallInst *CodeGenFunction::EmitTrapCall(llvm::Intrinsic::ID IntrID) {
+  return EmitTrapCall(IntrID, CGM.getCodeGenOpts().TrapFuncName);

Isn't it easier to just kill this function, and always pass in 
CGM.getCodeGenOpts().TrapFuncName where applicable?


Comment at: tools/clang/lib/CodeGen/CGExprScalar.cpp:2386
@@ -2385,3 +2385,3 @@
 } else
-  CGF.EmitTrapCheck(Builder.CreateNot(overflow));
+  CGF.EmitSanitizeTrapCheck(Builder.CreateNot(overflow));
 return result;

Why? Looks like this check is not emitted as a part of 
`-fsanitize=signed-integer-overflow` 


Comment at: tools/clang/lib/Frontend/CompilerInvocation.cpp:507
@@ -506,2 +506,3 @@
   Opts.TrapFuncName = Args.getLastArgValue(OPT_ftrap_function_EQ);
+  Opts.SanitizeTrapFuncName = 
Args.getLastArgValue(OPT_fsanitize_trap_function_EQ);
   Opts.UseInitArray = Args.hasArg(OPT_fuse_init_array);

Please parse this argument next to another sanitizer arguments.


Repository:
  rL LLVM

http://reviews.llvm.org/D12181



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

[PATCH] D12215: [UBSan] Add the ability to print more precise error kind in summary line.

[Alexey Samsonov via cfe-commits]

samsonov created this revision.
samsonov added reviewers: rsmith, pcc.
samsonov added a subscriber: cfe-commits.

http://reviews.llvm.org/D12215

Files:
  lib/ubsan/ubsan_checks.inc
  lib/ubsan/ubsan_diag.cc
  lib/ubsan/ubsan_diag.h
  lib/ubsan/ubsan_flags.inc
  lib/ubsan/ubsan_handlers.cc
  lib/ubsan/ubsan_handlers_cxx.cc
  test/ubsan/TestCases/Float/cast-overflow.cpp
  test/ubsan/TestCases/Integer/summary.cpp
  test/ubsan/TestCases/Misc/bool.cpp

Index: test/ubsan/TestCases/Misc/bool.cpp
===
--- test/ubsan/TestCases/Misc/bool.cpp
+++ test/ubsan/TestCases/Misc/bool.cpp
@@ -1,10 +1,13 @@
-// RUN: %clangxx -fsanitize=bool %s -O3 -o %t && not %run %t 2>&1 | FileCheck %s
+// RUN: %clangxx -fsanitize=bool %s -O3 -o %t
+// RUN: not %run %t 2>&1 | FileCheck %s
+// RUN: env UBSAN_OPTIONS=print_summary=1:report_error_type=1 not %run %t 2>&1 | FileCheck %s --check-prefix=SUMMARY
 
 unsigned char NotABool = 123;
 
 int main(int argc, char **argv) {
   bool *p = (bool*)&NotABool;
 
-  // CHECK: bool.cpp:9:10: runtime error: load of value 123, which is not a valid value for type 'bool'
+  // CHECK: bool.cpp:[[@LINE+1]]:10: runtime error: load of value 123, which is not a valid value for type 'bool'
   return *p;
+  // SUMMARY: SUMMARY: {{.*}}Sanitizer: invalid-bool-load {{.*}}bool.cpp:[[@LINE-1]]
 }
Index: test/ubsan/TestCases/Integer/summary.cpp
===
--- test/ubsan/TestCases/Integer/summary.cpp
+++ test/ubsan/TestCases/Integer/summary.cpp
@@ -1,10 +1,13 @@
-// RUN: %clangxx -fsanitize=integer %s -o %t && %t 2>&1 | FileCheck %s
+// RUN: %clangxx -fsanitize=integer %s -o %t
+// RUN: %t 2>&1 | FileCheck %s --check-prefix=CHECK-NOTYPE
+// RUN: env UBSAN_OPTIONS=report_error_type=1 %t 2>&1 | FileCheck %s --check-prefix=CHECK-TYPE
 // REQUIRES: ubsan-asan
 
 #include 
 
 int main() {
   (void)(uint64_t(1000ull) + uint64_t(900ull));
-  // CHECK: SUMMARY: AddressSanitizer: undefined-behavior {{.*}}summary.cpp:[[@LINE-1]]:44
+  // CHECK-NOTYPE: SUMMARY: AddressSanitizer: undefined-behavior {{.*}}summary.cpp:[[@LINE-1]]:44
+  // CHECK-TYPE: SUMMARY: AddressSanitizer: unsigned-integer-overflow {{.*}}summary.cpp:[[@LINE-2]]:44
   return 0;
 }
Index: test/ubsan/TestCases/Float/cast-overflow.cpp
===
--- test/ubsan/TestCases/Float/cast-overflow.cpp
+++ test/ubsan/TestCases/Float/cast-overflow.cpp
@@ -1,6 +1,6 @@
 // RUN: %clangxx -fsanitize=float-cast-overflow %s -o %t
 // RUN: %run %t _
-// RUN: env UBSAN_OPTIONS=print_summary=1 %run %t 0 2>&1 | FileCheck %s --check-prefix=CHECK-0
+// RUN: env UBSAN_OPTIONS=print_summary=1:report_error_type=1 %run %t 0 2>&1 | FileCheck %s --check-prefix=CHECK-0
 // RUN: %run %t 1 2>&1 | FileCheck %s --check-prefix=CHECK-1
 // RUN: %run %t 2 2>&1 | FileCheck %s --check-prefix=CHECK-2
 // RUN: %run %t 3 2>&1 | FileCheck %s --check-prefix=CHECK-3
@@ -88,7 +88,7 @@
 // successfully round-trip, depending on the rounding mode.
 // CHECK-0: {{.*}}cast-overflow.cpp:[[@LINE+1]]:27: runtime error: value 2.14748{{.*}} is outside the range of representable values of type 'int'
 static int test_int = MaxFloatRepresentableAsInt + 0x80;
-// CHECK-0: SUMMARY: {{.*}}Sanitizer: undefined-behavior {{.*}}cast-overflow.cpp:[[@LINE-1]]
+// CHECK-0: SUMMARY: {{.*}}Sanitizer: float-cast-overflow {{.*}}cast-overflow.cpp:[[@LINE-1]]
 return 0;
 }
   case '1': {
Index: lib/ubsan/ubsan_handlers_cxx.cc
===
--- lib/ubsan/ubsan_handlers_cxx.cc
+++ lib/ubsan/ubsan_handlers_cxx.cc
@@ -45,7 +45,7 @@
   if (Loc.isDisabled())
 return;
 
-  ScopedReport R(Opts, Loc);
+  ScopedReport R(Opts, Loc, ErrorType::DynamicTypeMismatch);
 
   Diag(Loc, DL_Error,
"%0 address %1 which does not point to an object of type %2")
@@ -85,7 +85,7 @@
 static void HandleCFIBadType(CFIBadTypeData *Data, ValueHandle Vtable,
  ReportOptions Opts) {
   SourceLocation Loc = Data->Loc.acquire();
-  ScopedReport R(Opts, Loc);
+  ScopedReport R(Opts, Loc, ErrorType::CFIBadType);
   DynamicTypeInfo DTI = getDynamicTypeInfoFromVtable((void*)Vtable);
 
   static const char *TypeCheckKinds[] = {
Index: lib/ubsan/ubsan_handlers.cc
===
--- lib/ubsan/ubsan_handlers.cc
+++ lib/ubsan/ubsan_handlers.cc
@@ -53,18 +53,22 @@
 
   ScopedReport R(Opts, Loc);
 
-  if (!Pointer)
+  if (!Pointer) {
+R.setErrorType(ErrorType::NullPointerUse);
 Diag(Loc, DL_Error, "%0 null pointer of type %1")
   << TypeCheckKinds[Data->TypeCheckKind] << Data->Type;
-  else if (Data->Alignment && (Pointer & (Data->Alignment - 1)))
+  } else if (Data->Alignment && (Pointer & (Data->Alignment - 1))) {
+R.setErrorType(ErrorType::MisalignedPointerUse);
 Diag(Loc, DL_Error

Re: [PATCH] D12181: [sanitizer] Add -fsanitize-trap-function.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

See https://llvm.org/bugs/show_bug.cgi?id=24443 (it's worth including this 
reference to change description).


http://reviews.llvm.org/D12181



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

Re: [PATCH] D12181: [sanitizer] Add -fsanitize-trap-function.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Overall, this looks reasonable to me, but I'd like Richard to confirm he's fine 
with this change as well.



Comment at: docs/UsersManual.rst:1121
@@ +1120,3 @@
+   Instruct code generator to emit a function call to the specified
+   function name instead of a trap instruction for checks configured to trap.
+

for sanitizer checks configured to trap.


Comment at: include/clang/Driver/Options.td:610
@@ -608,1 +609,3 @@
+ Flags<[CC1Option, CoreOption]>,
+ HelpText<"Make trapping sanitizers issue a 
call to specified function rather than a trap instruction">;
 def fsanitize_undefined_trap_on_error : Flag<["-"], 
"fsanitize-undefined-trap-on-error">,

80 cols


Comment at: lib/CodeGen/CodeGenFunction.h:2895
@@ -2890,1 +2894,3 @@
 
+  /// \brief Create a basic block that will call the specified trap function,
+  /// and emit a conditional branch to it.

You can probably make this private


Comment at: lib/CodeGen/CodeGenFunction.h:2903
@@ -2894,1 +2902,3 @@
 
+  /// \brief Emit a call to trap or debugtrap and attach function attribute
+  /// "trap-func-name" if nonempty.

And this


http://reviews.llvm.org/D12181



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

Re: [PATCH] D12215: [UBSan] Add the ability to print more precise error kind in summary line.

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: lib/ubsan/ubsan_flags.inc:26
@@ +25,2 @@
+UBSAN_FLAG(bool, report_error_type, false,
+"Print specific error type instead of 'undefined-behavior' in 
summary.")

filcab wrote:
> Do we care that much about keeping the "always say 'undefined-behavior'" 
> behavior around?
Yes, there are users who grep for "SUMMARY: .* undefined-behavior" lines in 
their logs. We should stay backwards-compatible for a while.


http://reviews.llvm.org/D12215



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

Re: [PATCH] D12215: [UBSan] Add the ability to print more precise error kind in summary line.

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: lib/ubsan/ubsan_handlers.cc:57-58
@@ -57,2 +56,4 @@
+  if (!Pointer) {
+R.setErrorType(ErrorType::NullPointerUse);
 Diag(Loc, DL_Error, "%0 null pointer of type %1")
   << TypeCheckKinds[Data->TypeCheckKind] << Data->Type;

rsmith wrote:
> Can we pass the error type to `Diag` in the place of `DL_Error` instead of 
> specifying it separately?
We still need error type somewhere outside `Diag`, because it will be used 
later when we print (or not print) summary, after several `Diag` invocations 
(for DL_Error and DL_Note).


http://reviews.llvm.org/D12215



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

Re: [PATCH] D12215: [UBSan] Add the ability to print more precise error kind in summary line.

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: lib/ubsan/ubsan_handlers.cc:57-58
@@ -57,2 +56,4 @@
+  if (!Pointer) {
+R.setErrorType(ErrorType::NullPointerUse);
 Diag(Loc, DL_Error, "%0 null pointer of type %1")
   << TypeCheckKinds[Data->TypeCheckKind] << Data->Type;

rsmith wrote:
> samsonov wrote:
> > rsmith wrote:
> > > Can we pass the error type to `Diag` in the place of `DL_Error` instead 
> > > of specifying it separately?
> > We still need error type somewhere outside `Diag`, because it will be used 
> > later when we print (or not print) summary, after several `Diag` 
> > invocations (for DL_Error and DL_Note).
> We would make exactly one invocation to `Diag` with an error type, wouldn't 
> we? Is the summary information computed separately from diagnostic emission?
The answer to last question is "yes". `Diag` object prints the diagnostic 
message in destructor (and there can be several `Diag` objects). We need to 
print summary information after all the diagnostics (DL_Error and DL_Note), so 
we do this in `ScopedReport` destructor.

There is a different benefit in passing error kind to Diag() object - we can 
print the actual error kind instead of generic `runtime error:` line, but 
that's a different problem, which can probably be addressed afterwards.


http://reviews.llvm.org/D12215



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

Re: [PATCH] D12215: [UBSan] Add the ability to print more precise error kind in summary line.

[Alexey Samsonov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL245897: [UBSan] Add the ability to print more precise error 
kind in summary line. (authored by samsonov).

Changed prior to commit:
  http://reviews.llvm.org/D12215?vs=32753&id=33019#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12215

Files:
  compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
  compiler-rt/trunk/lib/ubsan/ubsan_diag.cc
  compiler-rt/trunk/lib/ubsan/ubsan_diag.h
  compiler-rt/trunk/lib/ubsan/ubsan_flags.inc
  compiler-rt/trunk/lib/ubsan/ubsan_handlers.cc
  compiler-rt/trunk/lib/ubsan/ubsan_handlers_cxx.cc
  compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
  compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
  compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp

Index: compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
===
--- compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
+++ compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
@@ -1,10 +1,13 @@
-// RUN: %clangxx -fsanitize=integer %s -o %t && %t 2>&1 | FileCheck %s
+// RUN: %clangxx -fsanitize=integer %s -o %t
+// RUN: %t 2>&1 | FileCheck %s --check-prefix=CHECK-NOTYPE
+// RUN: env UBSAN_OPTIONS=report_error_type=1 %t 2>&1 | FileCheck %s --check-prefix=CHECK-TYPE
 // REQUIRES: ubsan-asan
 
 #include 
 
 int main() {
   (void)(uint64_t(1000ull) + uint64_t(900ull));
-  // CHECK: SUMMARY: AddressSanitizer: undefined-behavior {{.*}}summary.cpp:[[@LINE-1]]:44
+  // CHECK-NOTYPE: SUMMARY: AddressSanitizer: undefined-behavior {{.*}}summary.cpp:[[@LINE-1]]:44
+  // CHECK-TYPE: SUMMARY: AddressSanitizer: unsigned-integer-overflow {{.*}}summary.cpp:[[@LINE-2]]:44
   return 0;
 }
Index: compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp
===
--- compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp
+++ compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp
@@ -1,10 +1,13 @@
-// RUN: %clangxx -fsanitize=bool %s -O3 -o %t && not %run %t 2>&1 | FileCheck %s
+// RUN: %clangxx -fsanitize=bool %s -O3 -o %t
+// RUN: not %run %t 2>&1 | FileCheck %s
+// RUN: env UBSAN_OPTIONS=print_summary=1:report_error_type=1 not %run %t 2>&1 | FileCheck %s --check-prefix=SUMMARY
 
 unsigned char NotABool = 123;
 
 int main(int argc, char **argv) {
   bool *p = (bool*)&NotABool;
 
-  // CHECK: bool.cpp:9:10: runtime error: load of value 123, which is not a valid value for type 'bool'
+  // CHECK: bool.cpp:[[@LINE+1]]:10: runtime error: load of value 123, which is not a valid value for type 'bool'
   return *p;
+  // SUMMARY: SUMMARY: {{.*}}Sanitizer: invalid-bool-load {{.*}}bool.cpp:[[@LINE-1]]
 }
Index: compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
===
--- compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
+++ compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
@@ -1,6 +1,6 @@
 // RUN: %clangxx -fsanitize=float-cast-overflow %s -o %t
 // RUN: %run %t _
-// RUN: env UBSAN_OPTIONS=print_summary=1 %run %t 0 2>&1 | FileCheck %s --check-prefix=CHECK-0
+// RUN: env UBSAN_OPTIONS=print_summary=1:report_error_type=1 %run %t 0 2>&1 | FileCheck %s --check-prefix=CHECK-0
 // RUN: %run %t 1 2>&1 | FileCheck %s --check-prefix=CHECK-1
 // RUN: %run %t 2 2>&1 | FileCheck %s --check-prefix=CHECK-2
 // RUN: %run %t 3 2>&1 | FileCheck %s --check-prefix=CHECK-3
@@ -88,7 +88,7 @@
 // successfully round-trip, depending on the rounding mode.
 // CHECK-0: {{.*}}cast-overflow.cpp:[[@LINE+1]]:27: runtime error: value 2.14748{{.*}} is outside the range of representable values of type 'int'
 static int test_int = MaxFloatRepresentableAsInt + 0x80;
-// CHECK-0: SUMMARY: {{.*}}Sanitizer: undefined-behavior {{.*}}cast-overflow.cpp:[[@LINE-1]]
+// CHECK-0: SUMMARY: {{.*}}Sanitizer: float-cast-overflow {{.*}}cast-overflow.cpp:[[@LINE-1]]
 return 0;
 }
   case '1': {
Index: compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
===
--- compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
+++ compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
@@ -0,0 +1,53 @@
+//===-- ubsan_checks.inc *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// List of checks handled by UBSan runtime.
+//
+//===--===//
+#ifndef UBSAN_CHECK
+# error "Define UBSAN_CHECK prior to including this file!"
+#endif
+
+// UBSAN_CHECK(Name, SummaryKind, FlagName)
+// SummaryKind and FlagName should be string literals.
+
+UBSAN_CHECK(Ge

Re: [PATCH] D12401: Handling i686 architecture in makefiles for clang.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

See my comment in a different CL - I would strongly prefer to not touch 
autoconf build system unless absolutely necessary.


Repository:
  rL LLVM

http://reviews.llvm.org/D12401



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

r246795 - Add -target flag to Clang invocations in this test.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Thu Sep  3 14:11:42 2015
New Revision: 246795

URL: http://llvm.org/viewvc/llvm-project?rev=246795&view=rev
Log:
Add -target flag to Clang invocations in this test.

ASan may not be supported for the default target triple.

Modified:
cfe/trunk/test/Driver/fsanitize-blacklist.c

Modified: cfe/trunk/test/Driver/fsanitize-blacklist.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-blacklist.c?rev=246795&r1=246794&r2=246795&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-blacklist.c (original)
+++ cfe/trunk/test/Driver/fsanitize-blacklist.c Thu Sep  3 14:11:42 2015
@@ -12,40 +12,40 @@
 // RUN: echo "fun:bar" > %t.second
 // RUN: echo "badline" > %t.bad
 
-// RUN: %clang -fsanitize=address -fsanitize-blacklist=%t.good 
-fsanitize-blacklist=%t.second %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-BLACKLIST
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-blacklist=%t.good -fsanitize-blacklist=%t.second %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-BLACKLIST
 // CHECK-BLACKLIST: -fsanitize-blacklist={{.*}}.good" 
"-fsanitize-blacklist={{.*}}.second
 
 // Now, check for -fdepfile-entry flags.
-// RUN: %clang -fsanitize=address -fsanitize-blacklist=%t.good 
-fsanitize-blacklist=%t.second %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-BLACKLIST2
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-blacklist=%t.good -fsanitize-blacklist=%t.second %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-BLACKLIST2
 // CHECK-BLACKLIST2: -fdepfile-entry={{.*}}.good" 
"-fdepfile-entry={{.*}}.second
 
 // Check that the default blacklist is not added as an extra dependency.
-// RUN: %clang -fsanitize=address -resource-dir=%S/Inputs/resource_dir %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-DEFAULT-BLACKLIST 
--implicit-check-not=fdepfile-entry
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-resource-dir=%S/Inputs/resource_dir %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-DEFAULT-BLACKLIST --implicit-check-not=fdepfile-entry
 // CHECK-DEFAULT-BLACKLIST: -fsanitize-blacklist={{.*}}asan_blacklist.txt
 
 // Ignore -fsanitize-blacklist flag if there is no -fsanitize flag.
-// RUN: %clang -fsanitize-blacklist=%t.good %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-NO-SANITIZE --check-prefix=DELIMITERS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize-blacklist=%t.good %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-SANITIZE --check-prefix=DELIMITERS
 // CHECK-NO-SANITIZE-NOT: -fsanitize-blacklist
 
 // Ignore -fsanitize-blacklist flag if there is no -fsanitize flag.
 // Now, check for the absense of -fdepfile-entry flags.
-// RUN: %clang -fsanitize-blacklist=%t.good %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-NO-SANITIZE2 --check-prefix=DELIMITERS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize-blacklist=%t.good %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-NO-SANITIZE2 --check-prefix=DELIMITERS
 // CHECK-NO-SANITIZE2-NOT: -fdepfile-entry
 
 // Flag -fno-sanitize-blacklist wins if it is specified later.
-// RUN: %clang -fsanitize=address -fsanitize-blacklist=%t.good 
-fno-sanitize-blacklist %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-NO-BLACKLIST --check-prefix=DELIMITERS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-blacklist=%t.good -fno-sanitize-blacklist %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-NO-BLACKLIST --check-prefix=DELIMITERS
 // CHECK-NO-BLACKLIST-NOT: -fsanitize-blacklist
 
 // Driver barks on unexisting blacklist files.
-// RUN: %clang -fno-sanitize-blacklist -fsanitize-blacklist=unexisting.txt %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-SUCH-FILE
+// RUN: %clang -target x86_64-linux-gnu -fno-sanitize-blacklist 
-fsanitize-blacklist=unexisting.txt %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-NO-SUCH-FILE
 // CHECK-NO-SUCH-FILE: error: no such file or directory: 'unexisting.txt'
 
 // Driver properly reports malformed blacklist files.
-// RUN: %clang -fsanitize=address -fsanitize-blacklist=%t.second 
-fsanitize-blacklist=%t.bad -fsanitize-blacklist=%t.good %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-BAD-BLACKLIST
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-blacklist=%t.second -fsanitize-blacklist=%t.bad 
-fsanitize-blacklist=%t.good %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-BAD-BLACKLIST
 // CHECK-BAD-BLACKLIST: error: malformed sanitizer blacklist: 'error parsing 
file '{{.*}}.bad': malformed line 1: 'badline''
 
 // -fno-sanitize-blacklist disables all blacklists specified earlier.
-// RUN: %clang -fsanitize=address -fsanitize-blacklist=%t.good 
-fno-sanitize-blacklist -fsanitize-blacklist=%t.second %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-ONLY-FIRST-DISABLED
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-blacklist=%t.good -fno-sanitize-blacklist 
-fsanitize-blacklist=

r246804 - Add target flag to clang-cl invocation in this test.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Thu Sep  3 15:53:14 2015
New Revision: 246804

URL: http://llvm.org/viewvc/llvm-project?rev=246804&view=rev
Log:
Add target flag to clang-cl invocation in this test.

Modified:
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=246804&r1=246803&r2=246804&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Thu Sep  3 15:53:14 2015
@@ -61,7 +61,7 @@
 // CHECK-EXTEND-LEGACY: -fsanitize-coverage-type=1
 // CHECK-EXTEND-LEGACY: -fsanitize-coverage-trace-cmp
 
-// RUN: %clang_cl -fsanitize=address -fsanitize-coverage=1 -c -### -- %s 2>&1 
| FileCheck %s -check-prefix=CLANG-CL-COVERAGE
+// RUN: %clang_cl --target=i386-pc-win32 -fsanitize=address 
-fsanitize-coverage=1 -c -### -- %s 2>&1 | FileCheck %s 
-check-prefix=CLANG-CL-COVERAGE
 // CLANG-CL-COVERAGE-NOT: error:
 // CLANG-CL-COVERAGE-NOT: warning:
 // CLANG-CL-COVERAGE-NOT: argument unused


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

Re: [PATCH] D13399: [CMake] Bug 14109 - CMake build for compiler-rt should use just-built clang

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: runtime/CMakeLists.txt:41
@@ +40,3 @@
+
+  add_custom_target(compiler-rt-clear
+DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-cleared

So, that's the target that you can invoke manually to clean compiler-rt build?


Comment at: runtime/CMakeLists.txt:46
@@ +45,3 @@
+OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-cleared
+DEPENDS clang llvm-config
+COMMAND ${CMAKE_COMMAND} -E remove_directory ${BINARY_DIR}

Hm? But "compiler-rt" target also depends on clang and llvm-config.


Comment at: runtime/CMakeLists.txt:69
@@ -47,3 +68,3 @@
-DCOMPILER_RT_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
-   -DCOMPILER_RT_ENABLE_WERROR=ON
+   -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
 INSTALL_COMMAND ""

I thought we only refer to COMPILER_RT_INSTALL_PATH in compiler-rt's CMake. Do 
we actually need CMAKE_INSTALL_PREFIX there as well?


Comment at: runtime/CMakeLists.txt:70
@@ -49,2 +69,3 @@
+   -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
 INSTALL_COMMAND ""
 STEP_TARGETS configure build

Disagree - we can't set COMPILER_RT_ENABLE_WERROR in compiler-rt's CMake, 
because standalone compiler-rt can be built with any compiler in the world, 
which we don't control. OTOH, if we *know* we're building it with trunk Clang, 
having it -Werror-clean is smth. we can enforce. It's also consistent with what 
autoconf did previously.


Comment at: runtime/CMakeLists.txt:78
@@ -62,11 +77,3 @@
 
-  ExternalProject_Add_Step(compiler-rt clobber
-COMMAND ${CMAKE_COMMAND} -E remove_directory 
-COMMAND ${CMAKE_COMMAND} -E make_directory 
-COMMENT "Clobberring compiler-rt build directory..."
-DEPENDERS configure
-DEPENDS ${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-  )
-
-  ExternalProject_Get_Property(compiler-rt BINARY_DIR)
-  set(COMPILER_RT_BINARY_DIR ${BINARY_DIR})
+  add_custom_target(install-compiler-rt
+DEPENDS compiler-rt

This is also convenience target, right?


http://reviews.llvm.org/D13399



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

Re: [PATCH] D13399: [CMake] Bug 14109 - CMake build for compiler-rt should use just-built clang

[Alexey Samsonov via cfe-commits]

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

Looks pretty good. I'm still not convinced with your -Werror arguments, and 
will be unavailable during the next week, so feel free to land it, provided 
we'll return to the discussion later :)

Thank you!



Comment at: runtime/CMakeLists.txt:62
@@ -49,2 +61,3 @@
+   -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
 INSTALL_COMMAND ""
 STEP_TARGETS configure build

Why should it be tied to LLVM_ENABLE_WERROR? LLVM_ENABLE_WERROR only makes 
sense if host compiler is known to be "good" and we want it to build LLVM w/o 
errors. Here, the compiler is *always* good. As for the user, we don't give her 
the option to define the compiler that would build compiler-rt: it is set to be 
just-built Clang. I can imagine the test case which verifies that just-built 
Clang compiles given source file w/o warnings. We can as well keep a large 
subproject just-built-Clang clean.


http://reviews.llvm.org/D13399



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

Re: [libcxx] r250319 - [libcxx] Make it drastically simpler to link libc++.

[Alexey Samsonov via cfe-commits]

After this change I am unable to configure libcxx as external project from
compiler-rt with extra build flags.
The problem is gen_link_script.py is invoked with incorrect number of
arguments: LIBCXX_CXX_ABI_LIBNAME is automatically deduced to be "none",
and LIBCXX_CXX_ABI_LIBRARY which is passed to gen_link_script.py is then
empty.

I can suppress this by using condition
  if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT AND LIBCXX_CXX_ABI_LIBRARY)
in libcxx/lib/CMakeLists.txt, but I don't think this fix is clean enough. I
can also pass -DLIBCXX_ENABLE_ABI_LINKER_SCRIPT=OFF when I configure libc++,
but probably this should be deduced automatically...


On Wed, Oct 21, 2015 at 5:44 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Thanks. I'll look to see if any other LLVM projects have bumped the CMake
> version to 3 yet. If so that's the direction I will head.
>
>
>
>
> On Oct 20, 2015 9:39 PM, "Hahnfeld, Jonas" 
> wrote:
>
>> > -Original Message-
>> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
>> > Of Eric Fiselier via cfe-commits
>> > Sent: Wednesday, October 14, 2015 9:54 PM
>> > To: cfe-commits@lists.llvm.org
>> > Subject: [libcxx] r250319 - [libcxx] Make it drastically simpler to link
>> > libc++.
>> >
>> > Author: ericwf
>> > Date: Wed Oct 14 14:54:03 2015
>> > New Revision: 250319
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=250319&view=rev
>> > Log:
>> > [libcxx] Make it drastically simpler to link libc++.
>> [...]
>> >  if (LIBCXX_INSTALL_LIBRARY)
>> >install(TARGETS cxx
>> >  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
>> >  ARCHIVE DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
>> >  )
>> > +  # NOTE: This install command must go after the cxx install command
>> > + otherwise  # it will not be executed after the library symlinks are
>> > installed.
>> > +  if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
>> > +install(FILES "$"
>> > +  DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
>> > +  COMPONENT libcxx)
>> > +  endif()
>> >  endif()
>>
>> Generator expressions in install(FILES) are only allowed since CMake 3.0
>> (https://cmake.org/cmake/help/v3.0/release/3.0.0.html#commands).
>> The current minimum for libcxx is 2.8, so this should either be raised or
>> we
>> have to find another possibility of writing this install command...
>>
>> Greetings
>> Jonas
>>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r250319 - [libcxx] Make it drastically simpler to link libc++.

[Alexey Samsonov via cfe-commits]

Seems to work now, thanks for the quick fix!

On Thu, Oct 22, 2015 at 1:57 PM, Eric Fiselier  wrote:

> Hi Alexey,
>
> Please confirm that this works for you now after r251063. Sorry for the
> breakage.
>
> /Eric
>
> On Thu, Oct 22, 2015 at 9:23 AM, Alexey Samsonov 
> wrote:
>
>> After this change I am unable to configure libcxx as external project
>> from compiler-rt with extra build flags.
>> The problem is gen_link_script.py is invoked with incorrect number of
>> arguments: LIBCXX_CXX_ABI_LIBNAME is automatically deduced to be "none",
>> and LIBCXX_CXX_ABI_LIBRARY which is passed to gen_link_script.py is then
>> empty.
>>
>> I can suppress this by using condition
>>   if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT AND LIBCXX_CXX_ABI_LIBRARY)
>> in libcxx/lib/CMakeLists.txt, but I don't think this fix is clean enough.
>> I can also pass -DLIBCXX_ENABLE_ABI_LINKER_SCRIPT=OFF when I configure
>> libc++,
>> but probably this should be deduced automatically...
>>
>>
>> On Wed, Oct 21, 2015 at 5:44 PM, Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Thanks. I'll look to see if any other LLVM projects have bumped the
>>> CMake version to 3 yet. If so that's the direction I will head.
>>>
>>>
>>>
>>>
>>> On Oct 20, 2015 9:39 PM, "Hahnfeld, Jonas" 
>>> wrote:
>>>
>>>> > -Original Message-
>>>> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On
>>>> Behalf
>>>> > Of Eric Fiselier via cfe-commits
>>>> > Sent: Wednesday, October 14, 2015 9:54 PM
>>>> > To: cfe-commits@lists.llvm.org
>>>> > Subject: [libcxx] r250319 - [libcxx] Make it drastically simpler to
>>>> link
>>>> > libc++.
>>>> >
>>>> > Author: ericwf
>>>> > Date: Wed Oct 14 14:54:03 2015
>>>> > New Revision: 250319
>>>> >
>>>> > URL: http://llvm.org/viewvc/llvm-project?rev=250319&view=rev
>>>> > Log:
>>>> > [libcxx] Make it drastically simpler to link libc++.
>>>> [...]
>>>> >  if (LIBCXX_INSTALL_LIBRARY)
>>>> >install(TARGETS cxx
>>>> >  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
>>>> >  ARCHIVE DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
>>>> >  )
>>>> > +  # NOTE: This install command must go after the cxx install command
>>>> > + otherwise  # it will not be executed after the library symlinks are
>>>> > installed.
>>>> > +  if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
>>>> > +install(FILES "$"
>>>> > +  DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
>>>> > +  COMPONENT libcxx)
>>>> > +  endif()
>>>> >  endif()
>>>>
>>>> Generator expressions in install(FILES) are only allowed since CMake 3.0
>>>> (https://cmake.org/cmake/help/v3.0/release/3.0.0.html#commands).
>>>> The current minimum for libcxx is 2.8, so this should either be raised
>>>> or we
>>>> have to find another possibility of writing this install command...
>>>>
>>>> Greetings
>>>> Jonas
>>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>>
>> --
>> Alexey Samsonov
>> vonos...@gmail.com
>>
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r251712 - Support watchOS and tvOS in compiler-rt builds

[Alexey Samsonov via cfe-commits]

Do we need to port this to CMake as well?

On Fri, Oct 30, 2015 at 9:30 AM, Tim Northover via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: tnorthover
> Date: Fri Oct 30 11:30:51 2015
> New Revision: 251712
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251712&view=rev
> Log:
> Support watchOS and tvOS in compiler-rt builds
>
> Hopefully autotools will be deprecated soon and this entire file can go
> away,
> but until then...
>
> Modified:
> cfe/trunk/runtime/compiler-rt/Makefile
>
> Modified: cfe/trunk/runtime/compiler-rt/Makefile
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/compiler-rt/Makefile?rev=251712&r1=251711&r2=251712&view=diff
>
> ==
> --- cfe/trunk/runtime/compiler-rt/Makefile (original)
> +++ cfe/trunk/runtime/compiler-rt/Makefile Fri Oct 30 11:30:51 2015
> @@ -83,6 +83,25 @@ RuntimeLibrary.darwin.Configs := \
>
>  IOS_SDK := $(shell xcrun --show-sdk-path -sdk iphoneos 2> /dev/null)
>  IOSSIM_SDK := $(shell xcrun --show-sdk-path -sdk iphonesimulator 2>
> /dev/null)
> +TVOS_SDK := $(shell xcrun --show-sdk-path -sdk appletvos 2> /dev/null)
> +TVOSSIM_SDK := $(shell xcrun --show-sdk-path -sdk appletvsimulator 2>
> /dev/null)
> +WATCHOS_SDK := $(shell xcrun --show-sdk-path -sdk watchos 2> /dev/null)
> +WATCHOSSIM_SDK := $(shell xcrun --show-sdk-path -sdk watchsimulator 2>
> /dev/null)
> +
> +LinkerSupportedArches = \
> +  $(shell \
> +result=""; \
> +for arch in $1; do \
> +  if $(LD) -v 2>&1 | grep "configured to support" | tr ' ' '\n' |
> grep "^$$arch$$" >/dev/null 2>/dev/null; then \
> +result="$$result$$arch "; \
> +  fi; \
> +done; \
> +echo $$result)
> +
> +
> +RuntimeLibrary.macho_embedded.Configs := \
> +   hard_static.a hard_pic.a
> +ifneq (,$(findstring ARM,$(TARGETS_TO_BUILD)))
>
>  ifneq ($(IOS_SDK)$(IOSSIM_SDK),)
>  RuntimeLibrary.darwin.Configs += ios.a profile_ios.a
> @@ -99,9 +118,23 @@ RuntimeLibrary.darwin.Configs += asan_io
>   ubsan_iossim_dynamic.dylib
>  endif
>
> -RuntimeLibrary.macho_embedded.Configs := \
> -   hard_static.a hard_pic.a
> -ifneq (,$(findstring ARM,$(TARGETS_TO_BUILD)))
> +
> +ifneq ($(TVOS_SDK)$(TVOSSIM_SDK),)
> +RuntimeLibrary.darwin.Configs += tvos.a profile_tvos.a
> +endif
> +
> +ifneq ($(TVOS_SDK),)
> +RuntimeLibrary.darwin.Configs += cc_kext_tvos.a
> +endif
> +
> +ifneq ($(WATCHOS_SDK)$(WATCHOSSIM_SDK),)
> +RuntimeLibrary.darwin.Configs += watchos.a profile_watchos.a
> +endif
> +
> +ifneq ($(WATCHOS_SDK),)
> +RuntimeLibrary.darwin.Configs += cc_kext_watchos.a
> +endif
> +
>  RuntimeLibrary.macho_embedded.Configs += \
> soft_static.a soft_pic.a
>  endif
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16823: [cfi] Safe handling of unaddressable vtable pointers (clang).

[Alexey Samsonov via cfe-commits]

samsonov added a subscriber: samsonov.


Comment at: lib/CodeGen/CGExpr.cpp:2494
@@ +2493,3 @@
+  llvm::Value *ValidVtable = nullptr;
+  if (CheckAndAppendValidVtable) {
+llvm::Value *AllVtables = llvm::MetadataAsValue::get(

This is really ugly. Why are you not passing it down in DynamicArgs? Is it 
performance penalty you don't want to pay if the check will not succeed? How 
large will it be?


Repository:
  rL LLVM

http://reviews.llvm.org/D16823



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

Re: [PATCH] D16823: [cfi] Safe handling of unaddressable vtable pointers (clang).

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: lib/CodeGen/CGExpr.cpp:2642
@@ +2641,3 @@
+  llvm::MDString::get(CGM.getLLVMContext(), "all-vtables"));
+  llvm::Value *ValidVtable = Builder.CreateZExt(
+  Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::bitset_test),

This is almost the same as EmitVTablePtrCheck, but with ZExt? Is the difference 
intentional/important? Is it possible to extract this logic (getting 
"all-vtables" metadata and running bitset test) to a function?


Comment at: lib/CodeGen/CodeGenModule.cpp:4034
@@ +4033,3 @@
+  // is not in the trapping mode.
+  return ((LangOpts.Sanitize.has(SanitizerKind::CFIVCall) &&
+   !CodeGenOpts.SanitizeTrap.has(SanitizerKind::CFIVCall)) ||

Hm, can you write this as a loop?


Repository:
  rL LLVM

http://reviews.llvm.org/D16823



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

Re: [PATCH] D16823: [cfi] Safe handling of unaddressable vtable pointers (clang).

[Alexey Samsonov via cfe-commits]

samsonov accepted this revision.
samsonov added a reviewer: samsonov.
samsonov added a comment.
This revision is now accepted and ready to land.

LGTM



Comment at: lib/CodeGen/CGClass.cpp:2608
@@ -2607,3 +2607,3 @@
   auto TypeId = CGM.CreateCfiIdForTypeMetadata(MD);
   if (CGM.getCodeGenOpts().SanitizeCfiCrossDso && TypeId) {
 EmitCfiSlowPathCheck(M, BitSetTest, TypeId, CastedVTable, StaticData);

Can we rewrite this as if-elseif-else block now?


Comment at: lib/CodeGen/CGExpr.cpp:2642
@@ +2641,3 @@
+  llvm::MDString::get(CGM.getLLVMContext(), "all-vtables"));
+  llvm::Value *ValidVtable = Builder.CreateZExt(
+  Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::bitset_test),

eugenis wrote:
> samsonov wrote:
> > This is almost the same as EmitVTablePtrCheck, but with ZExt? Is the 
> > difference intentional/important? Is it possible to extract this logic 
> > (getting "all-vtables" metadata and running bitset test) to a function?
> Not important. Zext makes the test a bit simpler.
> Extracting these two lines to a function is surely possible, but is it worth 
> it?
> 
Probably not, as long as we have the test coverage.


Repository:
  rL LLVM

http://reviews.llvm.org/D16823



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

Re: [libcxx] r260570 - Work around regression in glibc 2.22: request that glibc provides the correct

[Alexey Samsonov via cfe-commits]

I see bogus boostrap build failures when we're trying to use just-built
Clang to build libc++:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/22540/steps/bootstrap%20clang/logs/stdio

Do you think it can be related to one of your changes? I'm pretty sure the
contents of /usr/include/string.h wasn't changed for a while :)

In file included from
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/libcxxabi/src/cxa_demangle.cpp:15:
In file included from
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/libcxx/include/vector:265:
In file included from
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/libcxx/include/__bit_reference:15:
In file included from
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/libcxx/include/algorithm:626:
In file included from
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/libcxx/include/cstring:61:
In file included from
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/libcxx/include/string.h:65:
/usr/include/string.h:81:1: error: unknown type name
'__extern_always_inline'
__extern_always_inline void *
^
/usr/include/string.h:81:24: error: expected unqualified-id
__extern_always_inline void *
   ^

On Thu, Feb 11, 2016 at 11:40 AM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Thu Feb 11 13:40:06 2016
> New Revision: 260570
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260570&view=rev
> Log:
> Work around regression in glibc 2.22: request that glibc provides the
> correct
> prototypes for  functions that are converted into overload sets
> in
> C++. This matches the existing workaround in .
>
> Modified:
> libcxx/trunk/include/string.h
>
> Modified: libcxx/trunk/include/string.h
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string.h?rev=260570&r1=260569&r2=260570&view=diff
>
> ==
> --- libcxx/trunk/include/string.h (original)
> +++ libcxx/trunk/include/string.h Thu Feb 11 13:40:06 2016
> @@ -58,6 +58,10 @@ size_t strlen(const char* s);
>  #pragma GCC system_header
>  #endif
>
> +#ifdef __cplusplus
> +#define __CORRECT_ISO_CPP_STRING_H_PROTO
> +#endif
> +
>  #include_next 
>
>  // MSVCRT, GNU libc and its derivates already have the correct prototype
> in
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260779 - Disable two tests that use a lot of stack under ASan.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Feb 12 19:02:59 2016
New Revision: 260779

URL: http://llvm.org/viewvc/llvm-project?rev=260779&view=rev
Log:
Disable two tests that use a lot of stack under ASan.

Modified:
cfe/trunk/test/Index/index-many-call-ops.cpp
cfe/trunk/test/Index/index-many-logical-ops.c

Modified: cfe/trunk/test/Index/index-many-call-ops.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/index-many-call-ops.cpp?rev=260779&r1=260778&r2=260779&view=diff
==
--- cfe/trunk/test/Index/index-many-call-ops.cpp (original)
+++ cfe/trunk/test/Index/index-many-call-ops.cpp Fri Feb 12 19:02:59 2016
@@ -4,8 +4,8 @@
 // Check that we don't get stack overflow trying to index a huge number of
 // call operators.
 
-// UBSan increses stack usage.
-// REQUIRES: not_ubsan
+// ASan and UBSan increase stack usage.
+// REQUIRES: not_asan, not_ubsan
 
 struct S {
   S &operator()();

Modified: cfe/trunk/test/Index/index-many-logical-ops.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/index-many-logical-ops.c?rev=260779&r1=260778&r2=260779&view=diff
==
--- cfe/trunk/test/Index/index-many-logical-ops.c (original)
+++ cfe/trunk/test/Index/index-many-logical-ops.c Fri Feb 12 19:02:59 2016
@@ -4,8 +4,8 @@
 // Check that we don't get stack overflow trying to index a huge number of
 // logical operators.
 
-// UBSan increses stack usage.
-// REQUIRES: not_ubsan
+// ASan and UBSan increase stack usage.
+// REQUIRES: not_asan, not_ubsan
 
 // CHECK: [indexDeclaration]: kind: function | name: foo
 int foo(int x) {


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

r263081 - EmitCXXStructorCall -> EmitCXXDestructorCall. NFC.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Wed Mar  9 18:20:37 2016
New Revision: 263081

URL: http://llvm.org/viewvc/llvm-project?rev=263081&view=rev
Log:
EmitCXXStructorCall -> EmitCXXDestructorCall. NFC.

This function is only used in Microsoft ABI and only to emit
destructors. Rename/simplify it accordingly.

Modified:
cfe/trunk/lib/CodeGen/CGExprCXX.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp

Modified: cfe/trunk/lib/CodeGen/CGExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprCXX.cpp?rev=263081&r1=263080&r2=263081&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExprCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprCXX.cpp Wed Mar  9 18:20:37 2016
@@ -82,15 +82,15 @@ RValue CodeGenFunction::EmitCXXMemberOrO
   Callee, ReturnValue, Args, MD);
 }
 
-RValue CodeGenFunction::EmitCXXStructorCall(
-const CXXMethodDecl *MD, llvm::Value *Callee, ReturnValueSlot ReturnValue,
-llvm::Value *This, llvm::Value *ImplicitParam, QualType ImplicitParamTy,
-const CallExpr *CE, StructorType Type) {
+RValue CodeGenFunction::EmitCXXDestructorCall(
+const CXXDestructorDecl *DD, llvm::Value *Callee, llvm::Value *This,
+llvm::Value *ImplicitParam, QualType ImplicitParamTy, const CallExpr *CE,
+StructorType Type) {
   CallArgList Args;
-  commonEmitCXXMemberOrOperatorCall(*this, MD, This, ImplicitParam,
+  commonEmitCXXMemberOrOperatorCall(*this, DD, This, ImplicitParam,
 ImplicitParamTy, CE, Args);
-  return EmitCall(CGM.getTypes().arrangeCXXStructorDeclaration(MD, Type),
-  Callee, ReturnValue, Args, MD);
+  return EmitCall(CGM.getTypes().arrangeCXXStructorDeclaration(DD, Type),
+  Callee, ReturnValueSlot(), Args, DD);
 }
 
 static CXXRecordDecl *getCXXRecord(const Expr *E) {

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.h?rev=263081&r1=263080&r2=263081&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.h Wed Mar  9 18:20:37 2016
@@ -2710,11 +2710,10 @@ public:
   ReturnValueSlot ReturnValue, llvm::Value *This,
   llvm::Value *ImplicitParam,
   QualType ImplicitParamTy, const CallExpr *E);
-  RValue EmitCXXStructorCall(const CXXMethodDecl *MD, llvm::Value *Callee,
- ReturnValueSlot ReturnValue, llvm::Value *This,
- llvm::Value *ImplicitParam,
- QualType ImplicitParamTy, const CallExpr *E,
- StructorType Type);
+  RValue EmitCXXDestructorCall(const CXXDestructorDecl *DD, llvm::Value 
*Callee,
+   llvm::Value *This, llvm::Value *ImplicitParam,
+   QualType ImplicitParamTy, const CallExpr *E,
+   StructorType Type);
   RValue EmitCXXMemberCallExpr(const CXXMemberCallExpr *E,
ReturnValueSlot ReturnValue);
   RValue EmitCXXMemberOrOperatorMemberCallExpr(const CallExpr *CE,

Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=263081&r1=263080&r2=263081&view=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Wed Mar  9 18:20:37 2016
@@ -1494,10 +1494,10 @@ void MicrosoftCXXABI::EmitDestructorCall
 This, false);
   }
 
-  CGF.EmitCXXStructorCall(DD, Callee, ReturnValueSlot(), This.getPointer(),
-  /*ImplicitParam=*/nullptr,
-  /*ImplicitParamTy=*/QualType(), nullptr,
-  getFromDtorType(Type));
+  CGF.EmitCXXDestructorCall(DD, Callee, This.getPointer(),
+/*ImplicitParam=*/nullptr,
+/*ImplicitParamTy=*/QualType(), nullptr,
+getFromDtorType(Type));
 }
 
 void MicrosoftCXXABI::emitVTableBitSetEntries(VPtrInfo *Info,
@@ -1849,10 +1849,9 @@ llvm::Value *MicrosoftCXXABI::EmitVirtua
   DtorType == Dtor_Deleting);
 
   This = adjustThisArgumentForVirtualFunctionCall(CGF, GD, This, true);
-  RValue RV = CGF.EmitCXXStructorCall(Dtor, Callee, ReturnValueSlot(),
-  This.getPointer(),
-  ImplicitParam, Context.IntTy, CE,
-  StructorType::Deleting);
+  RValue RV =
+  CGF.EmitCXXDestructorCall(Dtor, Callee, This.getPointer(), ImplicitParam,
+

r263080 - Remove unused function arguments. NFC.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Wed Mar  9 18:20:33 2016
New Revision: 263080

URL: http://llvm.org/viewvc/llvm-project?rev=263080&view=rev
Log:
Remove unused function arguments. NFC.

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

Modified: cfe/trunk/lib/CodeGen/CGExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprCXX.cpp?rev=263080&r1=263079&r2=263080&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExprCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprCXX.cpp Wed Mar  9 18:20:33 2016
@@ -24,10 +24,11 @@
 using namespace clang;
 using namespace CodeGen;
 
-static RequiredArgs commonEmitCXXMemberOrOperatorCall(
-CodeGenFunction &CGF, const CXXMethodDecl *MD, llvm::Value *Callee,
-ReturnValueSlot ReturnValue, llvm::Value *This, llvm::Value *ImplicitParam,
-QualType ImplicitParamTy, const CallExpr *CE, CallArgList &Args) {
+static RequiredArgs
+commonEmitCXXMemberOrOperatorCall(CodeGenFunction &CGF, const CXXMethodDecl 
*MD,
+  llvm::Value *This, llvm::Value 
*ImplicitParam,
+  QualType ImplicitParamTy, const CallExpr *CE,
+  CallArgList &Args) {
   assert(CE == nullptr || isa(CE) ||
  isa(CE));
   assert(MD->isInstance() &&
@@ -76,8 +77,7 @@ RValue CodeGenFunction::EmitCXXMemberOrO
   const FunctionProtoType *FPT = MD->getType()->castAs();
   CallArgList Args;
   RequiredArgs required = commonEmitCXXMemberOrOperatorCall(
-  *this, MD, Callee, ReturnValue, This, ImplicitParam, ImplicitParamTy, CE,
-  Args);
+  *this, MD, This, ImplicitParam, ImplicitParamTy, CE, Args);
   return EmitCall(CGM.getTypes().arrangeCXXMethodCall(Args, FPT, required),
   Callee, ReturnValue, Args, MD);
 }
@@ -87,8 +87,8 @@ RValue CodeGenFunction::EmitCXXStructorC
 llvm::Value *This, llvm::Value *ImplicitParam, QualType ImplicitParamTy,
 const CallExpr *CE, StructorType Type) {
   CallArgList Args;
-  commonEmitCXXMemberOrOperatorCall(*this, MD, Callee, ReturnValue, This,
-ImplicitParam, ImplicitParamTy, CE, Args);
+  commonEmitCXXMemberOrOperatorCall(*this, MD, This, ImplicitParam,
+ImplicitParamTy, CE, Args);
   return EmitCall(CGM.getTypes().arrangeCXXStructorDeclaration(MD, Type),
   Callee, ReturnValue, Args, MD);
 }


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

Re: r263429 - [Frontend] Disable value name discarding for all sanitizers.

[Alexey Samsonov via cfe-commits]

On Mon, Mar 14, 2016 at 9:50 AM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 14 Mar 2016 6:28 a.m., "Benjamin Kramer via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Author: d0k
> > Date: Mon Mar 14 08:23:58 2016
> > New Revision: 263429
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=263429&view=rev
> > Log:
> > [Frontend] Disable value name discarding for all sanitizers.
> >
> > ASan also relies on names on allocas and will emit unhelpful output if
> > they're not present. Just force-enable value names for now. Should
> > unbreak release builds of asan.
> >
> > Modified:
> > cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> >
> > Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=263429&r1=263428&r2=263429&view=diff
> >
> ==
> > --- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
> > +++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Mon Mar 14 08:23:58
> 2016
> > @@ -541,6 +541,7 @@ static bool ParseCodeGenArgs(CodeGenOpti
> >Opts.DisableFPElim =
> >(Args.hasArg(OPT_mdisable_fp_elim) || Args.hasArg(OPT_pg));
> >Opts.DisableFree = Args.hasArg(OPT_disable_free);
> > +  Opts.DiscardValueNames = Args.hasArg(OPT_discard_value_names);
> >Opts.DisableTailCalls = Args.hasArg(OPT_mdisable_tail_calls);
> >Opts.FloatABI = Args.getLastArgValue(OPT_mfloat_abi);
> >if (Arg *A = Args.getLastArg(OPT_meabi)) {
> > @@ -793,12 +794,6 @@ static bool ParseCodeGenArgs(CodeGenOpti
> >Opts.CudaGpuBinaryFileNames =
> >Args.getAllArgValues(OPT_fcuda_include_gpubinary);
> >
> > -  // DiscardValueNames is set here so that it can depend (perhaps
> temporarily)
> > -  // on other options.
> > -  // We check SanitizeMemoryTrackOrigins here because the backend pass
> depends
> > -  // on the name of the alloca in order to print out names.
> > -  Opts.DiscardValueNames =
> > -  Args.hasArg(OPT_discard_value_names) &&
> !Opts.SanitizeMemoryTrackOrigins;
> >return Success;
> >  }
> >
> > @@ -2158,6 +2153,12 @@ bool CompilerInvocation::CreateFromArgs(
> >  if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
> >Res.getLangOpts()->ObjCExceptions = 1;
> >}
> > +
> > +  // FIXME: Override value name discarding when sanitizers are used
> because the
> > +  // backend passes depend on the name of the alloca in order to print
> out
> > +  // names.
> > +  Res.getCodeGenOpts().DiscardValueNames &=
> Res.getLangOpts()->Sanitize.empty();
>
> This should not be applied to all sanitizers. UBSan checks have no need of
> this (there is no backend pass).
>
+1. IIRC we only use it in ASan/MSan.


> >// FIXME: ParsePreprocessorArgs uses the FileManager to read the
> contents of
> >// PCH file and find the original header name. Remove the need to do
> that in
> >// ParsePreprocessorArgs and remove the FileManager
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r263429 - [Frontend] Disable value name discarding for all sanitizers.

[Alexey Samsonov via cfe-commits]

>>>> !Opts.SanitizeMemoryTrackOrigins;
> >>>>return Success;
> >>>>  }
> >>>>
> >>>> @@ -2158,6 +2153,12 @@ bool CompilerInvocation::CreateFromArgs(
> >>>>  if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
> >>>>Res.getLangOpts()->ObjCExceptions = 1;
> >>>>}
> >>>> +
> >>>> +  // FIXME: Override value name discarding when sanitizers are used
> >>>> because the
> >>>> +  // backend passes depend on the name of the alloca in order to
> print
> >>>> out
> >>>> +  // names.
> >>>> +  Res.getCodeGenOpts().DiscardValueNames &=
> >>>> Res.getLangOpts()->Sanitize.empty();
> >>>> +
> >>>>// FIXME: ParsePreprocessorArgs uses the FileManager to read the
> >>>> contents of
> >>>>// PCH file and find the original header name. Remove the need to
> do
> >>>> that in
> >>>>// ParsePreprocessorArgs and remove the FileManager
> >>>>
> >>>>
> >>>> ___
> >>>> cfe-commits mailing list
> >>>> cfe-commits@lists.llvm.org
> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >>>
> >>>
> >>> ___
> >>> cfe-commits mailing list
> >>> cfe-commits@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >>>
> >>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18280: [tsan] Allow -fsanitize=thread for iOS-style simulator targets

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Cool, great to see this coming. I'll let Kuba sign this off.



Comment at: test/Driver/fsanitize.c:220
@@ -219,1 +219,3 @@
 
+// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=thread %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-TSAN-X86-64-DARWIN
+// CHECK-TSAN-X86-64-DARWIN-NOT: unsupported option

Care to add a test for ios or tvos?


http://reviews.llvm.org/D18280



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

Re: r264281 - Recommitted r263425 "Supporting all entities declared in lexical scope in LLVM debug info."

[Alexey Samsonov via cfe-commits]

 }
>
> Modified: cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp?rev=264281&r1=264280&r2=264281&view=diff
>
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp Thu Mar 24
> 08:30:41 2016
> @@ -44,7 +44,12 @@ void instantiate(int x) {
>buildBytes(x);
>  }
>
> +// CHECK: ![[UNION:[0-9]+]] = !DICompositeType(tag: DW_TAG_union_type,
> +// CHECK-NOT: name:
> +// CHECK: elements
>  // CHECK: [[FILE:.*]] = !DIFile(filename:
> "{{.*}}debug-info-anon-union-vars.cpp",
> +// CHECK: !DIDerivedType(tag: DW_TAG_member, name: "i", scope: ![[UNION]],
> +// CHECK: !DIDerivedType(tag: DW_TAG_member, name: "c", scope: ![[UNION]],
>  // CHECK: !DIGlobalVariable(name: "c",{{.*}} file: [[FILE]], line:
> 6,{{.*}} isLocal: true, isDefinition: true
>  // CHECK: !DIGlobalVariable(name: "d",{{.*}} file: [[FILE]], line:
> 6,{{.*}} isLocal: true, isDefinition: true
>  // CHECK: !DIGlobalVariable(name: "a",{{.*}} file: [[FILE]], line:
> 6,{{.*}} isLocal: true, isDefinition: true
> @@ -55,9 +60,4 @@ void instantiate(int x) {
>  // CHECK: !DILocalVariable(name: "c", {{.*}}, flags: DIFlagArtificial
>  // CHECK: !DILocalVariable(
>  // CHECK-NOT: name:
> -// CHECK: type: ![[UNION:[0-9]+]]
> -// CHECK: ![[UNION]] = !DICompositeType(tag: DW_TAG_union_type,
> -// CHECK-NOT: name:
> -// CHECK: elements
> -// CHECK: !DIDerivedType(tag: DW_TAG_member, name: "i", scope: ![[UNION]],
> -// CHECK: !DIDerivedType(tag: DW_TAG_member, name: "c", scope: ![[UNION]],
> +// CHECK: type: ![[UNION]]
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r264281 - Recommitted r263425 "Supporting all entities declared in lexical scope in LLVM debug info."

[Alexey Samsonov via cfe-commits]

I've been using no-asserts build, and it led to segfault, so probably it
was required. I see that Reid already proceeded with the revert. I will
still work on a reproducer.

On Thu, Mar 24, 2016 at 1:43 PM, Aboud, Amjad  wrote:

> I believe it is safe to disable the assertion.
>
> I added this assertion...I am trying to figure out why we are hitting it.
>
>
>
> I am not convinced that we should do a total revert.
>
>
>
> Regards,
>
> Amjad
>
>
>
> *From:* Alexey Samsonov [mailto:vonos...@gmail.com]
> *Sent:* Thursday, March 24, 2016 22:27
> *To:* Aboud, Amjad 
> *Cc:* cfe-commits 
> *Subject:* Re: r264281 - Recommitted r263425 "Supporting all entities
> declared in lexical scope in LLVM debug info."
>
>
>
> Heads-up: I see segmentation faults in Clang following this revision. I
> will try to come up with a standalone reproducer and update
> https://llvm.org/bugs/show_bug.cgi?id=26942, possibly reverting this
> change.
>
>
>
> On Thu, Mar 24, 2016 at 6:30 AM, Amjad Aboud via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: aaboud
> Date: Thu Mar 24 08:30:41 2016
> New Revision: 264281
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264281&view=rev
> Log:
> Recommitted r263425 "Supporting all entities declared in lexical scope in
> LLVM debug info."
> After fixing PR26942 (the fix is included in this commit).
>
> Differential Revision: http://reviews.llvm.org/D18350
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-lb.cpp
>   - copied unchanged from r263435,
> cfe/trunk/test/CodeGenCXX/debug-info-lb.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
> cfe/trunk/lib/CodeGen/CGDecl.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=264281&r1=264280&r2=264281&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Mar 24 08:30:41 2016
> @@ -831,15 +831,18 @@ llvm::DIType *CGDebugInfo::CreateType(co
>
>  llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
>llvm::DIFile *Unit) {
> +  TypedefNameDecl *TD = Ty->getDecl();
>// We don't set size information, but do specify where the typedef was
>// declared.
> -  SourceLocation Loc = Ty->getDecl()->getLocation();
> +  SourceLocation Loc = TD->getLocation();
> +
> +  llvm::DIScope *TDContext = getDeclarationLexicalScope(*TD, QualType(Ty,
> 0));
>
>// Typedefs are derived from some other type.
>return DBuilder.createTypedef(
>getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit),
>Ty->getDecl()->getName(), getOrCreateFile(Loc), getLineNumber(Loc),
> -  getDeclContextDescriptor(Ty->getDecl()));
> +  TDContext);
>  }
>
>  llvm::DIType *CGDebugInfo::CreateType(const FunctionType *Ty,
> @@ -1472,6 +1475,23 @@ llvm::DIType *CGDebugInfo::getOrCreateSt
>return T;
>  }
>
> +void CGDebugInfo::recordDeclarationLexicalScope(const Decl &D) {
> +  assert(LexicalBlockMap.find(&D) == LexicalBlockMap.end() &&
> + "D is already mapped to lexical block scope");
> +  if (!LexicalBlockStack.empty())
> +LexicalBlockMap[&D] = LexicalBlockStack.back();
> +}
> +
> +llvm::DIScope *CGDebugInfo::getDeclarationLexicalScope(const Decl &D,
> +   QualType Ty) {
> +  auto I = LexicalBlockMap.find(&D);
> +  if (I != LexicalBlockMap.end()) {
> +RetainedTypes.push_back(Ty.getAsOpaquePtr());
> +return I->second;
> +  }
> +  return getDeclContextDescriptor(cast(&D));
> +}
> +
>  void CGDebugInfo::completeType(const EnumDecl *ED) {
>if (DebugKind <= codegenoptions::DebugLineTablesOnly)
>  return;
> @@ -2057,7 +2077,7 @@ llvm::DIType *CGDebugInfo::CreateEnumTyp
>  // entered into the ReplaceMap: finalize() will replace the first
>  // FwdDecl with the second and then replace the second with
>  // complete type.
> -llvm::DIScope *EDContext = getDeclContextDescriptor(ED);
> +llvm::DIScope *EDContext = getDeclarationLexicalScope(*ED,
> QualType(Ty, 0));
>  llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
>  llvm::TempDIScope TmpContext(DBuilder.createReplaceableCompositeType(
>  llvm::dwarf::DW_TAG_enumeration_typ

Re: r264428 - [ASTMatchers] Fix build for VariadicFunction.

[Alexey Samsonov via cfe-commits]

On Fri, Mar 25, 2016 at 10:55 AM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Fri, Mar 25, 2016 at 10:46 AM, Samuel Benzaquen via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: sbenza
>> Date: Fri Mar 25 12:46:02 2016
>> New Revision: 264428
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=264428&view=rev
>> Log:
>> [ASTMatchers] Fix build for VariadicFunction.
>>
>> Under some conditions the implicit conversion from array to ArrayRef<>
>> is not working.
>>
>
> Any idea what those conditions are?
>

This was causing the build failure with opt GCC. I will try to create a
smaller reproducer later today.


>
>
>> Fix the build by making it explicit.
>>
>> Modified:
>> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>
>> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=264428&r1=264427&r2=264428&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
>> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Fri Mar 25
>> 12:46:02 2016
>> @@ -90,7 +90,7 @@ private:
>>// before we make the array.
>>template  ResultT Execute(const ArgsT &... Args)
>> const {
>>  const ArgT *const ArgsArray[] = {&Args...};
>> -return Func(ArgsArray);
>> +return Func(ArrayRef(ArgsArray, sizeof...(ArgsT)));
>>}
>>  };
>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

Interesting. Do we run test/asan/TestCases/suppressions-interceptor.cc on
Windows? Seems so: I don't see an XFAIL there, and it also uses
suppressions, but with single quote, followed by double quote:

%env_asan_opts=suppressions='"%t.supp"'

Why does it work there?

On Tue, Dec 22, 2015 at 4:35 PM, Nico Weber  wrote:

> thakis added a comment.
>
> I've looked at it some, and couldn't find a way of escaping quotes that
> lit doesn't strip but that ubsan accepts.
>
> '"c:\foo"' gets its quotes stripped by lit, so does """c:\foo""".
> \"c:\foo\" confuses lit enough that it tries to call lit.util.warning()
> which doesn't exist.
>
> I've XFAIL'd the test on win32 in 256307 for now. Please take a look when
> you're back. Maybe teaching lit about \" escaping is the best fix.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D15363
>
>
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15624: Add iOS/watchOS/tvOS support for ASan (clang part)

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Sorry, lost track of this.



Comment at: lib/Driver/ToolChains.cpp:368
@@ +367,3 @@
+  StringRef OS = "";
+  if (isTargetMacOS())
+OS = "osx";

zaks.anna wrote:
> samsonov wrote:
> > Wait, this looks horrible. Can we teach toolchain to give us OS name?
> These are not OS names; they are prefixes we use to name the library. I 
> believe "appletvsimulator" would be a platform name, which is too long to 
> append to the dylib name.
> 
> I could factor this out into a separate function, but there are no other 
> immediate users. Not sure if the profiler library could be refactored to use 
> it, logic there seems more complicated.
Then we can name it as getOSLibraryNamePrefix() or smth. like that. I worry 
that this logic would hardly be discoverable inside `AddLinkSanitizerLibArgs` 
if it's going to be reused somewhere (which is likely).


http://reviews.llvm.org/D15624



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

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

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Sorry for delay.



Comment at: lib/CodeGen/CGExpr.cpp:2543
@@ +2542,3 @@
+  // RE: Bug: 25682
+  if(!CGM.getCodeGenOpts().MergeTraps || 
!CGM.getCodeGenOpts().OptimizationLevel || !TrapBB) {
+// If we aren't merging traps, set the function to not be optimized as some

This condition is somewhat hard to parse. Consider inverting it:
  // Collapse all trap calls to one per function if we're optimizing, and 
  if (TrapBB && CGM.getCodeGenOpts().OptimizationLevel && 
CGM.getCodeGenOpts().MergeTraps) {
Builder.CreateCondBr(Checked, Cont, TrapBB);
  } else {
 //...
  }


Comment at: lib/CodeGen/CGExpr.cpp:2557
@@ +2556,3 @@
+  // This closely mirrors what is done to avoid function merging
+  // in the address sanitizer. The trap function is not set
+  // to not return as there is an unreachable instruction

Nit: AddressSanitizer, or ASan.


Comment at: lib/CodeGen/CGExpr.cpp:2558
@@ +2557,3 @@
+  // in the address sanitizer. The trap function is not set
+  // to not return as there is an unreachable instruction
+  // generated at the end of the block.

What's wrong with marking trap function as noreturn anyway? unreachable 
instruction is, well, supposed to be unreachable.


Comment at: lib/CodeGen/CGExpr.cpp:2560
@@ +2559,3 @@
+  // generated at the end of the block.
+  EmitTrapCall(llvm::Intrinsic::trap);
+  llvm::InlineAsm *EmptyAsm = 
llvm::InlineAsm::get(llvm::FunctionType::get(Builder.getVoidTy(), false),

This can also be hoisted from branches.


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

On Wed, Jan 20, 2016 at 12:42 PM, Nico Weber  wrote:

> thakis added a comment.
>
> After some more debugging, the only thing in this test that's still
> faiilng on Windows is the "unsigned-integer-overflow:do_overflow"
> suppression -- when llvm-symbolizer gets symbols from PDBs it currently
> requires the DIA SDK. If that's not found at cmake time, then
> llvm-symbolizer silently can't symbolize executables with pdb debug info.
>
> The test should probably have some "REQUIRES: symbols" thingie. (I'll also
> fix llvm not finding the DIA SDK in our build setup, but the test will
> still fail for others who don't have that.)
>

Interesting, thanks for digging into this! IIRC the story with Dwarf
support on Windows (both producing it by Clang and consuming it by
llvm-symbolizer) got slightly better recently. Maybe, we can add a compiler
flag to force Clang emit Dwarf data on Windows in our compiler-rt test
suites?


>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D15363
>
>
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15624: Add iOS/watchOS/tvOS support for ASan (clang part)

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Thanks.



Comment at: lib/Driver/ToolChains.cpp:322
@@ -321,1 +321,3 @@
 
+StringRef Darwin::getOSLibraryNameSuffix() const {
+  if (isTargetMacOS())

Fun fact: if TargetPlatform is `TvOSSimulator`, this function will return 
`iossim` because `isTargetIOSSimulator` will return true.
I suggest to just switch on the value of `TargetPlatform` instead of using 
these helpers.


Comment at: lib/Driver/ToolChains.cpp:330
@@ +329,3 @@
+  if (isTargetIOSSimulator())
+return "iossim";
+  if (isTargetIPhoneOS())

Also, is it possible to add a test case for this?


http://reviews.llvm.org/D15624



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

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

On Thu, Jan 21, 2016 at 10:20 AM, Nico Weber  wrote:

> On Thu, Jan 21, 2016 at 1:19 PM, Alexey Samsonov 
> wrote:
>
>>
>> On Wed, Jan 20, 2016 at 12:42 PM, Nico Weber  wrote:
>>
>>> thakis added a comment.
>>>
>>> After some more debugging, the only thing in this test that's still
>>> faiilng on Windows is the "unsigned-integer-overflow:do_overflow"
>>> suppression -- when llvm-symbolizer gets symbols from PDBs it currently
>>> requires the DIA SDK. If that's not found at cmake time, then
>>> llvm-symbolizer silently can't symbolize executables with pdb debug info.
>>>
>>> The test should probably have some "REQUIRES: symbols" thingie. (I'll
>>> also fix llvm not finding the DIA SDK in our build setup, but the test will
>>> still fail for others who don't have that.)
>>>
>>
>> Interesting, thanks for digging into this! IIRC the story with Dwarf
>> support on Windows (both producing it by Clang and consuming it by
>> llvm-symbolizer) got slightly better recently. Maybe, we can add a compiler
>> flag to force Clang emit Dwarf data on Windows in our compiler-rt test
>> suites?
>>
>
> It isn't heavily tested and it'd require using lld instead of link. I
> think it's possible. But most clients probably use PDBs for now, so maybe
> testing that is better, not sure.
>

Oh, ok, let's not depend on lld then. So, we need to either determine if
DIA SDK is available at compiler-rt configure time, or teach
llvm-symbolizer.exe to tell us that (as we support standalone compiler-rt
build)...


>
>
>>
>>
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> http://reviews.llvm.org/D15363
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Alexey Samsonov
>> vonos...@gmail.com
>>
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

In http://reviews.llvm.org/D15225#328218, @zaks.anna wrote:

> > I see, so essentially you want to use a different approach for determining 
> > sanitizer availability (on OS X for now): if the library is present, then 
> > we support 
>
> >  sanitizer, otherwise we don't: i.e. the binary distribution is the source 
> > of truth, not the list of sanitizers hardcoded into Clang driver source 
> > code. I'm fine with 
>
> >  that, and see why it would make sense.
>
>
> Correct.
>
> > It's just that error message looks misleading: the problem is not TSan is 
> > unsupported for target, it's just unavailable in this distribution for one 
> > reason or 
>
> >  another.
>
>
> The main advantage of the error message Kuba has right now is that it is user 
> friendly. A sanitizer IS unsupported for the given target in the given 
> distribution if the library is missing. Saying something along the lines of 
> "runtime components for '-fsanitize=thread' not available" is vague. For 
> example, does it mean that the user needs to install the runtime components 
> in some other way?


s/unsupported/unavailable? I don't know, is there a way to install runtime 
components for ASan if your distribution doesn't happen to have one (that must 
be tricky, as the version of ASan should match the version of the compiler). 
Anyway, you're in much better position to make a judgement here, leaving this 
to you.

I believe, at least part of this patch will be superseded by 
http://reviews.llvm.org/D15624? Feel free to update this one when the latter 
lands.


http://reviews.llvm.org/D15225



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

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

On Thu, Jan 21, 2016 at 10:58 AM, Reid Kleckner  wrote:

> On Thu, Jan 21, 2016 at 10:47 AM, Nico Weber  wrote:
>
>> Oh, ok, let's not depend on lld then. So, we need to either determine if
>>> DIA SDK is available at compiler-rt configure time, or teach
>>> llvm-symbolizer.exe to tell us that (as we support standalone compiler-rt
>>> build)...
>>>
>>
>> Maybe the lit config file could compile a small program with clang-cl and
>> then run it through llvm-symbolizer and see if a symbol is returned?
>>
>
> I'd rather duplicate this check in compiler-rt than add auto-conf style
> tests to check-asan startup:
>   # See if the DIA SDK is available and usable.
>   set(MSVC_DIA_SDK_DIR "$ENV{VSINSTALLDIR}DIA SDK")
>   if (IS_DIRECTORY ${MSVC_DIA_SDK_DIR})
> set(HAVE_DIA_SDK 1)
>   else()
> set(HAVE_DIA_SDK 0)
>   endif()
>

Yes. It's not 100% correct, but probably fine to assume that if we failed
to find DIA SDK at configure time, so did llvm-symbolizer when it was built.


>
> It is also possible to change LLVMSymbolizer::SymbolizePC to return false
> when llvm-symbolizer returns no useful information.
>

Do we want LLVMSymbolizer::SymbolizePC to succeed if we fetched file/line
info, but not function name?
Also, there may well be another issue that will be hard to debug. It makes
sense to store information about what features of llvm-symbolizer we expect
to work explicitly.


> This will cause the sanitizers to try calling into dbghelp, which will
> probably work. It doesn't return PDB column info or work with dwarf, which
> is why we try llvm-symbolizer first. I think I made this change at one
> point, but I was asked to revert it or there were minor issues that didn't
> seem worth fixing.
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r258476 - [Docs] Slightly update LSan documentation.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Thu Jan 21 19:35:45 2016
New Revision: 258476

URL: http://llvm.org/viewvc/llvm-project?rev=258476&view=rev
Log:
[Docs] Slightly update LSan documentation.

Modified:
cfe/trunk/docs/AddressSanitizer.rst
cfe/trunk/docs/LeakSanitizer.rst

Modified: cfe/trunk/docs/AddressSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/AddressSanitizer.rst?rev=258476&r1=258475&r2=258476&view=diff
==
--- cfe/trunk/docs/AddressSanitizer.rst (original)
+++ cfe/trunk/docs/AddressSanitizer.rst Thu Jan 21 19:35:45 2016
@@ -232,6 +232,23 @@ problems happening in certain source fil
 type:*BadInitClassSubstring*=init
 src:bad/init/files/*=init
 
+Suppressing memory leaks
+
+
+Memory leak reports produced by :doc:`LeakSanitizer` (if it is run as a part
+of AddressSanitizer) can be suppressed by a separate file passed as
+
+.. code-block:: bash
+
+LSAN_OPTIONS=suppressions=MyLSan.supp
+
+which contains lines of the form `leak:`. Memory leak will be
+suppressed if pattern matches any function name, source file name, or
+library name in the symbolized stack trace of the leak report. See
+`full documentation
+`_
+for more details.
+
 Limitations
 ===
 

Modified: cfe/trunk/docs/LeakSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LeakSanitizer.rst?rev=258476&r1=258475&r2=258476&view=diff
==
--- cfe/trunk/docs/LeakSanitizer.rst (original)
+++ cfe/trunk/docs/LeakSanitizer.rst Thu Jan 21 19:35:45 2016
@@ -9,21 +9,39 @@ Introduction
 
 
 LeakSanitizer is a run-time memory leak detector. It can be combined with
-:doc:`AddressSanitizer` to get both memory error and leak detection.
-LeakSanitizer does not introduce any additional slowdown when used in this 
mode.
-The LeakSanitizer runtime can also be linked in separately to get leak 
detection
-only, at a minimal performance cost.
-
-Current status
-==
-
-LeakSanitizer is turned on by default, but it is only supported on x86\_64
-Linux.
-
-The combined mode has been tested on fairly large software projects. The
-stand-alone mode has received much less testing.
-
-There are plans to support LeakSanitizer in :doc:`MemorySanitizer` builds.
+:doc:`AddressSanitizer` to get both memory error and leak detection, or
+used in a stand-alone mode. LSan adds almost no performance overhead
+until the very end of the process, at which point there is an extra leak
+detection phase.
+
+Usage
+=
+
+LeakSanitizer is only supported on x86\_64 Linux. In order to use it,
+simply build your program with :doc:`AddressSanitizer`:
+
+.. code-block:: console
+
+$ cat memory-leak.c
+#include 
+void *p;
+int main() {
+  p = malloc(7);
+  p = 0; // The memory is leaked here.
+  return 0;
+}
+% clang -fsanitize=address -g memory-leak.c ; ./a.out
+==23646==ERROR: LeakSanitizer: detected memory leaks
+Direct leak of 7 byte(s) in 1 object(s) allocated from:
+#0 0x4af01b in __interceptor_malloc 
/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52:3
+#1 0x4da26a in main memory-leak.c:4:7
+#2 0x7f076fd9cec4 in __libc_start_main libc-start.c:287
+SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
+
+To use LeakSanitizer in stand-alone mode, link your program with
+``-fsanitize=leak`` flag. Make sure to use ``clang`` (not ``ld``) for the
+link step, so that it would link in proper LeakSanitizer run-time library
+into the final executable.
 
 More Information
 


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

Re: [PATCH] D15624: Add iOS/watchOS/tvOS support for ASan (clang part)

[Alexey Samsonov via cfe-commits]

samsonov accepted this revision.
samsonov added a reviewer: samsonov.
samsonov added a comment.

LGTM



Comment at: lib/Driver/ToolChains.cpp:339
@@ +338,3 @@
+  }
+}
+

You might need `llvm_unreachable` at the very end to suppress GCC warnings 
(http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations)


http://reviews.llvm.org/D15624



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

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

Thank you for fixing this!

On Fri, Jan 22, 2016 at 12:30 PM, Nico Weber  wrote:

> I implemented Reid's suggestion in 258545. I tested that the test runs and
> passes when the DIA SDK is around (this is usually the case), and doesn't
> run when it isn't.
>
> On Thu, Jan 21, 2016 at 2:09 PM, Alexey Samsonov 
> wrote:
>
>> On Thu, Jan 21, 2016 at 10:58 AM, Reid Kleckner  wrote:
>>
>>> On Thu, Jan 21, 2016 at 10:47 AM, Nico Weber 
>>> wrote:
>>>
>>>> Oh, ok, let's not depend on lld then. So, we need to either determine
>>>>> if DIA SDK is available at compiler-rt configure time, or teach
>>>>> llvm-symbolizer.exe to tell us that (as we support standalone compiler-rt
>>>>> build)...
>>>>>
>>>>
>>>> Maybe the lit config file could compile a small program with clang-cl
>>>> and then run it through llvm-symbolizer and see if a symbol is returned?
>>>>
>>>
>>> I'd rather duplicate this check in compiler-rt than add auto-conf style
>>> tests to check-asan startup:
>>>   # See if the DIA SDK is available and usable.
>>>   set(MSVC_DIA_SDK_DIR "$ENV{VSINSTALLDIR}DIA SDK")
>>>   if (IS_DIRECTORY ${MSVC_DIA_SDK_DIR})
>>> set(HAVE_DIA_SDK 1)
>>>   else()
>>> set(HAVE_DIA_SDK 0)
>>>   endif()
>>>
>>
>> Yes. It's not 100% correct, but probably fine to assume that if we failed
>> to find DIA SDK at configure time, so did llvm-symbolizer when it was built.
>>
>>
>>>
>>> It is also possible to change LLVMSymbolizer::SymbolizePC to return
>>> false when llvm-symbolizer returns no useful information.
>>>
>>
>> Do we want LLVMSymbolizer::SymbolizePC to succeed if we fetched file/line
>> info, but not function name?
>> Also, there may well be another issue that will be hard to debug. It
>> makes sense to store information about what features of llvm-symbolizer we
>> expect to work explicitly.
>>
>>
>>> This will cause the sanitizers to try calling into dbghelp, which will
>>> probably work. It doesn't return PDB column info or work with dwarf, which
>>> is why we try llvm-symbolizer first. I think I made this change at one
>>> point, but I was asked to revert it or there were minor issues that didn't
>>> seem worth fixing.
>>>
>>
>>
>> --
>> Alexey Samsonov
>> vonos...@gmail.com
>>
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r259260 - [UBSan] Add documentation for runtime issue suppression.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Jan 29 17:07:14 2016
New Revision: 259260

URL: http://llvm.org/viewvc/llvm-project?rev=259260&view=rev
Log:
[UBSan] Add documentation for runtime issue suppression.

Modified:
cfe/trunk/docs/UndefinedBehaviorSanitizer.rst

Modified: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=259260&r1=259259&r2=259260&view=diff
==
--- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (original)
+++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Fri Jan 29 17:07:14 2016
@@ -168,6 +168,38 @@ UndefinedBehaviorSanitizer supports ``sr
 :doc:`SanitizerSpecialCaseList`, that can be used to suppress error reports
 in the specified source files or functions.
 
+Runtime suppressions
+
+
+Sometimes you can suppress UBSan error reports for specific files, functions,
+or libraries without recompiling the code. You need to pass a path to
+suppression file in a ``UBSAN_OPTIONS`` environment variable.
+
+.. code-block:: bash
+
+UBSAN_OPTIONS=suppressions=MyUBSan.supp
+
+You need to specify a :ref:`check ` you are suppressing and the
+bug location. For example:
+
+.. code-block:: bash
+
+  signed-integer-overflow:file-with-known-overflow.cpp
+  alignment:function_doing_unaligned_access
+  vptr:shared_object_with_vptr_failures.so
+
+There are several limitations:
+
+* Sometimes your binary must have enough debug info and/or symbol table, so
+  that the runtime could figure out source file or function name to match
+  against the suppression.
+* It is only possible to suppress recoverable checks. For the example above,
+  you can additionally pass
+  ``-fsanitize-recover=signed-integer-overflow,alignment,vptr``, although
+  most of UBSan checks are recoverable by default.
+* Check groups (like ``undefined``) can't be used in suppressions file, only
+  fine-grained checks are supported.
+
 Supported Platforms
 ===
 


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

Re: r259260 - [UBSan] Add documentation for runtime issue suppression.

[Alexey Samsonov via cfe-commits]

Hans, do you think it makes sense to merge this patch into 3.8?

On Fri, Jan 29, 2016 at 3:07 PM, Alexey Samsonov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: samsonov
> Date: Fri Jan 29 17:07:14 2016
> New Revision: 259260
>
> URL: http://llvm.org/viewvc/llvm-project?rev=259260&view=rev
> Log:
> [UBSan] Add documentation for runtime issue suppression.
>
> Modified:
> cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
>
> Modified: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=259260&r1=259259&r2=259260&view=diff
>
> ==
> --- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (original)
> +++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Fri Jan 29 17:07:14 2016
> @@ -168,6 +168,38 @@ UndefinedBehaviorSanitizer supports ``sr
>  :doc:`SanitizerSpecialCaseList`, that can be used to suppress error
> reports
>  in the specified source files or functions.
>
> +Runtime suppressions
> +
> +
> +Sometimes you can suppress UBSan error reports for specific files,
> functions,
> +or libraries without recompiling the code. You need to pass a path to
> +suppression file in a ``UBSAN_OPTIONS`` environment variable.
> +
> +.. code-block:: bash
> +
> +UBSAN_OPTIONS=suppressions=MyUBSan.supp
> +
> +You need to specify a :ref:`check ` you are suppressing and
> the
> +bug location. For example:
> +
> +.. code-block:: bash
> +
> +  signed-integer-overflow:file-with-known-overflow.cpp
> +  alignment:function_doing_unaligned_access
> +  vptr:shared_object_with_vptr_failures.so
> +
> +There are several limitations:
> +
> +* Sometimes your binary must have enough debug info and/or symbol table,
> so
> +  that the runtime could figure out source file or function name to match
> +  against the suppression.
> +* It is only possible to suppress recoverable checks. For the example
> above,
> +  you can additionally pass
> +  ``-fsanitize-recover=signed-integer-overflow,alignment,vptr``, although
> +  most of UBSan checks are recoverable by default.
> +* Check groups (like ``undefined``) can't be used in suppressions file,
> only
> +  fine-grained checks are supported.
> +
>  Supported Platforms
>  ===
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r259260 - [UBSan] Add documentation for runtime issue suppression.

[Alexey Samsonov via cfe-commits]

On Fri, Jan 29, 2016 at 3:16 PM, Hans Wennborg  wrote:

> Yes, that seems like a good idea. Go ahead and merge (or let me know
> if you'd prefer me to do it).
>

I'd appreciate if you could do it. Thanks!


>
> On Fri, Jan 29, 2016 at 3:14 PM, Alexey Samsonov 
> wrote:
> > Hans, do you think it makes sense to merge this patch into 3.8?
> >
> > On Fri, Jan 29, 2016 at 3:07 PM, Alexey Samsonov via cfe-commits
> >  wrote:
> >>
> >> Author: samsonov
> >> Date: Fri Jan 29 17:07:14 2016
> >> New Revision: 259260
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=259260&view=rev
> >> Log:
> >> [UBSan] Add documentation for runtime issue suppression.
> >>
> >> Modified:
> >> cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
> >>
> >> Modified: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=259260&r1=259259&r2=259260&view=diff
> >>
> >>
> ==
> >> --- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (original)
> >> +++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Fri Jan 29 17:07:14
> 2016
> >> @@ -168,6 +168,38 @@ UndefinedBehaviorSanitizer supports ``sr
> >>  :doc:`SanitizerSpecialCaseList`, that can be used to suppress error
> >> reports
> >>  in the specified source files or functions.
> >>
> >> +Runtime suppressions
> >> +
> >> +
> >> +Sometimes you can suppress UBSan error reports for specific files,
> >> functions,
> >> +or libraries without recompiling the code. You need to pass a path to
> >> +suppression file in a ``UBSAN_OPTIONS`` environment variable.
> >> +
> >> +.. code-block:: bash
> >> +
> >> +UBSAN_OPTIONS=suppressions=MyUBSan.supp
> >> +
> >> +You need to specify a :ref:`check ` you are suppressing
> and
> >> the
> >> +bug location. For example:
> >> +
> >> +.. code-block:: bash
> >> +
> >> +  signed-integer-overflow:file-with-known-overflow.cpp
> >> +  alignment:function_doing_unaligned_access
> >> +  vptr:shared_object_with_vptr_failures.so
> >> +
> >> +There are several limitations:
> >> +
> >> +* Sometimes your binary must have enough debug info and/or symbol
> table,
> >> so
> >> +  that the runtime could figure out source file or function name to
> match
> >> +  against the suppression.
> >> +* It is only possible to suppress recoverable checks. For the example
> >> above,
> >> +  you can additionally pass
> >> +  ``-fsanitize-recover=signed-integer-overflow,alignment,vptr``,
> although
> >> +  most of UBSan checks are recoverable by default.
> >> +* Check groups (like ``undefined``) can't be used in suppressions file,
> >> only
> >> +  fine-grained checks are supported.
> >> +
> >>  Supported Platforms
> >>  ===
> >>
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
> >
> >
> > --
> > Alexey Samsonov
> > vonos...@gmail.com
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r259278 - Remove references to autotools build.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Jan 29 18:54:42 2016
New Revision: 259278

URL: http://llvm.org/viewvc/llvm-project?rev=259278&view=rev
Log:
Remove references to autotools build.

Modified:
cfe/trunk/CODE_OWNERS.TXT
cfe/trunk/www/get_started.html

Modified: cfe/trunk/CODE_OWNERS.TXT
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CODE_OWNERS.TXT?rev=259278&r1=259277&r2=259278&view=diff
==
--- cfe/trunk/CODE_OWNERS.TXT (original)
+++ cfe/trunk/CODE_OWNERS.TXT Fri Jan 29 18:54:42 2016
@@ -23,7 +23,7 @@ D: CMake, library layering
 
 N: Eric Christopher
 E: echri...@gmail.com
-D: Debug Information, autotools/configure/make build, inline assembly
+D: Debug Information, inline assembly
 
 N: Doug Gregor
 E: dgre...@apple.com

Modified: cfe/trunk/www/get_started.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/get_started.html?rev=259278&r1=259277&r2=259278&view=diff
==
--- cfe/trunk/www/get_started.html (original)
+++ cfe/trunk/www/get_started.html Fri Jan 29 18:54:42 2016
@@ -98,9 +98,6 @@ follows:
 KDevelop3. For more details see
 http://llvm.org/docs/CMake.html";>Building LLVM with CMake
 page.
-  You can also build Clang with
-http://llvm.org/docs/BuildingLLVMWithAutotools.html";>
-autotools, but some features may be unavailable there.
   
   
 


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

[libcxx] r259281 - [docs] Remove references to autoconf build.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Jan 29 19:11:42 2016
New Revision: 259281

URL: http://llvm.org/viewvc/llvm-project?rev=259281&view=rev
Log:
[docs] Remove references to autoconf build.

Modified:
libcxx/trunk/docs/BuildingLibcxx.rst

Modified: libcxx/trunk/docs/BuildingLibcxx.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/BuildingLibcxx.rst?rev=259281&r1=259280&r2=259281&view=diff
==
--- libcxx/trunk/docs/BuildingLibcxx.rst (original)
+++ libcxx/trunk/docs/BuildingLibcxx.rst Fri Jan 29 19:11:42 2016
@@ -34,8 +34,7 @@ The basic steps needed to build libc++ a
 
 #. Configure and build libc++ with libc++abi:
 
-   CMake is the only supported configuration system. Unlike other LLVM
-   projects autotools is not supported for either libc++ or libc++abi.
+   CMake is the only supported configuration system.
 
Clang is the preferred compiler when building and using libc++.
 


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

Re: r253958 - Reduce the stack usage per recursive step when RecursiveASTVisitor cannot perform data recursion.

[Alexey Samsonov via cfe-commits]

Looks like Clang::Index/index-many-call-ops.cpp still uses too much stack
in ASan mode:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/10177/steps/check-clang%20asan/logs/stdio

ASan increases the stack usage, so do you think there's more to fix here,
or we should just disable the test under ASan?

On Mon, Nov 23, 2015 at 11:13 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Nov 24 01:13:06 2015
> New Revision: 253958
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253958&view=rev
> Log:
> Reduce the stack usage per recursive step when RecursiveASTVisitor cannot
> perform data recursion.
>
> Modified:
> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>
> Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=253958&r1=253957&r2=253958&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
> +++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Tue Nov 24 01:13:06
> 2015
> @@ -471,28 +471,10 @@ private:
>/// \brief Process clauses with list of variables.
>template  bool VisitOMPClauseList(T *Node);
>
> -  bool dataTraverse(Stmt *S);
>bool dataTraverseNode(Stmt *S, DataRecursionQueue *Queue);
>  };
>
>  template 
> -bool RecursiveASTVisitor::dataTraverse(Stmt *S) {
> -  SmallVector Queue;
> -  Queue.push_back(S);
> -
> -  while (!Queue.empty()) {
> -Stmt *CurrS = Queue.pop_back_val();
> -
> -size_t N = Queue.size();
> -TRY_TO(dataTraverseNode(CurrS, &Queue));
> -// Process new children in the order they were added.
> -std::reverse(Queue.begin() + N, Queue.end());
> -  }
> -
> -  return true;
> -}
> -
> -template 
>  bool RecursiveASTVisitor::dataTraverseNode(Stmt *S,
>  DataRecursionQueue
> *Queue) {
>  #define DISPATCH_STMT(NAME, CLASS, VAR)
>   \
> @@ -561,10 +543,23 @@ bool RecursiveASTVisitor::Trave
>&RecursiveASTVisitor::TraverseStmt>::value)
>  return dataTraverseNode(S, nullptr);
>
> -  if (!Queue)
> -return dataTraverse(S);
> +  if (Queue) {
> +Queue->push_back(S);
> +return true;
> +  }
> +
> +  SmallVector LocalQueue;
> +  LocalQueue.push_back(S);
> +
> +  while (!LocalQueue.empty()) {
> +Stmt *CurrS = LocalQueue.pop_back_val();
> +
> +size_t N = LocalQueue.size();
> +TRY_TO(dataTraverseNode(CurrS, &LocalQueue));
> +// Process new children in the order they were added.
> +std::reverse(LocalQueue.begin() + N, LocalQueue.end());
> +  }
>
> -  Queue->push_back(S);
>return true;
>  }
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r253958 - Reduce the stack usage per recursive step when RecursiveASTVisitor cannot perform data recursion.

[Alexey Samsonov via cfe-commits]

Unfortunately, that change breaks the Clang compilation, see r254041 review
thread.

On Tue, Nov 24, 2015 at 3:54 PM, Richard Smith 
wrote:

> On Tue, Nov 24, 2015 at 1:16 PM, Alexey Samsonov 
> wrote:
>
>> Looks like Clang::Index/index-many-call-ops.cpp still uses too much stack
>> in ASan mode:
>>
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/10177/steps/check-clang%20asan/logs/stdio
>>
>> ASan increases the stack usage, so do you think there's more to fix here,
>> or we should just disable the test under ASan?
>>
>
> I think this should work even under ASan conditions; fixed in r254041.
>
>
>> On Mon, Nov 23, 2015 at 11:13 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Tue Nov 24 01:13:06 2015
>>> New Revision: 253958
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=253958&view=rev
>>> Log:
>>> Reduce the stack usage per recursive step when RecursiveASTVisitor
>>> cannot perform data recursion.
>>>
>>> Modified:
>>> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>>>
>>> Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=253958&r1=253957&r2=253958&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
>>> +++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Tue Nov 24
>>> 01:13:06 2015
>>> @@ -471,28 +471,10 @@ private:
>>>/// \brief Process clauses with list of variables.
>>>template  bool VisitOMPClauseList(T *Node);
>>>
>>> -  bool dataTraverse(Stmt *S);
>>>bool dataTraverseNode(Stmt *S, DataRecursionQueue *Queue);
>>>  };
>>>
>>>  template 
>>> -bool RecursiveASTVisitor::dataTraverse(Stmt *S) {
>>> -  SmallVector Queue;
>>> -  Queue.push_back(S);
>>> -
>>> -  while (!Queue.empty()) {
>>> -Stmt *CurrS = Queue.pop_back_val();
>>> -
>>> -size_t N = Queue.size();
>>> -TRY_TO(dataTraverseNode(CurrS, &Queue));
>>> -// Process new children in the order they were added.
>>> -std::reverse(Queue.begin() + N, Queue.end());
>>> -  }
>>> -
>>> -  return true;
>>> -}
>>> -
>>> -template 
>>>  bool RecursiveASTVisitor::dataTraverseNode(Stmt *S,
>>>  DataRecursionQueue
>>> *Queue) {
>>>  #define DISPATCH_STMT(NAME, CLASS, VAR)
>>> \
>>> @@ -561,10 +543,23 @@ bool RecursiveASTVisitor::Trave
>>>
>>>  &RecursiveASTVisitor::TraverseStmt>::value)
>>>  return dataTraverseNode(S, nullptr);
>>>
>>> -  if (!Queue)
>>> -return dataTraverse(S);
>>> +  if (Queue) {
>>> +Queue->push_back(S);
>>> +return true;
>>> +  }
>>> +
>>> +  SmallVector LocalQueue;
>>> +  LocalQueue.push_back(S);
>>> +
>>> +  while (!LocalQueue.empty()) {
>>> +Stmt *CurrS = LocalQueue.pop_back_val();
>>> +
>>> +size_t N = LocalQueue.size();
>>> +TRY_TO(dataTraverseNode(CurrS, &LocalQueue));
>>> +// Process new children in the order they were added.
>>> +std::reverse(LocalQueue.begin() + N, LocalQueue.end());
>>> +  }
>>>
>>> -  Queue->push_back(S);
>>>return true;
>>>  }
>>>
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>>
>>
>> --
>> Alexey Samsonov
>> vonos...@gmail.com
>>
>
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254041 - Teach RAV to pass its DataRecursionQueue to derived classes if they ask for it,

[Alexey Samsonov via cfe-commits]

dle of traversing another statement. Can only be
> called
> +// from within a DEF_TRAVERSE_STMT body or similar context.
>  #define TRY_TO_TRAVERSE_OR_ENQUEUE_STMT(S)
>  \
>do {
>  \
>  if (!TRAVERSE_STMT_BASE(Stmt, Stmt, S, Queue))
>  \
> @@ -535,14 +545,6 @@ bool RecursiveASTVisitor::Trave
>if (!S)
>  return true;
>
> -  // If TraverseStmt was overridden (and called the base class version),
> don't
> -  // do any data recursion; it would be observable.
> -  if (!is_same_member_pointer -  &Derived::TraverseStmt,
> -
> decltype(&RecursiveASTVisitor::TraverseStmt),
> -  &RecursiveASTVisitor::TraverseStmt>::value)
> -return dataTraverseNode(S, nullptr);
> -
>if (Queue) {
>  Queue->push_back(S);
>  return true;
>
> Modified: cfe/trunk/tools/libclang/IndexBody.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/IndexBody.cpp?rev=254041&r1=254040&r2=254041&view=diff
>
> ==
> --- cfe/trunk/tools/libclang/IndexBody.cpp (original)
> +++ cfe/trunk/tools/libclang/IndexBody.cpp Tue Nov 24 17:50:47 2015
> @@ -125,10 +125,11 @@ public:
>  return true;
>}
>
> -  bool TraverseCXXOperatorCallExpr(CXXOperatorCallExpr *E) {
> +  bool TraverseCXXOperatorCallExpr(CXXOperatorCallExpr *E,
> +   DataRecursionQueue *Q = nullptr) {
>  if (E->getOperatorLoc().isInvalid())
>return true; // implicit.
> -return base::TraverseCXXOperatorCallExpr(E);
> +return base::TraverseCXXOperatorCallExpr(E, Q);
>}
>
>bool VisitDeclStmt(DeclStmt *S) {
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254041 - Teach RAV to pass its DataRecursionQueue to derived classes if they ask for it,

[Alexey Samsonov via cfe-commits]

Unfortunately, the bot still seems to be unhappy:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/12246/steps/build%20fresh%20clang/logs/stdio

On Tue, Nov 24, 2015 at 6:45 PM, Richard Smith 
wrote:

> Hah, looks like a rejects-valid, but it found a real bug, so *shrug*. =)
> Hopefully fixed in r254053.
>
>
> On Tue, Nov 24, 2015 at 5:14 PM, Alexey Samsonov 
> wrote:
>
>> Hm, looks like we can't compile Clang itself after this change (with GCC):
>>
>>
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/12237
>>
>> On Tue, Nov 24, 2015 at 3:50 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Tue Nov 24 17:50:47 2015
>>> New Revision: 254041
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=254041&view=rev
>>> Log:
>>> Teach RAV to pass its DataRecursionQueue to derived classes if they ask
>>> for it,
>>> to allow them to explicitly opt into data recursion despite having
>>> overridden
>>> Traverse*Stmt or Traverse*Expr. Use this to reintroduce data recursion
>>> to the
>>> one place that lost it when DataRecursiveASTVisitor was removed.
>>>
>>> Modified:
>>> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>>> cfe/trunk/tools/libclang/IndexBody.cpp
>>>
>>> Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=254041&r1=254040&r2=254041&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
>>> +++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Tue Nov 24
>>> 17:50:47 2015
>>> @@ -14,6 +14,8 @@
>>>  #ifndef LLVM_CLANG_AST_RECURSIVEASTVISITOR_H
>>>  #define LLVM_CLANG_AST_RECURSIVEASTVISITOR_H
>>>
>>> +#include 
>>> +
>>>  #include "clang/AST/Attr.h"
>>>  #include "clang/AST/Decl.h"
>>>  #include "clang/AST/DeclCXX.h"
>>> @@ -132,13 +134,13 @@ namespace clang {
>>>  /// instantiations will be visited at the same time as the pattern
>>>  /// from which they were produced.
>>>  template  class RecursiveASTVisitor {
>>> +public:
>>>/// A queue used for performing data recursion over statements.
>>>/// Parameters involving this type are used to implement data
>>>/// recursion over Stmts and Exprs within this class, and should
>>> -  /// not be explicitly specified by derived classes.
>>> +  /// typically not be explicitly specified by derived classes.
>>>typedef SmallVectorImpl DataRecursionQueue;
>>>
>>> -public:
>>>/// \brief Return a reference to the derived class.
>>>Derived &getDerived() { return *static_cast(this); }
>>>
>>> @@ -274,24 +276,32 @@ public:
>>>  //  Methods on Stmts 
>>>
>>>  private:
>>> -  template
>>> -  struct is_same_member_pointer : std::false_type {};
>>> -  template
>>> -  struct is_same_member_pointer : std::true_type {};
>>> -
>>> -  // Traverse the given statement. If the traverse function was not
>>> overridden,
>>> -  // pass on the data recursion queue information.
>>> +  // Determine if the specified derived-class member M can be passed a
>>> +  // DataRecursionQueue* argument.
>>> +  template
>>> +  std::false_type callableWithQueue(...);
>>> +  template
>>> +  std::true_type callableWithQueue(M m, Derived *d = nullptr, P *p =
>>> nullptr,
>>> +   DataRecursionQueue *q = nullptr,
>>> +   decltype((d->*m)(p, q)) = false);
>>> +
>>> +  // Traverse the given statement. If the most-derived traverse
>>> function takes a
>>> +  // data recursion queue, pass it on; otherwise, discard it. Note that
>>> the
>>> +  // first branch of this conditional must compile whether or not the
>>> derived
>>> +  // class can take a queue, so if we're taking the second arm, make
>>> the first
>>> +  // arm call our function rather than the derived class version.
>>>  #define TRAVERSE_STMT_BASE(NAME, CLASS, VAR, QUEUE)
>>> \
>>> -  (is_same_member_pointer>> \
>

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

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

I agree with Richard here.


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

r254672 - [Docs] Sanitizer docs migrated from code.google.com to github.com.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Thu Dec  3 18:38:13 2015
New Revision: 254672

URL: http://llvm.org/viewvc/llvm-project?rev=254672&view=rev
Log:
[Docs] Sanitizer docs migrated from code.google.com to github.com.

Modified:
cfe/trunk/docs/AddressSanitizer.rst
cfe/trunk/docs/LeakSanitizer.rst
cfe/trunk/docs/MemorySanitizer.rst
cfe/trunk/docs/ThreadSanitizer.rst

Modified: cfe/trunk/docs/AddressSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/AddressSanitizer.rst?rev=254672&r1=254671&r2=254672&view=diff
==
--- cfe/trunk/docs/AddressSanitizer.rst (original)
+++ cfe/trunk/docs/AddressSanitizer.rst Thu Dec  3 18:38:13 2015
@@ -267,5 +267,4 @@ check-asan`` command.
 More Information
 
 
-`http://code.google.com/p/address-sanitizer 
`_
-
+``_

Modified: cfe/trunk/docs/LeakSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LeakSanitizer.rst?rev=254672&r1=254671&r2=254672&view=diff
==
--- cfe/trunk/docs/LeakSanitizer.rst (original)
+++ cfe/trunk/docs/LeakSanitizer.rst Thu Dec  3 18:38:13 2015
@@ -28,6 +28,4 @@ There are plans to support LeakSanitizer
 More Information
 
 
-`https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer
-`_
-
+``_

Modified: cfe/trunk/docs/MemorySanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/MemorySanitizer.rst?rev=254672&r1=254671&r2=254672&view=diff
==
--- cfe/trunk/docs/MemorySanitizer.rst (original)
+++ cfe/trunk/docs/MemorySanitizer.rst Thu Dec  3 18:38:13 2015
@@ -197,5 +197,4 @@ real-world programs, like Clang/LLVM its
 More Information
 
 
-`http://code.google.com/p/memory-sanitizer 
`_
-
+``_

Modified: cfe/trunk/docs/ThreadSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ThreadSanitizer.rst?rev=254672&r1=254671&r2=254672&view=diff
==
--- cfe/trunk/docs/ThreadSanitizer.rst (original)
+++ cfe/trunk/docs/ThreadSanitizer.rst Thu Dec  3 18:38:13 2015
@@ -131,5 +131,4 @@ especially in the form of minimized stan
 
 More Information
 
-`http://code.google.com/p/thread-sanitizer 
`_.
-
+``_


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

r254733 - Clang documentation for UBSan.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Dec  4 11:30:29 2015
New Revision: 254733

URL: http://llvm.org/viewvc/llvm-project?rev=254733&view=rev
Log:
Clang documentation for UBSan.

Summary:
Create a separate page describing UBSan tool, move the description of
fine-grained checks there, provide extra information about supported
platforms, symbolization etc. This text is compiled from four parts:

* Existing documentation copied from User's Manual
* Layout used in documentation for another sanitizers (ASan, MSan etc.)
* Text written from scratch
* Small parts taken from Michael Morrison's attempt at creating UBSan
  page:
  http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20141215/249503.html

Reviewers: kcc, rsmith, silvas

Subscribers: tberghammer, danalbert, srhines, kcc

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

Added:
cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
Modified:
cfe/trunk/docs/UsersManual.rst
cfe/trunk/docs/index.rst

Added: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=254733&view=auto
==
--- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (added)
+++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Fri Dec  4 11:30:29 2015
@@ -0,0 +1,202 @@
+==
+UndefinedBehaviorSanitizer
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior detector.
+UBSan modifies the program at compile-time to catch various kinds of undefined
+behavior during program execution, for example:
+
+* Using misaligned or null pointer
+* Signed integer overflow
+* Conversion to, from, or between floating-point types which would
+  overflow the destination
+
+See the full list of available :ref:`checks ` below.
+
+UBSan has an optional run-time library which provides better error reporting.
+The checks have small runtime cost and no impact on address space layout or 
ABI.
+
+How to build
+
+
+Build LLVM/Clang with `CMake `_.
+
+Usage
+=
+
+Use ``clang++`` to compile and link your program with ``-fsanitize=undefined``
+flag. Make sure to use ``clang++`` (not ``ld``) as a linker, so that your
+executable is linked with proper UBSan runtime libraries. You can use ``clang``
+instead of ``clang++`` if you're compiling/linking C code.
+
+.. code-block:: console
+
+  % cat test.cc
+  int main(int argc, char **argv) {
+int k = 0x7fff;
+k += argc;
+return 0;
+  }
+  % clang++ -fsanitize=undefined test.cc
+  % ./a.out
+  test.cc:3:5: runtime error: signed integer overflow: 2147483647 + 1 cannot 
be represented in type 'int'
+
+You can enable only a subset of :ref:`checks ` offered by UBSan,
+and define the desired behavior for each kind of check:
+
+* print a verbose error report and continue execution (default);
+* print a verbose error report and exit the program;
+* execute a trap instruction (doesn't require UBSan run-time support).
+
+For example if you compile/link your program as:
+
+.. code-block:: console
+
+  % clang++ -fsanitize=signed-integer-overflow,null,alignment 
-fno-sanitize-recover=null -fsanitize-trap=alignment
+
+the program will continue execution after signed integer overflows, exit after
+the first invalid use of a null pointer, and trap after the first use of 
misaligned
+pointer.
+
+.. _ubsan-checks:
+
+Availablle checks
+=
+
+Available checks are:
+
+  -  ``-fsanitize=alignment``: Use of a misaligned pointer or creation
+ of a misaligned reference.
+  -  ``-fsanitize=bool``: Load of a ``bool`` value which is neither
+ ``true`` nor ``false``.
+  -  ``-fsanitize=bounds``: Out of bounds array indexing, in cases
+ where the array bound can be statically determined.
+  -  ``-fsanitize=enum``: Load of a value of an enumerated type which
+ is not in the range of representable values for that enumerated
+ type.
+  -  ``-fsanitize=float-cast-overflow``: Conversion to, from, or
+ between floating-point types which would overflow the
+ destination.
+  -  ``-fsanitize=float-divide-by-zero``: Floating point division by
+ zero.
+  -  ``-fsanitize=function``: Indirect call of a function through a
+ function pointer of the wrong type (Linux, C++ and x86/x86_64 only).
+  -  ``-fsanitize=integer-divide-by-zero``: Integer division by zero.
+  -  ``-fsanitize=nonnull-attribute``: Passing null pointer as a function
+ parameter which is declared to never be null.
+  -  ``-fsanitize=null``: Use of a null pointer or creation of a null
+ reference.
+  -  ``-fsanitize=object-size``: An attempt to use bytes which the
+ optimizer can determine are not part of the object being
+ accessed. The sizes of objects are determined using
+ ``__builtin_object_size``, and consequently may be able to detect
+ m

Re: [PATCH] D15217: Clang documentation for UBSan.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Thanks! Addressed the comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D15217



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

Re: [PATCH] D15217: Clang documentation for UBSan.

[Alexey Samsonov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
samsonov marked 5 inline comments as done.
Closed by commit rL254733: Clang documentation for UBSan. (authored by 
samsonov).

Changed prior to commit:
  http://reviews.llvm.org/D15217?vs=41823&id=41891#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15217

Files:
  cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
  cfe/trunk/docs/UsersManual.rst
  cfe/trunk/docs/index.rst

Index: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
===
--- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
+++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
@@ -0,0 +1,202 @@
+==
+UndefinedBehaviorSanitizer
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior detector.
+UBSan modifies the program at compile-time to catch various kinds of undefined
+behavior during program execution, for example:
+
+* Using misaligned or null pointer
+* Signed integer overflow
+* Conversion to, from, or between floating-point types which would
+  overflow the destination
+
+See the full list of available :ref:`checks ` below.
+
+UBSan has an optional run-time library which provides better error reporting.
+The checks have small runtime cost and no impact on address space layout or ABI.
+
+How to build
+
+
+Build LLVM/Clang with `CMake `_.
+
+Usage
+=
+
+Use ``clang++`` to compile and link your program with ``-fsanitize=undefined``
+flag. Make sure to use ``clang++`` (not ``ld``) as a linker, so that your
+executable is linked with proper UBSan runtime libraries. You can use ``clang``
+instead of ``clang++`` if you're compiling/linking C code.
+
+.. code-block:: console
+
+  % cat test.cc
+  int main(int argc, char **argv) {
+int k = 0x7fff;
+k += argc;
+return 0;
+  }
+  % clang++ -fsanitize=undefined test.cc
+  % ./a.out
+  test.cc:3:5: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
+
+You can enable only a subset of :ref:`checks ` offered by UBSan,
+and define the desired behavior for each kind of check:
+
+* print a verbose error report and continue execution (default);
+* print a verbose error report and exit the program;
+* execute a trap instruction (doesn't require UBSan run-time support).
+
+For example if you compile/link your program as:
+
+.. code-block:: console
+
+  % clang++ -fsanitize=signed-integer-overflow,null,alignment -fno-sanitize-recover=null -fsanitize-trap=alignment
+
+the program will continue execution after signed integer overflows, exit after
+the first invalid use of a null pointer, and trap after the first use of misaligned
+pointer.
+
+.. _ubsan-checks:
+
+Availablle checks
+=
+
+Available checks are:
+
+  -  ``-fsanitize=alignment``: Use of a misaligned pointer or creation
+ of a misaligned reference.
+  -  ``-fsanitize=bool``: Load of a ``bool`` value which is neither
+ ``true`` nor ``false``.
+  -  ``-fsanitize=bounds``: Out of bounds array indexing, in cases
+ where the array bound can be statically determined.
+  -  ``-fsanitize=enum``: Load of a value of an enumerated type which
+ is not in the range of representable values for that enumerated
+ type.
+  -  ``-fsanitize=float-cast-overflow``: Conversion to, from, or
+ between floating-point types which would overflow the
+ destination.
+  -  ``-fsanitize=float-divide-by-zero``: Floating point division by
+ zero.
+  -  ``-fsanitize=function``: Indirect call of a function through a
+ function pointer of the wrong type (Linux, C++ and x86/x86_64 only).
+  -  ``-fsanitize=integer-divide-by-zero``: Integer division by zero.
+  -  ``-fsanitize=nonnull-attribute``: Passing null pointer as a function
+ parameter which is declared to never be null.
+  -  ``-fsanitize=null``: Use of a null pointer or creation of a null
+ reference.
+  -  ``-fsanitize=object-size``: An attempt to use bytes which the
+ optimizer can determine are not part of the object being
+ accessed. The sizes of objects are determined using
+ ``__builtin_object_size``, and consequently may be able to detect
+ more problems at higher optimization levels.
+  -  ``-fsanitize=return``: In C++, reaching the end of a
+ value-returning function without returning a value.
+  -  ``-fsanitize=returns-nonnull-attribute``: Returning null pointer
+ from a function which is declared to never return null.
+  -  ``-fsanitize=shift``: Shift operators where the amount shifted is
+ greater or equal to the promoted bit-width of the left hand side
+ or less than zero, or where the left hand side is negative. For a
+ signed left shift, also checks for signed overflow in C, and for
+ unsigned overflow in C++. You can use ``-fsanitize=shift-base`` or
+ ``-fsanitiz

r254734 - [Docs] Remove false claim: UBSan can also be combined with TSan/MSan.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Dec  4 11:35:47 2015
New Revision: 254734

URL: http://llvm.org/viewvc/llvm-project?rev=254734&view=rev
Log:
[Docs] Remove false claim: UBSan can also be combined with TSan/MSan.

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=254734&r1=254733&r2=254734&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Fri Dec  4 11:35:47 2015
@@ -1031,8 +1031,7 @@ are listed below.
 
It is not possible to combine more than one of the ``-fsanitize=address``,
``-fsanitize=thread``, and ``-fsanitize=memory`` checkers in the same
-   program. The ``-fsanitize=undefined`` checks can only be combined with
-   ``-fsanitize=address``.
+   program.
 
 **-f[no-]sanitize-recover=check1,check2,...**
 


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

[PATCH] D15237: [Docs] Use proper headling levels in CFI doc.

[Alexey Samsonov via cfe-commits]

samsonov created this revision.
samsonov added reviewers: pcc, kcc.
samsonov added a subscriber: cfe-commits.

Before that, all sections were considered a subsection of
"Introduction".

[Docs] Move the list of CFI schemes down to CFI doc, and update it.

http://reviews.llvm.org/D15237

Files:
  docs/ControlFlowIntegrity.rst
  docs/UsersManual.rst

Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -974,19 +974,8 @@
 
There are more fine-grained checks available: see
the :ref:`list ` of specific kinds of
-   undefined behavior that can be detected. Checks for :doc:`ControlFlowIntegrity`
-   are:
-
-   -  ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks
-  `.
-   -  ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong
-  dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another
-  unrelated type to the wrong dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of
-  the wrong dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the
-  wrong dynamic type. Requires ``-flto``.
+   undefined behavior that can be detected and the :ref:`list `
+   of control flow integrity schemes.
 
You can turn off or modify checks for certain source files, functions
or even variables by providing a special file:
Index: docs/ControlFlowIntegrity.rst
===
--- docs/ControlFlowIntegrity.rst
+++ docs/ControlFlowIntegrity.rst
@@ -20,22 +20,49 @@
 allowing developers to enable them in release builds.
 
 To enable Clang's available CFI schemes, use the flag ``-fsanitize=cfi``.
-As currently implemented, all of Clang's CFI schemes (``cfi-vcall``,
-``cfi-derived-cast``, ``cfi-unrelated-cast``, ``cfi-nvcall``, ``cfi-icall``)
-rely on link-time optimization (LTO); so it is required to specify
-``-flto``, and the linker used must support LTO, for example via the `gold
-plugin`_. To allow the checks to be implemented efficiently, the program must
+You can enable only a subset of offered :ref:`schemes `.
+As currently implemented, all schemes rely on link-time optimization (LTO);
+so it is required to specify ``-flto``, and the linker used must support LTO,
+for example via the `gold plugin`_.
+To allow the checks to be implemented efficiently, the program must
 be structured such that certain object files are compiled with CFI enabled,
 and are statically linked into the program. This may preclude the use of
 shared libraries in some cases.
 
-Clang currently implements forward-edge CFI for member function calls and
-bad cast checking. More schemes are under development.
-
 .. _gold plugin: http://llvm.org/docs/GoldPlugin.html
 
+.. _cfi-schemes:
+
+Available schemes
+=
+
+Available schemes are:
+
+  -  ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks
+ `.
+  -  ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong
+ dynamic type.
+  -  ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another
+ unrelated type to the wrong dynamic type.
+  -  ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of
+ the wrong dynamic type.
+  -  ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the
+ wrong dynamic type.
+  -  ``-fsanitize=cfi-icall``: Indirect call of a function with wrong dynamic
+ type.
+
+You can use ``-fsanitize=cfi`` to enable all the schemes and use
+``-fno-sanitize`` flag to narrow down the set of schemes as desired.
+For example, you can build your program with
+``-fsanitize=cfi -fno-sanitize=cfi-nvcall``
+to use all schemes except for non-virtual member function call checking.
+
+Remember that you have to provide ``-flto`` if at least one CFI scheme is
+enabled.
+
+
 Forward-Edge CFI for Virtual Calls
---
+==
 
 This scheme checks that virtual calls take place using a vptr of the correct
 dynamic type; that is, the dynamic type of the called object must be a
@@ -59,7 +86,7 @@
 of up to 15% has been observed for Chromium.
 
 Bad Cast Checking
--
+=
 
 This scheme checks that pointer casts are made to an object of the correct
 dynamic type; that is, the dynamic type of the object must be a derived class
@@ -94,7 +121,7 @@
 and be statically linked into the program.
 
 Non-Virtual Member Function Call Checking
--
+=
 
 This scheme checks that non-virtual calls take place using an object of
 the correct dynamic type; that is, the dynamic type of the called object
@@ -126,7 +153,7 @@
 default. It can be disabled with ``-fsanitize=cfi-cast-strict``.
 
 Indirect Func

Re: [PATCH] D15237: [Docs] Use proper headling levels in CFI doc.

[Alexey Samsonov via cfe-commits]

samsonov updated this revision to Diff 41905.
samsonov marked 3 inline comments as done.
samsonov added a comment.

- Address pcc's comments.


http://reviews.llvm.org/D15237

Files:
  docs/ControlFlowIntegrity.rst
  docs/UsersManual.rst

Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -974,19 +974,8 @@
 
There are more fine-grained checks available: see
the :ref:`list ` of specific kinds of
-   undefined behavior that can be detected. Checks for :doc:`ControlFlowIntegrity`
-   are:
-
-   -  ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks
-  `.
-   -  ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong
-  dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another
-  unrelated type to the wrong dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of
-  the wrong dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the
-  wrong dynamic type. Requires ``-flto``.
+   undefined behavior that can be detected and the :ref:`list `
+   of control flow integrity schemes.
 
You can turn off or modify checks for certain source files, functions
or even variables by providing a special file:
Index: docs/ControlFlowIntegrity.rst
===
--- docs/ControlFlowIntegrity.rst
+++ docs/ControlFlowIntegrity.rst
@@ -20,22 +20,50 @@
 allowing developers to enable them in release builds.
 
 To enable Clang's available CFI schemes, use the flag ``-fsanitize=cfi``.
-As currently implemented, all of Clang's CFI schemes (``cfi-vcall``,
-``cfi-derived-cast``, ``cfi-unrelated-cast``, ``cfi-nvcall``, ``cfi-icall``)
-rely on link-time optimization (LTO); so it is required to specify
-``-flto``, and the linker used must support LTO, for example via the `gold
-plugin`_. To allow the checks to be implemented efficiently, the program must
+You can also enable a subset of available :ref:`schemes `.
+As currently implemented, all schemes rely on link-time optimization (LTO);
+so it is required to specify ``-flto``, and the linker used must support LTO,
+for example via the `gold plugin`_.
+To allow the checks to be implemented efficiently, the program must
 be structured such that certain object files are compiled with CFI enabled,
 and are statically linked into the program. This may preclude the use of
 shared libraries in some cases.
 
-Clang currently implements forward-edge CFI for member function calls and
-bad cast checking. More schemes are under development.
-
 .. _gold plugin: http://llvm.org/docs/GoldPlugin.html
 
+.. _cfi-schemes:
+
+Available schemes
+=
+
+Available schemes are:
+
+  -  ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks
+ `.
+  -  ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong
+ dynamic type.
+  -  ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another
+ unrelated type to the wrong dynamic type.
+  -  ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of
+ the wrong dynamic type.
+  -  ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the
+ wrong dynamic type.
+  -  ``-fsanitize=cfi-icall``: Indirect call of a function with wrong dynamic
+ type.
+
+You can use ``-fsanitize=cfi`` to enable all the schemes and use
+``-fno-sanitize`` flag to narrow down the set of schemes as desired.
+For example, you can build your program with
+``-fsanitize=cfi -fno-sanitize=cfi-nvcall,cfi-icall``
+to use all schemes except for non-virtual member function call and indirect call
+checking.
+
+Remember that you have to provide ``-flto`` if at least one CFI scheme is
+enabled.
+
+
 Forward-Edge CFI for Virtual Calls
---
+==
 
 This scheme checks that virtual calls take place using a vptr of the correct
 dynamic type; that is, the dynamic type of the called object must be a
@@ -48,7 +76,7 @@
 ``-fsanitize=cfi-vcall`` enabled and be statically linked into the program.
 
 Performance
-~~~
+---
 
 A performance overhead of less than 1% has been measured by running the
 Dromaeo benchmark suite against an instrumented version of the Chromium
@@ -59,7 +87,7 @@
 of up to 15% has been observed for Chromium.
 
 Bad Cast Checking
--
+=
 
 This scheme checks that pointer casts are made to an object of the correct
 dynamic type; that is, the dynamic type of the object must be a derived class
@@ -94,7 +122,7 @@
 and be statically linked into the program.
 
 Non-Virtual Member Function Call Checking
--
+=
 
 This scheme checks that non-virtual calls ta

Re: [PATCH] D15237: [Docs] Use proper headling levels in CFI doc.

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: docs/ControlFlowIntegrity.rst:23
@@ -22,6 +22,3 @@
 To enable Clang's available CFI schemes, use the flag ``-fsanitize=cfi``.
-As currently implemented, all of Clang's CFI schemes (``cfi-vcall``,
-``cfi-derived-cast``, ``cfi-unrelated-cast``, ``cfi-nvcall``, ``cfi-icall``)
-rely on link-time optimization (LTO); so it is required to specify
-``-flto``, and the linker used must support LTO, for example via the `gold
-plugin`_. To allow the checks to be implemented efficiently, the program must
+You can enable only a subset of offered :ref:`schemes `.
+As currently implemented, all schemes rely on link-time optimization (LTO);

pcc wrote:
> This sentence was a little confusing, as it implies that only a subset of 
> schemes are supported. Maybe "You can also enable a subset of available 
> schemes by following [these instructions]."
Fixed. Let me know if you want instructions to be more verbose.


http://reviews.llvm.org/D15237



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

r254771 - [Docs] Move the list of CFI schemes down to CFI doc, and update it.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Dec  4 15:30:58 2015
New Revision: 254771

URL: http://llvm.org/viewvc/llvm-project?rev=254771&view=rev
Log:
[Docs] Move the list of CFI schemes down to CFI doc, and update it.

Use proper headling levels in CFI doc. Before that, all sections
were considered a subsection of "Introduction".

Reviewers: pcc, kcc

Subscribers: cfe-commits

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

Modified:
cfe/trunk/docs/ControlFlowIntegrity.rst
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/ControlFlowIntegrity.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrity.rst?rev=254771&r1=254770&r2=254771&view=diff
==
--- cfe/trunk/docs/ControlFlowIntegrity.rst (original)
+++ cfe/trunk/docs/ControlFlowIntegrity.rst Fri Dec  4 15:30:58 2015
@@ -20,22 +20,50 @@ program's control flow. These schemes ha
 allowing developers to enable them in release builds.
 
 To enable Clang's available CFI schemes, use the flag ``-fsanitize=cfi``.
-As currently implemented, all of Clang's CFI schemes (``cfi-vcall``,
-``cfi-derived-cast``, ``cfi-unrelated-cast``, ``cfi-nvcall``, ``cfi-icall``)
-rely on link-time optimization (LTO); so it is required to specify
-``-flto``, and the linker used must support LTO, for example via the `gold
-plugin`_. To allow the checks to be implemented efficiently, the program must
+You can also enable a subset of available :ref:`schemes `.
+As currently implemented, all schemes rely on link-time optimization (LTO);
+so it is required to specify ``-flto``, and the linker used must support LTO,
+for example via the `gold plugin`_.
+To allow the checks to be implemented efficiently, the program must
 be structured such that certain object files are compiled with CFI enabled,
 and are statically linked into the program. This may preclude the use of
 shared libraries in some cases.
 
-Clang currently implements forward-edge CFI for member function calls and
-bad cast checking. More schemes are under development.
-
 .. _gold plugin: http://llvm.org/docs/GoldPlugin.html
 
+.. _cfi-schemes:
+
+Available schemes
+=
+
+Available schemes are:
+
+  -  ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks
+ `.
+  -  ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong
+ dynamic type.
+  -  ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another
+ unrelated type to the wrong dynamic type.
+  -  ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of
+ the wrong dynamic type.
+  -  ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the
+ wrong dynamic type.
+  -  ``-fsanitize=cfi-icall``: Indirect call of a function with wrong dynamic
+ type.
+
+You can use ``-fsanitize=cfi`` to enable all the schemes and use
+``-fno-sanitize`` flag to narrow down the set of schemes as desired.
+For example, you can build your program with
+``-fsanitize=cfi -fno-sanitize=cfi-nvcall,cfi-icall``
+to use all schemes except for non-virtual member function call and indirect 
call
+checking.
+
+Remember that you have to provide ``-flto`` if at least one CFI scheme is
+enabled.
+
+
 Forward-Edge CFI for Virtual Calls
---
+==
 
 This scheme checks that virtual calls take place using a vptr of the correct
 dynamic type; that is, the dynamic type of the called object must be a
@@ -48,7 +76,7 @@ of :ref:`blacklisted ` ty
 ``-fsanitize=cfi-vcall`` enabled and be statically linked into the program.
 
 Performance
-~~~
+---
 
 A performance overhead of less than 1% has been measured by running the
 Dromaeo benchmark suite against an instrumented version of the Chromium
@@ -59,7 +87,7 @@ Note that this scheme has not yet been o
 of up to 15% has been observed for Chromium.
 
 Bad Cast Checking
--
+=
 
 This scheme checks that pointer casts are made to an object of the correct
 dynamic type; that is, the dynamic type of the object must be a derived class
@@ -94,7 +122,7 @@ of :ref:`blacklisted ` ty
 and be statically linked into the program.
 
 Non-Virtual Member Function Call Checking
--
+=
 
 This scheme checks that non-virtual calls take place using an object of
 the correct dynamic type; that is, the dynamic type of the called object
@@ -111,7 +139,7 @@ of :ref:`blacklisted ` ty
 .. _cfi-strictness:
 
 Strictness
-~~
+--
 
 If a class has a single non-virtual base and does not introduce or override
 virtual member functions or fields other than an implicitly defined virtual
@@ -126,7 +154,7 @@ most compilers and should not have secur
 default. It can be disabled with ``-fsanitize=cfi-cast-strict``.
 
 Indirect Function Call Checking

+==

Re: [PATCH] D15237: [Docs] Use proper headling levels in CFI doc.

[Alexey Samsonov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL254771: [Docs] Move the list of CFI schemes down to CFI doc, 
and update it. (authored by samsonov).

Changed prior to commit:
  http://reviews.llvm.org/D15237?vs=41905&id=41933#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15237

Files:
  cfe/trunk/docs/ControlFlowIntegrity.rst
  cfe/trunk/docs/UsersManual.rst

Index: cfe/trunk/docs/UsersManual.rst
===
--- cfe/trunk/docs/UsersManual.rst
+++ cfe/trunk/docs/UsersManual.rst
@@ -974,19 +974,8 @@
 
There are more fine-grained checks available: see
the :ref:`list ` of specific kinds of
-   undefined behavior that can be detected. Checks for :doc:`ControlFlowIntegrity`
-   are:
-
-   -  ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks
-  `.
-   -  ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong
-  dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another
-  unrelated type to the wrong dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of
-  the wrong dynamic type. Requires ``-flto``.
-   -  ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the
-  wrong dynamic type. Requires ``-flto``.
+   undefined behavior that can be detected and the :ref:`list `
+   of control flow integrity schemes.
 
You can turn off or modify checks for certain source files, functions
or even variables by providing a special file:
Index: cfe/trunk/docs/ControlFlowIntegrity.rst
===
--- cfe/trunk/docs/ControlFlowIntegrity.rst
+++ cfe/trunk/docs/ControlFlowIntegrity.rst
@@ -20,22 +20,50 @@
 allowing developers to enable them in release builds.
 
 To enable Clang's available CFI schemes, use the flag ``-fsanitize=cfi``.
-As currently implemented, all of Clang's CFI schemes (``cfi-vcall``,
-``cfi-derived-cast``, ``cfi-unrelated-cast``, ``cfi-nvcall``, ``cfi-icall``)
-rely on link-time optimization (LTO); so it is required to specify
-``-flto``, and the linker used must support LTO, for example via the `gold
-plugin`_. To allow the checks to be implemented efficiently, the program must
+You can also enable a subset of available :ref:`schemes `.
+As currently implemented, all schemes rely on link-time optimization (LTO);
+so it is required to specify ``-flto``, and the linker used must support LTO,
+for example via the `gold plugin`_.
+To allow the checks to be implemented efficiently, the program must
 be structured such that certain object files are compiled with CFI enabled,
 and are statically linked into the program. This may preclude the use of
 shared libraries in some cases.
 
-Clang currently implements forward-edge CFI for member function calls and
-bad cast checking. More schemes are under development.
-
 .. _gold plugin: http://llvm.org/docs/GoldPlugin.html
 
+.. _cfi-schemes:
+
+Available schemes
+=
+
+Available schemes are:
+
+  -  ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks
+ `.
+  -  ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong
+ dynamic type.
+  -  ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another
+ unrelated type to the wrong dynamic type.
+  -  ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of
+ the wrong dynamic type.
+  -  ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the
+ wrong dynamic type.
+  -  ``-fsanitize=cfi-icall``: Indirect call of a function with wrong dynamic
+ type.
+
+You can use ``-fsanitize=cfi`` to enable all the schemes and use
+``-fno-sanitize`` flag to narrow down the set of schemes as desired.
+For example, you can build your program with
+``-fsanitize=cfi -fno-sanitize=cfi-nvcall,cfi-icall``
+to use all schemes except for non-virtual member function call and indirect call
+checking.
+
+Remember that you have to provide ``-flto`` if at least one CFI scheme is
+enabled.
+
+
 Forward-Edge CFI for Virtual Calls
---
+==
 
 This scheme checks that virtual calls take place using a vptr of the correct
 dynamic type; that is, the dynamic type of the called object must be a
@@ -48,7 +76,7 @@
 ``-fsanitize=cfi-vcall`` enabled and be statically linked into the program.
 
 Performance
-~~~
+---
 
 A performance overhead of less than 1% has been measured by running the
 Dromaeo benchmark suite against an instrumented version of the Chromium
@@ -59,7 +87,7 @@
 of up to 15% has been observed for Chromium.
 
 Bad Cast Checking
--
+=
 
 This scheme checks that pointer casts are made to an object of the correct
 dynamic type; that is, the dynamic type of the object must be a derived class
@@ -94

[PATCH] D15246: [Docs] Update MSan docs

[Alexey Samsonov via cfe-commits]

samsonov created this revision.
samsonov added reviewers: eugenis, kcc.
samsonov added a subscriber: cfe-commits.

1. Move MSan-specific flags and features from user manual to MSan page.
2. Update current status / list of supported platforms.

http://reviews.llvm.org/D15246

Files:
  docs/MemorySanitizer.rst
  docs/UsersManual.rst

Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -958,8 +958,8 @@
-  .. _opt_fsanitize_memory:
 
   ``-fsanitize=memory``: :doc:`MemorySanitizer`,
-  an *experimental* detector of uninitialized reads. Not ready for
-  widespread use.
+  a detector of uninitialized reads. Requires instrumentation of all
+  program code.
-  .. _opt_fsanitize_undefined:
 
   ``-fsanitize=undefined``: :doc:`UndefinedBehaviorSanitizer`,
@@ -986,31 +986,6 @@
-  ``-fno-sanitize-blacklist``: don't use blacklist file, if it was
   specified earlier in the command line.
 
-   Extra features of MemorySanitizer (require explicit
-   ``-fsanitize=memory``):
-
-   -  ``-fsanitize-memory-track-origins[=level]``: Enables origin tracking in
-  MemorySanitizer. Adds a second section to MemorySanitizer
-  reports pointing to the heap or stack allocation the
-  uninitialized bits came from. Slows down execution by additional
-  1.5x-2x.
-
-  Possible values for level are 0 (off), 1, 2 (default). Level 2
-  adds more sections to MemorySanitizer reports describing the
-  order of memory stores the uninitialized value went
-  through. This mode may use extra memory in programs that copy
-  uninitialized memory a lot.
-   -  ``-fsanitize-memory-use-after-dtor``: Enables use-after-destruction
-  detection in MemorySanitizer. After invocation of the destructor,
-  the object is considered no longer readable. Facilitates the
-  detection of use-after-destroy bugs.
-
-  Setting the MSAN_OPTIONS=poison_in_dtor=1 enables the poisoning of
-  memory at runtime. Any subsequent access to the destroyed object
-  fails at runtime. This feature is still experimental, but this
-  environment variable must be set to 1 in order for the above flag
-  to have any effect.
-
The ``-fsanitize=`` argument must also be provided when linking, in
order to link to the appropriate runtime library. When using
``-fsanitize=vptr`` (or a group that includes it, such as
Index: docs/MemorySanitizer.rst
===
--- docs/MemorySanitizer.rst
+++ docs/MemorySanitizer.rst
@@ -48,19 +48,18 @@
 % clang -fsanitize=memory -fno-omit-frame-pointer -g -O2 umr.cc
 
 If a bug is detected, the program will print an error message to
-stderr and exit with a non-zero exit code. Currently, MemorySanitizer
-does not symbolize its output by default, so you may need to use a
-separate script to symbolize the result offline (this will be fixed in
-future).
+stderr and exit with a non-zero exit code.
 
 .. code-block:: console
 
 % ./a.out
 WARNING: MemorySanitizer: use-of-uninitialized-value
 #0 0x7f45944b418a in main umr.cc:6
 #1 0x7f45938b676c in __libc_start_main libc-start.c:226
 
-By default, MemorySanitizer exits on the first detected error.
+By default, MemorySanitizer exits on the first detected error. If you
+find the error report hard to understand, try enabling
+:ref:`origin tracking `.
 
 ``__has_feature(memory_sanitizer)``
 
@@ -102,6 +101,8 @@
 reports. Make sure that ``llvm-symbolizer`` binary is in ``PATH``,
 or set environment variable ``MSAN_SYMBOLIZER_PATH`` to point to it.
 
+.. _msan-origins:
+
 Origin Tracking
 ===
 
@@ -143,14 +144,29 @@
 intermediate stores the uninitialized value went through.  Origin
 tracking has proved to be very useful for debugging MemorySanitizer
 reports. It slows down program execution by a factor of 1.5x-2x on top
-of the usual MemorySanitizer slowdown.
+of the usual MemorySanitizer slowdown and increases memory overhead.
 
-Clang option ``-fsanitize-memory-track-origins=1`` enabled a slightly
+Clang option ``-fsanitize-memory-track-origins=1`` enables a slightly
 faster mode when MemorySanitizer collects only allocation points but
 not intermediate stores.
 
+Use-after-destruction detection
+===
+
+You can enable experimental use-after-destruction detection in MemorySanitizer.
+After invocation of the destructor, the object will be considered no longer
+readable, and using underlying memory will lead to error reports in runtime.
+
+This feature is still experimental, in order to enable it at runtime you need
+to:
+
+#. Pass addition Clang option ``-fsanitize-memory-use-after-dtor`` during
+   compilation.
+#. Set environment variable `MSAN_OPTIONS=poison_in_dtor=1` before running
+   the program.
+
 Handling external code
-===

Re: [PATCH] D15246: [Docs] Update MSan docs

[Alexey Samsonov via cfe-commits]

samsonov marked 2 inline comments as done.
samsonov added a comment.

Addressed, thanks!


http://reviews.llvm.org/D15246



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

r254788 - [Docs] Update MSan docs

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Dec  4 16:50:44 2015
New Revision: 254788

URL: http://llvm.org/viewvc/llvm-project?rev=254788&view=rev
Log:
[Docs] Update MSan docs

Summary:
1. Move MSan-specific flags and features from user manual to MSan page.
2. Update current status / list of supported platforms.

Reviewers: eugenis, kcc

Subscribers: cfe-commits

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

Modified:
cfe/trunk/docs/MemorySanitizer.rst
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/MemorySanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/MemorySanitizer.rst?rev=254788&r1=254787&r2=254788&view=diff
==
--- cfe/trunk/docs/MemorySanitizer.rst (original)
+++ cfe/trunk/docs/MemorySanitizer.rst Fri Dec  4 16:50:44 2015
@@ -48,10 +48,7 @@ to disable inlining (just use ``-O1``) a
 % clang -fsanitize=memory -fno-omit-frame-pointer -g -O2 umr.cc
 
 If a bug is detected, the program will print an error message to
-stderr and exit with a non-zero exit code. Currently, MemorySanitizer
-does not symbolize its output by default, so you may need to use a
-separate script to symbolize the result offline (this will be fixed in
-future).
+stderr and exit with a non-zero exit code.
 
 .. code-block:: console
 
@@ -60,7 +57,9 @@ future).
 #0 0x7f45944b418a in main umr.cc:6
 #1 0x7f45938b676c in __libc_start_main libc-start.c:226
 
-By default, MemorySanitizer exits on the first detected error.
+By default, MemorySanitizer exits on the first detected error. If you
+find the error report hard to understand, try enabling
+:ref:`origin tracking `.
 
 ``__has_feature(memory_sanitizer)``
 
@@ -102,10 +101,12 @@ MemorySanitizer uses an external symboli
 reports. Make sure that ``llvm-symbolizer`` binary is in ``PATH``,
 or set environment variable ``MSAN_SYMBOLIZER_PATH`` to point to it.
 
+.. _msan-origins:
+
 Origin Tracking
 ===
 
-MemorySanitizer can track origins of unitialized values, similar to
+MemorySanitizer can track origins of uninitialized values, similar to
 Valgrind's --track-origins option. This feature is enabled by
 ``-fsanitize-memory-track-origins=2`` (or simply
 ``-fsanitize-memory-track-origins``) Clang option. With the code from
@@ -143,14 +144,29 @@ By default, MemorySanitizer collects bot
 intermediate stores the uninitialized value went through.  Origin
 tracking has proved to be very useful for debugging MemorySanitizer
 reports. It slows down program execution by a factor of 1.5x-2x on top
-of the usual MemorySanitizer slowdown.
+of the usual MemorySanitizer slowdown and increases memory overhead.
 
-Clang option ``-fsanitize-memory-track-origins=1`` enabled a slightly
+Clang option ``-fsanitize-memory-track-origins=1`` enables a slightly
 faster mode when MemorySanitizer collects only allocation points but
 not intermediate stores.
 
+Use-after-destruction detection
+===
+
+You can enable experimental use-after-destruction detection in MemorySanitizer.
+After invocation of the destructor, the object will be considered no longer
+readable, and using underlying memory will lead to error reports in runtime.
+
+This feature is still experimental, in order to enable it at runtime you need
+to:
+
+#. Pass addition Clang option ``-fsanitize-memory-use-after-dtor`` during
+   compilation.
+#. Set environment variable `MSAN_OPTIONS=poison_in_dtor=1` before running
+   the program.
+
 Handling external code
-
+==
 
 MemorySanitizer requires that all program code is instrumented. This
 also includes any libraries that the program depends on, even libc.
@@ -167,9 +183,7 @@ self-built instrumented libc++ (as a rep
 Supported Platforms
 ===
 
-MemorySanitizer is supported on
-
-* Linux x86\_64 (tested on Ubuntu 12.04);
+MemorySanitizer is supported on Linux x86\_64/MIPS64/AArch64.
 
 Limitations
 ===
@@ -180,19 +194,17 @@ Limitations
   address space. This means that tools like ``ulimit`` may not work as
   usually expected.
 * Static linking is not supported.
-* Non-position-independent executables are not supported.  Therefore, the
-  ``fsanitize=memory`` flag will cause Clang to act as though the ``-fPIE``
-  flag had been supplied if compiling without ``-fPIC``, and as though the
-  ``-pie`` flag had been supplied if linking an executable.
-* Depending on the version of Linux kernel, running without ASLR may
-  be not supported. Note that GDB disables ASLR by default. To debug
-  instrumented programs, use "set disable-randomization off".
+* Older versions of MSan (LLVM 3.7 and older) didn't work with
+  non-position-independent executables, and could fail on some Linux
+  kernel versions with disabled ASLR. Refer to documentation for older versions
+  for more details.
 
 Current Status
 ==
 
-MemorySanitizer is an e

Re: [PATCH] D15246: [Docs] Update MSan docs

[Alexey Samsonov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL254788: [Docs] Update MSan docs (authored by samsonov).

Changed prior to commit:
  http://reviews.llvm.org/D15246?vs=41941&id=41946#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15246

Files:
  cfe/trunk/docs/MemorySanitizer.rst
  cfe/trunk/docs/UsersManual.rst

Index: cfe/trunk/docs/MemorySanitizer.rst
===
--- cfe/trunk/docs/MemorySanitizer.rst
+++ cfe/trunk/docs/MemorySanitizer.rst
@@ -48,19 +48,18 @@
 % clang -fsanitize=memory -fno-omit-frame-pointer -g -O2 umr.cc
 
 If a bug is detected, the program will print an error message to
-stderr and exit with a non-zero exit code. Currently, MemorySanitizer
-does not symbolize its output by default, so you may need to use a
-separate script to symbolize the result offline (this will be fixed in
-future).
+stderr and exit with a non-zero exit code.
 
 .. code-block:: console
 
 % ./a.out
 WARNING: MemorySanitizer: use-of-uninitialized-value
 #0 0x7f45944b418a in main umr.cc:6
 #1 0x7f45938b676c in __libc_start_main libc-start.c:226
 
-By default, MemorySanitizer exits on the first detected error.
+By default, MemorySanitizer exits on the first detected error. If you
+find the error report hard to understand, try enabling
+:ref:`origin tracking `.
 
 ``__has_feature(memory_sanitizer)``
 
@@ -102,10 +101,12 @@
 reports. Make sure that ``llvm-symbolizer`` binary is in ``PATH``,
 or set environment variable ``MSAN_SYMBOLIZER_PATH`` to point to it.
 
+.. _msan-origins:
+
 Origin Tracking
 ===
 
-MemorySanitizer can track origins of unitialized values, similar to
+MemorySanitizer can track origins of uninitialized values, similar to
 Valgrind's --track-origins option. This feature is enabled by
 ``-fsanitize-memory-track-origins=2`` (or simply
 ``-fsanitize-memory-track-origins``) Clang option. With the code from
@@ -143,14 +144,29 @@
 intermediate stores the uninitialized value went through.  Origin
 tracking has proved to be very useful for debugging MemorySanitizer
 reports. It slows down program execution by a factor of 1.5x-2x on top
-of the usual MemorySanitizer slowdown.
+of the usual MemorySanitizer slowdown and increases memory overhead.
 
-Clang option ``-fsanitize-memory-track-origins=1`` enabled a slightly
+Clang option ``-fsanitize-memory-track-origins=1`` enables a slightly
 faster mode when MemorySanitizer collects only allocation points but
 not intermediate stores.
 
+Use-after-destruction detection
+===
+
+You can enable experimental use-after-destruction detection in MemorySanitizer.
+After invocation of the destructor, the object will be considered no longer
+readable, and using underlying memory will lead to error reports in runtime.
+
+This feature is still experimental, in order to enable it at runtime you need
+to:
+
+#. Pass addition Clang option ``-fsanitize-memory-use-after-dtor`` during
+   compilation.
+#. Set environment variable `MSAN_OPTIONS=poison_in_dtor=1` before running
+   the program.
+
 Handling external code
-
+==
 
 MemorySanitizer requires that all program code is instrumented. This
 also includes any libraries that the program depends on, even libc.
@@ -167,9 +183,7 @@
 Supported Platforms
 ===
 
-MemorySanitizer is supported on
-
-* Linux x86\_64 (tested on Ubuntu 12.04);
+MemorySanitizer is supported on Linux x86\_64/MIPS64/AArch64.
 
 Limitations
 ===
@@ -180,19 +194,17 @@
   address space. This means that tools like ``ulimit`` may not work as
   usually expected.
 * Static linking is not supported.
-* Non-position-independent executables are not supported.  Therefore, the
-  ``fsanitize=memory`` flag will cause Clang to act as though the ``-fPIE``
-  flag had been supplied if compiling without ``-fPIC``, and as though the
-  ``-pie`` flag had been supplied if linking an executable.
-* Depending on the version of Linux kernel, running without ASLR may
-  be not supported. Note that GDB disables ASLR by default. To debug
-  instrumented programs, use "set disable-randomization off".
+* Older versions of MSan (LLVM 3.7 and older) didn't work with
+  non-position-independent executables, and could fail on some Linux
+  kernel versions with disabled ASLR. Refer to documentation for older versions
+  for more details.
 
 Current Status
 ==
 
-MemorySanitizer is an experimental tool. It is known to work on large
-real-world programs, like Clang/LLVM itself.
+MemorySanitizer is known to work on large real-world programs
+(like Clang/LLVM itself) that can be recompiled from source, including all
+dependent libraries.
 
 More Information
 
Index: cfe/trunk/docs/UsersManual.rst
===
--- cfe/trunk/docs/UsersM

r254798 - [Docs] One more cleanup of -fsanitize= section.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Fri Dec  4 17:13:14 2015
New Revision: 254798

URL: http://llvm.org/viewvc/llvm-project?rev=254798&view=rev
Log:
[Docs] One more cleanup of -fsanitize= section.

Describe -fsanitize-blacklist flags in separate paragraphs, move
notes about importance of clang++ for vptr down to UBSan docs.

Modified:
cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=254798&r1=254797&r2=254798&view=diff
==
--- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (original)
+++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Fri Dec  4 17:13:14 2015
@@ -119,7 +119,9 @@ Available checks are:
  does not evaluate to a positive value.
   -  ``-fsanitize=vptr``: Use of an object whose vptr indicates that
  it is of the wrong dynamic type, or that its lifetime has not
- begun or has ended. Incompatible with ``-fno-rtti``.
+ begun or has ended. Incompatible with ``-fno-rtti``. Link must
+ be performed by ``clang++``, not ``clang``, to make sure C++-specific
+ parts of the runtime library and C++ standard libraries are present.
 
 You can also use the following check groups:
   -  ``-fsanitize=undefined``: All of the checks listed above other than

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=254798&r1=254797&r2=254798&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Fri Dec  4 17:13:14 2015
@@ -977,21 +977,8 @@ are listed below.
undefined behavior that can be detected and the :ref:`list `
of control flow integrity schemes.
 
-   You can turn off or modify checks for certain source files, functions
-   or even variables by providing a special file:
-
-   -  ``-fsanitize-blacklist=/path/to/blacklist/file``: disable or modify
-  sanitizer checks for objects listed in the file. See
-  :doc:`SanitizerSpecialCaseList` for file format description.
-   -  ``-fno-sanitize-blacklist``: don't use blacklist file, if it was
-  specified earlier in the command line.
-
The ``-fsanitize=`` argument must also be provided when linking, in
-   order to link to the appropriate runtime library. When using
-   ``-fsanitize=vptr`` (or a group that includes it, such as
-   ``-fsanitize=undefined``) with a C++ program, the link must be
-   performed by ``clang++``, not ``clang``, in order to link against the
-   C++-specific parts of the runtime library.
+   order to link to the appropriate runtime library.
 
It is not possible to combine more than one of the ``-fsanitize=address``,
``-fsanitize=thread``, and ``-fsanitize=memory`` checkers in the same
@@ -1028,14 +1015,24 @@ are listed below.
be used (for instance, when building libc or a kernel module), or where
the binary size increase caused by the sanitizer runtime is a concern.
 
-   This flag is only compatible with ``local-bounds``,
-   ``unsigned-integer-overflow``, sanitizers in the ``cfi`` group and
-   sanitizers in the ``undefined`` group other than ``vptr``. If this flag
+   This flag is only compatible with :doc:`control flow integrity
+   ` schemes and :doc:`UndefinedBehaviorSanitizer`
+   checks other than ``vptr``. If this flag
is supplied together with ``-fsanitize=undefined``, the ``vptr`` sanitizer
will be implicitly disabled.
 
This flag is enabled by default for sanitizers in the ``cfi`` group.
 
+.. option:: -fsanitize-blacklist=/path/to/blacklist/file
+
+   Disable or modify sanitizer checks for objects (source files, functions,
+   variables, types) listed in the file. See
+   :doc:`SanitizerSpecialCaseList` for file format description.
+
+.. option:: -fno-sanitize-blacklist
+
+   Don't use blacklist file, if it was specified earlier in the command line.
+
 **-f[no-]sanitize-coverage=[type,features,...]**
 
Enable simple code coverage in addition to certain sanitizers.


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

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: include/clang/Driver/ToolChain.h:410
@@ -407,1 +409,3 @@
+  /// (don't require runtime library).
+  virtual SanitizerMask getSanitizersRequiringTrap() const;
 };

I don't think this is relevant to ToolChain at all. `SanitizerArgs` has 
`TrappingSupported` mask, which is what you should need: if you don't have 
runtimes for all sanitizers you're enabling, and *some* of these sanitizers 
support trapping, driver may advise to use this flag.


Comment at: lib/Driver/ToolChains.cpp:360
@@ +359,3 @@
+  StringRef OS = "";
+  if (isTargetMacOS()) OS = "osx";
+  if (isTargetWatchOSSimulator()) OS = "watchossim";

Can we teach ToolChain (or at least Darwin toolchain) to return us OS name 
instead?


Comment at: lib/Driver/ToolChains.cpp:369
@@ +368,3 @@
+
+  return (Twine("libclang_rt.") + Sanitizer + "_" + OS + "_dynamic.dylib")
+  .str();

Oh no, please don't return a `StringRef` which points to temporary.


Comment at: test/Driver/fsanitize.c:14
@@ +13,3 @@
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN1
+// CHECK-UNDEFINED-DARWIN1: error: '-fsanitize-trap=undefined' required with 
'-fsanitize=undefined' option
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir_darwin_sanitizers -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN2

I find this diagnostic misleading :-/ It's not the case that 
`-fsanitize=undefined` *requires* you to additionally provide 
`-fsanitize-trap=undefined`. It requires having a UBSan runtime library 
available. Or, if you can't provide it (it's not available on your system), you 
can workaround this by using `-fsanitize-trap`. The latter should be a 
suggestion, really.


Comment at: test/Driver/fsanitize.c:33
@@ -30,3 +32,3 @@
 
-// RUN: %clang -fsanitize=bounds -### -fsyntax-only %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-BOUNDS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=bounds -### -fsyntax-only 
%s 2>&1 | FileCheck %s --check-prefix=CHECK-BOUNDS
 // CHECK-BOUNDS: "-fsanitize={{((array-bounds|local-bounds),?){2}"}}

Nice catch, please commit this fix as a separate change.


Comment at: test/Driver/fsanitize.c:214
@@ -205,3 +213,3 @@
 
-// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=memory %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-MSAN-DARWIN
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=memory %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-MSAN-DARWIN
 // CHECK-MSAN-DARWIN: unsupported option '-fsanitize=memory' for target 
'x86_64-apple-darwin10'

Why not resource_dir_darwin_sanitizers here and below?


Comment at: test/Driver/fsanitize.c:221
@@ +220,3 @@
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=memory -fsanitize=thread,memory 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-TSAN-MSAN-DARWIN1
+// CHECK-MSAN-TSAN-MSAN-DARWIN1: unsupported option '-fsanitize=thread,memory' 
for target 'x86_64-apple-darwin10'
+// CHECK-MSAN-TSAN-MSAN-DARWIN1-NOT: unsupported option

Again, I feel like we're lying to users here: `-fsanitize=thread` *is* 
supported for this target, it just requires building a runtime.


http://reviews.llvm.org/D15225



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

r254961 - Add llvm-objdump to compiler-rt test deps.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Mon Dec  7 16:45:36 2015
New Revision: 254961

URL: http://llvm.org/viewvc/llvm-project?rev=254961&view=rev
Log:
Add llvm-objdump to compiler-rt test deps.

Modified:
cfe/trunk/runtime/CMakeLists.txt

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=254961&r1=254960&r2=254961&view=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Mon Dec  7 16:45:36 2015
@@ -111,7 +111,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
   if(LLVM_INCLUDE_TESTS)
 # Add binaries that compiler-rt tests depend on.
 set(COMPILER_RT_TEST_DEPENDENCIES
-  FileCheck count not llvm-nm llvm-symbolizer)
+  FileCheck count not llvm-nm llvm-objdump llvm-symbolizer)
 
 # Add top-level targets for various compiler-rt test suites.
 set(COMPILER_RT_TEST_SUITES check-asan check-asan-dynamic check-dfsan


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

Re: r254935 - AST: defer to TypeLoc::copy in TypeLoc::initializeFullCopy

[Alexey Samsonov via cfe-commits]

Thanks for taking care of this!

On Mon, Dec 7, 2015 at 12:04 PM, Justin Bogner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: bogner
> Date: Mon Dec  7 14:04:57 2015
> New Revision: 254935
>
> URL: http://llvm.org/viewvc/llvm-project?rev=254935&view=rev
> Log:
> AST: defer to TypeLoc::copy in TypeLoc::initializeFullCopy
>
> If we're initializing a TypeLoc from one that's been allocated with
> different alignment, memcpy will get the padding wrong. The `copy`
> method already checks and handles this case, so we should just defer
> to it.
>
> This also drops the `const` off of the `initializeFullCopy`
> declarations, since it isn't even remotely true (and the compiler
> notices when we try to call copy() instead of tricking it with
> memcpy).
>
> Fixes llvm.org/pr23516.
>
> Modified:
> cfe/trunk/include/clang/AST/TypeLoc.h
>
> Modified: cfe/trunk/include/clang/AST/TypeLoc.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TypeLoc.h?rev=254935&r1=254934&r2=254935&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/TypeLoc.h (original)
> +++ cfe/trunk/include/clang/AST/TypeLoc.h Mon Dec  7 14:04:57 2015
> @@ -170,19 +170,18 @@ public:
>
>/// \brief Initializes this by copying its information from another
>/// TypeLoc of the same type.
> -  void initializeFullCopy(TypeLoc Other) const {
> +  void initializeFullCopy(TypeLoc Other) {
>  assert(getType() == Other.getType());
> -size_t Size = getFullDataSize();
> -memcpy(getOpaqueData(), Other.getOpaqueData(), Size);
> +copy(Other);
>}
>
>/// \brief Initializes this by copying its information from another
>/// TypeLoc of the same type.  The given size must be the full data
>/// size.
> -  void initializeFullCopy(TypeLoc Other, unsigned Size) const {
> +  void initializeFullCopy(TypeLoc Other, unsigned Size) {
>  assert(getType() == Other.getType());
>  assert(getFullDataSize() == Size);
> -memcpy(getOpaqueData(), Other.getOpaqueData(), Size);
> +copy(Other);
>}
>
>/// Copies the other type loc into this one.
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Sorry for the late response. Ugh, flag naming is hard, and it's far too 
complicated for sanitizers already.

However, I'm opposed to passing this down as `-fsanitize=` option =/. So far 
we're trying to make values of `-fsanitize=` correspond *only* to different 
kinds of checks, not configuration modes. For instance, we've pushed back 
against somewhat similar feature request for CFI: original plan for enabling 
"debug mode" in CFI was to pass "-fsanitize=cfi-diag", but we instead changed 
it to be "-fsanitize=cfi -fno-sanitize-trap=cfi".

And we have three possible configurations: recoverable checks, 
fatal/unrecoverable checks, trapping checks. You need, essentially 
"trapping-but-distinguishable checks". I'm afraid adding fourth configuration 
will make things incomprehensible. `-fsanitize-merge-traps` (true by default)?


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

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

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

That is, I presume it's highly unlikely user will need to have fine-grained 
setup for deciding which UBSan checks should be merged, and which should not. 
So, probably having a single `-fsanitize-merge-traps`  / 
`-fno-sanitize-merge-traps` option would be enough. I'd like to hear other 
opinions, though.


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

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

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

That is, I presume it's highly unlikely user will need to have fine-grained 
setup for deciding which UBSan checks should be merged, and which should not. 
So, probably having a single `-fsanitize-merge-traps`  / 
`-fno-sanitize-merge-traps` option would be enough. I'd like to hear other 
opinions, though.

In http://reviews.llvm.org/D15208#305199, @eugenis wrote:

> Better -fsanitize-merge-checks, and it should apply to non-trap checks as 
> well (i.e. SIGILL address should uniquely correspond to the failure source 
> location).


Just to make sure I understand it, you suggest to eventually pass it down to 
ASan/MSan instrumentation passes?


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

[PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

samsonov created this revision.
samsonov added reviewers: rsmith, kcc.
samsonov added a subscriber: cfe-commits.

Add the ability to suppress UBSan reports for files/functions/modules
at runtime. The user can now pass UBSAN_OPTIONS=suppressions=supp.txt
with the contents of the form:

signed-integer-overflow:file-with-known-overflow.cpp
alignment:function_doing_unaligned_access
vptr:shared_object_with_vptr_failures.so

Suppression categories match the arguments passed to -fsanitize=
flag (although, see below). There is no overhead if suppressions are
not provided. Otherwise there is extra overhead for symbolization.

Limitations:
1) sometimes suppressions need debug info / symbol table to function
   properly (although sometimes frontend generates enough info to
   do the match).
2) it's only possible to suppress recoverable UB kinds - if you've
   built the code with -fno-sanitize-recover=undefined, suppressions
   will not work.
3) categories are fine-grained check kinds, not groups like "undefined"
   or "integer", so you can't write "undefined:file_with_ub.cc".

http://reviews.llvm.org/D15363

Files:
  lib/sanitizer_common/sanitizer_suppressions.h
  lib/ubsan/ubsan_diag.cc
  lib/ubsan/ubsan_diag.h
  lib/ubsan/ubsan_handlers.cc
  lib/ubsan/ubsan_handlers_cxx.cc
  test/ubsan/TestCases/Integer/suppressions.cpp

Index: test/ubsan/TestCases/Integer/suppressions.cpp
===
--- /dev/null
+++ test/ubsan/TestCases/Integer/suppressions.cpp
@@ -0,0 +1,33 @@
+// RUN: %clangxx -fsanitize=integer -g0 %s -o %t
+
+// Fails without any suppression.
+// RUN: %env_ubsan_opts=halt_on_error=1 not %run %t 2>&1 | FileCheck %s
+
+// RUN: echo "signed-integer-overflow:%t" > %t.wrong-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.wrong-supp" not %run %t 2>&1 | FileCheck %s
+
+// RUN: echo "unsigned-integer-overflow:do_overflow" > %t.func-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.func-supp" %run %t
+// RUN: echo "unsigned-integer-overflow:%t" > %t.module-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.module-supp" %run %t
+
+// Note: file-level suppressions should work even without debug info.
+// RUN: echo "unsigned-integer-overflow:%s" > %t.file-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.file-supp" %run %t
+
+// Suppressions don't work for unrecoverable kinds.
+// RUN: %clangxx -fsanitize=integer -fno-sanitize-recover=integer %s -o %t-norecover
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.module-supp" not %run %t-norecover 2>&1 | FileCheck %s
+
+#include 
+
+extern "C" void do_overflow() {
+  (void)(uint64_t(1000ull) + uint64_t(900ull));
+  // CHECK: runtime error: unsigned integer overflow
+}
+
+int main() {
+  do_overflow();
+  return 0;
+}
+
Index: lib/ubsan/ubsan_handlers_cxx.cc
===
--- lib/ubsan/ubsan_handlers_cxx.cc
+++ lib/ubsan/ubsan_handlers_cxx.cc
@@ -43,10 +43,11 @@
 return false;
 
   SourceLocation Loc = Data->Loc.acquire();
-  if (Loc.isDisabled())
+  ErrorType ET = ErrorType::DynamicTypeMismatch;
+  if (ignoreReport(Loc, Opts, ET))
 return false;
 
-  ScopedReport R(Opts, Loc, ErrorType::DynamicTypeMismatch);
+  ScopedReport R(Opts, Loc, ET);
 
   Diag(Loc, DL_Error,
"%0 address %1 which does not point to an object of type %2")
@@ -89,10 +90,12 @@
 static void HandleCFIBadType(CFIBadTypeData *Data, ValueHandle Vtable,
  ReportOptions Opts) {
   SourceLocation Loc = Data->Loc.acquire();
+  ErrorType ET = ErrorType::CFIBadType;
 
-  if (ignoreReport(Loc, Opts))
+  if (ignoreReport(Loc, Opts, ET))
 return;
-  ScopedReport R(Opts, Loc, ErrorType::CFIBadType);
+
+  ScopedReport R(Opts, Loc, ET);
   DynamicTypeInfo DTI = getDynamicTypeInfoFromVtable((void*)Vtable);
 
   static const char *TypeCheckKinds[] = {
Index: lib/ubsan/ubsan_handlers.cc
===
--- lib/ubsan/ubsan_handlers.cc
+++ lib/ubsan/ubsan_handlers.cc
@@ -22,7 +22,7 @@
 using namespace __ubsan;
 
 namespace __ubsan {
-bool ignoreReport(SourceLocation SLoc, ReportOptions Opts) {
+bool ignoreReport(SourceLocation SLoc, ReportOptions Opts, ErrorType ET) {
   // We are not allowed to skip error report: if we are in unrecoverable
   // handler, we have to terminate the program right now, and therefore
   // have to print some diagnostic.
@@ -32,7 +32,7 @@
   // thread could have acquired it, but not yet printed the report.
   if (Opts.FromUnrecoverableHandler)
 return false;
-  return SLoc.isDisabled();
+  return SLoc.isDisabled() || IsPCSuppressed(ET, Opts.pc, SLoc.getFilename());
 }
 
 const char *TypeCheckKinds[] = {
@@ -44,15 +44,6 @@
 static void handleTypeMismatchImpl(TypeMismatchData *Data, ValueHandle Pointer,
ReportOptions Opts) {
   Location Loc = Data->Loc.acquire();

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

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Please consider adding a test case.



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

Why is it a language, not codegen option?


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

MergeTraps


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

These should probably be CC1Option as well.


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

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


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

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


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

  Args.hasFlag(OPT_fsanitize_merge_traps, OPT_fno_sanitize_merge_traps, true);


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

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

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


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

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


Repository:
  rL LLVM

http://reviews.llvm.org/D15208



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

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: test/Driver/fsanitize.c:221
@@ +220,3 @@
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=memory -fsanitize=thread,memory 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-TSAN-MSAN-DARWIN1
+// CHECK-MSAN-TSAN-MSAN-DARWIN1: unsupported option '-fsanitize=thread,memory' 
for target 'x86_64-apple-darwin10'
+// CHECK-MSAN-TSAN-MSAN-DARWIN1-NOT: unsupported option

beanz wrote:
> kubabrecka wrote:
> > samsonov wrote:
> > > Again, I feel like we're lying to users here: `-fsanitize=thread` *is* 
> > > supported for this target, it just requires building a runtime.
> > I'd like to see this from the point-of-view of a binary distribution.  If 
> > the binary distribution (e.g. the one from llvm.org or Apple's Clang in 
> > Xcode) doesn't contain a runtime library, then the sanitizer is *not* 
> > supported in that distribution.  Also, see http://reviews.llvm.org/D14846, 
> > we'd like to have CMake options to select which runtimes will be built.  If 
> > you deliberately choose not to build ThreadSanitizer, then that sanitizer 
> > is *not* supported in your version of Clang.  If you're experimenting and 
> > porting a runtime to a new platform, then this sanitizer *is* supported in 
> > your version of Clang.
> Maybe the point is we should have a different error message for cases where 
> the runtime is just missing. Something like "runtime components for 
> '-fsanitize=thread' not available"
I see, so essentially you want to use a different approach for determining 
sanitizer availability (on OS X for now): if the library is present, then we 
support sanitizer, otherwise we don't: i.e. the binary distribution is the 
source of truth, not the list of sanitizers hardcoded into Clang driver source 
code. I'm fine with that, and see why it would make sense.

It's just that error message looks misleading: the problem is not TSan is 
unsupported for target, it's just unavailable in this distribution for one 
reason or another.


http://reviews.llvm.org/D15225



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

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Richard, could you take a look at this?


http://reviews.llvm.org/D15363



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

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Kostya, PTAL. IIRC it was your feature request :)


http://reviews.llvm.org/D15363



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

[PATCH] D15598: [Driver] Make AddCXXStdlibLibArgs responsible for handling -static-libstdc++.

[Alexey Samsonov via cfe-commits]

samsonov created this revision.
samsonov added reviewers: rafael, compnerd.
samsonov added a subscriber: cfe-commits.

After this change, AddCXXStdlibLibArgs will check the presence of
-static-libstdc++ flag and, if necessary, wrap -lc++/-lstdc++ in
-Bstatic/-Bdynamic to force static linking of C++ standard library.

It's no longer necessary to copy this code around across toolchains
(unless toolchain is overriding AddCXXStdlibLibArgs).

This change has an important consequnce: if the user provides "-lstdc++"
manually (i.e. it's not added automatically when we're linking C++ binary),
then "-static-libstdc++" *will* work as expected.

Other than that, the change attempts to preserve the existing behavior.

http://reviews.llvm.org/D15598

Files:
  lib/Driver/CrossWindowsToolChain.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/Tools.cpp
  test/Driver/static-libstdcxx.c

Index: test/Driver/static-libstdcxx.c
===
--- /dev/null
+++ test/Driver/static-libstdcxx.c
@@ -0,0 +1,11 @@
+// RUN: %clang -no-canonical-prefixes -target x86_64-unknown-linux -static-libstdc++ %s -### 2>&1 | FileCheck %s --check-prefix=C-ONLY-CODE
+// C-ONLY-CODE: warning: argument unused during compilation: '-static-libstdc++'
+
+// RUN: %clang --driver-mode=g++ -no-canonical-prefixes -target x86_64-unknown-linux -static-libstdc++ %s -### 2>&1 | FileCheck %s --check-prefix=CXX-CODE
+// CXX-CODE: "-Bstatic" "-lstdc++" "-Bdynamic"
+
+// RUN: %clang --driver-mode=g++ -no-canonical-prefixes -target x86_64-unknown-linux -static-libstdc++ -stdlib=libc++ %s -### 2>&1 | FileCheck %s --check-prefix=LIBCXX
+// LIBCXX: "-Bstatic" "-lc++" "-Bdynamic"
+
+// RUN: %clang -no-canonical-prefixes -target x86_64-unknown-linux -static-libstdc++ -lstdc++ %s -### 2>&1 | FileCheck %s --check-prefix=C-CODE-WITH-EXPLICIT-LSTDCXX
+// C-CODE-WITH-EXPLICIT-LSTDCXX: "-Bstatic" "-lstdc++" "-Bdynamic"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8754,13 +8754,7 @@
 
   if (D.CCCIsCXX() &&
   !Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
-bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
-   !Args.hasArg(options::OPT_static);
-if (OnlyLibstdcxxStatic)
-  CmdArgs.push_back("-Bstatic");
 ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
-if (OnlyLibstdcxxStatic)
-  CmdArgs.push_back("-Bdynamic");
 CmdArgs.push_back("-lm");
   }
   // Silence warnings when linking C code with a C++ '-stdlib' argument.
@@ -8946,13 +8940,7 @@
 
   if (D.CCCIsCXX() &&
   !Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
-bool OnlyLibstdcxxStatic =
-Args.hasArg(options::OPT_static_libstdcxx) && !IsStatic;
-if (OnlyLibstdcxxStatic)
-  CmdArgs.push_back("-Bstatic");
 ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
-if (OnlyLibstdcxxStatic)
-  CmdArgs.push_back("-Bdynamic");
 CmdArgs.push_back("-lm");
   }
 
@@ -9704,13 +9692,7 @@
 
   if (D.CCCIsCXX() &&
   !Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
-bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
-   !Args.hasArg(options::OPT_static);
-if (OnlyLibstdcxxStatic)
-  CmdArgs.push_back("-Bstatic");
 TC.AddCXXStdlibLibArgs(Args, CmdArgs);
-if (OnlyLibstdcxxStatic)
-  CmdArgs.push_back("-Bdynamic");
   }
 
   if (!Args.hasArg(options::OPT_nostdlib)) {
@@ -9978,13 +9960,7 @@
 
   if (D.CCCIsCXX() && !Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_nodefaultlibs)) {
-bool StaticCXX = Args.hasArg(options::OPT_static_libstdcxx) &&
- !Args.hasArg(options::OPT_static);
-if (StaticCXX)
-  CmdArgs.push_back("-Bstatic");
 TC.AddCXXStdlibLibArgs(Args, CmdArgs);
-if (StaticCXX)
-  CmdArgs.push_back("-Bdynamic");
   }
 
   if (!Args.hasArg(options::OPT_nostdlib)) {
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -2849,7 +2849,15 @@
   // Check for -stdlib= flags. We only support libc++ but this consumes the arg
   // if the value is libc++, and emits an error for other values.
   GetCXXStdlibType(Args);
+  const bool IsStatic =
+  !Args.hasArg(options::OPT_dynamic) && !Args.hasArg(options::OPT_shared);
+  const bool OnlyCXXStdlibStatic =
+  Args.hasArg(options::OPT_static_libstdcxx) && !IsStatic;
+  if (OnlyCXXStdlibStatic)
+CmdArgs.push_back("-Bstatic");
   CmdArgs.push_back("-lc++");
+  if (OnlyCXXStdlibStatic)
+CmdArgs.push_back("-Bdynamic");
 }
 
 void NaClToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
Index: lib/Driver/ToolChain.cpp
===
-

Re: [PATCH] D15624: Add iOS/watchOS/tvOS support for ASan (clang part)

[Alexey Samsonov via cfe-commits]

samsonov added a subscriber: samsonov.


Comment at: lib/Driver/ToolChains.cpp:368
@@ +367,3 @@
+  StringRef OS = "";
+  if (isTargetMacOS())
+OS = "osx";

Wait, this looks horrible. Can we teach toolchain to give us OS name?


http://reviews.llvm.org/D15624



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

Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL256018: [UBSan] Implement runtime suppressions (PR25066). 
(authored by samsonov).

Changed prior to commit:
  http://reviews.llvm.org/D15363?vs=42250&id=43254#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15363

Files:
  compiler-rt/trunk/lib/sanitizer_common/sanitizer_suppressions.h
  compiler-rt/trunk/lib/ubsan/ubsan_diag.cc
  compiler-rt/trunk/lib/ubsan/ubsan_diag.h
  compiler-rt/trunk/lib/ubsan/ubsan_handlers.cc
  compiler-rt/trunk/lib/ubsan/ubsan_handlers_cxx.cc
  compiler-rt/trunk/test/ubsan/TestCases/Integer/suppressions.cpp

Index: compiler-rt/trunk/test/ubsan/TestCases/Integer/suppressions.cpp
===
--- compiler-rt/trunk/test/ubsan/TestCases/Integer/suppressions.cpp
+++ compiler-rt/trunk/test/ubsan/TestCases/Integer/suppressions.cpp
@@ -0,0 +1,33 @@
+// RUN: %clangxx -fsanitize=integer -g0 %s -o %t
+
+// Fails without any suppression.
+// RUN: %env_ubsan_opts=halt_on_error=1 not %run %t 2>&1 | FileCheck %s
+
+// RUN: echo "signed-integer-overflow:%t" > %t.wrong-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.wrong-supp" not %run %t 2>&1 | FileCheck %s
+
+// RUN: echo "unsigned-integer-overflow:do_overflow" > %t.func-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.func-supp" %run %t
+// RUN: echo "unsigned-integer-overflow:%t" > %t.module-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.module-supp" %run %t
+
+// Note: file-level suppressions should work even without debug info.
+// RUN: echo "unsigned-integer-overflow:%s" > %t.file-supp
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.file-supp" %run %t
+
+// Suppressions don't work for unrecoverable kinds.
+// RUN: %clangxx -fsanitize=integer -fno-sanitize-recover=integer %s -o %t-norecover
+// RUN: %env_ubsan_opts=halt_on_error=1:suppressions="%t.module-supp" not %run %t-norecover 2>&1 | FileCheck %s
+
+#include 
+
+extern "C" void do_overflow() {
+  (void)(uint64_t(1000ull) + uint64_t(900ull));
+  // CHECK: runtime error: unsigned integer overflow
+}
+
+int main() {
+  do_overflow();
+  return 0;
+}
+
Index: compiler-rt/trunk/lib/sanitizer_common/sanitizer_suppressions.h
===
--- compiler-rt/trunk/lib/sanitizer_common/sanitizer_suppressions.h
+++ compiler-rt/trunk/lib/sanitizer_common/sanitizer_suppressions.h
@@ -43,7 +43,7 @@
   void GetMatched(InternalMmapVector *matched);
 
  private:
-  static const int kMaxSuppressionTypes = 16;
+  static const int kMaxSuppressionTypes = 32;
   const char **const suppression_types_;
   const int suppression_types_num_;
 
Index: compiler-rt/trunk/lib/ubsan/ubsan_handlers_cxx.cc
===
--- compiler-rt/trunk/lib/ubsan/ubsan_handlers_cxx.cc
+++ compiler-rt/trunk/lib/ubsan/ubsan_handlers_cxx.cc
@@ -43,10 +43,11 @@
 return false;
 
   SourceLocation Loc = Data->Loc.acquire();
-  if (Loc.isDisabled())
+  ErrorType ET = ErrorType::DynamicTypeMismatch;
+  if (ignoreReport(Loc, Opts, ET))
 return false;
 
-  ScopedReport R(Opts, Loc, ErrorType::DynamicTypeMismatch);
+  ScopedReport R(Opts, Loc, ET);
 
   Diag(Loc, DL_Error,
"%0 address %1 which does not point to an object of type %2")
@@ -89,10 +90,12 @@
 static void HandleCFIBadType(CFIBadTypeData *Data, ValueHandle Vtable,
  ReportOptions Opts) {
   SourceLocation Loc = Data->Loc.acquire();
+  ErrorType ET = ErrorType::CFIBadType;
 
-  if (ignoreReport(Loc, Opts))
+  if (ignoreReport(Loc, Opts, ET))
 return;
-  ScopedReport R(Opts, Loc, ErrorType::CFIBadType);
+
+  ScopedReport R(Opts, Loc, ET);
   DynamicTypeInfo DTI = getDynamicTypeInfoFromVtable((void*)Vtable);
 
   static const char *TypeCheckKinds[] = {
Index: compiler-rt/trunk/lib/ubsan/ubsan_diag.h
===
--- compiler-rt/trunk/lib/ubsan/ubsan_diag.h
+++ compiler-rt/trunk/lib/ubsan/ubsan_diag.h
@@ -225,7 +225,7 @@
 #undef UBSAN_CHECK
 };
 
-bool ignoreReport(SourceLocation SLoc, ReportOptions Opts);
+bool ignoreReport(SourceLocation SLoc, ReportOptions Opts, ErrorType ET);
 
 #define GET_REPORT_OPTIONS(unrecoverable_handler) \
 GET_CALLER_PC_BP; \
@@ -246,6 +246,9 @@
 
 void InitializeSuppressions();
 bool IsVptrCheckSuppressed(const char *TypeName);
+// Sometimes UBSan runtime can know filename from handlers arguments, even if
+// debug info is missing.
+bool IsPCSuppressed(ErrorType ET, uptr PC, const char *Filename);
 
 } // namespace __ubsan
 
Index: compiler-rt/trunk/lib/ubsan/ubsan_diag.cc
===
--- compiler-rt/trunk/lib/ubsan/ubsan_diag.cc
+++ compiler-rt/trunk/lib/ubsan/ubsan_diag.cc
@@ -54,6 +54,17 @@
   UNREACHABLE("unknown ErrorType!");
 }
 
+static const char 

Re: [PATCH] D15598: [Driver] Make AddCXXStdlibLibArgs responsible for handling -static-libstdc++.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

In http://reviews.llvm.org/D15598#314127, @rafael wrote:

> I am not sure what is "expected" is here:


Interesting.
I was assuming that Clang tends to understand "-lstdc++" as a special argument 
that says "link against C++ standard library", not "link against 
libstdc++.{a,so}".
For instance,

  clang a.cc -lstdc++ -stdlib=libc++

will effectively replace "-lstdc++" with "-lc++", and

  clang++ a.cc -stdlib=libc++ -static-libstdc++

will link against libc++ statically. In that sense, it makes sense to assume 
that "-static-libstdc++" will bind to "-lstdc++" argument.

Apparently, it's not what GCC does :( Do you think we should keep being 
compatible here?

> $ gcc test.o -o test.so -lstdc++ -shared -static-libstdc++ && ldd

>  test.so | grep libst

>  libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f848e57d000)

> 

> $ gcc test.o -o test.so -shared -static-libstdc++ -lstdc++ && ldd

>  test.so | grep libst

>  libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7fc25516d000)



http://reviews.llvm.org/D15598



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

Re: [PATCH] D15598: [Driver] Make AddCXXStdlibLibArgs responsible for handling -static-libstdc++.

[Alexey Samsonov via cfe-commits]

On Fri, Dec 18, 2015 at 3:20 PM, Rafael Espíndola <
rafael.espind...@gmail.com> wrote:

> On 18 December 2015 at 18:13, Alexey Samsonov  wrote:
> > samsonov added a comment.
> >
> > In http://reviews.llvm.org/D15598#314127, @rafael wrote:
> >
> >> I am not sure what is "expected" is here:
> >
> >
> > Interesting.
> > I was assuming that Clang tends to understand "-lstdc++" as a special
> argument that says "link against C++ standard library", not "link against
> libstdc++.{a,so}".
> > For instance,
> >
> >   clang a.cc -lstdc++ -stdlib=libc++
> >
> > will effectively replace "-lstdc++" with "-lc++", and
> >
> >   clang++ a.cc -stdlib=libc++ -static-libstdc++
> >
> > will link against libc++ statically. In that sense, it makes sense to
> assume that "-static-libstdc++" will bind to "-lstdc++" argument.
> >
> > Apparently, it's not what GCC does :( Do you think we should keep being
> compatible here?
>
> My preference would be for -lstdc++ to be as least special as
> possible.


Got it. I can always use "-Bstatic -lstdc++ -Bdynamic" to manually link
against my explicitly passed libstdc++,
I just wanted to make it less ugly.


> Do you know why -stdlib=libc++ is not a clang++ only option?
>

Not really. However, I believe there are setups which only use "clang" (w/o
even --driver-mode=g++) and
pass include/library directories manually, and -stdlib=libc++ might be
handy to choose between standard lib version.


> Cheers,
> Rafael
>


-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits