public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: Thomas Koenig <tkoenig@netcologne.de>,
	Janne Blomqvist	<blomqvist.janne@gmail.com>
Cc: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	"gcc-patches@gcc.gnu.org"	<gcc-patches@gcc.gnu.org>
Subject: Re: [patch, libfortran] Fix thead sanitizer issue with libgfortran
Date: Sun, 01 Oct 2017 14:23:00 -0000	[thread overview]
Message-ID: <AM5PR0701MB2657680AE5A7E543013AFB55E47C0@AM5PR0701MB2657.eurprd07.prod.outlook.com> (raw)
In-Reply-To: <17746f9b-3dea-d99e-514f-56dfe0cbc814@netcologne.de>

On 10/01/17 15:41, Thomas Koenig wrote:
> Am 01.10.2017 um 10:59 schrieb Bernd Edlinger:
>> maybe there is a way how you could explicitly join
>> all running threads?
> 
> Yes, that seems to do the trick. Thanks!
> 

Oh, that is really very surprising...

I believe that all omp threads are created in detached state,
so pthread_join should be undefined on them, just tsan *thinks*
otherwise?

When I look further on the libgomp sources, I see there
are two completely different implementations of the
mutexes, barriers, etc.

One using posix functions which should be visible to tsan
and another one using raw linux futex calls which should be
invisible to tsan, by default the linux system calls are
used, which explains why tsan seems to be unaware of the
actual synchronization in this example.

Have you tried to build with --enable-linux-futex=no ?
I just saw the following line in libgomp/configure.tgt:

# Since we require POSIX threads, assume a POSIX system by default.
config_path="posix"

# Check for futex enabled all at once.
if test x$enable_linux_futex = xyes; then

So maybe completely different things will be reported if
this value is set to no?



> Here is a patch which appears to work. It does hit a snag with static
> linking, though, because it calls __gthread_self (), and that causes
> a segfault with -static :-(.
> 
> The test case in question is static_linking_1.f.
> 
> This appears to be a general problem, and has  been discussed
> before, for example in
> https://gcc.gnu.org/ml/gcc-help/2010-05/msg00029.html .
> 
> What would be the best way to proceed? Modify the behavior of -static
> with gfortran?
> 
> Regards
> 
>      Thomas
> 
> 2017-10-01  Thomas Koenig  <tkoenig@gcc.gnu.org>
> 
> 
>          PR fortran/66756
>          PR fortran/82378
>          * io/io.h: Add field th to gfc_unit. Add prototypes for
>          lock_unit and trylock_unit.
>          * io/unit.c (insert_unit): Do not create lock and lock, move to
>          (gfc_get_unit): here; lock after insert_unit has succeded.
>          Use lock_unit and trylock_unit instead of __gthread_mutex_lock
>          and __gthread_mutex_trylock.
>          (init_units): Do not unlock unit locks for stdin, stdout and
>          stderr.
>          (lock_unit): New function.
>          (trylock_unit): New function.
>          (close_units): If a unit still has a lock, wait for the
>          completion of the corresponding thread.
>          * io/unix.c (find_file): Use lock_unit and trylock_unit instead
>          of __gthread_mutex_lock and __gthread_mutex_trylock.
>          (flush_all_units): Likewise.
> 
> 2017-10-01  Thomas Koenig  <tkoenig@gcc.gnu.org>
> 
>          PR fortran/66756
>          PR fortran/82378
>          * gfortran.dg/openmp-close.f90: New test.

  reply	other threads:[~2017-10-01 14:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-01  9:02 Bernd Edlinger
2017-10-01 13:41 ` Thomas Koenig
2017-10-01 14:23   ` Bernd Edlinger [this message]
2017-10-01 16:54     ` Thomas Koenig
  -- strict thread matches above, loose matches on Subject: below --
2017-09-28 17:29 Thomas Koenig
2017-09-29  6:03 ` Thomas Koenig
2017-09-29  8:04   ` Janne Blomqvist
2017-09-29 18:53     ` Thomas Koenig
2017-10-01  7:42       ` Janne Blomqvist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM5PR0701MB2657680AE5A7E543013AFB55E47C0@AM5PR0701MB2657.eurprd07.prod.outlook.com \
    --to=bernd.edlinger@hotmail.de \
    --cc=blomqvist.janne@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=tkoenig@netcologne.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).