[PATCH 0/7] Libsanitizer merge from upstream r249633.

[PATCH 0/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

Hi,

it's been a while since the last libsanitizer merge from upstream into 
GCC happened and the library has significantly changed since that time. 
The main features to be ported are:

-New common strings interceptors were added.
-Various allocator improvements were performed.
-Improvements for ASan deactivated start were performed.
-TSan and LSan were enabled for Aarch64.
-Fast unwinding was enabled for Aarch64.
-New tsan_unaligned_{load, store}_[n] functions were intoduced.
-asan_stack_malloc_[n] doesn't take a local stack as a second parameter 
anymore.
-sanitization for std containers is supported now.
-New interface functions for dynamic allocas and VLA's 
poisoning/unpoisoning were introduced.

Some features are not ported for now, by might be enabled in future:

-Embedded UBSan runtime into ASan and TSan ones. I don't enable this 
now, because of errors during ASan static linkage: GCC uses 
-whole-archive option that would lead to undefined references to C++ stuff.
-UBSan data descriptors for float-cast conversion support location 
propagation now. But sometimes we have loc == UNKNOWN_LOCATION in 
ubsan_instrument_float_cast, so use old ABI for now. See below for details.

The first patch of the series is the merge itself.

The second one introduces corresponding compiler changes.

Other patches are applied to library and they are GCC-specific:

Patches 3 and 4 are just reapplied David's and Jakub's patches for SPARC 
and disabling ODR violation detection respectively.

Patch 5 removes UBSan stubs from ASan and TSan code since we don't 
support embedded UBSan runtime into ASan and TSan.

Patch 6 changes heuristic for extracting last PC from stack frame for 
ARM in fast unwind routine. More details can be found here 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771).

Patch 7 forces libsanitizer to use an old ABI for ubsan float cast data 
descriptors, because sometimes we can have loc == UNKNOWN_LOCATION in 
ubsan_instrument_float_cast e.g. in a such case:

......
volatile double foo; // ubsan_instrument_float_cast is called by convert 
function.
......

Since foo is a tcc_declaration, loc is UNKNOWN_LOCATION. I'm actually 
not sure about this, perhaps we can fix this in GCC somehow.

I've regtested and {A, UB}San bootstrapped these patches on 
x86-64-unknown-linux-gnu and aarch64-linux-gnueabi (Juno board, 39 bit 
VA space) and tested for ARM under QEMU-ARM.
Testing ASan under QEMU-AARCH64 revealed many test failures due to LSan 
was enabled. In particular, it tries to call internal_clone function in 
LSan internals, that in turn calls _NR_clone syscall and than QEMU exits 
with EINTR error code (that might be expected, AFAIK QEMU is not very 
good with threads). So, I wonder, if I should disable LSan for AArch64 now?

I'm also asking community to help me with testing these patches on 
various targets (ARM, PPC, etc) I'm lack of, so could you help me on 
this please?

-Maxim

[PATCH 2/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

This patch introduces required compiler changes. Now, we don't version 
asan_init, we have a special __asan_version_mismatch_check_v[n] symbol 
for this.

Also, asan_stack_malloc_[n] doesn't take a local stack as a second 
parameter anymore, so don't pass it.

[-- Attachment #2: 2.diff --]
[-- Type: text/x-patch, Size: 2975 bytes --]

2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

config/

	* bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
	LSAN_OPTIONS=detect_leaks

gcc/

	* asan.c (asan_emit_stack_protection): Don't pass local stack to
	asan_stack_malloc_[n] anymore.
	(asan_finish_file): Instert __asan_version_mismatch_check_v[n] call.
	* sanitizer.def (BUILT_IN_ASAN_INIT): Rename to __asan_init.
	(BUILT_IN_ASAN_VERSION_MISMATCH_CHECK): Add new builtin call.

gcc/testsuite/

	g++.dg/asan/default-options-1.C: Adjust testcase.

Index: gcc/asan.c
===================================================================
--- gcc/asan.c	(revision 228704)
+++ gcc/asan.c	(working copy)
@@ -1132,12 +1132,10 @@
       snprintf (buf, sizeof buf, "__asan_stack_malloc_%d",
 		use_after_return_class);
       ret = init_one_libfunc (buf);
-      rtx addr = convert_memory_address (ptr_mode, base);
-      ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode, 2,
+      ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode, 1,
 				     GEN_INT (asan_frame_size
 					      + base_align_bias),
-				     TYPE_MODE (pointer_sized_int_node),
-				     addr, ptr_mode);
+				     TYPE_MODE (pointer_sized_int_node));
       ret = convert_memory_address (Pmode, ret);
       emit_move_insn (base, ret);
       emit_label (lab);
@@ -2470,6 +2468,8 @@
     {
       tree fn = builtin_decl_implicit (BUILT_IN_ASAN_INIT);
       append_to_statement_list (build_call_expr (fn, 0), &asan_ctor_statements);
+      fn = builtin_decl_implicit (BUILT_IN_ASAN_VERSION_MISMATCH_CHECK);
+      append_to_statement_list (build_call_expr (fn, 0), &asan_ctor_statements);
     }
   FOR_EACH_DEFINED_VARIABLE (vnode)
     if (TREE_ASM_WRITTEN (vnode->decl)
Index: gcc/sanitizer.def
===================================================================
--- gcc/sanitizer.def	(revision 228704)
+++ gcc/sanitizer.def	(working copy)
@@ -27,8 +27,11 @@
    for other FEs by asan.c.  */
 
 /* Address Sanitizer */
-DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_INIT, "__asan_init_v4",
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_INIT, "__asan_init",
 		      BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_VERSION_MISMATCH_CHECK,
+		      "__asan_version_mismatch_check_v6",
+		      BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
 /* Do not reorder the BUILT_IN_ASAN_{REPORT,CHECK}* builtins, e.g. cfgcleanup.c
    relies on this order.  */
 DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD1, "__asan_report_load1",
Index: gcc/testsuite/g++.dg/asan/default-options-1.C
===================================================================
--- gcc/testsuite/g++.dg/asan/default-options-1.C	(revision 228704)
+++ gcc/testsuite/g++.dg/asan/default-options-1.C	(working copy)
@@ -12,4 +12,4 @@
   return 0;
 }
 
-// { dg-output "Using the defaults from __asan_default_options:.* foo=bar.*(\n|\r\n|\r)" }
+// { dg-output "WARNING: found 1 unrecognized flag\\(s\\):(\n|\r\n|\r).*foo(\n|\r\n|\r)" }

