I just tried a valgrind version of recent trunk gfortran over testsuite file gfortran.dg/bessel_5.f90. I got $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c ./gfortran.dg/bessel_5.f90 ./gfortran.dg/bessel_5.f90:64:50: 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) & | 1 Error: Result of BESSEL_YN overflows its kind at (1) ./gfortran.dg/bessel_5.f90:64:26: 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) & | 1 Error: Result of BESSEL_YN is -INF at (1) ==1776287== Invalid read of size 8 ==1776287== at 0x603913: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1325) ==1776287== by 0x60397A: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1312) ==1776287== by 0x603B34: reduce_binary(arith (*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1438) ==1776287== by 0x603F72: eval_intrinsic(gfc_intrinsic_op, eval_f, gfc_expr*, gfc_expr*) (arith.c:1613) Please note I didn't use the recommended testsuite flags of -Wall -fno-range-check. Also, since this valgrind error occurs after gfortran finds an error in the user's source code, it doesn't look very important to me.
Confirmed, started with r9-1566-g87c789f1c0b2df41.
(In reply to David Binderman from comment #0) > I just tried a valgrind version of recent trunk gfortran over testsuite file > gfortran.dg/bessel_5.f90. > > I got > > $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c > ./gfortran.dg/bessel_5.f90 > ./gfortran.dg/bessel_5.f90:64:50: > > 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) > ])) & > | 1 > Error: Result of BESSEL_YN overflows its kind at (1) > ./gfortran.dg/bessel_5.f90:64:26: > > 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) > ])) & > | 1 > Error: Result of BESSEL_YN is -INF at (1) > ==1776287== Invalid read of size 8 > ==1776287== at 0x603913: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1325) > ==1776287== by 0x60397A: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1312) > ==1776287== by 0x603B34: reduce_binary(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1438) > ==1776287== by 0x603F72: eval_intrinsic(gfc_intrinsic_op, eval_f, > gfc_expr*, gfc_expr*) (arith.c:1613) > > Please note I didn't use the recommended testsuite flags of > -Wall -fno-range-check. > So, what happens if you do use the required -fno-range-check option?
(In reply to kargl from comment #2) > So, what happens if you do use the required -fno-range-check > option? The code is compiled happily: $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c -Wall -fno-range-check gfortran.dg/bessel_5.f90 $
On Sat, Mar 21, 2020 at 10:27:03PM +0000, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 > > --- Comment #3 from David Binderman <dcb314 at hotmail dot com> --- > (In reply to kargl from comment #2) > > So, what happens if you do use the required -fno-range-check > > option? > > The code is compiled happily: > > $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c -Wall > -fno-range-check gfortran.dg/bessel_5.f90 So, the code should be closed with WONTFIX or INVALID.
It's still a valid bugreport, the compiler shouldn't crash even on invalid programs.
On Mon, Mar 23, 2020 at 07:35:54AM +0000, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 > > Richard Biener <rguenth at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Keywords| |error-recovery, > | |ice-on-invalid-code > Priority|P3 |P5 > > --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- > It's still a valid bugreport, the compiler shouldn't crash even on invalid > programs. > I disagree.
I get an ICE even for the non-valgrind version on x86_64-pc-linux-gnu: gcc/testsuite/gfortran.dg/bessel_5.f90:64:50: 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) & | 1 Error: Result of BESSEL_YN overflows its kind at (1) gcc/testsuite/gfortran.dg/bessel_5.f90:64:26: 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) & | 1 Error: Result of BESSEL_YN is -INF at (1) f951: internal compiler error: Segmentation fault 0xd4aedf crash_signal ../../gcc-trunk/gcc/toplev.c:328 0x65ae4f reduce_binary_ac ../../gcc-trunk/gcc/fortran/arith.c:1325 0x65aee2 reduce_binary_ac ../../gcc-trunk/gcc/fortran/arith.c:1312 0x65b034 reduce_binary ../../gcc-trunk/gcc/fortran/arith.c:1438 0x65b35b eval_intrinsic ../../gcc-trunk/gcc/fortran/arith.c:1613 0x6965f8 simplify_intrinsic_op ../../gcc-trunk/gcc/fortran/expr.c:1219 0x6965f8 gfc_simplify_expr(gfc_expr*, int) ../../gcc-trunk/gcc/fortran/expr.c:2233 0x708c89 resolve_operator ../../gcc-trunk/gcc/fortran/resolve.c:4377 0x706177 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:7022 0x70993f gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:2162 0x70993f resolve_actual_arglist ../../gcc-trunk/gcc/fortran/resolve.c:2081 0x70654e resolve_function ../../gcc-trunk/gcc/fortran/resolve.c:3183 0x70654e gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:7029 0x70e7d1 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:6996 0x70e7d1 gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:10618 0x6fe518 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11706 0x700d9d resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:17233 0x700e6e gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:17268 0x6ef01d resolve_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:6245 0x6ef01d gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6492 I agree with Richard that this should not happen.
Reduced testcase: implicit none integer :: i if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) & then STOP 6 end if if (any (abs (BESSEL_YN(0, 10, 1.0) & - [ (BESSEL_YN(i, 1.0), i = 0, 10) ]) & > epsilon(0.0)*32)) then STOP 8 end if end
On Mon, Mar 23, 2020 at 07:29:02PM +0000, anlauf at gcc dot gnu.org wrote: > --- Comment #7 from anlauf at gcc dot gnu.org --- > I get an ICE even for the non-valgrind version on x86_64-pc-linux-gnu: > > gcc/testsuite/gfortran.dg/bessel_5.f90:64:50: > > 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) > & > | 1 > Error: Result of BESSEL_YN overflows its kind at (1) > gcc/testsuite/gfortran.dg/bessel_5.f90:64:26: > > 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) > & > | 1 > Error: Result of BESSEL_YN is -INF at (1) > f951: internal compiler error: Segmentation fault (snip) > > I agree with Richard that this should not happen. > 1. Fix the errors that are already emitted. It won't happen. 2. Use -fmax-errors = 1. It won't happen. -fmax-errors=1 should be the default. Unfortunately, the GCC diagnosistic has usurped that option. 3. Write correct Fortran. It won't happen. 4. Apply this patch. Watch for cut-n-paste tab corruption. ndex: gcc/fortran/arith.c =================================================================== --- gcc/fortran/arith.c (revision 280157) +++ gcc/fortran/arith.c (working copy) @@ -1322,6 +1322,12 @@ reduce_binary_ac (arith (*eval) (gfc_expr *, gfc_expr else { gfc_constructor *c = gfc_constructor_first (head); + + if (!c) + gfc_fatal_error ("\"To handle a language skillfully is to " + "practice a kind of evocative sorcery.\" " + "Charles Baudelaire"); + r = gfc_get_array_expr (c->expr->ts.type, c->expr->ts.kind, &op1->where); r->shape = gfc_copy_shape (op1->shape, op1->rank);
Created attachment 48108 [details] Fix for problem with one regression The attached fixes the problem but causes pr35849.f90 to regress in a rather peculiar fashion: pr35849.f90:5:55: 5 | INTEGER, PARAMETER, DIMENSION(10) :: B = ISHFTC(j, A, -20) ! { dg-error "must be positive" } | 1 Error: SIZE at (1) must be positive pr35849.f90:6:57: 6 | INTEGER, PARAMETER, DIMENSION(10) :: C = ISHFTC(1_1, A, j) ! { dg-error "less than or equal to BIT_SIZE" } | 1 Error: ‘SIZE’ at (1) must be less than or equal to BIT_SIZE(‘I’) pr35849.f90:7:51: 7 | INTEGER, PARAMETER, DIMENSION(10) :: D = ISHFTC(3, A, 5) ! { dg-error "Absolute value of SHIFT shall be less than or equal" } | 1 Error: Invalid character in name at (1) pr35849.f90:8:51: 8 | INTEGER, PARAMETER, DIMENSION(10) :: E = ISHFTC(3_1, A) ! { dg-error "second argument of ISHFTC exceeds BIT_SIZE of first argument" } | 1 Error: Invalid character in name at (1) The last two error come from match.c and must be left overs that have not been cleared. Cheers Paul
This issue was solved for GCC 10 = mainline by the following commit. Note: This commit caused PR94386. Note: As the commit message did not use the PR <category>/<bugid> syntax, the commit was not automatically added to the PR :-( commit r10-7444-g7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65 Author: Paul Thomas <pault@pc30.home> Date: Sat Mar 28 19:11:35 2020 +0000 Patch for PR94246 + PR fortran/94246 + * arith.c : Remove trailing white space. + * expr.c (scalarize_intrinsic_call): Remove the error checking. + Make a copy of the expression to be simplified and only replace + the original if the simplification succeeds. + PR fortran/94348 + * decl.c (gfc_match_submod_proc): Add result var to the + proc's namespace. [SIC! – the last PR seems to be wrong.]
(In reply to Tobias Burnus from comment #11) > This issue was solved for GCC 10 = mainline by the following commit. > > commit r10-7444-g7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65 Thus marking as 9 regression.
The releases/gcc-9 branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:f448af69b208ba95496748c4596a22d11b1a09b9 commit r9-9148-gf448af69b208ba95496748c4596a22d11b1a09b9 Author: Paul Thomas <pault@gcc.gnu.org> Date: Mon Jan 4 08:15:18 2021 +0000 Fortran: Fix scalarization of constant expressions. [PR94246]. 2021-01-04 Paul Thomas <pault@gcc.gnu.org> gcc/fortran PR fortran/94246 * expr.c (scalarize_intrinsic_call): Remove the error checking. Make a copy of the expression to be simplified and only replace the original if the simplification succeeds. gcc/testsuite/ PR fortran/94246 * gfortran.dg/bessel_5_redux.f90 : New test.
Fixed on 9-, 10- and 11- branches. Thanks for the reports. Paul