[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-03-06 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Martin Liška  ---
Should be fixed now.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-03-06 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #20 from Martin Liška  ---
Author: marxin
Date: Tue Mar  6 20:07:49 2018
New Revision: 258300

URL: https://gcc.gnu.org/viewcvs?rev=258300=gcc=rev
Log:
Backport r257932

2018-03-06  Martin Liska  

Backport from mainline
2018-02-23  Segher Boessenkool  

PR testsuite/80551
* c-c++-common/tsan/race_on_mutex.c: Change regexp to allow
__GI___pthread_mutex_init as well.

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Segher Boessenkool  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #19 from Segher Boessenkool  ---
.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Segher Boessenkool  changed:

   What|Removed |Added

Version|7.0 |8.0
 Depends on||79455

--- Comment #18 from Segher Boessenkool  ---
It fails on 7 (and always has).  The fix for PR79455 needs to be applied before
this one can be.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79455
[Bug 79455] c-c++-common/tsan/race_on_mutex.c fails on powerpcle starting with
r244854 (where it was activated)

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-23 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #17 from Martin Liška  ---
Let's close it, if somebody sees problem on GCC 7, then we should reopen it.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #16 from Segher Boessenkool  ---
Fixed on trunk.  Does this actually fail on GCC 7?  The regexp there should
work AFAICS.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #15 from Segher Boessenkool  ---
Author: segher
Date: Fri Feb 23 14:17:35 2018
New Revision: 257932

URL: https://gcc.gnu.org/viewcvs?rev=257932=gcc=rev
Log:
Fix tsan race_on_mutex.c testcase (PR80551)

The testcase did not match the glibc internal names while it should.
This fixes it.


gcc/testsuite/
PR testsuite/80551
* c-c++-common/tsan/race_on_mutex.c: Change regexp to allow
__GI___pthread_mutex_init as well.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #14 from Jakub Jelinek  ---
Changing that (__)? to ((__GI_)?__)? is preapproved if it works.
Those are just glibc internal aliases which are in the symbol table too though,
so if you have full debug info for libpthread.so rather than just what .dynsym
contains it is possible you get it instead.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #13 from Segher Boessenkool  ---
It is trying to match

#[01] (__)?pthread_mutex_init

but instead it gets

#1 __GI___pthread_mutex_init

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-22 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #12 from Segher Boessenkool  ---
It does break if I set the breakpoints before the shared libs have loaded.


Thread 3 "a.out" hit Breakpoint 1, 0x3fffb6e0c860 in .__memset_power7 ()
   from /lib64/libc.so.6
#0  0x3fffb6e0c860 in .__memset_power7 () from /lib64/libc.so.6
#1  0x3fffb7055b10 in __interceptor_memset (dst=0x100201f0 , 
v=, size=40)
at
/home/segher/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709
#2  0x3fffb6f9f2b0 in .pthread_mutex_init () from /lib64/libpthread.so.0
#3  0x3fffb704d58c in __interceptor_pthread_mutex_init (
m=0x100201f0 , a=0x0)
at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:1132
#4  0x1dc4 in .Thread1 ()
#5  0x3fffb7049454 in __tsan_thread_start_func (arg=0x3fffeda0)
at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:905
#6  0x3fffb6f9c95c in .start_thread () from /lib64/libpthread.so.0
#7  0x3fffb6e83bbc in .__clone () from /lib64/libc.so.6

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-22 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #11 from Segher Boessenkool  ---
I rebuilt everything, and it still does not break at all.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #10 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #9)
> Nothing, it never reaches memset before it exits.

Are you sure? I was able to place breakpoint on memset and ~14th iteration of
the breakpoint was really mutex init function. Can you please double check it?

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-19 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #9 from Segher Boessenkool  ---
Nothing, it never reaches memset before it exits.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-19 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2018-02-19 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #8 from Martin Liška  ---
I've just used gcc110 and gcc112 machine (ppc64 and ppc64le) and both print
following stack-trace in the tsan error:

#0 memset
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709
(libtsan.so.0+0x55abc)
#1 __GI___pthread_mutex_init  (libpthread.so.0+0xf2ac)
#2 Thread1 c-c++-common/tsan/race_on_mutex.c:12
(race_on_mutex.exe+0x1f00)

I also verified that non-sanitized version in gdb also has missing source file
for the __GI___pthread_mutex_init function. Thus '' is here proper value.

Can you seurer test the problematic ppc64 machine where you see:
#1  

What do you see in gdb if you put a breakpoint to memset function?
Thanks

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2017-08-10 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #7 from Segher Boessenkool  ---
Why can't the unwinder find the function name here?

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2017-08-10 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #6 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #5)
> Why disable it?  Can the feature not work, can the test not work?
> 
> Disabling the test is papering over the problem as far as I see.

The test does not work :) So should we generalize more the scanned back-trace
in order to survive '#1  ' ?

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2017-08-10 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #5 from Segher Boessenkool  ---
Why disable it?  Can the feature not work, can the test not work?

Disabling the test is papering over the problem as far as I see.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2017-08-10 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #4 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #3)
> It apparently started failing last week of January 2017.  Only 64-bit
> fails, -m32 is fine.
> 
> I don't know where that missing function name is coming from.

Yep, it must start in r244854 where we enable TSAN on power. So we don't have
much detailed information should I disable it for power?

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2017-08-02 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #3 from Segher Boessenkool  ---
It apparently started failing last week of January 2017.  Only 64-bit
fails, -m32 is fine.

I don't know where that missing function name is coming from.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2017-08-02 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #2 from Martin Liška  ---
Segher any investigation about this?

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

2017-04-28 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Good, I can help you with that. Can you please investigate why unwinding fails
to identify function name?

I guess softening the pattern scan can lead to catch basically every function
:/