[Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

            Bug ID: 103628
           Summary: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: powerpc-e300c3-linux-gnu

Created attachment 51956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51956&action=edit
Testcase

gcc 12.0.0 20211205 snapshot (g:c9419faef0bfaf31e6a6f744baa064892e0d105c) ICEs
when compiling test/f90_correct/src/qp54.f08 from the flang test suite for a
32-bit BE target::

% powerpc-e300c3-linux-gnu-gfortran-12.0.0 -w -c
flang/testsuite/f90_correct/src/qp54.f08
f951: internal compiler error: Segmentation fault
0xf19f66 crash_signal
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/toplev.c:322
0x940280 tree_check(tree_node*, char const*, int, char const*, tree_code)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/tree.h:3440
0x940280 gfc_conv_tree_to_mpfr(__mpfr_struct*, tree_node*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/trans-const.c:285
0x90e770 gfc_interpret_float(int, unsigned char*, unsigned long,
__mpfr_struct*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/target-memory.c:419
0x816071 gfc_hollerith2real(gfc_expr*, int)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/arith.c:2605
0x900018 gfc_convert_constant(gfc_expr*, bt, int)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/simplify.c:8728
0x867b87 do_simplify
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/intrinsic.c:4636
0x87513a gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/intrinsic.c:5362
0x85c6f3 gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/expr.c:4545
0x837986 add_init_expr_to_sym
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/decl.c:2014
0x8437ba variable_decl
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/decl.c:3108
0x8437ba gfc_match_data_decl()
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/decl.c:6297
0x8b87a9 match_word
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/parse.c:67
0x8b87a9 decode_statement
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/parse.c:378
0x8bea44 next_free
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/parse.c:1397
0x8bea44 next_statement
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/parse.c:1629
0x8c0c8b parse_spec
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/parse.c:4168
0x8c4051 parse_progunit
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/parse.c:6192
0x8c4bf3 gfc_parse_file()
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/parse.c:6737
0x91adde gfc_be_parse_file
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/fortran/f95-lang.c:216

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

seurer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
It took me a while to figure out where this test case is located (not being
familiar with flang) but when I try to compile it I get an error message:

flang/test/f90_correct/src/qp54.f08:7:7:

    7 |   use check_mod
      |       1
Fatal Error: Cannot open module file 'check_mod.mod' for reading at (1): No
such file or directory


I assume I am missing something?

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

--- Comment #2 from Arseny Solokha <asolokha at gmx dot com> ---
Indeed. Sorry.

So could you cd flang/test/f90_correct/src and than invoke gfortran the
following way instead:

% powerpc-e300c3-linux-gnu-gfortran-12.0.1 -w -c check_mod.f90 qp54.f08
f951: internal compiler error: Segmentation fault
0xf264e6 crash_signal
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/toplev.cc:322

<…>

?

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

--- Comment #3 from seurer at gcc dot gnu.org ---
There isn't a check_mod.f90 but there is a check_mod.F90 (Linux is case
sensitive) and using that I was able to reproduce.

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

--- Comment #4 from Arseny Solokha <asolokha at gmx dot com> ---
Yes, I actually have both. But that's the peculiarity of the way I build my
test corpus, which I build from multiple sources, and not really important.
Sorry for mistakenly pointing you at the wrong file copied from the source
other what was originally mentioned in the PR.

After reducing qp54.f08 and check_mod.F90 together, the testcase boils down to
the following:

program main
  integer, parameter :: k = 16
  real(kind = k):: b = 4h1234
end program main

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[guihaoc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

HaoChen Gui <guihaoc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |guihaoc at gcc dot gnu.org
                 CC|                            |guihaoc at gcc dot gnu.org

--- Comment #5 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
The memory representation of IBM long double is not unique. It's actually the
sum of two 64-bit doubles. 

During decoding, the real variable b can be 
b = = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0,
  uexp = 67108357, sig = {0, 0, 9295712554570040320}}
which is sum of following two doubles
u = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0,
  uexp = 67108356, sig = {0, 0, 9295712899447228416}}
v = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0,
  uexp = 67108356, sig = {0, 0, 9295712209692852224}}

During encoding, the real variable b can be
b = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0,
  uexp = 67108357, sig = {0, 0, 9295712554570040320}}
which is splited to following two doubles
u = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0,
  uexp = 67108357, sig = {0, 0, 9295712554570039296}}
v = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0,
  uexp = 67108304, sig = {0, 0, 9223372036854775808}}

After decoding and encoding, the memory representation changes. After PR95450
added a verification of decoding/encoding check, native_interpret_expr returns
a NULL tree for this case which causes ICE.

Shall we disable Hollerith constant for IBM long double(-mabi=ibmlongdouble)?
Or just throw it to upper layer and let parser report an error? Please advice.

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by HaoChen Gui <guihaoc@gcc.gnu.org>:

https://gcc.gnu.org/g:3b67db31236631432e7f6d74ed49af9ae2183a4d

commit r13-6843-g3b67db31236631432e7f6d74ed49af9ae2183a4d
Author: Haochen Gui <guihaoc@gcc.gnu.org>
Date:   Fri Mar 24 10:45:52 2023 +0800

    Fortran: Escalate failure when Hollerith constant to real conversion fails

    gcc/fortran/
            PR target/103628
            * target-memory.cc (gfc_interpret_float): Return FAIL when
            native_interpret_expr gets a NULL tree.
            * arith.cc (gfc_hollerith2real): Return NULL when
            gfc_interpret_float fails.
            * error.cc (gfc_buffered_p): Define.
            * gfortran.h (gfc_buffered_p): Declare.
            * intrinsic.cc: Add diagnostic.h to include list.
            (do_simplify): Save errorcount and check it at finish.  Report a
            "Cannot simplify expression" error on a bad result if error count
            doesn't change and no other errors buffered.

    gcc/testsuite/
            PR target/103628
            * gfortran.dg/assumed_size_refs_2.f90: Check "Cannot simplify
            expression" error.
            * gfortran.dg/unpack_field_1.f90: Likewise.
            * gfortran.dg/pr103628.f90: New.

    Co-Authored-By: Tobias Burnus <tobias@codesourcery.com>

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to HaoChen Gui from comment #5)
> The memory representation of IBM long double is not unique. It's actually
> the sum of two 64-bit doubles. 

Yes, and the first of those two DP numbers is required to be the full
number rounded to double precision (with round-to-nearest).

What happened here?  I cannot make much sense of those numbers, but it
seems to contain something with uppercase ASCII overwritten?