Re: [PATCH 2/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Tue, Oct 13, 2015 at 02:16:23PM +0300, Maxim Ostapenko wrote:
> This patch introduces required compiler changes. Now, we don't version
> asan_init, we have a special __asan_version_mismatch_check_v[n] symbol for
> this.

For this, I just have to wonder what is the actual improvement over what we
had.  To me it looks like a step in the wrong direction, it will only bloat
the size of the ctors.  I can live with it, but just want to put on record I
think it is a mistake.

> Also, asan_stack_malloc_[n] doesn't take a local stack as a second parameter
> anymore, so don't pass it.

I think this is another mistake, but this time with actually bad fix on the
compiler side for it.  If I read the code well, previously
__asan_stack_malloc_n would return you the local stack if it failed for
whatever reason, which is actually what you want as fallback.
But, the new code returns NULL instead, so I think you would need to compare
the return value of __asan_stack_malloc_n with NULL and if it is NULL, use
the addr instead of what it returned; which is not what your asan.c change
does.  Now, what is the improvement here?  Bloat the compiler generated
code... :(

> 2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
> 
> config/
> 
> 	* bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
> 	LSAN_OPTIONS=detect_leaks

Missing . at the end, and the config/ hunk missing from the patch.

> gcc/
> 
> 	* asan.c (asan_emit_stack_protection): Don't pass local stack to
> 	asan_stack_malloc_[n] anymore.
> 	(asan_finish_file): Instert __asan_version_mismatch_check_v[n] call.

s/Instert/Instead/

	Jakub

Re: [PATCH 2/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On 14/10/15 10:30, Jakub Jelinek wrote:
> On Tue, Oct 13, 2015 at 02:16:23PM +0300, Maxim Ostapenko wrote:
>> This patch introduces required compiler changes. Now, we don't version
>> asan_init, we have a special __asan_version_mismatch_check_v[n] symbol for
>> this.
> For this, I just have to wonder what is the actual improvement over what we
> had.  To me it looks like a step in the wrong direction, it will only bloat
> the size of the ctors.  I can live with it, but just want to put on record I
> think it is a mistake.
>
>> Also, asan_stack_malloc_[n] doesn't take a local stack as a second parameter
>> anymore, so don't pass it.
> I think this is another mistake, but this time with actually bad fix on the
> compiler side for it.  If I read the code well, previously
> __asan_stack_malloc_n would return you the local stack if it failed for
> whatever reason, which is actually what you want as fallback.
> But, the new code returns NULL instead, so I think you would need to compare
> the return value of __asan_stack_malloc_n with NULL and if it is NULL, use
> the addr instead of what it returned; which is not what your asan.c change
> does.  Now, what is the improvement here?  Bloat the compiler generated
> code... :(
>

Ah, right, fixing this now. Does this looks better now?

>> 2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
>>
>> config/
>>
>> 	* bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
>> 	LSAN_OPTIONS=detect_leaks
> Missing . at the end, and the config/ hunk missing from the patch.
>
>> gcc/
>>
>> 	* asan.c (asan_emit_stack_protection): Don't pass local stack to
>> 	asan_stack_malloc_[n] anymore.
>> 	(asan_finish_file): Instert __asan_version_mismatch_check_v[n] call.
> s/Instert/Instead/

Fixed now.

>
> 	Jakub
>


[-- Attachment #2: 2.diff --]
[-- Type: text/x-patch, Size: 3926 bytes --]

2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

config/

	* bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
	LSAN_OPTIONS=detect_leaks.

gcc/

	* asan.c (asan_emit_stack_protection): Don't pass local stack to
	asan_stack_malloc_[n] anymore. Check if asan_stack_malloc_[n] returned
	NULL and use local stack than.
	(asan_finish_file): Insert __asan_version_mismatch_check_v[n] call
	in addition to __asan_init.
	* sanitizer.def (BUILT_IN_ASAN_INIT): Rename to __asan_init.
	(BUILT_IN_ASAN_VERSION_MISMATCH_CHECK): Add new builtin call.

gcc/testsuite/

	g++.dg/asan/default-options-1.C: Adjust testcase.

Index: gcc/asan.c
===================================================================
--- gcc/asan.c	(revision 228817)
+++ gcc/asan.c	(working copy)
@@ -1132,12 +1132,16 @@
       snprintf (buf, sizeof buf, "__asan_stack_malloc_%d",
 		use_after_return_class);
       ret = init_one_libfunc (buf);
-      rtx addr = convert_memory_address (ptr_mode, base);
-      ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode, 2,
+      ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode, 1,
 				     GEN_INT (asan_frame_size
 					      + base_align_bias),
-				     TYPE_MODE (pointer_sized_int_node),
-				     addr, ptr_mode);
+				     TYPE_MODE (pointer_sized_int_node));
+      /* __asan_stack_malloc_[n] returns a pointer to fake stack if succeeded
+	 and NULL otherwise.  Check if RET value is NULL and jump over the
+	 BASE reassignment in this case.  Otherwise, reassign BASE to RET.  */
+      int very_unlikely = REG_BR_PROB_BASE / 2000 - 1;
+      emit_cmp_and_jump_insns (ret, const0_rtx, EQ, NULL_RTX,
+			       VOIDmode, 0, lab, very_unlikely);
       ret = convert_memory_address (Pmode, ret);
       emit_move_insn (base, ret);
       emit_label (lab);
@@ -2470,6 +2474,8 @@
     {
       tree fn = builtin_decl_implicit (BUILT_IN_ASAN_INIT);
       append_to_statement_list (build_call_expr (fn, 0), &asan_ctor_statements);
+      fn = builtin_decl_implicit (BUILT_IN_ASAN_VERSION_MISMATCH_CHECK);
+      append_to_statement_list (build_call_expr (fn, 0), &asan_ctor_statements);
     }
   FOR_EACH_DEFINED_VARIABLE (vnode)
     if (TREE_ASM_WRITTEN (vnode->decl)
Index: gcc/sanitizer.def
===================================================================
--- gcc/sanitizer.def	(revision 228817)
+++ gcc/sanitizer.def	(working copy)
@@ -27,8 +27,11 @@
    for other FEs by asan.c.  */
 
 /* Address Sanitizer */
-DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_INIT, "__asan_init_v4",
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_INIT, "__asan_init",
 		      BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_VERSION_MISMATCH_CHECK,
+		      "__asan_version_mismatch_check_v6",
+		      BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
 /* Do not reorder the BUILT_IN_ASAN_{REPORT,CHECK}* builtins, e.g. cfgcleanup.c
    relies on this order.  */
 DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD1, "__asan_report_load1",
Index: gcc/testsuite/g++.dg/asan/default-options-1.C
===================================================================
--- gcc/testsuite/g++.dg/asan/default-options-1.C	(revision 228817)
+++ gcc/testsuite/g++.dg/asan/default-options-1.C	(working copy)
@@ -12,4 +12,4 @@
   return 0;
 }
 
-// { dg-output "Using the defaults from __asan_default_options:.* foo=bar.*(\n|\r\n|\r)" }
+// { dg-output "WARNING: found 1 unrecognized flag\\(s\\):(\n|\r\n|\r).*foo(\n|\r\n|\r)" }
Index: config/bootstrap-asan.mk
===================================================================
--- config/bootstrap-asan.mk	(revision 228817)
+++ config/bootstrap-asan.mk	(working copy)
@@ -1,7 +1,7 @@
 # This option enables -fsanitize=address for stage2 and stage3.
 
 # Suppress LeakSanitizer in bootstrap.
-export ASAN_OPTIONS="detect_leaks=0"
+export LSAN_OPTIONS="detect_leaks=0"
 
 STAGE2_CFLAGS += -fsanitize=address
 STAGE3_CFLAGS += -fsanitize=address

Re: [PATCH 2/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Thu, Oct 15, 2015 at 01:34:06PM +0300, Maxim Ostapenko wrote:
> Ah, right, fixing this now. Does this looks better now?

Yes, it is ok now.

> 2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
> 
> config/
> 
> 	* bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
> 	LSAN_OPTIONS=detect_leaks.
> 
> gcc/
> 
> 	* asan.c (asan_emit_stack_protection): Don't pass local stack to
> 	asan_stack_malloc_[n] anymore. Check if asan_stack_malloc_[n] returned
> 	NULL and use local stack than.
> 	(asan_finish_file): Insert __asan_version_mismatch_check_v[n] call
> 	in addition to __asan_init.
> 	* sanitizer.def (BUILT_IN_ASAN_INIT): Rename to __asan_init.
> 	(BUILT_IN_ASAN_VERSION_MISMATCH_CHECK): Add new builtin call.
> 
> gcc/testsuite/
> 
> 	g++.dg/asan/default-options-1.C: Adjust testcase.

	Jakub

Re: [PATCH 2/7] Libsanitizer merge from upstream r249633.

[Yury Gribov]

On 10/13/2015 02:16 PM, Maxim Ostapenko wrote:
> This patch introduces required compiler changes. Now, we don't version
> asan_init, we have a special __asan_version_mismatch_check_v[n] symbol
> for this.
>
> Also, asan_stack_malloc_[n] doesn't take a local stack as a second
> parameter anymore, so don't pass it.

Did you compare libasan.so and libclang_rt-asan.so for other ABI 
incompatibilities e.g. via libabigail?

-Y

[PATCH 4/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 160 bytes --]

This is a reapplied Jakub's patch for disabling ODR violation detection. 
More details can be found here 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888).

[-- Attachment #2: 4.diff --]
[-- Type: text/x-patch, Size: 1134 bytes --]

2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

	PR bootstrap/63888
	Reapply:
	2015-02-20  Jakub Jelinek  <jakub@redhat.com>

	* asan/asan_globals.cc (RegisterGlobal): Disable detect_odr_violation
	support until it is rewritten upstream.

	* c-c++-common/asan/pr63888.c: New test.

Index: libsanitizer/asan/asan_globals.cc
===================================================================
--- libsanitizer/asan/asan_globals.cc	(revision 250059)
+++ libsanitizer/asan/asan_globals.cc	(working copy)
@@ -146,7 +146,9 @@
   CHECK(AddrIsInMem(g->beg));
   CHECK(AddrIsAlignedByGranularity(g->beg));
   CHECK(AddrIsAlignedByGranularity(g->size_with_redzone));
-  if (flags()->detect_odr_violation) {
+  // This "ODR violation" detection is fundamentally incompatible with
+  // how GCC registers globals.  Disable as useless until rewritten upstream.
+  if (0 && flags()->detect_odr_violation) {
     // Try detecting ODR (One Definition Rule) violation, i.e. the situation
     // where two globals with the same name are defined in different modules.
     if (__asan_region_is_poisoned(g->beg, g->size_with_redzone)) {

Re: [PATCH 4/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Tue, Oct 13, 2015 at 02:18:41PM +0300, Maxim Ostapenko wrote:
> This is a reapplied Jakub's patch for disabling ODR violation detection.
> More details can be found here
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888).

This is ok when all the other changes are acked.

> 2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
> 
> 	PR bootstrap/63888
> 	Reapply:
> 	2015-02-20  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* asan/asan_globals.cc (RegisterGlobal): Disable detect_odr_violation
> 	support until it is rewritten upstream.
> 
> 	* c-c++-common/asan/pr63888.c: New test.
> 
> Index: libsanitizer/asan/asan_globals.cc
> ===================================================================
> --- libsanitizer/asan/asan_globals.cc	(revision 250059)
> +++ libsanitizer/asan/asan_globals.cc	(working copy)
> @@ -146,7 +146,9 @@
>    CHECK(AddrIsInMem(g->beg));
>    CHECK(AddrIsAlignedByGranularity(g->beg));
>    CHECK(AddrIsAlignedByGranularity(g->size_with_redzone));
> -  if (flags()->detect_odr_violation) {
> +  // This "ODR violation" detection is fundamentally incompatible with
> +  // how GCC registers globals.  Disable as useless until rewritten upstream.
> +  if (0 && flags()->detect_odr_violation) {
>      // Try detecting ODR (One Definition Rule) violation, i.e. the situation
>      // where two globals with the same name are defined in different modules.
>      if (__asan_region_is_poisoned(g->beg, g->size_with_redzone)) {


	Jakub

[PATCH 3/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

This is just reapplied patch for SPARC by David S. Miller. I was unable 
to test this, so could anyone help me here?

[-- Attachment #2: 3.diff --]
[-- Type: text/x-patch, Size: 5172 bytes --]

2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

	PR sanitizer/63958
	Reapply:
	2015-03-09  Jakub Jelinek  <jakub@redhat.com>

	PR sanitizer/63958
	Reapply:
	2014-10-14  David S. Miller  <davem@davemloft.net>

	* sanitizer_common/sanitizer_platform_limits_linux.cc (time_t):
	Define at __kernel_time_t, as needed for sparc.
	(struct __old_kernel_stat): Don't check if __sparc__ is defined.
	* libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
	(__sanitizer): Define struct___old_kernel_stat_sz,
	struct_kernel_stat_sz, and struct_kernel_stat64_sz for sparc.
	(__sanitizer_ipc_perm): Adjust for sparc targets.
	(__sanitizer_shmid_ds): Likewsie.
	(__sanitizer_sigaction): Likewise.
	(IOC_SIZE): Likewsie.

Index: libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
===================================================================
--- libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc	(revision 250059)
+++ libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc	(working copy)
@@ -38,6 +38,7 @@
 #define uid_t __kernel_uid_t
 #define gid_t __kernel_gid_t
 #define off_t __kernel_off_t
+#define time_t __kernel_time_t
 // This header seems to contain the definitions of _kernel_ stat* structs.
 #include <asm/stat.h>
 #undef ino_t
@@ -62,7 +63,7 @@
 }  // namespace __sanitizer
 
 #if !defined(__powerpc64__) && !defined(__x86_64__) && !defined(__aarch64__)\
-                            && !defined(__mips__)
+                            && !defined(__mips__) && !defined(__sparc__)
 COMPILER_CHECK(struct___old_kernel_stat_sz == sizeof(struct __old_kernel_stat));
 #endif
 
Index: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
===================================================================
--- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h	(revision 250059)
+++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h	(working copy)
@@ -83,6 +83,14 @@
   const unsigned struct_kernel_stat_sz = 144;
   #endif
   const unsigned struct_kernel_stat64_sz = 104;
+#elif defined(__sparc__) && defined(__arch64__)
+  const unsigned struct___old_kernel_stat_sz = 0;
+  const unsigned struct_kernel_stat_sz = 104;
+  const unsigned struct_kernel_stat64_sz = 144;
+#elif defined(__sparc__) && !defined(__arch64__)
+  const unsigned struct___old_kernel_stat_sz = 0;
+  const unsigned struct_kernel_stat_sz = 64;
+  const unsigned struct_kernel_stat64_sz = 104;
 #endif
   struct __sanitizer_perf_event_attr {
     unsigned type;
@@ -105,7 +113,7 @@
 
 #if defined(__powerpc64__)
   const unsigned struct___old_kernel_stat_sz = 0;
-#else
+#elif !defined(__sparc__)
   const unsigned struct___old_kernel_stat_sz = 32;
 #endif
 
@@ -184,6 +192,18 @@
     unsigned short __pad1;
     unsigned long __unused1;
     unsigned long __unused2;
+#elif defined(__sparc__)
+# if defined(__arch64__)
+    unsigned mode;
+    unsigned short __pad1;
+# else
+    unsigned short __pad1;
+    unsigned short mode;
+    unsigned short __pad2;
+# endif
+    unsigned short __seq;
+    unsigned long long __unused1;
+    unsigned long long __unused2;
 #else
     unsigned short mode;
     unsigned short __pad1;
@@ -201,6 +221,26 @@
 
   struct __sanitizer_shmid_ds {
     __sanitizer_ipc_perm shm_perm;
+  #if defined(__sparc__)
+  # if !defined(__arch64__)
+    u32 __pad1;
+  # endif
+    long shm_atime;
+  # if !defined(__arch64__)
+    u32 __pad2;
+  # endif
+    long shm_dtime;
+  # if !defined(__arch64__)
+    u32 __pad3;
+  # endif
+    long shm_ctime;
+    uptr shm_segsz;
+    int shm_cpid;
+    int shm_lpid;
+    unsigned long shm_nattch;
+    unsigned long __glibc_reserved1;
+    unsigned long __glibc_reserved2;
+  #else    
   #ifndef __powerpc__
     uptr shm_segsz;
   #elif !defined(__powerpc64__)
@@ -238,6 +278,7 @@
     uptr __unused4;
     uptr __unused5;
   #endif
+#endif
   };
 #elif SANITIZER_FREEBSD
   struct __sanitizer_ipc_perm {
@@ -555,9 +596,13 @@
 #else
     __sanitizer_sigset_t sa_mask;
 #ifndef __mips__
+#if defined(__sparc__)
+    unsigned long sa_flags;
+#else
     int sa_flags;
 #endif
 #endif
+#endif
 #if SANITIZER_LINUX
     void (*sa_restorer)();
 #endif
@@ -799,7 +844,7 @@
 
 #define IOC_NRBITS 8
 #define IOC_TYPEBITS 8
-#if defined(__powerpc__) || defined(__powerpc64__) || defined(__mips__)
+#if defined(__powerpc__) || defined(__powerpc64__) || defined(__mips__) || defined(__sparc__)
 #define IOC_SIZEBITS 13
 #define IOC_DIRBITS 3
 #define IOC_NONE 1U
@@ -829,7 +874,17 @@
 #define IOC_DIR(nr) (((nr) >> IOC_DIRSHIFT) & IOC_DIRMASK)
 #define IOC_TYPE(nr) (((nr) >> IOC_TYPESHIFT) & IOC_TYPEMASK)
 #define IOC_NR(nr) (((nr) >> IOC_NRSHIFT) & IOC_NRMASK)
+
+#if defined(__sparc__)
+// In sparc the 14 bits SIZE field overlaps with the
+// least significant bit of DIR, so either IOC_READ or
+// IOC_WRITE shall be 1 in order to get a non-zero SIZE.
+# define IOC_SIZE(nr)                       \
+  ((((((nr) >> 29) & 0x7) & (4U|2U)) == 0)? \
+   0 : (((nr) >> 16) & 0x3fff))
+#else
 #define IOC_SIZE(nr) (((nr) >> IOC_SIZESHIFT) & IOC_SIZEMASK)
+#endif
 
   extern unsigned struct_ifreq_sz;
   extern unsigned struct_termios_sz;

Re: [PATCH 3/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Tue, Oct 13, 2015 at 02:17:46PM +0300, Maxim Ostapenko wrote:
> This is just reapplied patch for SPARC by David S. Miller. I was unable to
> test this, so could anyone help me here?

This is ok if all the other changes are approved.  You don't need to list
my name in there, just list David's.  We don't want 20 copies of Reapply in
a few years.

> 2015-10-12  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
> 
> 	PR sanitizer/63958
> 	Reapply:
> 	2015-03-09  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR sanitizer/63958
> 	Reapply:
> 	2014-10-14  David S. Miller  <davem@davemloft.net>
> 
> 	* sanitizer_common/sanitizer_platform_limits_linux.cc (time_t):
> 	Define at __kernel_time_t, as needed for sparc.
> 	(struct __old_kernel_stat): Don't check if __sparc__ is defined.
> 	* libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> 	(__sanitizer): Define struct___old_kernel_stat_sz,
> 	struct_kernel_stat_sz, and struct_kernel_stat64_sz for sparc.
> 	(__sanitizer_ipc_perm): Adjust for sparc targets.
> 	(__sanitizer_shmid_ds): Likewsie.
> 	(__sanitizer_sigaction): Likewise.
> 	(IOC_SIZE): Likewsie.

	Jakub

[PATCH 5/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

This patch removes UBSan stubs from ASan and TSan code. We don't embed 
UBSan to ASan and UBSan because that would lead to undefined references 
to C++ stuff when linking with -static-libasan. AFAIK, sanitizer 
developers use different libraries for C and CXX runtimes, but I think 
this is out of scope of this merge.

[-- Attachment #2: 5.diff --]
[-- Type: text/x-patch, Size: 2499 bytes --]

2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

	* tsan/tsan_defs.h: Define TSAN_CONTAINS_UBSAN to 0.
	* asan/asan_flags.cc (InitializeFlags): Do not initialize UBSan flags.
	* asan/asan_rtl.cc (AsanInitInternal): Do not init UBSan.

Index: libsanitizer/asan/asan_flags.cc
===================================================================
--- libsanitizer/asan/asan_flags.cc	(revision 250059)
+++ libsanitizer/asan/asan_flags.cc	(working copy)
@@ -86,15 +86,6 @@
   RegisterCommonFlags(&lsan_parser);
 #endif
 
-#if CAN_SANITIZE_UB
-  __ubsan::Flags *uf = __ubsan::flags();
-  uf->SetDefaults();
-
-  FlagParser ubsan_parser;
-  __ubsan::RegisterUbsanFlags(&ubsan_parser, uf);
-  RegisterCommonFlags(&ubsan_parser);
-#endif
-
   // Override from ASan compile definition.
   const char *asan_compile_def = MaybeUseAsanDefaultOptionsCompileDefinition();
   asan_parser.ParseString(asan_compile_def);
@@ -102,20 +93,11 @@
   // Override from user-specified string.
   const char *asan_default_options = MaybeCallAsanDefaultOptions();
   asan_parser.ParseString(asan_default_options);
-#if CAN_SANITIZE_UB
-  const char *ubsan_default_options = __ubsan::MaybeCallUbsanDefaultOptions();
-  ubsan_parser.ParseString(ubsan_default_options);
-#endif
-
   // Override from command line.
   asan_parser.ParseString(GetEnv("ASAN_OPTIONS"));
 #if CAN_SANITIZE_LEAKS
   lsan_parser.ParseString(GetEnv("LSAN_OPTIONS"));
 #endif
-#if CAN_SANITIZE_UB
-  ubsan_parser.ParseString(GetEnv("UBSAN_OPTIONS"));
-#endif
-
   // Let activation flags override current settings. On Android they come
   // from a system property. On other platforms this is no-op.
   if (!flags()->start_deactivated) {
Index: libsanitizer/asan/asan_rtl.cc
===================================================================
--- libsanitizer/asan/asan_rtl.cc	(revision 250059)
+++ libsanitizer/asan/asan_rtl.cc	(working copy)
@@ -513,10 +513,6 @@
   }
 #endif  // CAN_SANITIZE_LEAKS
 
-#if CAN_SANITIZE_UB
-  __ubsan::InitAsPlugin();
-#endif
-
   InitializeSuppressions();
 
   VReport(1, "AddressSanitizer Init done\n");
Index: libsanitizer/tsan/rtl/tsan_defs.h
===================================================================
--- libsanitizer/tsan/tsan_defs.h	(revision 250059)
+++ libsanitizer/tsan/tsan_defs.h	(working copy)
@@ -29,7 +29,7 @@
 #endif
 
 #ifndef TSAN_CONTAINS_UBSAN
-# define TSAN_CONTAINS_UBSAN (CAN_SANITIZE_UB && !defined(SANITIZER_GO))
+# define TSAN_CONTAINS_UBSAN 0
 #endif
 
 namespace __tsan {

Re: [PATCH 5/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Tue, Oct 13, 2015 at 02:20:06PM +0300, Maxim Ostapenko wrote:
> This patch removes UBSan stubs from ASan and TSan code. We don't embed UBSan
> to ASan and UBSan because that would lead to undefined references to C++
> stuff when linking with -static-libasan. AFAIK, sanitizer developers use
> different libraries for C and CXX runtimes, but I think this is out of scope
> of this merge.

Where is CAN_SANITIZE_UB defined?  I don't see it anywhere in the current
libsanitizer and in the patch only:
grep CAN_SANITIZE_UB libsanitizer-249633-2.diff 
+#if CAN_SANITIZE_UB
+# define TSAN_CONTAINS_UBSAN (CAN_SANITIZE_UB && !defined(SANITIZER_GO))
+#if CAN_SANITIZE_UB
+#endif  // CAN_SANITIZE_UB
+#if CAN_SANITIZE_UB
+#endif  // CAN_SANITIZE_UB
+#if CAN_SANITIZE_UB
+#endif  // CAN_SANITIZE_UB
+#if CAN_SANITIZE_UB
+#endif  // CAN_SANITIZE_UB
+#if CAN_SANITIZE_UB
+#endif  // CAN_SANITIZE_UB
+#if CAN_SANITIZE_UB
+#endif  // CAN_SANITIZE_UB
+#if CAN_SANITIZE_UB
+#endif  // CAN_SANITIZE_UB

So, unless I'm missing something, it would be best to arrange for
-DCAN_SANITIZE_UB=1 to be in CXXFLAGS for ubsan/ source files and
-DCAN_SANITIZE_UB=0 to be in CXXFLAGS for {a,t}san/ source files?
Are there any other defines that are supposedly set from cmake or wherever
upstream and are left undefined?

> 2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
> 
> 	* tsan/tsan_defs.h: Define TSAN_CONTAINS_UBSAN to 0.
> 	* asan/asan_flags.cc (InitializeFlags): Do not initialize UBSan flags.
> 	* asan/asan_rtl.cc (AsanInitInternal): Do not init UBSan.

	Jakub

Re: [PATCH 5/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

On 14/10/15 10:37, Jakub Jelinek wrote:
> On Tue, Oct 13, 2015 at 02:20:06PM +0300, Maxim Ostapenko wrote:
>> This patch removes UBSan stubs from ASan and TSan code. We don't embed UBSan
>> to ASan and UBSan because that would lead to undefined references to C++
>> stuff when linking with -static-libasan. AFAIK, sanitizer developers use
>> different libraries for C and CXX runtimes, but I think this is out of scope
>> of this merge.
> Where is CAN_SANITIZE_UB defined?  I don't see it anywhere in the current
> libsanitizer and in the patch only:
> grep CAN_SANITIZE_UB libsanitizer-249633-2.diff
> +#if CAN_SANITIZE_UB
> +# define TSAN_CONTAINS_UBSAN (CAN_SANITIZE_UB && !defined(SANITIZER_GO))
> +#if CAN_SANITIZE_UB
> +#endif  // CAN_SANITIZE_UB
> +#if CAN_SANITIZE_UB
> +#endif  // CAN_SANITIZE_UB
> +#if CAN_SANITIZE_UB
> +#endif  // CAN_SANITIZE_UB
> +#if CAN_SANITIZE_UB
> +#endif  // CAN_SANITIZE_UB
> +#if CAN_SANITIZE_UB
> +#endif  // CAN_SANITIZE_UB
> +#if CAN_SANITIZE_UB
> +#endif  // CAN_SANITIZE_UB
> +#if CAN_SANITIZE_UB
> +#endif  // CAN_SANITIZE_UB

Hm, this is strange, perhaps the patch was malformed.

>
> So, unless I'm missing something, it would be best to arrange for
> -DCAN_SANITIZE_UB=1 to be in CXXFLAGS for ubsan/ source files and
> -DCAN_SANITIZE_UB=0 to be in CXXFLAGS for {a,t}san/ source files?

CAN_SANITIZE_UB definition is hardcoded into new ubsan/ubsan_platform.h 
file. To use DCAN_SANITIZE_UB from CXXFLAGS, we still need some changes 
in libsanitizer against upstream:

Index: libsanitizer/ubsan/ubsan_platform.h
===================================================================
--- libsanitizer/ubsan/ubsan_platform.h    (revision 250295)
+++ libsanitizer/ubsan/ubsan_platform.h    (working copy)
@@ -13,6 +13,7 @@
  #ifndef UBSAN_PLATFORM_H
  #define UBSAN_PLATFORM_H

+#ifndef CAN_SANITIZE_UB
  // Other platforms should be easy to add, and probably work as-is.
  #if (defined(__linux__) || defined(__FreeBSD__) || defined(__APPLE__)) 
&& \
      (defined(__x86_64__) || defined(__i386__) || defined(__arm__) || \
@@ -23,5 +24,6 @@
  #else
  # define CAN_SANITIZE_UB 0
  #endif
+#endif // CAN_SANITIZE_UB

  #endif

> Are there any other defines that are supposedly set from cmake or wherever
> upstream and are left undefined?

There is ASAN_DYNAMIC macro, but I see it into current libsanitizer too 
and it's not touched in any Makefile. Same for 
ASAN_DYNAMIC_RUNTIME_THUNK, that is used for Windows build and 
ASAN_LOW_MEMORY, that set explicitly only for Android. Do we need to 
touch them?
Also, ASAN_FLEXIBLE_MAPPING_AND_OFFSET was bumped upstream, so we don't 
need it anymore.

I'm applying the patch mentioned above, redefining CAN_SANITIZE_UB in 
corresponding Makefiles, dropping ASAN_FLEXIBLE_MAPPING_AND_OFFSET and 
resending libsanitizer-249633-2.diff in corresponding thread.
>> 2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
>>
>> 	* tsan/tsan_defs.h: Define TSAN_CONTAINS_UBSAN to 0.
>> 	* asan/asan_flags.cc (InitializeFlags): Do not initialize UBSan flags.
>> 	* asan/asan_rtl.cc (AsanInitInternal): Do not init UBSan.
> 	Jakub
>

[PATCH 6/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 165 bytes --]

This patch adjusts the fix for 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 to extract the last 
PC from the stack frame if no valid FP is available for ARM.

[-- Attachment #2: 6.diff --]
[-- Type: text/x-patch, Size: 906 bytes --]

2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

	* sanitizer_common/sanitizer_stacktrace.cc (GetCanonicFrame): Assume we
	compiled code with GCC when extracting the caller PC for ARM if no
	valid frame pointer is available.

Index: libsanitizer/sanitizer_common/sanitizer_stacktrace.cc
===================================================================
--- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc	(revision 250059)
+++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc	(working copy)
@@ -62,8 +62,8 @@
   // Nope, this does not look right either. This means the frame after next does
   // not have a valid frame pointer, but we can still extract the caller PC.
   // Unfortunately, there is no way to decide between GCC and LLVM frame
-  // layouts. Assume LLVM.
-  return bp_prev;
+  // layouts. Assume GCC.
+  return bp_prev - 1;
 #else
   return (uhwptr*)bp;
 #endif

Re: [PATCH 6/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Tue, Oct 13, 2015 at 02:21:21PM +0300, Maxim Ostapenko wrote:
> This patch adjusts the fix for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 to extract the last PC
> from the stack frame if no valid FP is available for ARM.

I guess this is ok once all other changes are acked.

> 2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
> 
> 	* sanitizer_common/sanitizer_stacktrace.cc (GetCanonicFrame): Assume we
> 	compiled code with GCC when extracting the caller PC for ARM if no
> 	valid frame pointer is available.
> 
> Index: libsanitizer/sanitizer_common/sanitizer_stacktrace.cc
> ===================================================================
> --- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc	(revision 250059)
> +++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc	(working copy)
> @@ -62,8 +62,8 @@
>    // Nope, this does not look right either. This means the frame after next does
>    // not have a valid frame pointer, but we can still extract the caller PC.
>    // Unfortunately, there is no way to decide between GCC and LLVM frame
> -  // layouts. Assume LLVM.
> -  return bp_prev;
> +  // layouts. Assume GCC.
> +  return bp_prev - 1;
>  #else
>    return (uhwptr*)bp;
>  #endif


	Jakub

[PATCH 7/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

This is the final patch. Force libsanitizer to use an old ABI for ubsan 
float cast data descriptors, because for some exprs (e.g. that type of 
tcc_declaration) we can't get the right location for now. I'm not sure 
about this, perhaps it should be fixed in GCC somehow.

[-- Attachment #2: 7.diff --]
[-- Type: text/x-patch, Size: 702 bytes --]

2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

	* ubsan/ubsan_handlers.cc (looksLikeFloatCastOverflowDataV1): Always
	return true for now.

Index: libsanitizer/ubsan/ubsan_handlers.cc
===================================================================
--- libsanitizer/ubsan/ubsan_handlers.cc	(revision 250059)
+++ libsanitizer/ubsan/ubsan_handlers.cc	(working copy)
@@ -307,6 +307,9 @@
 }
 
 static bool looksLikeFloatCastOverflowDataV1(void *Data) {
+  // (TODO): propagate SourceLocation into DataDescriptor and use this
+  // heuristic than.
+  return true;
   // First field is either a pointer to filename or a pointer to a
   // TypeDescriptor.
   u8 *FilenameOrTypeDescriptor;

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Tue, Oct 13, 2015 at 02:22:36PM +0300, Maxim Ostapenko wrote:
> This is the final patch. Force libsanitizer to use an old ABI for ubsan
> float cast data descriptors, because for some exprs (e.g. that type of
> tcc_declaration) we can't get the right location for now. I'm not sure about
> this, perhaps it should be fixed in GCC somehow.

I don't like this (neither the heuristics on the libubsan, it wouldn't be a
big deal to add a new library entrypoint).
If because of the heuristics you need to ensure that the SourceLocation is
always known, then either you check in ubsan.c whether expand_location
gives you NULL xloc.file and in that case use old style float cast overflow
(without location) - i.e. pass 0, NULL, otherwise you use new style, i.e.
pass 1, &loc.  Or arrange through some special option to emit something like
{ "<unknown>", 0, 0 } instead of { NULL, 0, 0 } for the float cast case.
And, regardless of this, any progress in making sure we have fewer cases
with UNKNOWN_LOCATION on this will not hurt.  I think at this point I'd
prefer the first choice, i.e. using old style for locations without
filename, and new style otherwise.

> 2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
> 
> 	* ubsan/ubsan_handlers.cc (looksLikeFloatCastOverflowDataV1): Always
> 	return true for now.
> 
> Index: libsanitizer/ubsan/ubsan_handlers.cc
> ===================================================================
> --- libsanitizer/ubsan/ubsan_handlers.cc	(revision 250059)
> +++ libsanitizer/ubsan/ubsan_handlers.cc	(working copy)
> @@ -307,6 +307,9 @@
>  }
>  
>  static bool looksLikeFloatCastOverflowDataV1(void *Data) {
> +  // (TODO): propagate SourceLocation into DataDescriptor and use this
> +  // heuristic than.
> +  return true;
>    // First field is either a pointer to filename or a pointer to a
>    // TypeDescriptor.
>    u8 *FilenameOrTypeDescriptor;


	Jakub

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

On 14/10/15 10:48, Jakub Jelinek wrote:
> On Tue, Oct 13, 2015 at 02:22:36PM +0300, Maxim Ostapenko wrote:
>> This is the final patch. Force libsanitizer to use an old ABI for ubsan
>> float cast data descriptors, because for some exprs (e.g. that type of
>> tcc_declaration) we can't get the right location for now. I'm not sure about
>> this, perhaps it should be fixed in GCC somehow.
> I don't like this (neither the heuristics on the libubsan, it wouldn't be a
> big deal to add a new library entrypoint).
> If because of the heuristics you need to ensure that the SourceLocation is
> always known, then either you check in ubsan.c whether expand_location
> gives you NULL xloc.file and in that case use old style float cast overflow
> (without location) - i.e. pass 0, NULL, otherwise you use new style, i.e.
> pass 1, &loc.  Or arrange through some special option to emit something like
> { "<unknown>", 0, 0 } instead of { NULL, 0, 0 } for the float cast case.
> And, regardless of this, any progress in making sure we have fewer cases
> with UNKNOWN_LOCATION on this will not hurt.  I think at this point I'd
> prefer the first choice, i.e. using old style for locations without
> filename, and new style otherwise.
>
>> 2015-10-13  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>
>>
>> 	* ubsan/ubsan_handlers.cc (looksLikeFloatCastOverflowDataV1): Always
>> 	return true for now.
>>
>> Index: libsanitizer/ubsan/ubsan_handlers.cc
>> ===================================================================
>> --- libsanitizer/ubsan/ubsan_handlers.cc	(revision 250059)
>> +++ libsanitizer/ubsan/ubsan_handlers.cc	(working copy)
>> @@ -307,6 +307,9 @@
>>   }
>>   
>>   static bool looksLikeFloatCastOverflowDataV1(void *Data) {
>> +  // (TODO): propagate SourceLocation into DataDescriptor and use this
>> +  // heuristic than.
>> +  return true;
>>     // First field is either a pointer to filename or a pointer to a
>>     // TypeDescriptor.
>>     u8 *FilenameOrTypeDescriptor;
>
> 	Jakub
>

Ok, got it. The first solution would require changes in libsanitizer 
because heuristic doesn't work for GCC, so perhaps new UBSan entry point 
should go upstream, right? Or this may be implemented as local patch for 
GCC?

BTW, I actually saw UNKNOWN_LOCATION for this expr:

volatile double var;  // this is tcc_decaration, so we have 
UNKNOWN_LOCATION for it.

I wonder if we need emit __ubsan_handle_float_cast_overflow here at all.

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
> Ok, got it. The first solution would require changes in libsanitizer because
> heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
> upstream, right? Or this may be implemented as local patch for GCC?

No.  The heuristics relies on:
1) either it is old style float cast overflow without location
2) or it is new style float cast with location, but the location must:
   a) not have NULL filename
   b) the filename must not be ""
   c) the filename must not be "\1"
So, my proposal was to emit in GCC the old style float cast overflow if a), b) or
c) is true, otherwise the new style.  I have no idea what you mean by
heuristic doesn't work for GCC after that.

> BTW, I actually saw UNKNOWN_LOCATION for this expr:
> 
> volatile double var;  // this is tcc_decaration, so we have UNKNOWN_LOCATION
> for it.

This is not a complete testcase, so I wonder what exactly you are talking
about.  The above doesn't not generate any
__ubsan_handle_float_cast_overflow calls with
-fsanitize=float-cast-overflow, and
volatile double d;
int bar (void) { return d; }
has location.

	Jakub

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

On 14/10/15 14:06, Jakub Jelinek wrote:
> On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
>> Ok, got it. The first solution would require changes in libsanitizer because
>> heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
>> upstream, right? Or this may be implemented as local patch for GCC?
> No.  The heuristics relies on:
> 1) either it is old style float cast overflow without location
> 2) or it is new style float cast with location, but the location must:
>     a) not have NULL filename
>     b) the filename must not be ""
>     c) the filename must not be "\1"
> So, my proposal was to emit in GCC the old style float cast overflow if a), b) or
> c) is true, otherwise the new style.  I have no idea what you mean by
> heuristic doesn't work for GCC after that.

I mean that there are some cases where (FilenameOrTypeDescriptor[0] + 
FilenameOrTypeDescriptor[1] < 2) is not sufficient to determine if we 
should use old style. I actually caught this on float-cast-overflow-10.c 
testcase. Here:

$ /home/max/build/master-ref/gcc/xgcc -B/home/max/build/master-ref/gcc/ 
/home/max/workspace/downloads/svn/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-10.c 
-B/home/max/build/master-ref/x86_64-unknown-linux-gnu/./libsanitizer/ 
-B/home/max/build/master-ref/x86_64-unknown-linux-gnu/./libsanitizer/ubsan/ 
-L/home/max/build/master-ref/x86_64-unknown-linux-gnu/./libsanitizer/ubsan/.libs 
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 
-fsanitize=float-cast-overflow -fsanitize-recover=float-cast-overflow 
-DUSE_INT128 -DUSE_DFP -DBROKEN_DECIMAL_INT128 -lm -o 
./float-cast-overflow-10.s -S

$ cat float-cast-overflow-10.s

cvt_sc_d32:
.LFB0:
         .cfi_startproc
         pushq   %rbx
......
.L6:
         movl    %ebx, %esi
         movl    $.Lubsan_data0, %edi
         call    __ubsan_handle_float_cast_overflow
.......
.Lubsan_data0:
         .quad   .Lubsan_type1
         .quad   .Lubsan_type0
         .align 2
         .type   .Lubsan_type1, @object
         .size   .Lubsan_type1, 17
.Lubsan_type1:
         .value  -1  // <- TypeKind
         .value  32
         .string "'_Decimal32'"
         .align 2
         .type   .Lubsan_type0, @object
         .size   .Lubsan_type0, 18
.Lubsan_type0:
         .value  0 // <- TypeKind
         .value  7
         .string "'signed char'"
         .section        .rodata.cst4,"aM",@progbits,4
         .align 4

Here, one can see, we have FilenameOrTypeDescriptor[0]  == -1 and 
FilenameOrTypeDescriptor[1] == 0. So, we end up with wrong decision and 
have SEGV later.
>> BTW, I actually saw UNKNOWN_LOCATION for this expr:
>>
>> volatile double var;  // this is tcc_decaration, so we have UNKNOWN_LOCATION
>> for it.
> This is not a complete testcase, so I wonder what exactly you are talking
> about.  The above doesn't not generate any
> __ubsan_handle_float_cast_overflow calls with
> -fsanitize=float-cast-overflow, and
> volatile double d;
> int bar (void) { return d; }
> has location.
>
> 	Jakub
>

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Wed, Oct 14, 2015 at 03:02:22PM +0300, Maxim Ostapenko wrote:
> On 14/10/15 14:06, Jakub Jelinek wrote:
> >On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
> >>Ok, got it. The first solution would require changes in libsanitizer because
> >>heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
> >>upstream, right? Or this may be implemented as local patch for GCC?
> >No.  The heuristics relies on:
> >1) either it is old style float cast overflow without location
> >2) or it is new style float cast with location, but the location must:
> >    a) not have NULL filename
> >    b) the filename must not be ""
> >    c) the filename must not be "\1"
> >So, my proposal was to emit in GCC the old style float cast overflow if a), b) or
> >c) is true, otherwise the new style.  I have no idea what you mean by
> >heuristic doesn't work for GCC after that.
> 
> I mean that there are some cases where (FilenameOrTypeDescriptor[0] +
> FilenameOrTypeDescriptor[1] < 2) is not sufficient to determine if we should
> use old style. I actually caught this on float-cast-overflow-10.c testcase.

