[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #10 from Harald Anlauf 2012-12-29 23:05:45 UTC --- I have a simple case where CLASS(*) leads to an ICE. If it doesn't fit here, please feel free to move it elsewhere. module gfcbug121 implicit none type myobj class(*), allocatable :: x contains procedure :: print end type myobj contains subroutine print(this) class(myobj) :: this end subroutine print end module gfcbug121 I get: % gfc-trunk gfcbug121.f90 -c f951: internal compiler error: Segmentation fault 0x8621590 crash_signal ../../trunk/gcc/toplev.c:334 0x8198ffb gfc_default_initializer(gfc_typespec*) ../../trunk/gcc/fortran/expr.c:3870 0x817ef24 gfc_find_intrinsic_vtab(gfc_typespec*) ../../trunk/gcc/fortran/class.c:2315 0x817f642 gfc_class_null_initializer(gfc_typespec*, gfc_expr*) ../../trunk/gcc/fortran/class.c:417 0x82639a0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../trunk/gcc/fortran/trans-expr.c:5665 0x825436e gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../trunk/gcc/fortran/trans-expr.c:6132 0x826394d gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../trunk/gcc/fortran/trans-expr.c:5667 0x8248b8d gfc_get_symbol_decl(gfc_symbol*) ../../trunk/gcc/fortran/trans-decl.c:1494 0x8249d45 gfc_create_module_variable ../../trunk/gcc/fortran/trans-decl.c:4086 0x8249d45 gfc_create_module_variable ../../trunk/gcc/fortran/trans-decl.c:4016 0x82085e3 do_traverse_symtree ../../trunk/gcc/fortran/symbol.c:3451 0x8243e05 gfc_generate_module_vars(gfc_namespace*) ../../trunk/gcc/fortran/trans-decl.c:4485 0x8221232 gfc_generate_module_code(gfc_namespace*) ../../trunk/gcc/fortran/trans.c:1620 0x81dc72d translate_all_program_units ../../trunk/gcc/fortran/parse.c:4452 0x81dc72d gfc_parse_file() ../../trunk/gcc/fortran/parse.c:4679 0x821ba1f gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:191
[Bug libgomp/40362] openmp: some libgomp functions trigger data races
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362 --- Comment #14 from Dmitry Vyukov 2012-12-29 22:36:11 UTC --- (In reply to comment #13) > (In reply to comment #12) > > ws = gomp_ptrlock_get (&ws->next_ws); > > This is really just: > ws = gomp_ptrlock_get (ws+offsetof(next_ws)); > > So there are no loads there. The race is between store to ws->end/incr/chunk_size in gomp_loop_init() and loads in gomp_iter_dynamic_next(). They are not synchronized in any way. So a worker thread can load bogus ws->end/incr/chunk_size. There is another race on thr->ts.last_work_share->next_ws.ptr in ptrlock_get()/set(). > This is a race condition only if we go from > non-null to null which cannot happen here. This *is* the race condition. Period. There is no if. Undefined behavior. > TSAN cannot detect that as it does > not understand that case which is a complex case to understand This is trivial case and tsan correctly identifies it as a data race. > Also does TSAN understand futex's which might the other thing throwing it off > just as Hellgrtind and drd was thrown off by it. This data race is not related to futexes. Moreover, futexes rarely provide synchronization, just as condition variables they are usually used as wait optimization. For example futexes in config/linux/mutex.c do not provide any synchronization, so there is nothing to undertand.
[Bug libgomp/40362] openmp: some libgomp functions trigger data races
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362 --- Comment #13 from Andrew Pinski 2012-12-29 21:32:06 UTC --- (In reply to comment #12) > ws = gomp_ptrlock_get (&ws->next_ws); This is really just: ws = gomp_ptrlock_get (ws+offsetof(next_ws)); So there are no loads there. This is a race condition only if we go from non-null to null which cannot happen here. TSAN cannot detect that as it does not understand that case which is a complex case to understand Also does TSAN understand futex's which might the other thing throwing it off just as Hellgrtind and drd was thrown off by it.
[Bug bootstrap/55707] [4.7 Regression] bootstrap fails in gcc/graphite-dependences.c error cast loses precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55707 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz 2012-12-29 20:47:33 UTC --- Please post patch to ML. That is a trivial one. Btw do you have made already paper-work with FSF?
[Bug web/54711] Fix --target_board examples on test.html page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54711 Gerald Pfeifer changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment #9 from Gerald Pfeifer 2012-12-29 17:46:48 UTC --- I addressed comments 3-6 concerning our web pages / documentation via the following two changes http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01470.html http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01468.html and will be adding more over the next two weeks.
[Bug fortran/55827] ICE with multiple fortran modules and character lenght determined by an interfaced pure function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55827 --- Comment #6 from Mikael Morin 2012-12-29 16:40:07 UTC --- (In reply to comment #5) > Although I agree with Mikael that gfortran should probably > not have a NULL symtree by the time we reach gfc_conv_function_expr, > the above patch regression tests cleanly. Indeed, it's probably not that bad actually, as value.function.esym is properly set, despite symtree being NULL. Regarding: (In reply to comment #2) > I'm not > familiar with the internals for CLASS, so the > change to class.c may need some additional work. > That change is certainly OK: If e->symtree == NULL, it doesn't make sense to have subreferences (e->ref == NULL), so the function reduces to a no-op.
[Bug fortran/55827] ICE with multiple fortran modules and character lenght determined by an interfaced pure function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55827
--- Comment #5 from Steve Kargl
2012-12-29 16:04:45 UTC ---
On Fri, Dec 28, 2012 at 10:02:43PM +, kargl at gcc dot gnu.org wrote:
>
> Index: class.c
> ===
> --- class.c (revision 194745)
> +++ class.c (working copy)
> @@ -162,7 +162,8 @@ gfc_fix_class_refs (gfc_expr *e)
>if ((e->expr_type != EXPR_VARIABLE
> && e->expr_type != EXPR_FUNCTION)
>|| (e->expr_type == EXPR_FUNCTION
> - && e->value.function.isym != NULL))
> + && e->value.function.isym != NULL)
> + || e->symtree == NULL)
> return;
>
>ts = &e->symtree->n.sym->ts;
> Index: trans-expr.c
> ===
> --- trans-expr.c(revision 194745)
> +++ trans-expr.c(working copy)
> @@ -5527,7 +5527,7 @@ gfc_conv_function_expr (gfc_se * se, gfc
>
>/* We distinguish statement functions from general functions to improve
> runtime performance. */
> - if (expr->symtree->n.sym->attr.proc == PROC_ST_FUNCTION)
> + if (expr->symtree && expr->symtree->n.sym->attr.proc == PROC_ST_FUNCTION)
> {
>gfc_conv_statement_function (se, expr);
>
Although I agree with Mikael that gfortran should probably
not have a NULL symtree by the time we reach gfc_conv_function_expr,
the above patch regression tests cleanly.
[Bug libgomp/40362] openmp: some libgomp functions trigger data races
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
--- Comment #12 from Dmitry Vyukov 2012-12-29
12:31:02 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > gomp_ptrlock_get() function is not thread-safe. It's not only about
> > atomicity,
> > it's also about memory ordering. Thread that calls gomp_ptrlock_set() can
> > reorder stores to ws and the store to ptrlock->ptr. Alpha processors can
> > even
> > reorder load from ws and load of ptrlock->ptr (they do not respect data
> > dependencies).
>
> Wait a second ptrlock->ptr is really ws->next_ws.ptr which is really
> (ws+offset) so there is no data dependency here as far as I can see.
If that would be the case, then it would be even worser. But it's not the case,
there is certainly a data dependency between load of prtlock->ptr itself and
load of data through prtlock->ptr.
ws = gomp_ptrlock_get (&ws->next_ws);
if (ws == NULL)
...
else
{
thr->ts.work_share = ws;
> As Jakub
> mentioned before ws->next_ws.ptr only from NULL to non-null.
I do not see how it affects anything.
> So as far as I
> can tell it still stands as being thread-safe just not detectable from either
> valgrind or tsan.
tsan does not produce false warnings. data races are undefined behavior.
> This is just like some of the false uninitialized warnings
> which gcc can emit. It is sometimes hard to prove that the code is fine
> except
> with extra knowledge like the NULL to non-NULL.
>
> And about the stores being reordered:
> gomp_ptrlock_set (&thr->ts.last_work_share->next_ws, thr->ts.work_share);
>
> so ptr is always ws.
What do you mean?
> I again looked at the code and I still agree with Jakub's reasoning.
Among other things (e.g. just launching nuclear missiles), the following code:
if (gomp_work_share_start (false))
{
gomp_loop_init (thr->ts.work_share, start, end, incr,
GFS_STATIC, chunk_size);
gomp_work_share_init_done ();
}
can be executed as:
if (gomp_work_share_start (false))
{
thr->ts.last_work_share->next_ws.ptr = thr->ts.work_share;
gomp_loop_init (thr->ts.work_share, start, end, incr,
GFS_STATIC, chunk_size);
gomp_mutex_unlock (&thr->ts.last_work_share->next_ws.lock);
}
Then it will kaboom!
[Bug libgomp/40362] openmp: some libgomp functions trigger data races
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362 --- Comment #11 from Andrew Pinski 2012-12-29 12:09:15 UTC --- (In reply to comment #10) > gomp_ptrlock_get() function is not thread-safe. It's not only about atomicity, > it's also about memory ordering. Thread that calls gomp_ptrlock_set() can > reorder stores to ws and the store to ptrlock->ptr. Alpha processors can even > reorder load from ws and load of ptrlock->ptr (they do not respect data > dependencies). Wait a second ptrlock->ptr is really ws->next_ws.ptr which is really (ws+offset) so there is no data dependency here as far as I can see. As Jakub mentioned before ws->next_ws.ptr only from NULL to non-null. So as far as I can tell it still stands as being thread-safe just not detectable from either valgrind or tsan. This is just like some of the false uninitialized warnings which gcc can emit. It is sometimes hard to prove that the code is fine except with extra knowledge like the NULL to non-NULL. And about the stores being reordered: gomp_ptrlock_set (&thr->ts.last_work_share->next_ws, thr->ts.work_share); so ptr is always ws. I again looked at the code and I still agree with Jakub's reasoning.
[Bug libgomp/40362] openmp: some libgomp functions trigger data races
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362 --- Comment #10 from Dmitry Vyukov 2012-12-29 10:28:06 UTC --- ThreadSanitizer says the same: Testcase: !$OMP PARALLEL PRIVATE(j) j=OMP_GET_THREAD_NUM() ! no warnings without the dynamic schedule !$OMP DO SCHEDULE(DYNAMIC,2) DO i=1,10 ENDDO !$OMP END PARALLEL END Result: vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out == WARNING: ThreadSanitizer: data race (pid=35190) Read of size 8 at 0x7d327290 by main thread: #0 gomp_iter_dynamic_next /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/iter.c:190 (libgomp.so.1+0x6678) #1 GOMP_loop_dynamic_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:128 (libgomp.so.1+0x7a03) #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d) #3 MAIN__ test.f90:0 (exe+0x0ccb) #4 main ??:0 (exe+0x0d1a) Previous write of size 8 at 0x7d327290 by thread 1: #0 gomp_loop_init /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:41 (libgomp.so.1+0x7a96) #1 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d) #2 gomp_thread_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116 (libgomp.so.1+0xd012) Location is heap block of size 1568 at 0x7d327100 allocated by main thread: #0 malloc ??:0 (libtsan.so.0+0x0001896e) #1 gomp_malloc /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36 (libgomp.so.1+0x417a) #2 gomp_new_team /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:145 (libgomp.so.1+0xd27a) #3 GOMP_parallel_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108 (libgomp.so.1+0xafc7) #4 MAIN__ test.f90:0 (exe+0x0cc1) #5 main ??:0 (exe+0x0d1a) Thread 1 (tid=35191, running) created at: #0 pthread_create ??:0 (libtsan.so.0+0x0001a868) #1 gomp_team_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440 (libgomp.so.1+0xd908) #2 GOMP_parallel_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108 (libgomp.so.1+0xafd7) #3 MAIN__ test.f90:0 (exe+0x0cc1) #4 main ??:0 (exe+0x0d1a) gomp_ptrlock_get() function is not thread-safe. It's not only about atomicity, it's also about memory ordering. Thread that calls gomp_ptrlock_set() can reorder stores to ws and the store to ptrlock->ptr. Alpha processors can even reorder load from ws and load of ptrlock->ptr (they do not respect data dependencies).
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #21 from Dmitry Vyukov 2012-12-29
10:21:06 UTC ---
It is a known issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362#c7
and Jakub said it's safe. I am not that sure.
On Sat, Dec 29, 2012 at 2:13 PM, dvyukov at google dot com
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
>
> --- Comment #20 from Dmitry Vyukov 2012-12-29
> 10:13:00 UTC ---
> (In reply to comment #19)
>> On Wed, Dec 26, 2012 at 12:23 AM, Joost.VandeVondele at mat dot
>> ethz.ch wrote:
>> >
>> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
>> >
>> > --- Comment #16 from Joost VandeVondele > > ethz.ch> 2012-12-25 20:23:07 UTC ---
>> > many things appear to work fine, but seemingly parallel do loops with a
>> > dynamic
>> > schedule generate warnings in libgomp. I also seem to observe that they
>> > are not
>> > strictly deterministic, sometimes these warnings happen, sometimes not.
>> >
>> > Testcase:
>> >
>> > !$OMP PARALLEL PRIVATE(j)
>> >
>> > j=OMP_GET_THREAD_NUM()
>> >
>> > ! no warnings without the dynamic schedule
>> > !$OMP DO SCHEDULE(DYNAMIC,2)
>> > DO i=1,10
>> > ENDDO
>> >
>> > !$OMP END PARALLEL
>> > END
>> >
>> > Result:
>> >
>> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
>> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
>> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
>> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
>> > ==
>> > WARNING: ThreadSanitizer: data race (pid=35190)
>> > Read of size 8 at 0x7d327290 by main thread:
>> > #0 gomp_iter_dynamic_next
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/iter.c:190
>> > (libgomp.so.1+0x6678)
>> > #1 GOMP_loop_dynamic_start
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:128
>> > (libgomp.so.1+0x7a03)
>> > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)
>> > #3 MAIN__ test.f90:0 (exe+0x0ccb)
>> > #4 main ??:0 (exe+0x0d1a)
>> >
>> > Previous write of size 8 at 0x7d327290 by thread 1:
>> > #0 gomp_loop_init
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:41
>> > (libgomp.so.1+0x7a96)
>> > #1 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)
>> > #2 gomp_thread_start
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116
>> > (libgomp.so.1+0xd012)
>> >
>> > Location is heap block of size 1568 at 0x7d327100 allocated by main
>> > thread:
>> > #0 malloc ??:0 (libtsan.so.0+0x0001896e)
>> > #1 gomp_malloc
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36
>> > (libgomp.so.1+0x417a)
>> > #2 gomp_new_team
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:145
>> > (libgomp.so.1+0xd27a)
>> > #3 GOMP_parallel_start
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108
>> > (libgomp.so.1+0xafc7)
>> > #4 MAIN__ test.f90:0 (exe+0x0cc1)
>> > #5 main ??:0 (exe+0x0d1a)
>> >
>> > Thread 1 (tid=35191, running) created at:
>> > #0 pthread_create ??:0 (libtsan.so.0+0x0001a868)
>> > #1 gomp_team_start
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440
>> > (libgomp.so.1+0xd908)
>> > #2 GOMP_parallel_start
>> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108
>> > (libgomp.so.1+0xafd7)
>> > #3 MAIN__ test.f90:0 (exe+0x0cc1)
>> > #4 main ??:0 (exe+0x0d1a)
>>
>>
>> Looks like unsafe publication of gomp_work_share data.
>>
>> Can you show disassembly of
>> > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)
>> ?
>> How does it choose between calling gomp_loop_init() and
>> GOMP_loop_dynamic_start()?
>>
>> Humm... do omp generated functions (like MAIN__._omp_fn.0) pass
>> through tsan pass? Perhaps it contains some atomic op that tsan does
>> not see.
>
>
> Congratulations! We've found racy unsafe publication in libgomp with
> ThreadSanitizer:
>
> gomp_loop_dynamic_start() uses the following functions to synchronize with
> each
> other. As you can see gomp_ptrlock_get() contains fast-and-dead unsafe
> fast-path.
>
> libgomp/config/posix/ptrlock.h
>
> static inline void *gomp_ptrlock_get (gomp_ptrlock_t *ptrlock)
> {
> if (ptrlock->ptr != NULL)
> return ptrlock->ptr;
>
> gomp_mutex_lock (&ptrlock->lock);
> if (ptrlock->ptr != NULL)
> {
> gomp_mutex_unlock (&ptrlock->lock);
> return ptrlock->ptr;
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #20 from Dmitry Vyukov 2012-12-29
10:13:00 UTC ---
(In reply to comment #19)
> On Wed, Dec 26, 2012 at 12:23 AM, Joost.VandeVondele at mat dot
> ethz.ch wrote:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
> >
> > --- Comment #16 from Joost VandeVondele > ethz.ch> 2012-12-25 20:23:07 UTC ---
> > many things appear to work fine, but seemingly parallel do loops with a
> > dynamic
> > schedule generate warnings in libgomp. I also seem to observe that they are
> > not
> > strictly deterministic, sometimes these warnings happen, sometimes not.
> >
> > Testcase:
> >
> > !$OMP PARALLEL PRIVATE(j)
> >
> > j=OMP_GET_THREAD_NUM()
> >
> > ! no warnings without the dynamic schedule
> > !$OMP DO SCHEDULE(DYNAMIC,2)
> > DO i=1,10
> > ENDDO
> >
> > !$OMP END PARALLEL
> > END
> >
> > Result:
> >
> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
> > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out
> > ==
> > WARNING: ThreadSanitizer: data race (pid=35190)
> > Read of size 8 at 0x7d327290 by main thread:
> > #0 gomp_iter_dynamic_next
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/iter.c:190
> > (libgomp.so.1+0x6678)
> > #1 GOMP_loop_dynamic_start
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:128
> > (libgomp.so.1+0x7a03)
> > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)
> > #3 MAIN__ test.f90:0 (exe+0x0ccb)
> > #4 main ??:0 (exe+0x0d1a)
> >
> > Previous write of size 8 at 0x7d327290 by thread 1:
> > #0 gomp_loop_init
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:41
> > (libgomp.so.1+0x7a96)
> > #1 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)
> > #2 gomp_thread_start
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116
> > (libgomp.so.1+0xd012)
> >
> > Location is heap block of size 1568 at 0x7d327100 allocated by main
> > thread:
> > #0 malloc ??:0 (libtsan.so.0+0x0001896e)
> > #1 gomp_malloc
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36
> > (libgomp.so.1+0x417a)
> > #2 gomp_new_team
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:145
> > (libgomp.so.1+0xd27a)
> > #3 GOMP_parallel_start
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108
> > (libgomp.so.1+0xafc7)
> > #4 MAIN__ test.f90:0 (exe+0x0cc1)
> > #5 main ??:0 (exe+0x0d1a)
> >
> > Thread 1 (tid=35191, running) created at:
> > #0 pthread_create ??:0 (libtsan.so.0+0x0001a868)
> > #1 gomp_team_start
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440
> > (libgomp.so.1+0xd908)
> > #2 GOMP_parallel_start
> > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108
> > (libgomp.so.1+0xafd7)
> > #3 MAIN__ test.f90:0 (exe+0x0cc1)
> > #4 main ??:0 (exe+0x0d1a)
>
>
> Looks like unsafe publication of gomp_work_share data.
>
> Can you show disassembly of
> > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)
> ?
> How does it choose between calling gomp_loop_init() and
> GOMP_loop_dynamic_start()?
>
> Humm... do omp generated functions (like MAIN__._omp_fn.0) pass
> through tsan pass? Perhaps it contains some atomic op that tsan does
> not see.
Congratulations! We've found racy unsafe publication in libgomp with
ThreadSanitizer:
gomp_loop_dynamic_start() uses the following functions to synchronize with each
other. As you can see gomp_ptrlock_get() contains fast-and-dead unsafe
fast-path.
libgomp/config/posix/ptrlock.h
static inline void *gomp_ptrlock_get (gomp_ptrlock_t *ptrlock)
{
if (ptrlock->ptr != NULL)
return ptrlock->ptr;
gomp_mutex_lock (&ptrlock->lock);
if (ptrlock->ptr != NULL)
{
gomp_mutex_unlock (&ptrlock->lock);
return ptrlock->ptr;
}
return NULL;
}
static inline void gomp_ptrlock_set (gomp_ptrlock_t *ptrlock, void *ptr)
{
ptrlock->ptr = ptr;
gomp_mutex_unlock (&ptrlock->lock);
}
[Bug fortran/55824] [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55824 --- Comment #2 from Tobias Burnus 2012-12-29 10:12:46 UTC --- >From trans-stmt.c's gfc_trans_allocate /* Evaluate expr3 just once if not a variable. */ ... && code->expr3->ts.type == BT_CLASS && code->expr3->expr_type != EXPR_VARIABLE) ... classexpr = gfc_evaluate_now (classexpr, &se.pre); I think we should handle intrinsic functions in a special way as they never change the actual type BT_CLASS; thus, the actual type can be taken from the actual argument of RESHAPE/TRANSPOSE. (Though, check that "transfer(f())" doesn't evaluate "f" twice.) (If one skips that if block, the ICE occurs in gfc_array_allocate when obtaining the size via gfc_array_init_size.)
[Bug c++/55828] New: problem with access to static method from lambda in another method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55828
Bug #: 55828
Summary: problem with access to static method from lambda in
another method
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vladimir.ba...@gmail.com
It looks like an issue.
When I'm trying to access to static method from lambda defined in another
method I'm getting following error:
Compilation finished with errors:
source.cpp: In lambda function:
source.cpp:7:22: error: 'this' was not captured for this lambda function
Sample code:
struct Test
{
static void func1() {}
void func2()
{
auto f = []() {
Test::func1();
};
}
};
int main()
{}
It's could be easily reproduced on gcc 4.7.3 and bellow.
I haven't checked iso standard for right behavior - but it seems msvc and clang
compilers work fine with this example.
Also it gets ok when I pass this to lambda.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #19 from Dmitry Vyukov 2012-12-29 09:38:13 UTC --- On Wed, Dec 26, 2012 at 12:23 AM, Joost.VandeVondele at mat dot ethz.ch wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 > > --- Comment #16 from Joost VandeVondele ethz.ch> 2012-12-25 20:23:07 UTC --- > many things appear to work fine, but seemingly parallel do loops with a > dynamic > schedule generate warnings in libgomp. I also seem to observe that they are > not > strictly deterministic, sometimes these warnings happen, sometimes not. > > Testcase: > > !$OMP PARALLEL PRIVATE(j) > > j=OMP_GET_THREAD_NUM() > > ! no warnings without the dynamic schedule > !$OMP DO SCHEDULE(DYNAMIC,2) > DO i=1,10 > ENDDO > > !$OMP END PARALLEL > END > > Result: > > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > == > WARNING: ThreadSanitizer: data race (pid=35190) > Read of size 8 at 0x7d327290 by main thread: > #0 gomp_iter_dynamic_next > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/iter.c:190 > (libgomp.so.1+0x6678) > #1 GOMP_loop_dynamic_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:128 > (libgomp.so.1+0x7a03) > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d) > #3 MAIN__ test.f90:0 (exe+0x0ccb) > #4 main ??:0 (exe+0x0d1a) > > Previous write of size 8 at 0x7d327290 by thread 1: > #0 gomp_loop_init > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:41 > (libgomp.so.1+0x7a96) > #1 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d) > #2 gomp_thread_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116 > (libgomp.so.1+0xd012) > > Location is heap block of size 1568 at 0x7d327100 allocated by main > thread: > #0 malloc ??:0 (libtsan.so.0+0x0001896e) > #1 gomp_malloc > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36 > (libgomp.so.1+0x417a) > #2 gomp_new_team > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:145 > (libgomp.so.1+0xd27a) > #3 GOMP_parallel_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108 > (libgomp.so.1+0xafc7) > #4 MAIN__ test.f90:0 (exe+0x0cc1) > #5 main ??:0 (exe+0x0d1a) > > Thread 1 (tid=35191, running) created at: > #0 pthread_create ??:0 (libtsan.so.0+0x0001a868) > #1 gomp_team_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440 > (libgomp.so.1+0xd908) > #2 GOMP_parallel_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108 > (libgomp.so.1+0xafd7) > #3 MAIN__ test.f90:0 (exe+0x0cc1) > #4 main ??:0 (exe+0x0d1a) Looks like unsafe publication of gomp_work_share data. Can you show disassembly of > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d) ? How does it choose between calling gomp_loop_init() and GOMP_loop_dynamic_start()? Humm... do omp generated functions (like MAIN__._omp_fn.0) pass through tsan pass? Perhaps it contains some atomic op that tsan does not see.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #18 from Dmitry Vyukov 2012-12-29 09:32:53 UTC --- On Tue, Dec 25, 2012 at 11:30 PM, Joost.VandeVondele at mat dot ethz.ch wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 > > --- Comment #15 from Joost VandeVondele ethz.ch> 2012-12-25 19:30:15 UTC --- > (In reply to comment #13) >> (In reply to comment #12) >> > That's great that gcc tsan works for Fortran/OpenMP out of the box! >> >> I'm afraid it yields false positives. > > The obvious solution to this seems to be that also the OMP runtime (libgomp) > must be compiled with -fsanitize=thread. If I do that, it appears to work. > That's cool, I will try to do some more testing. Good idea! It should do for now. It should eliminate all false positives since tsan must understand synchronization in libgomp (pthread, __sync). It can have false negatives, though. E.g. all gomp_iter_dynamic_next() synchronize with each other. > > A reasonable approach could be to build two versions of libgomp. One standard > one, and one sanitized one (libgomp_tsan ?). -fsanitize=thread -fopenmp could > link the second version automatically. > > Just for those trying this out... > > I used the following to build&install a sanitized libgomp (based on Jakub's > comments in PR55374 and a hack of mine (-L...)) after an initial normal build > > cd /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/ > make clean > make CFLAGS="-std=gnu99 -g -O2 -fsanitize=thread" FCFLAGS="-g -O2 > -fsanitize=thread" > LDFLAGS="-L/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/ > -B/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/ > -Wl,-rpath,/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/ > -fsanitize=thread" > cd /data/vjoost/gnu/gcc_trunk/obj/ > make install > > compilation as > > gfortran -fopenmp -fsanitize=thread -pie -fPIC test.f90 > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
