The attached code compiles but dies with a segmentation fault. If the omp directive is changed from !$omp parallel private(k,cell) to !$omp parallel private(k) the code executes.
Created attachment 17030 [details] openmp code showing segfault
gfc4x -g -o z -O -fopenmp gib.f90 (gdb) run ./z Starting program: /usr/home/kargl/tmp/z ./z [New LWP 100056] [New LWP 100056] 10 10 1 1 Assertion failed: (arena != NULL), function arena_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 3843. [New Thread 48103140 (LWP 100056)] Program received signal SIGABRT, Aborted. [Switching to Thread 48103140 (LWP 100056)] 0x0808792b in kill () (gdb) bt #0 0x0808792b in kill () #1 0x080611e4 in raise () #2 0x080867b5 in abort () #3 0x0807ac91 in __assert () #4 0x08070c5d in idalloc () #5 0x08070df7 in free () #6 0x0804829c in MAIN__.omp_fn.0 (.omp_data_i=0x0) at gib.f90:31 #7 0x0804867b in test_omp () at gib.f90:29 #8 0x08048709 in main (argc=2, argv=0xbfbfe6f4) at ../../../gcc4x/libgfortran/fmain.c:21
Using gfortran 4.3.3, a segfault also occurs but the backtrace is different. (gdb) run Starting program: /usr/home/kargl/tmp/z [New LWP 100173] [New Thread 48301140 (LWP 100173)] 10 10 1 1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 48301140 (LWP 100173)] 0x481d5aa3 in malloc_usable_size () from /lib/libc.so.7 (gdb) bt #0 0x481d5aa3 in malloc_usable_size () from /lib/libc.so.7 #1 0x481d63a7 in free () from /lib/libc.so.7 #2 0x080489c0 in MAIN__.omp_fn.0 (.omp_data_i=0x0) at gib.f90:31 #3 0x08048db2 in test_omp () at gib.f90:5 #4 0x08048e61 in main (argc=Error accessing memory address 0x0: Bad address. ) at ../.././..//gcc-4.3-20081120/libgfortran/fmain.c:21
Make the summary a little clear.
OpenMP 3.0 doesn't cover types with allocatable components, so this is undefined. If anything IMHO we should reject any attempts to privatize types with allocatable components, because it isn't clear what will OpenMP 4.0 require for them and if we now implement something different, it might be a compatibility problem.
Subject: Re: Segfault caused by derived-type with allocatable component in private clause On Sun, Jan 04, 2009 at 09:31:20PM -0000, jakub at gcc dot gnu dot org wrote: > > ------- Comment #5 from jakub at gcc dot gnu dot org 2009-01-04 21:31 ------- > OpenMP 3.0 doesn't cover types with allocatable components, so this is > undefined. If anything IMHO we should reject any attempts to privatize > types with allocatable components, because it isn't clear what will OpenMP 4.0 > require for them and if we now implement something different, it might be a > compatibility problem. > OK. Thanks for the info concerning OpenMP 3.0 and allocatable components. I agree gfortran should reject the program until we have some idea of the behavior with regards to OpenMP 4.0.
see also https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/vPs4MJamnCM
(In reply to Steve Kargl from comment #6) > I agree gfortran should reject the program until we have some idea of > the behavior with regards to OpenMP 4.0. It seems that the final OpenMP 4.0 specification does not support allocatable components. In particular it lists "Allocatable enhancement" as unsupported, which supposedly refers to TR 15581 and therefore includes alloc. comp., see http://openmp.org/wp/openmp-specifications/ So the test case should probably be rejected by the front end (alternatively: support it as a GNU extension).
Between revisions r211105 (2014-05-31, malloc error) and r211652 (2014-06-13, no run time error) the has started to run without error. The 'fix' has been back ported to 4.9. > So the test case should probably be rejected by the front end > (alternatively: support it as a GNU extension). The code compiles and executes at r229706 (trunk 6.0). Relate to/duplicate of pr40876?
> The code compiles and executes at r229706 (trunk 6.0). Can this PR closed as FIXED?
*** Bug 40876 has been marked as a duplicate of this bug. ***
Fixed.