https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78178
Bug ID: 78178
Summary: ICE in WHERE statement with diagnostic
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This is a spin-off from PR 65944.
As noted by Dominique in https://gcc.gnu.org/ml/fortran/2016-11/msg00002.html ,
gfc_match_simple_where also has an issue with not setting the locus
correctly. Test case:
! { dg-do compile }
! { dg-options "-Wcharacter-truncation" }
subroutine where_ice (i,j)
implicit none
character(8) :: y(10,10,2)
integer :: i
integer :: j
character(12) :: txt(5)
if (.true.) where (txt(1:3) /= '' ) y(1:3,i,j) = txt(1:3) ! { dg-warning
"CHARACTER expression will be truncated" }
end subroutine where_ice
Problem is that the obvious and simple fix
Index: match.c
===================================================================
--- match.c (Revision 241745)
+++ match.c (Arbeitskopie)
@@ -6219,6 +6219,7 @@ match_simple_where (void)
c->next = XCNEW (gfc_code);
*c->next = new_st;
+ c->next->loc = gfc_current_locus;
gfc_clear_new_st ();
new_st.op = EXEC_WHERE;
leads to lots of regressions:
ig25@linux-fd1f:~/Krempel/Where> gfortran actual_array_offset_1.f90
f951: internal compiler error: Segmentation fault
0xc2695f crash_signal
../../trunk/gcc/toplev.c:338
0x6f0ba6 resolve_select_type
../../trunk/gcc/fortran/resolve.c:8768
0x6e719c gfc_resolve_code(gfc_code*, gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:11045
0x6e94a7 resolve_codes
../../trunk/gcc/fortran/resolve.c:16025
0x6e93ee resolve_codes
../../trunk/gcc/fortran/resolve.c:16010
0x6e956e gfc_resolve(gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:16060
0x6d3ff2 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6092
0x717902 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:198
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
What on earth is going on there I don't know. I think I will
build from a clean tree and retry, and in the meantime fix
PR 65944 on the other branches.