Ah, ok, in that case the heuristics is flawed.  If they want to keep it,
they should check if MaybeFromTypeKind is either < 2 or equal to 0x1fe.
Can you report it upstream?  If that is changed, we'd need to change the
above and also add
  d) the filename must not start with "\xff\xff"
to the rules.

I think it would be better to just add a whole new entrypoint, but if they
think the heuristics is good enough, they should at least fix it up.

	Jakub

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

On 14/10/15 15:12, Jakub Jelinek wrote:
> On Wed, Oct 14, 2015 at 03:02:22PM +0300, Maxim Ostapenko wrote:
>> On 14/10/15 14:06, Jakub Jelinek wrote:
>>> On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
>>>> Ok, got it. The first solution would require changes in libsanitizer because
>>>> heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
>>>> upstream, right? Or this may be implemented as local patch for GCC?
>>> No.  The heuristics relies on:
>>> 1) either it is old style float cast overflow without location
>>> 2) or it is new style float cast with location, but the location must:
>>>     a) not have NULL filename
>>>     b) the filename must not be ""
>>>     c) the filename must not be "\1"
>>> So, my proposal was to emit in GCC the old style float cast overflow if a), b) or
>>> c) is true, otherwise the new style.  I have no idea what you mean by
>>> heuristic doesn't work for GCC after that.
>> I mean that there are some cases where (FilenameOrTypeDescriptor[0] +
>> FilenameOrTypeDescriptor[1] < 2) is not sufficient to determine if we should
>> use old style. I actually caught this on float-cast-overflow-10.c testcase.
> Ah, ok, in that case the heuristics is flawed.  If they want to keep it,
> they should check if MaybeFromTypeKind is either < 2 or equal to 0x1fe.
> Can you report it upstream?  If that is changed, we'd need to change the
> above and also add
>    d) the filename must not start with "\xff\xff"
> to the rules.
>
> I think it would be better to just add a whole new entrypoint, but if they
> think the heuristics is good enough, they should at least fix it up.
>
> 	Jakub
>

