Created attachment 42622 [details] test case [forwarded from https://bugs.debian.org/881918] seen building open-coarrays with the gcc-7-branch 20171115, not seen on the branch 20171001 $ gfortran global_field.f90 -fcoarray=lib global_field.f90:126:0: lhs%values(:) = rhs%state() internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x000000000067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) () (gdb) bt #0 0x000000000067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) () #1 0x000000000067cf7a in gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) () #2 0x00000000006a6572 in ?? () #3 0x00000000006b9814 in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) () #4 0x00000000006a0895 in ?? () #5 0x0000000000696a3b in gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) () #6 0x000000000066ee45 in gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) () #7 0x000000000069f37e in gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec<tree_node*, va_gc, vl_embed>*) () #8 0x00000000006a087d in ?? () #9 0x000000000067c239 in ?? () #10 0x000000000067cdf6 in gfc_conv_loop_setup(gfc_loopinfo*, locus*) () #11 0x00000000006a32e0 in ?? () #12 0x0000000000668b10 in ?? () #13 0x000000000068de98 in gfc_generate_function_code(gfc_namespace*) () #14 0x000000000066c86a in gfc_generate_module_code(gfc_namespace*) () #15 0x000000000062229c in gfc_parse_file() () #16 0x0000000000665630 in ?? () #17 0x0000000000a7ac6f in ?? () #18 0x000000000059923a in toplev::main(int, char**) () #19 0x000000000059b5eb in main ()
Could you please provide the file(s) needed to generate local_field_module.mod? Revision r254377 for the 7 branch is OK.
I suspect the source code in question is the same as https://github.com/sourceryinstitute/OpenCoarrays/blob/8eab16936fb958746575f5c9580ba521320e0444/src/tests/integration/pde_solvers/coarrayBurgers/local_field.F90
> > Could you please provide the file(s) needed to generate local_field_module.mod? > > I suspect the source code in question is the same as ... This file is not enough to generate local_field_module.mod. You have to provide a self contained reproducer otherwise the PR will be closed as INVALID.
(In reply to Dominique d'Humieres from comment #3) > > > Could you please provide the file(s) needed to generate local_field_module.mod? > > > > I suspect the source code in question is the same as ... > > This file is not enough to generate local_field_module.mod. > > You have to provide a self contained reproducer otherwise the PR will be > closed as INVALID. I have confirmed it. I will do a regression hunt in the next day or two. Getting a reduced test case will be a little tricky.
Created attachment 42636 [details] Correct testcase Sorry, I missed that one of the files was binary. Correct testcase is now attached. $ gfortran local_field.f90 global_field.f90 -fcoarray=lib global_field.f90:126:0: lhs%values(:) = rhs%state() internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions. $
> Created attachment 42636 [details] > Correct testcase Thanks. If the two files are merged in one, the ICE is gone. Bisecting the 7 branch points to revision r254429 (pr81447 and pr82783), thus r254427 for trunk.
Reduced test case module global_field_module use local_field_module, only : local_field implicit none private public :: global_field type global_field private real, allocatable :: values(:)[:] contains procedure, private :: assign_local_field generic :: assignment(=) => assign_local_field end type real :: dx integer, allocatable :: num_local_points integer, parameter:: num_end_points=2 real :: boundary_vals(num_end_points) contains subroutine assign_local_field(lhs,rhs) class(global_field), intent(inout) :: lhs class(local_field), intent(in) :: rhs lhs%values(:) = rhs%state() call synchronize() end subroutine end module
*** Bug 83042 has been marked as a duplicate of this bug. ***
Does the reproducer in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83042 maybe help to fix this bug? At the moment our usage of the gcc trunk is frozen as we cannot work around the many cases where it occurs.
Created attachment 42720 [details] A fix for this PR This fixes the problem and boostraps/regtests OK. Paul
The ICEs are indeed with that problem. (Duplicate ticket https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83042) However, now I get segfaults however in several of our C and C++ bind(C) interfaces. I do not know whether this is at all related to this here. Will try to isolate the other thing, however, that will not work without also shipping C code.
Author: pault Date: Tue Nov 28 15:13:42 2017 New Revision: 255202 URL: https://gcc.gnu.org/viewcvs?rev=255202&root=gcc&view=rev Log: 2017-11-28 Paul Thomas <pault@gcc.gnu.org> PR fortran/83021 * resolve.c (resolve_component): Only escape for use assciated vtypes if the current namespace has no proc_name and is most particularly block data. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
Author: pault Date: Tue Nov 28 15:38:55 2017 New Revision: 255205 URL: https://gcc.gnu.org/viewcvs?rev=255205&root=gcc&view=rev Log: 2017-11-28 Paul Thomas <pault@gcc.gnu.org> PR fortran/83021 * resolve.c (resolve_component): Only escape for use assciated vtypes if the current namespace has no proc_name and is most particularly block data. Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c
Fixed! Thanks for the report. Paul