https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88227
--- Comment #8 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #7) > (In reply to Dominique d'Humieres from comment #6) > > The following test giveS ALSO an ICE with -m32 > > > > % cat boz_10.f90 > > print *, real(b'1010101001101',10) > > end > > % gfortran -m32 boz_10.f90 > > f951: internal compiler error: Segmentation fault: 11 > > libbacktrace could not find executable to open > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See <https://gcc.gnu.org/bugs/> for instructions. > > I've thought about this, and think it can be fixed by > removing the use gfc_max_integer_kind variable. Simply > convert the BOZ to an GMP mpz_t with a suitable width. > As I don't use multilib or the precision promoting > options I cannot test the change. In gfortran's current manifestation, it is not possible to support BOZ conversion when someone uses a rather poor combination of options. The following patch prevents the ICE. Index: check.c =================================================================== --- check.c (revision 273766) +++ check.c (working copy) @@ -108,9 +108,8 @@ is_boz_constant (gfc_expr *a) bool gfc_boz2real (gfc_expr *x, int kind) { - extern int gfc_max_integer_kind; gfc_typespec ts; - int len; + int i, len; char *buf, *str; if (!is_boz_constant (x)) @@ -165,6 +164,11 @@ gfc_boz2real (gfc_expr *x, int kind) x->boz.str = XCNEWVEC (char, len + 1); strncpy (x->boz.str, buf, len); + i = gfc_validate_kind (BT_REAL, kind, false); + if (gfc_real_kinds[i].mode_precision > 8 * gfc_max_integer_kind) + gfc_fatal_error ("Insufficient INTEGER kind required " + "in BOZ conversion at %L!", &x->where); + /* Convert to widest possible integer. */ gfc_boz2int (x, gfc_max_integer_kind); ts.type = BT_REAL;