Done. I've realized that we could just set loc to input_location if loc 
== UNKNOWN_LOCATION. In this case, we always would have new style. This 
would require some changes in tests, because upstream UBSan suppress 
different reports for one location. How about this?

-Maxim

[-- Attachment #2: 2.diff --]
[-- Type: text/x-patch, Size: 34185 bytes --]

gcc/ChangeLog:

2015-10-16  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

	* ubsan.c (ubsan_instrument_float_cast): If location is unknown, assign
	 input_location to loc. Propagate loc to ubsan_create_data.

gcc/testsuite/ChangeLog:

2015-10-16  Maxim Ostapenko  <m.ostapenko@partner.samsung.com>

	* c-c++-common/ubsan/float-cast-overflow-10.c: Adjust test.
	* c-c++-common/ubsan/float-cast-overflow-8.c: Likewise.
	* c-c++-common/ubsan/float-cast-overflow-9.c: Likewise.

Index: gcc/ubsan.c
===================================================================
--- gcc/ubsan.c	(revision 228817)
+++ gcc/ubsan.c	(working copy)
@@ -1484,6 +1484,7 @@
   machine_mode mode = TYPE_MODE (expr_type);
   int prec = TYPE_PRECISION (type);
   bool uns_p = TYPE_UNSIGNED (type);
+  if (loc == UNKNOWN_LOCATION) loc = input_location;
 
   /* Float to integer conversion first truncates toward zero, so
      even signed char c = 127.875f; is not problematic.
@@ -1581,8 +1582,8 @@
   else
     {
       /* Create the __ubsan_handle_float_cast_overflow fn call.  */
-      tree data = ubsan_create_data ("__ubsan_float_cast_overflow_data", 0,
-				     NULL, ubsan_type_descriptor (expr_type),
+      tree data = ubsan_create_data ("__ubsan_float_cast_overflow_data", 1,
+				     &loc, ubsan_type_descriptor (expr_type),
 				     ubsan_type_descriptor (type), NULL_TREE,
 				     NULL_TREE);
       enum built_in_function bcode
Index: gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-10.c
===================================================================
--- gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-10.c	(revision 228817)
+++ gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-10.c	(working copy)
@@ -10,70 +10,37 @@
 
 /* _Decimal32 */
 /* { dg-output "value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* _Decimal64 */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* _Decimal128 */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'" } */
Index: gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
===================================================================
--- gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c	(revision 228817)
+++ gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c	(working copy)
@@ -100,106 +100,44 @@
 
 /* float */
 /* { dg-output "value -129 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "value \[0-9.e+-]* is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value 128 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value (-129|-1) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value (128|256) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 256 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -32769 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value 32768 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 65536 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
 /* No error for float and __int128 unsigned max value, as ui128_MAX is +Inf in float.  */
 /* double */
 /* { dg-output "\[^\n\r]*value -129 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value 128 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value (-129|-1) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value (128|256) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 256 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -32769 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value 32768 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 65536 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
 /* long double */
 /* { dg-output "\[^\n\r]*value -129 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value 128 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value (-129|-1) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value (128|256) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 256 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -32769 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
-/* { dg-output "\[^\n\r]*value 32768 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 65536 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" { target { ilp32 || lp64 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" { target { ! { ilp32 || lp64 } } } } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long unsigned int'" } */
-/* { dg-output "(\n|\r\n|\r)\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128 unsigned'" { target { int128 } } } */
Index: gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-9.c
===================================================================
--- gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-9.c	(revision 228817)
+++ gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-9.c	(working copy)
@@ -7,55 +7,29 @@
 
 /* __float80 */
 /* { dg-output "value -129 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 128 is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value (-129|-1) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value (128|256) is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 256 is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -32769 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 32768 is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value 65536 is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target int128 } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target int128 } } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target int128 } } */
-/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of representable values of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target int128 } } */
 /* __float128 */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'signed char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned char'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'short unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target int128 } } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target int128 } } */
 /* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target int128 } } */
