The following code (from pr40737) ! { dg-do compile } module testmod implicit none type VARIABLES_MAILLE real :: cell_var end type VARIABLES_MAILLE type (VARIABLES_MAILLE), pointer, dimension( :) :: Hydro_vars real, pointer, dimension(:) :: Ro end module testmod program TF_AD_SPLITTING_DRIVER_PLANE use testmod implicit none Ro => Hydro_vars(1:2)%cell_var end program gives a Segmentation fault when compiled with -fwhole-file. The backtrace is Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000018 0x00000001000d1d38 in gfc_trans_pointer_assignment (expr1=0x14191a3f0, expr2=0x141919960) at ../../work/gcc/fortran/trans-expr.c:4768 4768 gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp); (gdb) bt #0 0x00000001000d1d38 in gfc_trans_pointer_assignment (expr1=0x14191a3f0, expr2=0x141919960) at ../../work/gcc/fortran/trans-expr.c:4768 #1 0x00000001000a9ae6 in trans_code (code=0x14191a960, cond=0x0) at ../../work/gcc/fortran/trans.c:1109 #2 0x00000001000c7bd2 in gfc_generate_function_code (ns=<value temporarily unavailable, due to optimizations>) at ../../work/gcc/fortran/trans-decl.c:4495 #3 0x000000010006b0bd in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4253 #4 0x00000001000a496c in gfc_be_parse_file (set_yydebug=<value temporarily unavailable, due to optimizations>) at ../../work/gcc/fortran/f95-lang.c:241 #5 0x00000001006990da in toplev_main (argc=2, argv=0x7fff5fbfd9d8) at ../../work/gcc/toplev.c:945 #6 0x0000000100001154 in start ()
Carry over the comment from PR 45125, where I had posted it initially (and accidentally). The segfault occurs for: l.4768 gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp); It seems as if GFC_DECL_SPAN(decl) access a NULL pointer. That's decl->decl_common.lang_specific->span where lang_specific == NULL. While the dump has: tf_ad_splitting_driver_plane () { extern integer(kind=8) span.0 = 0; [...] span.0 = 4; the "span" variable does not really exist globally but is only created when needed, cf. http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/trans-decl.c;hb=HEAD#l1243 gfc_get_symbol_decl: 1243 else if (sym->attr.subref_array_pointer) 1245 /* We need the span for these beasts. */ 1246 gfc_allocate_lang_decl (decl); 1249 if (sym->attr.subref_array_pointer) 1261 GFC_DECL_SPAN (decl) = span; If one now recycles the definition for the array descriptor "desc" this information is not present. I think the real solution is the new array descriptor. I do not know how to fix this otherwise - except by always generating a span variable. Paul - any progress from the array-descriptor front?
Subject: Re: Segmentation fault with -fwhole-file for subref_array_pointer Dear Tobias, > If one now recycles the definition for the array descriptor "desc" this > information is not present. I think the real solution is the new array > descriptor. I do not know how to fix this otherwise - except by always > generating a span variable. This has occurred to me more than once! > > Paul - any progress from the array-descriptor front? Yes, I made a small start whilst on vacation. I have embarked on the first step of the project, which is to add to the existing dimension triplet the stride measure (sm) and extent fields. On top of that, I added an extra field to the descriptor itself, which does nothing but uncover all the accesses to the descriptor fields that do not use the ABI in trans-array.c. I just reached the stage of plugging all the segfaults arising from the latter. The next step is to evaluate the sm and extent fields, in parallel to the stride and upper fields, just to check all is well. Then will come the crucial step of using the new fields for evaluation of array references. I suspect that there will be a substantial performance hit in the scalarizer and problems with the library, both of which will require time to fix. Then, the stride and upper fields can be taken away. Finally, all the extra fields can be added to the descriptor. I will have some time to work on this next week. Cheers Paul
Paul, can you send me a preview of the new descriptor structure so I can be planning the internal unit I/O impacts if any.
Subject: Re: Segmentation fault with -fwhole-file for subref_array_pointer Dear Jerry, > ------- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-08-09 17:18 ------- > Paul, can you send me a preview of the new descriptor structure so I can be > planning the internal unit I/O impacts if any. This is something that we will all have to agree. At present, my work is entirely devoted to getting the new dimension triplet working and sorting out the side-effects of adding one or more new fields to the descriptor. It's a real dog....... Still, I have four evenings that I can devote to it this week :-) Cheers Paul
Isn't this the same as PR34640?
I confirm that it's a duplicate of PR 34640 (exact same backtrace). *** This bug has been marked as a duplicate of bug 34640 ***