https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
Bug ID: 97768
Summary: [10/11 Regression] 32-bit f951 ICE on code from
OpenMolcas
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
module fortran_strings
interface operator(.in.)
module procedure substr_in_str
end interface
contains
pure function to_upper (in_str) result (string)
character(len=*), intent(in) :: in_str
character(len=len(in_str)) :: string
string = in_str
end function to_upper
logical pure function substr_in_str(substring, string)
character(len=*), intent(in) :: string, substring
substr_in_str=.false.
end function
end module
subroutine foo ()
use fortran_strings, only : to_upper, operator(.in.)
character(len=8) str
logical l
str = 'abcdefgh'
l = 'I' .in. to_upper(str)
end subroutine foo
ICEs in f951 when it is built as 32-bit binary (e.g. on i686-linux) in 10 and
trunk (e.g. 10 snapshot from 25th August as well as current 10 branch and
current master) in gmp:
Program received signal SIGSEGV, Segmentation fault.
0xf7c196b5 in __gmpz_sizeinbase () from /lib/libgmp.so.10
(gdb) bt
#0 0xf7c196b5 in __gmpz_sizeinbase () from /lib/libgmp.so.10
#1 0x08f8b12a in wi::from_mpz (type=<optimized out>, x=0xa9ab710, wrap=true)
at ../../gcc/wide-int.cc:269
#2 0x08620751 in gfc_mpz_get_hwi (op=<optimized out>) at
../../gcc/fortran/misc.c:426
#3 gfc_typename (ex=0xa9a9db0) at ../../gcc/fortran/misc.c:228
#4 0x0865e80e in resolve_operator (e=0xa9a9e40) at
../../gcc/fortran/resolve.c:4309
#5 gfc_resolve_expr (e=0xa9a9e40) at ../../gcc/fortran/resolve.c:7081
#6 0x08667853 in gfc_resolve_expr (e=<optimized out>) at
../../gcc/fortran/resolve.c:7055
#7 gfc_resolve_code (code=<optimized out>, ns=<optimized out>) at
../../gcc/fortran/resolve.c:11806
#8 0x0866bc2b in resolve_codes (ns=ns@entry=0xa996160) at
../../gcc/fortran/resolve.c:17340
#9 0x08657ca6 in gfc_resolve (ns=0xa996160) at
../../gcc/fortran/resolve.c:17375
#10 gfc_resolve (ns=0xa996160) at ../../gcc/fortran/resolve.c:17354
#11 0x0864b76a in resolve_all_program_units (gfc_global_ns_list=<optimized
out>) at ../../gcc/fortran/parse.c:6285
#12 gfc_parse_file () at ../../gcc/fortran/parse.c:6537
#13 0x0869b7c8 in gfc_be_parse_file () at ../../gcc/fortran/f95-lang.c:212
#14 0x08c4696e in compile_file () at ../../gcc/toplev.c:460
#15 0x085a39a2 in do_compile () at ../../gcc/toplev.c:2320
#16 toplev::main (this=0xffffc97e, argc=<optimized out>, argv=<optimized out>)
at ../../gcc/toplev.c:2459
#17 0x085a7d21 in main (argc=3, argv=0xffffca54) at ../../gcc/main.c:39
(gdb) p *ex->ts.u.cl->length
$4 = {expr_type = EXPR_FUNCTION, ts = {type = BT_INTEGER, kind = 4, u =
{derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0,
is_iso_c = 0, f90_type = BT_INTEGER, deferred = false, interop_kind = 0x0},
rank = 0, shape = 0x0, symtree = 0xa996b70, ref = 0x0, where = {
nextc = 0xa98f7fc, lb = 0xa98f7d0}, base_expr = 0x0, is_snan = 0, error =
0, user_operator = 0, mold = 0, must_finalize = 0,
no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0, do_not_warn
= 0, from_constructor = 0, representation = {length = 0,
string = 0x0}, boz = {len = 0, rdx = 0, str = 0x0}, value = {logical =
177828352, iokind = 177828352, integer = {{_mp_alloc = 177828352,
_mp_size = -149074752, _mp_d = 0xa972250}}, real = {{_mpfr_prec =
177828352, _mpfr_sign = -149074752, _mpfr_exp = 177676880,
_mpfr_d = 0x0}}, complex = {{re = {{_mpfr_prec = 177828352, _mpfr_sign
= -149074752, _mpfr_exp = 177676880, _mpfr_d = 0x0}}, im = {{
_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}}},
op = {op = 177828352, uop = 0xf71d4cc0, op1 = 0xa972250,
op2 = 0x0}, function = {actual = 0xa997200, name = 0xf71d4cc0
"__len_1_i4", isym = 0xa972250, esym = 0x0}, compcall = {actual = 0xa997200,
name = 0xf71d4cc0 "__len_1_i4", base_object = 0xa972250, tbp = 0x0,
ignore_pass = 0, assign = 0}, character = {
length = -640271184321482240, string = 0xa972250}, constructor =
0xa997200}, param_list = 0x0}
I'd guess the problem is the negative value.integer._mp_size.
That value is set with:
3836 if (atom_string[0] == '\0')
3837 e->value.function.name = NULL;
3838 else
3839 e->value.function.name = gfc_get_string ("%s",
atom_string);
so I guess value.integer is not the right union member, value.function is
{actual = 0xa997200, name = 0xf71d4cc0 "__len_1_i4", isym = 0xa972250, esym =
0x0}
The reason why this doesn't ICE with 64-bit f951 is that both
value.function.actual and value.function.name are 64-bit pointers there, while
32-bit pointers in the 32-bit f951, but value.integer._mp_alloc and
value.integer._mp_size are 32-bit integers in all cases.
So on little-endian 64-bit that means integer._mp_size is the top 32 bits of
the value.function.actual pointer, and if lucky 0.
But on 32-bit little-endian or even 64-bit big-endian it causes more harm.