-/* { dg-output "\[^\n\r]*value <unknown> is outside the range of representable values of type '__int128 unsigned'" { target int128 } } */

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Fri, Oct 16, 2015 at 02:29:08PM +0300, Maxim Ostapenko wrote:
> On 14/10/15 15:12, Jakub Jelinek wrote:
> >On Wed, Oct 14, 2015 at 03:02:22PM +0300, Maxim Ostapenko wrote:
> >>On 14/10/15 14:06, Jakub Jelinek wrote:
> >>>On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
> >>>>Ok, got it. The first solution would require changes in libsanitizer because
> >>>>heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
> >>>>upstream, right? Or this may be implemented as local patch for GCC?
> >>>No.  The heuristics relies on:
> >>>1) either it is old style float cast overflow without location
> >>>2) or it is new style float cast with location, but the location must:
> >>>    a) not have NULL filename
> >>>    b) the filename must not be ""
> >>>    c) the filename must not be "\1"
> >>>So, my proposal was to emit in GCC the old style float cast overflow if a), b) or
> >>>c) is true, otherwise the new style.  I have no idea what you mean by
> >>>heuristic doesn't work for GCC after that.
> >>I mean that there are some cases where (FilenameOrTypeDescriptor[0] +
> >>FilenameOrTypeDescriptor[1] < 2) is not sufficient to determine if we should
> >>use old style. I actually caught this on float-cast-overflow-10.c testcase.
> >Ah, ok, in that case the heuristics is flawed.  If they want to keep it,
> >they should check if MaybeFromTypeKind is either < 2 or equal to 0x1fe.
> >Can you report it upstream?  If that is changed, we'd need to change the
> >above and also add
> >   d) the filename must not start with "\xff\xff"
> >to the rules.
> >
> >I think it would be better to just add a whole new entrypoint, but if they
> >think the heuristics is good enough, they should at least fix it up.
> >
> >	Jakub
> >
> 
> Done. I've realized that we could just set loc to input_location if loc ==
> UNKNOWN_LOCATION. In this case, we always would have new style. This would

