[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #9 from vries at gcc dot gnu.org ---
Created attachment 37675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37675=edit
tentative patch

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #8 from vries at gcc dot gnu.org ---
I managed to trigger the test returning 0 from the command line, by running it
in parallel:
...
$ ( export LD_LIBRARY_PATH=$(pwd -P)/install/lib64; for cnt in $(seq 1 400); do
(./a.out ; echo $? ) > log.$cnt 2>&1 & done )
$ egrep  '^0$' log.* | wc -l
54
...

I can't be sure if that is the reason that the test is failing (by returning 0)
during running the testsuite, but it's certainly possible (I'm running it with
-j12).

So, I suspect that the test fails because pthread_create fails with EAGAIN due
to insufficient resources:
...
int
main ()
{
  pthread_t th;
  barrier_init (, 2);
  if (pthread_create (, NULL, tf, NULL))
return 0;
...

Indeed in the testcase we do not distinguish between:
- return 0, case pthread_create failed, and
- return 0 at end of main, -fsanitize=thread failed to catch the race
condition.

It would probably be good to print an error message when pthread_create fails,
such that when looking at the fail in the testlog, we can easily see that that
is the reason it failed, and not expect it to reproduce otherwise.

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #7 from vries at gcc dot gnu.org ---
Ran into it once more while testing couple of patches on top of r233103.

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Mon Feb  1 22:03:57 2016
New Revision: 233053

URL: https://gcc.gnu.org/viewcvs?rev=233053=gcc=rev
Log:
PR tree-optimization/68580
* params.def (FSM_MAXIMUM_PHI_ARGUMENTS): New param.
* tree-ssa-threadbackward.c
(fsm_find_control_statement_thread_paths): Do not try to walk
through large PHI nodes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def
trunk/gcc/tree-ssa-threadbackward.c

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #6 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-cvs/2016-02/msg00030.html :

Author: law
Date: Mon Feb  1 22:05:58 2016
New Revision: 233054

URL: https://gcc.gnu.org/viewcvs?rev=233054=gcc=rev
Log:
Fix PR # in last change

Modified:
trunk/gcc/ChangeLog

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #4 from vries at gcc dot gnu.org ---
I've observed this failure now in two seperate build & test runs.

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #2 from Dmitry Vyukov  ---
If you change types of:

int v;
int q;
int o;

to 'long long', does it fix the failure?

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Dmitry Vyukov from comment #2)
> If you change types of:
> 
> int v;
> int q;
> int o;
> 
> to 'long long', does it fix the failure?

As long as I don't have a reliable way to reproduce the failure, I can't answer
that question.

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #1 from vries at gcc dot gnu.org ---
(In reply to vries from comment #0)
> I can't yet reproduce this failure on the command line.

That includes 1 iterations of running the executable, for both -O2 and -O0.