Bug 94246 - [9 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
Summary: [9 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g8...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 10.0
: P5 normal
Target Milestone: 9.4
Assignee: Paul Thomas
URL:
Keywords: error-recovery, ice-on-invalid-code
Depends on:
Blocks: ubsan
  Show dependency treegraph
 
Reported: 2020-03-21 09:14 UTC by David Binderman
Modified: 2021-01-04 09:08 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work: 10.0, 8.4.0
Known to fail: 9.3.0
Last reconfirmed: 2020-03-21 00:00:00


Attachments
Fix for problem with one regression (331 bytes, patch)
2020-03-24 17:48 UTC, Paul Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Binderman 2020-03-21 09:14:45 UTC
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.
Comment 1 Martin Liška 2020-03-21 10:34:43 UTC
Confirmed, started with r9-1566-g87c789f1c0b2df41.
Comment 2 kargl 2020-03-21 21:10:43 UTC
(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?
Comment 3 David Binderman 2020-03-21 22:27:03 UTC
(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
$
Comment 4 Steve Kargl 2020-03-21 23:04:04 UTC
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.
Comment 5 Richard Biener 2020-03-23 07:35:54 UTC
It's still a valid bugreport, the compiler shouldn't crash even on invalid programs.
Comment 6 Steve Kargl 2020-03-23 16:21:25 UTC
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.
Comment 7 anlauf 2020-03-23 19:29:02 UTC
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.
Comment 8 anlauf 2020-03-23 19:54:53 UTC
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
Comment 9 Steve Kargl 2020-03-23 20:20:20 UTC
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);
Comment 10 Paul Thomas 2020-03-24 17:48:30 UTC
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
Comment 11 Tobias Burnus 2020-04-01 09:58:26 UTC
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.]
Comment 12 anlauf 2020-04-29 20:52:24 UTC
(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.
Comment 13 CVS Commits 2021-01-04 08:15:28 UTC
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.
Comment 14 Paul Thomas 2021-01-04 09:08:31 UTC
Fixed on 9-, 10- and 11- branches.

Thanks for the reports.

Paul