While using input_location in this case (as it is invoked from the FEs)
might help sometimes, it still doesn't guarantee input_location will not
be UNKNOWN_LOCATION afterwards, or builtin location, or b), c) or d) above.

Plus there is no fix on the library side to the heuristics, which we need
anyway.

	Jakub

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

On 13/10/15 14:15, Maxim Ostapenko wrote:
> This is the raw merge itself. I'm bumping SONAME to libasan.so.3.
>
> -Maxim

I have just noticed that I've misused autoconf stuff (used wrong 
version). Here a fixed version of the same patch. Sorry for inconvenience.

-Maxim

[-- Attachment #2: libsanitizer-249633-2.tar.bz --]
[-- Type: application/x-bzip, Size: 230819 bytes --]

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Jakub Jelinek]

On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote:
> On 13/10/15 14:15, Maxim Ostapenko wrote:
> >This is the raw merge itself. I'm bumping SONAME to libasan.so.3.
> >
> >-Maxim
> 
> I have just noticed that I've misused autoconf stuff (used wrong version).
> Here a fixed version of the same patch. Sorry for inconvenience.

Is libubsan, libtsan backwards compatible, or do we want to change SONAME
there too?

The aarch64 changes are terrible, not just because it doesn't yet have
runtime decision on what VA to use or that it doesn't support 48-bit VA,
but also that for the 42-bit VA it uses a different shadow offset from
39-bit VA.  But on the compiler side we have just one...
Though, only the 39-bit VA is enabled right now by default, so out of the
box the state is as bad as we had in 5.x - users wanting 42-bit VA or 48-bit
VA have to patch libsanitizer.

Have you verified libbacktrace sanitization still works properly (that is
something upstream does not test)?

Do you plan to update the asan tests we have to reflect the changes in
upstream?

	Jakub

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

On 14/10/15 10:54, Jakub Jelinek wrote:
> On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote:
>> On 13/10/15 14:15, Maxim Ostapenko wrote:
>>> This is the raw merge itself. I'm bumping SONAME to libasan.so.3.
>>>
>>> -Maxim
>> I have just noticed that I've misused autoconf stuff (used wrong version).
>> Here a fixed version of the same patch. Sorry for inconvenience.
> Is libubsan, libtsan backwards compatible, or do we want to change SONAME
> there too?

No, they are not (for UBSan heuristic doesn't work well for GCC, TSan 
has some type changes into interceptors and data structures, e.g. in 
struct ReportStack). I  can share more details, if desired.

>
> The aarch64 changes are terrible, not just because it doesn't yet have
> runtime decision on what VA to use or that it doesn't support 48-bit VA,
> but also that for the 42-bit VA it uses a different shadow offset from
> 39-bit VA.  But on the compiler side we have just one...
> Though, only the 39-bit VA is enabled right now by default, so out of the
> box the state is as bad as we had in 5.x - users wanting 42-bit VA or 48-bit
> VA have to patch libsanitizer.
>
> Have you verified libbacktrace sanitization still works properly (that is
> something upstream does not test)?

I'm sorry, didn't catch well your words about libbacktrace sanitization. 
Did you mean symbolization? If so, I didn't perform any special 
validation here (thought output patterns tests use libbacktrace output, 
no?). But I wonder how can I verify this more or less automatically.

>
> Do you plan to update the asan tests we have to reflect the changes in
> upstream?

Hm, there aren't changes into instrumentation, so the only thing is new 
interceptors. If it is desirable, I can migrate some tests for new 
interceptors from upstream.

>
> 	Jakub
>

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Yury Gribov]

On 10/14/2015 12:34 PM, Maxim Ostapenko wrote:
> On 14/10/15 10:54, Jakub Jelinek wrote:
>> Do you plan to update the asan tests we have to reflect the changes in
>> upstream?
>
> Hm, there aren't changes into instrumentation, so the only thing is new
> interceptors. If it is desirable, I can migrate some tests for new
> interceptors from upstream.

What about e.g. "-Improvements for ASan deactivated start were performed"?

-Y

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On 14/10/15 12:34, Maxim Ostapenko wrote:
> On 14/10/15 10:54, Jakub Jelinek wrote:
>> On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote:
>>> On 13/10/15 14:15, Maxim Ostapenko wrote:
>>>> This is the raw merge itself. I'm bumping SONAME to libasan.so.3.
>>>>
>>>> -Maxim
>>> I have just noticed that I've misused autoconf stuff (used wrong 
>>> version).
>>> Here a fixed version of the same patch. Sorry for inconvenience.
>> Is libubsan, libtsan backwards compatible, or do we want to change 
>> SONAME
>> there too?
>
> No, they are not (for UBSan heuristic doesn't work well for GCC, TSan 
> has some type changes into interceptors and data structures, e.g. in 
> struct ReportStack). I  can share more details, if desired.
>
>>
>> The aarch64 changes are terrible, not just because it doesn't yet have
>> runtime decision on what VA to use or that it doesn't support 48-bit VA,
>> but also that for the 42-bit VA it uses a different shadow offset from
>> 39-bit VA.  But on the compiler side we have just one...
>> Though, only the 39-bit VA is enabled right now by default, so out of 
>> the
>> box the state is as bad as we had in 5.x - users wanting 42-bit VA or 
>> 48-bit
>> VA have to patch libsanitizer.
>>
>> Have you verified libbacktrace sanitization still works properly 
>> (that is
>> something upstream does not test)?
>
> I'm sorry, didn't catch well your words about libbacktrace 
> sanitization. Did you mean symbolization? If so, I didn't perform any 
> special validation here (thought output patterns tests use 
> libbacktrace output, no?). But I wonder how can I verify this more or 
> less automatically.
>
>>
>> Do you plan to update the asan tests we have to reflect the changes in
>> upstream?
>
> Hm, there aren't changes into instrumentation, so the only thing is 
> new interceptors. If it is desirable, I can migrate some tests for new 
> interceptors from upstream.
>
>>
>>     Jakub
>>
>
>

Addressing notes from thread 5 (thought it is better to move all 
Makefiles changes here).

[-- Attachment #2: libsanitizer-249633-3.tar.bz --]
[-- Type: application/x-bzip, Size: 257636 bytes --]

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Adhemerval Zanella]

On 14-10-2015 04:54, Jakub Jelinek wrote:
> On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote:
>> On 13/10/15 14:15, Maxim Ostapenko wrote:
>>> This is the raw merge itself. I'm bumping SONAME to libasan.so.3.
>>>
>>> -Maxim
>>
>> I have just noticed that I've misused autoconf stuff (used wrong version).
>> Here a fixed version of the same patch. Sorry for inconvenience.
> 
> Is libubsan, libtsan backwards compatible, or do we want to change SONAME
> there too?
> 
> The aarch64 changes are terrible, not just because it doesn't yet have
> runtime decision on what VA to use or that it doesn't support 48-bit VA,
> but also that for the 42-bit VA it uses a different shadow offset from
> 39-bit VA.  But on the compiler side we have just one...
> Though, only the 39-bit VA is enabled right now by default, so out of the
> box the state is as bad as we had in 5.x - users wanting 42-bit VA or 48-bit
> VA have to patch libsanitizer.

Yes we are aware with current deficiencies for aarch64 with a 39-bit and 
42-bit vma and the lack of support of 48-bit vma. On LLVM side current 
approach is to built compiler support for either 39 or 42 bit (and again
we are aware this is not the ideal approach). This approach was used
mainly for validation and buildbot enablement.

I am currently working on a way to make the sanitizer (asan and msan)
VMA independent on aarch64 (aiming to current support 39/42 and later 
48-bit vma) and the approach we decide to use is to change the 
instrumentation to use a parametrized value to compute the shadow memory
regions (based on VMA address) which will be initialized externally
by the  ibsanitizer. TSAN is somewhat easier since instrumentation 
does not  take in consideration the VMA (only the libsanitizer itself).

