[Bug fortran/88768] Derived type io in conjunction with allocatable component and recursion fails

2019-01-17 Thread mscfd at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768

--- Comment #3 from martin  ---
I have opened a separate PR 88899 for the openmp related invalid memory read,
but I guess it might have the same cause.

[Bug fortran/88768] Derived type io in conjunction with allocatable component and recursion fails

2019-01-14 Thread mscfd at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768

--- Comment #2 from martin  ---
If I add the "generic :: write(unformatted) => write_unformatted" part in my
code (but do not use it), I see other failures somehow triggered by openmp
parallelisation (no recursion involved). Using the address sanitizer I can see
that one thread tries to access some memory already freed by another thread.
However, the concerned variables (of what is type(t) in the example code above)
are thread private and in fact several subroutine calls and modules away from
the openmp parallelisation block.

Unfortunately so far I was not able to produce a simple test case. However, it
looks like that the DT IO part uses some kind of global addresses, which does
not work well with recursion or threading?

[Bug fortran/88768] Derived type io in conjunction with allocatable component and recursion fails

2019-01-11 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 7.4.1 up to trunk (9.0).

My instrumented fortran gives at run time

==50613==ERROR: AddressSanitizer: attempting double-free on 0x602002d0 in
thread T0:
#0 0x10a361a7f in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x10788a1ac in __mod_MOD_recurse (a.out:x86_64+0x111ac)
#2 0x10788aad6 in MAIN__ (a.out:x86_64+0x11ad6)
#3 0x10788ad08 in main (a.out:x86_64+0x11d08)
#4 0x7fff67115ed8 in start (libdyld.dylib:x86_64+0x16ed8)

0x602002d0 is located 0 bytes inside of 8-byte region
[0x602002d0,0x602002d8)
freed by thread T0 here:
#0 0x10a361a7f in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x107889e4f in __mod_MOD___final_mod_T (a.out:x86_64+0x10e4f)
#2 0x10788a2fd in __mod_MOD_set (a.out:x86_64+0x112fd)
#3 0x10788a193 in __mod_MOD_recurse (a.out:x86_64+0x11193)
#4 0x10788aad6 in MAIN__ (a.out:x86_64+0x11ad6)
#5 0x10788ad08 in main (a.out:x86_64+0x11d08)
#6 0x7fff67115ed8 in start (libdyld.dylib:x86_64+0x16ed8)

previously allocated by thread T0 here:
#0 0x10a360a0f in wrap_malloc sanitizer_malloc_mac.inc:114
#1 0x10788a710 in __mod_MOD_set (a.out:x86_64+0x11710)
#2 0x10788a1e4 in __mod_MOD_recurse (a.out:x86_64+0x111e4)
#3 0x10788a117 in __mod_MOD_recurse (a.out:x86_64+0x11117)
#4 0x10788aad6 in MAIN__ (a.out:x86_64+0x11ad6)
#5 0x10788ad08 in main (a.out:x86_64+0x11d08)
#6 0x7fff67115ed8 in start (libdyld.dylib:x86_64+0x16ed8)