Re: Many regressions with: [patch] Cleanup fortran/convert.c
On Sat, Mar 10, 2012 at 12:21 PM, Steven Bosscher wrote: > On Sat, Mar 10, 2012 at 11:19 AM, Tobias Burnus wrote: >> Steven Bosscher wrote: >>> >>> This cleans up some remnants of the ancestors of fortran's convert.c, >>> which was copied from GNAT IIRC. I would bootstrap&test this, but trunk >>> appears to be broken for x86_64-linux right now (ICE in patch_jump_insn). >>> But I can post this >>> for review, at least. >>> OK for trunk, after bootstrap+test? >> >> >> Your patch seems to have caused many Fortran regressions. At least I see >> with 185156 only one (known) failure, cf. >> http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01069.html >> >> While starting with 185160 there are many, many gfortran failures, cf. >> http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01073.html > > Yes, it seems that different boolean types aren't allowed. I must have > looked at the wrong test results somehow. > > I'm testing this fix: > > Index: convert.c > === > --- convert.c (revision 185160) > +++ convert.c (working copy) > @@ -95,7 +95,8 @@ convert (tree type, tree expr) > if (code == VOID_TYPE) > return fold_build1_loc (input_location, CONVERT_EXPR, type, e); > if (code == BOOLEAN_TYPE) > - return truthvalue_conversion (e); > + return fold_build1_loc (input_location, NOP_EXPR, type, > + truthvalue_conversion (e)); return fold_convert_loc (input_location, type, truthvalue_conversion (e)); > if (code == INTEGER_TYPE) > return fold (convert_to_integer (type, e)); > if (code == POINTER_TYPE || code == REFERENCE_TYPE)
Re: Many regressions with: [patch] Cleanup fortran/convert.c
Am 10.03.2012 11:19, schrieb Tobias Burnus: Steven Bosscher wrote: This cleans up some remnants of the ancestors of fortran's convert.c, which was copied from GNAT IIRC. I would bootstrap&test this, but trunk appears to be broken for x86_64-linux right now (ICE in patch_jump_insn). But I can post this for review, at least. OK for trunk, after bootstrap+test? Your patch seems to have caused many Fortran regressions. At least I see with 185156 only one (known) failure, cf. http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01069.html While starting with 185160 there are many, many gfortran failures, cf. http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01073.html One error from the log is /home/tkoenig/trunk/gcc/testsuite/gfortran.dg/gnu_logical_1.F:4:0: error: type mismatch in binary expression logical(kind=8) logical(kind=8) logical(kind=4) D.2303 = k8 & l1.26; Thomas
Re: Many regressions with: [patch] Cleanup fortran/convert.c
On Sat, Mar 10, 2012 at 11:19 AM, Tobias Burnus wrote: > Steven Bosscher wrote: >> >> This cleans up some remnants of the ancestors of fortran's convert.c, >> which was copied from GNAT IIRC. I would bootstrap&test this, but trunk >> appears to be broken for x86_64-linux right now (ICE in patch_jump_insn). >> But I can post this >> for review, at least. >> OK for trunk, after bootstrap+test? > > > Your patch seems to have caused many Fortran regressions. At least I see > with 185156 only one (known) failure, cf. > http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01069.html > > While starting with 185160 there are many, many gfortran failures, cf. > http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01073.html Yes, it seems that different boolean types aren't allowed. I must have looked at the wrong test results somehow. I'm testing this fix: Index: convert.c === --- convert.c (revision 185160) +++ convert.c (working copy) @@ -95,7 +95,8 @@ convert (tree type, tree expr) if (code == VOID_TYPE) return fold_build1_loc (input_location, CONVERT_EXPR, type, e); if (code == BOOLEAN_TYPE) -return truthvalue_conversion (e); +return fold_build1_loc (input_location, NOP_EXPR, type, + truthvalue_conversion (e)); if (code == INTEGER_TYPE) return fold (convert_to_integer (type, e)); if (code == POINTER_TYPE || code == REFERENCE_TYPE)
Many regressions with: [patch] Cleanup fortran/convert.c
Steven Bosscher wrote: This cleans up some remnants of the ancestors of fortran's convert.c, which was copied from GNAT IIRC. I would bootstrap&test this, but trunk appears to be broken for x86_64-linux right now (ICE in patch_jump_insn). But I can post this for review, at least. OK for trunk, after bootstrap+test? Your patch seems to have caused many Fortran regressions. At least I see with 185156 only one (known) failure, cf. http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01069.html While starting with 185160 there are many, many gfortran failures, cf. http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01073.html Tobias * Make-lang.in (convert.o): Depend on convert.h. * convert.c: Header and comment cleanups. (gfc_thruthvalue_conversion): Rename static function to truthvalue_conversion. Do not use 'internal_error' from here, use 'gcc_unreachable' instead. (convert): Do not use 'error' for conversions to void, use 'gcc_unreachable' instead. Likewise for conversions to non-scalar types. Do not hanlde ENUMERAL_TYPE, the front end never creates them. Clean up #if 0 code.
