public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) @ 2021-12-09 11:16 asolokha at gmx dot com 2022-02-16 22:38 ` [Bug target/103628] " seurer at gcc dot gnu.org ` (6 more replies) 0 siblings, 7 replies; 8+ messages in thread From: asolokha at gmx dot com @ 2021-12-09 11:16 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com @ 2022-02-16 22:38 ` seurer at gcc dot gnu.org 2022-02-17 6:39 ` asolokha at gmx dot com ` (5 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: seurer at gcc dot gnu.org @ 2022-02-16 22:38 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com 2022-02-16 22:38 ` [Bug target/103628] " seurer at gcc dot gnu.org @ 2022-02-17 6:39 ` asolokha at gmx dot com 2022-02-17 13:46 ` seurer at gcc dot gnu.org ` (4 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: asolokha at gmx dot com @ 2022-02-17 6:39 UTC (permalink / raw) To: gcc-bugs 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 <…> ? ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com 2022-02-16 22:38 ` [Bug target/103628] " seurer at gcc dot gnu.org 2022-02-17 6:39 ` asolokha at gmx dot com @ 2022-02-17 13:46 ` seurer at gcc dot gnu.org 2022-02-18 4:26 ` asolokha at gmx dot com ` (3 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: seurer at gcc dot gnu.org @ 2022-02-17 13:46 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com ` (2 preceding siblings ...) 2022-02-17 13:46 ` seurer at gcc dot gnu.org @ 2022-02-18 4:26 ` asolokha at gmx dot com 2023-02-22 9:00 ` guihaoc at gcc dot gnu.org ` (2 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: asolokha at gmx dot com @ 2022-02-18 4:26 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com ` (3 preceding siblings ...) 2022-02-18 4:26 ` asolokha at gmx dot com @ 2023-02-22 9:00 ` guihaoc at gcc dot gnu.org 2023-03-24 2:48 ` cvs-commit at gcc dot gnu.org 2023-03-24 14:53 ` segher at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: guihaoc at gcc dot gnu.org @ 2023-02-22 9:00 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com ` (4 preceding siblings ...) 2023-02-22 9:00 ` guihaoc at gcc dot gnu.org @ 2023-03-24 2:48 ` cvs-commit at gcc dot gnu.org 2023-03-24 14:53 ` segher at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2023-03-24 2:48 UTC (permalink / raw) To: gcc-bugs 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> ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com ` (5 preceding siblings ...) 2023-03-24 2:48 ` cvs-commit at gcc dot gnu.org @ 2023-03-24 14:53 ` segher at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: segher at gcc dot gnu.org @ 2023-03-24 14:53 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-03-24 14:53 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-09 11:16 [Bug target/103628] New: ICE: Segmentation fault (in gfc_conv_tree_to_mpfr) asolokha at gmx dot com 2022-02-16 22:38 ` [Bug target/103628] " seurer at gcc dot gnu.org 2022-02-17 6:39 ` asolokha at gmx dot com 2022-02-17 13:46 ` seurer at gcc dot gnu.org 2022-02-18 4:26 ` asolokha at gmx dot com 2023-02-22 9:00 ` guihaoc at gcc dot gnu.org 2023-03-24 2:48 ` cvs-commit at gcc dot gnu.org 2023-03-24 14:53 ` segher at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).