The idea is to avoid compiler switches a make is transparent to run
the binary regardless of the VMA in the system. The downside is 
instrumentation will require more steps (to lead the parametrized
value to compute shadow memory) and thus slower.



> 
> Have you verified libbacktrace sanitization still works properly (that is
> something upstream does not test)?
> 
> Do you plan to update the asan tests we have to reflect the changes in
> upstream?
> 
> 	Jakub
> 

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Evgenii Stepanov]

On Wed, Oct 14, 2015 at 11:03 AM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
> On 14-10-2015 04:54, Jakub Jelinek wrote:
>> On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote:
>>> On 13/10/15 14:15, Maxim Ostapenko wrote:
>>>> This is the raw merge itself. I'm bumping SONAME to libasan.so.3.
>>>>
>>>> -Maxim
>>>
>>> I have just noticed that I've misused autoconf stuff (used wrong version).
>>> Here a fixed version of the same patch. Sorry for inconvenience.
>>
>> Is libubsan, libtsan backwards compatible, or do we want to change SONAME
>> there too?
>>
>> The aarch64 changes are terrible, not just because it doesn't yet have
>> runtime decision on what VA to use or that it doesn't support 48-bit VA,
>> but also that for the 42-bit VA it uses a different shadow offset from
>> 39-bit VA.  But on the compiler side we have just one...
>> Though, only the 39-bit VA is enabled right now by default, so out of the
>> box the state is as bad as we had in 5.x - users wanting 42-bit VA or 48-bit
>> VA have to patch libsanitizer.
>
> Yes we are aware with current deficiencies for aarch64 with a 39-bit and
> 42-bit vma and the lack of support of 48-bit vma. On LLVM side current
> approach is to built compiler support for either 39 or 42 bit (and again
> we are aware this is not the ideal approach). This approach was used
> mainly for validation and buildbot enablement.
>
> I am currently working on a way to make the sanitizer (asan and msan)
> VMA independent on aarch64 (aiming to current support 39/42 and later
> 48-bit vma) and the approach we decide to use is to change the
> instrumentation to use a parametrized value to compute the shadow memory
> regions (based on VMA address) which will be initialized externally
> by the  ibsanitizer. TSAN is somewhat easier since instrumentation
> does not  take in consideration the VMA (only the libsanitizer itself).

Wait. As Jakub correctly pointed out in the other thread, there is no
obvious reason why there could not be a single shadow offset value
that would work for all 3 possible VMA settings. I suggest figuring
this out first.

>
> The idea is to avoid compiler switches a make is transparent to run
> the binary regardless of the VMA in the system. The downside is
> instrumentation will require more steps (to lead the parametrized
> value to compute shadow memory) and thus slower.
>
>
>
>>
>> Have you verified libbacktrace sanitization still works properly (that is
>> something upstream does not test)?
>>
>> Do you plan to update the asan tests we have to reflect the changes in
>> upstream?
>>
>>       Jakub
>>

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Renato Golin]

On 14 October 2015 at 19:21, Evgenii Stepanov <eugeni.stepanov@gmail.com> wrote:
> Wait. As Jakub correctly pointed out in the other thread, there is no
> obvious reason why there could not be a single shadow offset value
> that would work for all 3 possible VMA settings. I suggest figuring
> this out first.

We are.

cheers,
--renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Andrew Pinski]

On Wed, Oct 14, 2015 at 11:38 AM, Renato Golin <renato.golin@linaro.org> wrote:
> On 14 October 2015 at 19:21, Evgenii Stepanov <eugeni.stepanov@gmail.com> wrote:
>> Wait. As Jakub correctly pointed out in the other thread, there is no
>> obvious reason why there could not be a single shadow offset value
>> that would work for all 3 possible VMA settings. I suggest figuring
>> this out first.
>
> We are.

Then until that happens I think we should disable asan and tsan for
AARCH64 for GCC.

>
> cheers,
> --renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Renato Golin]

On 14 October 2015 at 20:00, Andrew Pinski <pinskia@gmail.com> wrote:
> Then until that happens I think we should disable asan and tsan for
> AARCH64 for GCC.

I can't comment on that, but we'll continue running the tests on our
side on both 39 and 42 VMA configurations, to make sure we don't
regress until we actually ready to go for a final solution.

For the people that weren't directly involved (or don't want to be),
we'll be letting you know when a final solution is agreed and
validated between all parties.

cheers,
--renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Andrew Pinski]

On Wed, Oct 14, 2015 at 12:15 PM, Renato Golin <renato.golin@linaro.org> wrote:
> On 14 October 2015 at 20:00, Andrew Pinski <pinskia@gmail.com> wrote:
>> Then until that happens I think we should disable asan and tsan for
>> AARCH64 for GCC.
>
> I can't comment on that, but we'll continue running the tests on our
> side on both 39 and 42 VMA configurations, to make sure we don't
> regress until we actually ready to go for a final solution.

It does not work for any standard Linux distros if they support dual
node ThunderX at all.  It is completely broken and does not even make
sense to do regression testing on a broken library.

>
> For the people that weren't directly involved (or don't want to be),
> we'll be letting you know when a final solution is agreed and
> validated between all parties.
>
> cheers,
> --renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Ramana Radhakrishnan]

On 14/10/15 20:17, Andrew Pinski wrote:
> On Wed, Oct 14, 2015 at 12:15 PM, Renato Golin <renato.golin@linaro.org> wrote:
>> On 14 October 2015 at 20:00, Andrew Pinski <pinskia@gmail.com> wrote:
>>> Then until that happens I think we should disable asan and tsan for
>>> AARCH64 for GCC.
>>
>> I can't comment on that, but we'll continue running the tests on our
>> side on both 39 and 42 VMA configurations, to make sure we don't
>> regress until we actually ready to go for a final solution.
> 
> It does not work for any standard Linux distros if they support dual
> node ThunderX at all.  It is completely broken and does not even make
> sense to do regression testing on a broken library.
> 

Everyone's agreed that there needs to be a clean solution for this.
If the upstream for asan and tsan have it supported, I fail to see
how it makes sense for GCC to be different.


regards
Ramana

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Yury Gribov]

On 10/14/2015 10:15 PM, Renato Golin wrote:
> On 14 October 2015 at 20:00, Andrew Pinski <pinskia@gmail.com> wrote:
>> Then until that happens I think we should disable asan and tsan for
>> AARCH64 for GCC.
>
> I can't comment on that, but we'll continue running the tests on our
> side on both 39 and 42 VMA configurations, to make sure we don't
> regress until we actually ready to go for a final solution.
>
> For the people that weren't directly involved (or don't want to be),
> we'll be letting you know when a final solution is agreed and
> validated between all parties.

Renato,

Do you have any estimation for when full AArch64 support is ready in 
LLVM? If it's still months away, I wonder if we may want to enable at 
least current (partial) support for non-Thunder users.

-Y

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Renato Golin]

On 15 October 2015 at 08:29, Yury Gribov <y.gribov@samsung.com> wrote:
> Do you have any estimation for when full AArch64 support is ready in LLVM?
> If it's still months away, I wonder if we may want to enable at least
> current (partial) support for non-Thunder users.

Hi Yury,

Unfortunately, no. Basic support is there, better support is a few
weeks away (fingers crossed), but full support may take years (and
we're not promising it :).

However, I can give you an overview of what is done and what is left
to do, so you can have your own judgement.

Last year, Christophe added ASAN to AArch64, but because of multiple
problems with the tests on environments we didn't have (the official
buildbot was a Juno outside of Linaro), we couldn't enable it by
default. So, support for ASAN and all other sanitizers on AArch64 was
put on hold. Since January this year, we've been studying TSAN, and
realised that there were many shared problems with ASAN, so we decided
to fix the buildbot problem and implement the other sanitizers.

Fast-forward to today, we have almost all sanitizers "working" on
AArch64. Not all features work (Adhemerval knows more about this), and
it doesn't work on every AArch64 hardware out there, namely those that
we don't have access to. But there are some things that do work, and
they are being tested on every commit since a few months ago. This
means that you can try it out, see what works and what doesn't, and
let us know by creating a bug in LLVM's bugzilla on Compiler-RT. It
doesn't mean we'll fix everything, but it means we'll know what's
broken, so we can plan better.

One hint to understand the level of support is to look at the tests.
We use two ways of marking tests: XFAIL, as usual, says the test
*must* fail, and normally means (merits aside), that a sanitizer
feature is not implemented, or the test is exclusive for a different
architecture. The other way is by marking it as "REQUIRES:
stable-runtime", which is for tests that fail on some platforms but
not others. This normally means an underlying (internal) sanitizer
feature is not present or too generic, and the test is not good enough
to detect it. None of that is good, we know, but it is what it is, and
as you can imagine, the priority is to get things working first.

For the future, there are still a few things we have to do:

1. Finish adding all the sanitizers. Because they share a lot of code
and execution, enabling one at a time and fixing all the bugs would
make us ignore the problems in all the other SANs, and we'd have to
re-implement a lot again on every new one. Like untangling hair,
working from inside only makes things worse. This would also allow
other people to test the sanitizers that they care about and report
bugs, so we can have a wider view of what's missing and what's broken.
Adhemerval is on the last ones now and we shall have them upstream,
tested (modulo XFAIL), in the next few weeks.

2. The first critical issue for AArch64 is the VMA problem and is our
current focus. Some ideas were put forward (including in this thread)
and right now Adhemerval is investigating Jakub's proposal. It
shouldn't take long for us to have a prototype, and we'll share our
findings here as soon as we have it. We'll focus on that problem for
now and only move to the next step once this is resolved and all SAN
tests pass on both 39 and 42 VMA. We don't have 48 or 56, so we'll
rely on you guys (Andrew?) to test the prototype and report back.
Otherwise, we'll assume working on 39/42 is good enough. This should
take another few weeks.

3. After the VMA issue is resolved, we'll look at clearing the
"stable-runtime" and XFAIL flags from as many tests as possible.
Either by implementing the features, or by improving the tests, or by
moving them into an architecture specific place where they don't get
tested in AArch64 if they don't have to (ex. x86 specific stuff). But
I have to warn you, this will be at a much lower priority than the VMA
issue, and it could take years to finish. Basically, we'll do on a
case by case basis, what people use, what is important, etc. So, no
promises there. But the "product" should be stable enough at this
stage on *what's implemented* that you can use it on your own code.

Hope that helps.

cheers,
--renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[pinskia]

> On Oct 15, 2015, at 1:42 AM, Renato Golin <renato.golin@linaro.org> wrote:
> 
>> On 15 October 2015 at 08:29, Yury Gribov <y.gribov@samsung.com> wrote:
>> Do you have any estimation for when full AArch64 support is ready in LLVM?
>> If it's still months away, I wonder if we may want to enable at least
>> current (partial) support for non-Thunder users.
> 
> Hi Yury,
> 
> Unfortunately, no. Basic support is there, better support is a few
> weeks away (fingers crossed), but full support may take years (and
> we're not promising it :).
> 
> However, I can give you an overview of what is done and what is left
> to do, so you can have your own judgement.
> 
> Last year, Christophe added ASAN to AArch64, but because of multiple
> problems with the tests on environments we didn't have (the official
> buildbot was a Juno outside of Linaro), we couldn't enable it by
> default. So, support for ASAN and all other sanitizers on AArch64 was
> put on hold. Since January this year, we've been studying TSAN, and
> realised that there were many shared problems with ASAN, so we decided
> to fix the buildbot problem and implement the other sanitizers.
> 
> Fast-forward to today, we have almost all sanitizers "working" on
> AArch64. Not all features work (Adhemerval knows more about this), and
> it doesn't work on every AArch64 hardware out there, namely those that
> we don't have access to. But there are some things that do work, and
> they are being tested on every commit since a few months ago. This
> means that you can try it out, see what works and what doesn't, and
> let us know by creating a bug in LLVM's bugzilla on Compiler-RT. It
> doesn't mean we'll fix everything, but it means we'll know what's
> broken, so we can plan better.
> 
> One hint to understand the level of support is to look at the tests.
> We use two ways of marking tests: XFAIL, as usual, says the test
> *must* fail, and normally means (merits aside), that a sanitizer
> feature is not implemented, or the test is exclusive for a different
> architecture. The other way is by marking it as "REQUIRES:
> stable-runtime", which is for tests that fail on some platforms but
> not others. This normally means an underlying (internal) sanitizer
> feature is not present or too generic, and the test is not good enough
> to detect it. None of that is good, we know, but it is what it is, and
> as you can imagine, the priority is to get things working first.
> 
> For the future, there are still a few things we have to do:
> 
> 1. Finish adding all the sanitizers. Because they share a lot of code
> and execution, enabling one at a time and fixing all the bugs would
> make us ignore the problems in all the other SANs, and we'd have to
> re-implement a lot again on every new one. Like untangling hair,
> working from inside only makes things worse. This would also allow
> other people to test the sanitizers that they care about and report
> bugs, so we can have a wider view of what's missing and what's broken.
> Adhemerval is on the last ones now and we shall have them upstream,
> tested (modulo XFAIL), in the next few weeks.
> 
> 2. The first critical issue for AArch64 is the VMA problem and is our
> current focus. Some ideas were put forward (including in this thread)
> and right now Adhemerval is investigating Jakub's proposal. It
> shouldn't take long for us to have a prototype, and we'll share our
> findings here as soon as we have it. We'll focus on that problem for
> now and only move to the next step once this is resolved and all SAN
> tests pass on both 39 and 42 VMA. We don't have 48 or 56, so we'll
> rely on you guys (Andrew?) to test the prototype and report back.
> Otherwise, we'll assume working on 39/42 is good enough. This should
> take another few weeks.

huh? You can get 48 bit va support on any normal aarch64 kernel without my support. It is a standard feature (not enabled by default though). It just happens to be required by thunderx but not unique to thunderx. 52 bit support does not exist yet (though it might in next year). 

So in summary just enable 48 bit va support in the upstream kernel right now and not needed to test on thunderx. So please enable 48 bit va in the kernel. It is supported on a kernel that supports juno, apm and amd processors. 

Note armv8.0 and 8.1 supports up to 48 bit physical addressing and 2 node thunderx uses that and that is why 48 bit va is needed for thunderx.

Thanks,
Andre


> 
> 3. After the VMA issue is resolved, we'll look at clearing the
> "stable-runtime" and XFAIL flags from as many tests as possible.
> Either by implementing the features, or by improving the tests, or by
> moving them into an architecture specific place where they don't get
> tested in AArch64 if they don't have to (ex. x86 specific stuff). But
> I have to warn you, this will be at a much lower priority than the VMA
> issue, and it could take years to finish. Basically, we'll do on a
> case by case basis, what people use, what is important, etc. So, no
> promises there. But the "product" should be stable enough at this
> stage on *what's implemented* that you can use it on your own code.
> 
> Hope that helps.
> 
> cheers,
> --renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Renato Golin]

On 15 October 2015 at 10:21,  <pinskia@gmail.com> wrote:
> So in summary just enable 48 bit va support in the upstream kernel right now and not needed to test on thunderx. So please enable 48 bit va in the kernel. It is supported on a kernel that supports juno, apm and amd processors.

Hi Andrew,

I'm sorry but we don't have bandwidth to do that ourselves, at least not now.

Furthermore, all hardware that we have available are in production and
we can't just change the kernel or add containers or we risk breaking
the bots and disabling testing on everything else we do.

Feel free to send us more hardware, and we'll make sure it works in 48
bits. Or you can help us and test it locally.

cheers,
--renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Renato Golin]

On 14 October 2015 at 19:38, Renato Golin <renato.golin@linaro.org> wrote:
> On 14 October 2015 at 19:21, Evgenii Stepanov <eugeni.stepanov@gmail.com> wrote:
>> Wait. As Jakub correctly pointed out in the other thread, there is no
>> obvious reason why there could not be a single shadow offset value
>> that would work for all 3 possible VMA settings. I suggest figuring
>> this out first.
>
> We are.

For anyone interested, here are the first few reviews:

http://reviews.llvm.org/D13781
http://reviews.llvm.org/D13782

There's more coming... :)

I don't want to spam this list for all the future patches, so if
you're interested, you might monitor the LLVM list, or register in our
Phabricator and create a filter for reviews with "VMA" to always CC
you.

cheers,
--renato

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko]

On 16/10/15 16:48, Renato Golin wrote:
> On 14 October 2015 at 19:38, Renato Golin <renato.golin@linaro.org> wrote:
>> On 14 October 2015 at 19:21, Evgenii Stepanov <eugeni.stepanov@gmail.com> wrote:
>>> Wait. As Jakub correctly pointed out in the other thread, there is no
>>> obvious reason why there could not be a single shadow offset value
>>> that would work for all 3 possible VMA settings. I suggest figuring
>>> this out first.
>> We are.
> For anyone interested, here are the first few reviews:
>
> http://reviews.llvm.org/D13781
> http://reviews.llvm.org/D13782
>
> There's more coming... :)
>
> I don't want to spam this list for all the future patches, so if
> you're interested, you might monitor the LLVM list, or register in our
> Phabricator and create a filter for reviews with "VMA" to always CC
> you.
>
> cheers,
> --renato
>

Yeah, thanks. Just wondering if I should step back until they are 
resolved upstream or we can have another merge in the future (stage3 is 
coming ...)?

-Maxim

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

[Renato Golin]

On 16 October 2015 at 14:59, Maxim Ostapenko
<m.ostapenko@partner.samsung.com> wrote:
> Yeah, thanks. Just wondering if I should step back until they are resolved
> upstream or we can have another merge in the future (stage3 is coming ...)?

Well, right now, the support is patchy, experimental, but it's
reasonably stable. From the moment the first patch concerning  VMA
lands, until they're all applied, support will be unstable.

So, if you want to merge, you better merge from the current tree, or
wait for the VMA issue to stabilise, which can take a few weeks. You
can also take 3.7.0, which was slightly better tested than current
trunk and isn't missing a lot.

cheers,
--renato

Re: [PATCH 0/7] Libsanitizer merge from upstream r249633.

[Andrew Pinski]

On Tue, Oct 13, 2015 at 4:13 AM, Maxim Ostapenko
<m.ostapenko@partner.samsung.com> wrote:
> Hi,
>
> it's been a while since the last libsanitizer merge from upstream into GCC
> happened and the library has significantly changed since that time. The main
> features to be ported are:
>
> -New common strings interceptors were added.
> -Various allocator improvements were performed.
> -Improvements for ASan deactivated start were performed.
> -TSan and LSan were enabled for Aarch64.
> -Fast unwinding was enabled for Aarch64.
> -New tsan_unaligned_{load, store}_[n] functions were intoduced.
> -asan_stack_malloc_[n] doesn't take a local stack as a second parameter
> anymore.
> -sanitization for std containers is supported now.
> -New interface functions for dynamic allocas and VLA's poisoning/unpoisoning
> were introduced.
>
> Some features are not ported for now, by might be enabled in future:
>
> -Embedded UBSan runtime into ASan and TSan ones. I don't enable this now,
> because of errors during ASan static linkage: GCC uses -whole-archive option
> that would lead to undefined references to C++ stuff.
> -UBSan data descriptors for float-cast conversion support location
> propagation now. But sometimes we have loc == UNKNOWN_LOCATION in
> ubsan_instrument_float_cast, so use old ABI for now. See below for details.
>
> The first patch of the series is the merge itself.
>
> The second one introduces corresponding compiler changes.
>
> Other patches are applied to library and they are GCC-specific:
>
> Patches 3 and 4 are just reapplied David's and Jakub's patches for SPARC and
> disabling ODR violation detection respectively.
>
> Patch 5 removes UBSan stubs from ASan and TSan code since we don't support
> embedded UBSan runtime into ASan and TSan.
>
> Patch 6 changes heuristic for extracting last PC from stack frame for ARM in
> fast unwind routine. More details can be found here
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771).
>
> Patch 7 forces libsanitizer to use an old ABI for ubsan float cast data
> descriptors, because sometimes we can have loc == UNKNOWN_LOCATION in
> ubsan_instrument_float_cast e.g. in a such case:
>
> ......
> volatile double foo; // ubsan_instrument_float_cast is called by convert
> function.
> ......
>
> Since foo is a tcc_declaration, loc is UNKNOWN_LOCATION. I'm actually not
> sure about this, perhaps we can fix this in GCC somehow.
>
> I've regtested and {A, UB}San bootstrapped these patches on
> x86-64-unknown-linux-gnu and aarch64-linux-gnueabi (Juno board, 39 bit VA
> space) and tested for ARM under QEMU-ARM.
> Testing ASan under QEMU-AARCH64 revealed many test failures due to LSan was
> enabled. In particular, it tries to call internal_clone function in LSan
> internals, that in turn calls _NR_clone syscall and than QEMU exits with
> EINTR error code (that might be expected, AFAIK QEMU is not very good with
> threads). So, I wonder, if I should disable LSan for AArch64 now?

We should just disable ASAN and TSAN for AARCH64 until 48bit VA is
supported.  Since the majority of the distros are going to be using
48bit VA as it is required to be used to support dual node ThunderX
(since ThunderX's physical address space uses all 48bits).

Thanks,
Andrew Pinski

>
> I'm also asking community to help me with testing these patches on various
> targets (ARM, PPC, etc) I'm lack of, so could you help me on this please?
>
> -Maxim