Re: Revert patch for MIPS TImode functions for 4.1.1
Roger Sayle [EMAIL PROTECTED] writes: On Fri, 19 May 2006, Mark Mitchell wrote: I'm evaluating the options. It would be helpful if someone has time to apply and test Richard's patch on 4.1, as that would let us know whether that option is viable as well. I've bootstrapped and regression tested a backport of Richard's patch against the gcc-4_1-branch on mips-sgi-irix6.5 with no new failures. His mainline change also has no testsuite problems on the same machine. The patch applies cleanly, with the exception of some mklibgcc.in hunks, due to the fact that the _floatun* symbols were added to 4.2 and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE functionality isn't on the branch. For the record, the final mklibgcc.in changes that I tested are attached to this e-mail. Thanks. I'll test this same version on mipsisa64-elf and mips64-linux-gnu. Richard
Re: Revert patch for MIPS TImode functions for 4.1.1
On Sun, 21 May 2006, Roger Sayle wrote: The patch applies cleanly, with the exception of some mklibgcc.in hunks, due to the fact that the _floatun* symbols were added to 4.2 and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE functionality isn't on the branch. For the record, the final mklibgcc.in changes that I tested are attached to this e-mail. This backport doesn't appear to be of the correct patch version, the final patch version used LIB2_SIDITI_CONV_FUNCS instead of LIB2LITERAL_CONVERSION_MODES. The patch (both that on mainline and this backport) includes _floatdidf in both the hardcoded lib2funcs list and that generated from lists of modes. This means that only one of the _floatdidf entries in the list gets deleted if _floatdidf is in LIB1ASMFUNCS, so causing a build error on such platforms (e.g. arm-none-linux-gnueabi, once a separate problem building mainline glibc with mainline GCC is fixed). -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Revert patch for MIPS TImode functions for 4.1.1
Joseph S. Myers [EMAIL PROTECTED] writes: The patch (both that on mainline and this backport) includes _floatdidf in both the hardcoded lib2funcs list and that generated from lists of modes. This means that only one of the _floatdidf entries in the list gets deleted if _floatdidf is in LIB1ASMFUNCS, so causing a build error on such platforms (e.g. arm-none-linux-gnueabi, once a separate problem building mainline glibc with mainline GCC is fixed). Argh! That was very sloppy of me, sorry. I've committed the patch below as obvious after testing on i686-pc-linux-gnu. Richard * mklibgcc.in (lib2funcs): Remove _floatdidf from initial assignment. Index: gcc/mklibgcc.in === --- gcc/mklibgcc.in (revision 113979) +++ gcc/mklibgcc.in (working copy) @@ -85,7 +85,7 @@ done # set to wordsize. objfile is the name of the associated object file lib2funcs='_muldi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3 - _cmpdi2 _ucmpdi2 _floatdidf _clear_cache + _cmpdi2 _ucmpdi2 _clear_cache _enable_execute_stack _trampoline __main _absvsi2 _absvdi2 _addvsi3 _addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors _ffssi2 _ffsdi2 _clz _clzsi2 _clzdi2 _ctzsi2 _ctzdi2 _popcount_tab
Re: Revert patch for MIPS TImode functions for 4.1.1
Richard Sandiford [EMAIL PROTECTED] writes:
Roger Sayle [EMAIL PROTECTED] writes:
On Fri, 19 May 2006, Mark Mitchell wrote:
I'm evaluating the options. It would be helpful if someone has time to
apply and test Richard's patch on 4.1, as that would let us know whether
that option is viable as well.
I've bootstrapped and regression tested a backport of Richard's patch
against the gcc-4_1-branch on mips-sgi-irix6.5 with no new failures.
His mainline change also has no testsuite problems on the same machine.
The patch applies cleanly, with the exception of some mklibgcc.in
hunks, due to the fact that the _floatun* symbols were added to 4.2
and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
functionality isn't on the branch. For the record, the final
mklibgcc.in changes that I tested are attached to this e-mail.
Thanks. I'll test this same version on mipsisa64-elf and
mips64-linux-gnu.
As Joseph said, that patch used the old makefile variable name, not the
revised LIBGCC2_SIDITI_CONV_FUNCS. Here's what I ended up testing.
It includes the fix for the duplicate _floatdidf.
Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
Mark, what do you think?
Richard
PR target/27681
* libgcc2.c (MIN_UNITS_PER_WORD): Move default definition from
libgcc2.h.
(LIBGCC2_UNITS_PER_WORD): Provide default definition, using old
MIN_UNITS_PER_WORD logic from libgcc2.h. Do nothing if
LIBGCC2_UNITS_PER_WORD MIN_UNITS_PER_WORD.
* libgcc2.h (MIN_UNITS_PER_WORD): Remove definition from here.
Use LIBGCC2_UNITS_PER_WORD rather than MIN_UNITS_PER_WORD to
determine the size of Wtype, etc.
* mklibgcc.in (LIB2_SIDITI_CONV_FUNCS): New argument.
(swfloatfuncs): New variable.
(dwfloatfuncs): Likewise.
(lib2funcs): Remove floating-point conversion functions from
initial assignment. Use LIB2_SIDITI_CONV_FUNCS to determine
the set of conversion routines needed. Allow entries to specify
an object name, filename and word size. Update users accordingly.
* Makefile.in (libgcc.mk): Pass LIB2_SIDITI_CONV_FUNCS.
* config/mips/t-mips (LIB2_SIDITI_CONV_FUNCS): Define.
Revert:
2006-02-08 Roger Sayle [EMAIL PROTECTED]
PR target/22209
* config/fixtfdi.c: New libgcc source file.
* config/fixunstfdi.c: New source file.
* config/floatditf.c: New source file.
* config/floatunditf.c: New souce file.
* config/mips/t-iris6 (LIB2FUNCS_EXTRA): Include the new source
files above instead of config/mips/_tilib.c.
* config/mips/t-linux64 (LIB2FUNCS_EXTRA): Likewise.
Index: gcc/libgcc2.c
===
--- gcc/libgcc2.c (revision 113971)
+++ gcc/libgcc2.c (working copy)
@@ -40,6 +40,23 @@ #define ATTRIBUTE_HIDDEN __attribute__
#define ATTRIBUTE_HIDDEN
#endif
+#ifndef MIN_UNITS_PER_WORD
+#define MIN_UNITS_PER_WORD UNITS_PER_WORD
+#endif
+
+#ifndef LIBGCC2_UNITS_PER_WORD
+# if MIN_UNITS_PER_WORD 4
+# define LIBGCC2_UNITS_PER_WORD 8
+# elif (MIN_UNITS_PER_WORD 2 \
+|| (MIN_UNITS_PER_WORD 1 LONG_LONG_TYPE_SIZE 32))
+# define LIBGCC2_UNITS_PER_WORD 4
+# else
+# define LIBGCC2_UNITS_PER_WORD MIN_UNITS_PER_WORD
+# endif
+#endif
+
+#if LIBGCC2_UNITS_PER_WORD = MIN_UNITS_PER_WORD
+
#include libgcc2.h
#ifdef DECLARE_LIBRARY_RENAMES
@@ -2010,3 +2027,4 @@ func_ptr __DTOR_LIST__[2] = {0, 0};
#endif
#endif /* no INIT_SECTION_ASM_OP and not CTOR_LISTS_DEFINED_EXTERNALLY */
#endif /* L_ctors */
+#endif /* LIBGCC2_UNITS_PER_WORD = MIN_UNITS_PER_WORD */
Index: gcc/libgcc2.h
===
--- gcc/libgcc2.h (revision 113971)
+++ gcc/libgcc2.h (working copy)
@@ -79,10 +79,6 @@ #define LIBGCC2_HAS_TF_MODE \
(BITS_PER_UNIT == 8 LIBGCC2_LONG_DOUBLE_TYPE_SIZE == 128)
#endif
-#ifndef MIN_UNITS_PER_WORD
-#define MIN_UNITS_PER_WORD UNITS_PER_WORD
-#endif
-
/* In the first part of this file, we are interfacing to calls generated
by the compiler itself. These calls pass values into these routines
which have very specific modes (rather than very specific types), and
@@ -155,7 +151,7 @@ #define double bogus_type
turns out that no platform would define COMPAT_DIMODE_TRAPPING_ARITHMETIC
if it existed. */
-#if MIN_UNITS_PER_WORD 4
+#if LIBGCC2_UNITS_PER_WORD == 8
#define W_TYPE_SIZE (8 * BITS_PER_UNIT)
#define Wtype DItype
#define UWtype UDItype
@@ -166,8 +162,7 @@ #define UDWtype UTItype
#define __NW(a,b) __ ## a ## di ## b
#define __NDW(a,b) __ ## a ## ti ## b
#define COMPAT_SIMODE_TRAPPING_ARITHMETIC
-#elif MIN_UNITS_PER_WORD 2 \
- || (MIN_UNITS_PER_WORD 1 LONG_LONG_TYPE_SIZE 32)
+#elif LIBGCC2_UNITS_PER_WORD == 4
#define W_TYPE_SIZE (4 * BITS_PER_UNIT)
#define Wtype SItype
#define UWtype USItype
Re: Revert patch for MIPS TImode functions for 4.1.1
Richard Sandiford wrote: Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf. Mark, what do you think? I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. So, we could declare that Fortran is not release-critical, and just release 4.1.1. On the other hand, it seems a shame to have a release in which a popular programming language is so horribly broken on a reasonably popular platform. You indicated off-line that your biggest concern with the patch was not its behavior on MIPS, but, rather, that it might break some other platform. I agree with that assessment of where the risks lie. In particular, with code like: +if [ $LIB2_SIDITI_CONV_FUNCS ]; then + for func in $swfloatfuncs; do +sifunc=`echo $func | sed -e 's/XX/si/'` +lib2funcs=$lib2funcs $sifunc:$sifunc:4 + done + for func in $dwfloatfuncs; do +difunc=`echo $func | sed -e 's/XX/di/'` +tifunc=`echo $func | sed -e 's/XX/ti/'` +lib2funcs=$lib2funcs $difunc:$difunc:4 $tifunc:$difunc:8 + done +else + lib2funcs=$lib2funcs `echo $swfloatfuncs | sed -e 's/XX/si/g'` + lib2funcs=$lib2funcs `echo $dwfloatfuncs | sed -e 's/XX/di/g'` +fi which, could, potentially change the libgcc API. However, I've started at the patch for quite some time, and I don't see any problems. And, thus far, there seem to be no problems on mainline. So, I think we should include this patch. Please apply, and let me know when you've done that, so that I can start an RC2 build. Thanks for working on this difficult issue. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
* Mark Mitchell [EMAIL PROTECTED] [2006-05-22 11:36]: I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. Did anyone investigate those abi_check failures I (and others) have seen? See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html -- Martin Michlmayr [EMAIL PROTECTED]
Re: Revert patch for MIPS TImode functions for 4.1.1
Martin Michlmayr wrote: * Mark Mitchell [EMAIL PROTECTED] [2006-05-22 11:36]: I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. Did anyone investigate those abi_check failures I (and others) have seen? See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html Yes, I asked the libstdc++ list, and Paolo C. says that they result from using a slightly different configuration from the configuration used to generate the baseline. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
Mark Mitchell wrote: Martin Michlmayr wrote: * Mark Mitchell [EMAIL PROTECTED] [2006-05-22 11:36]: I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. Did anyone investigate those abi_check failures I (and others) have seen? See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html Yes, I asked the libstdc++ list, and Paolo C. says that they result from using a slightly different configuration from the configuration used to generate the baseline. By the way, in case of no --enable-clocale= at configure time, a possible explanation is missing de_DE localedata, which leads to an automatic fall back to the generic locale model: http://gcc.gnu.org/onlinedocs/libstdc++/install.html Indeed, in those testresults I'm seeing ~300 unsupported tests, consistent with that situation. Of course, it would be nice if reporters could double check that on those machines gcc4.1.0 behaves the same. Paolo.
Re: Revert patch for MIPS TImode functions for 4.1.1
Mark Mitchell wrote: Richard Sandiford wrote: Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf. Mark, what do you think? I'm a bit torn. On the one hand, it doesn't look like there is any other reason to do a 4.1.1 RC2. So, we could declare that Fortran is not release-critical, and just release 4.1.1. On the other hand, it seems a shame to have a release in which a popular programming language is so horribly broken on a reasonably popular platform. Richard and I had another round of discussion about this patch, and I've decided to reverse my earlier decision. Sorry for the back-and-forth! In contrast to what I suggested above, 4.1.1 RC1 works for Fortran; the problem is that on soft-float 64-bit MIPS, conversions from floating-point types to 64-bit integers, and to unsigned 32-bit integers, are missing in libgcc. That's a serious problem, but one that we had in 4.1.0 as well. And, there is certainly some risk that the patch will break something; Joseph already caught one mistake. So, Richard and I have decided to leave well enough alone. Unless something else crops up in the next day or two, we'll consider 4.1.1 RC1 good enough, and spin final bits based on that. Gerald, your install.texi change is still OK. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
* Paolo Carlini [EMAIL PROTECTED] [2006-05-22 22:37]: Of course, it would be nice if reporters could double check that on those machines gcc4.1.0 behaves the same. I can confirm that the abi_check failure has gone away now that I have generated the de_DE locale. This makes me wonder, though, whether GCC could check whether the de_DE locale exists on the system and if not skips the abi_check test since it'll only give misleading results in that case. -- Martin Michlmayr http://www.cyrius.com/
Re: Revert patch for MIPS TImode functions for 4.1.1
On Fri, 19 May 2006, Mark Mitchell wrote:
I'm evaluating the options. It would be helpful if someone has time to
apply and test Richard's patch on 4.1, as that would let us know whether
that option is viable as well.
I've bootstrapped and regression tested a backport of Richard's patch
against the gcc-4_1-branch on mips-sgi-irix6.5 with no new failures.
His mainline change also has no testsuite problems on the same machine.
The patch applies cleanly, with the exception of some mklibgcc.in
hunks, due to the fact that the _floatun* symbols were added to 4.2
and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
functionality isn't on the branch. For the record, the final
mklibgcc.in changes that I tested are attached to this e-mail.
I hope this helps.
Roger
--
Index: mklibgcc.in
===
*** mklibgcc.in (revision 113936)
--- mklibgcc.in (working copy)
***
*** 17,22
--- 17,23
# LIB2ADDEHSTATIC
# LIB2ADDEHSHARED
# LIB2ADDEHDEP
+ # LIB2LITERAL_CONVERSION_MODES
# LIBUNWIND
# LIBUNWINDDEP
# SHLIBUNWIND_LINK
*** echo 'dirs = libgcc'
*** 54,63
echo
# Library members defined in libgcc2.c.
lib2funcs='_muldi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3
! _cmpdi2 _ucmpdi2 _floatdidf _floatdisf _fixunsdfsi _fixunssfsi
! _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi
! _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf _clear_cache
_enable_execute_stack _trampoline __main _absvsi2 _absvdi2 _addvsi3
_addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
_ffssi2 _ffsdi2 _clz _clzsi2 _clzdi2 _ctzsi2 _ctzdi2 _popcount_tab
--- 55,81
echo
# Library members defined in libgcc2.c.
+
+ # The floating-point conversion routines that involve a single-word integer.
+ # XX stands for the integer mode.
+ swfloatfuncs=
+ for mode in sf df xf; do
+ swfloatfuncs=$swfloatfuncs _fixuns${mode}XX
+ done
+
+ # Likewise double-word routines.
+ dwfloatfuncs=
+ for mode in sf df xf tf; do
+ dwfloatfuncs=$dwfloatfuncs _fix${mode}XX _fixuns${mode}XX
+ dwfloatfuncs=$dwfloatfuncs _floatXX${mode}
+ done
+
+ # Entries of the form objfile:func:wordsize indicate that libgcc2.c
+ # should be compiled with Lfunc defined and with LIBGCC2_UNITS_PER_WORD
+ # set to wordsize. objfile is the name of the associated object file
+
lib2funcs='_muldi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3
! _cmpdi2 _ucmpdi2 _floatdidf _clear_cache
_enable_execute_stack _trampoline __main _absvsi2 _absvdi2 _addvsi3
_addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
_ffssi2 _ffsdi2 _clz _clzsi2 _clzdi2 _ctzsi2 _ctzdi2 _popcount_tab
*** lib2funcs='_muldi3 _negdi2 _lshrdi3 _ash
*** 65,70
--- 83,103
_powixf2 _powitf2 _mulsc3 _muldc3 _mulxc3 _multc3 _divsc3 _divdc3
_divxc3 _divtc3'
+ if [ $LIB2LITERAL_CONVERSION_MODES ]; then
+ for func in $swfloatfuncs; do
+ sifunc=`echo $func | sed -e 's/XX/si/'`
+ lib2funcs=$lib2funcs $sifunc:$sifunc:4
+ done
+ for func in $dwfloatfuncs; do
+ difunc=`echo $func | sed -e 's/XX/di/'`
+ tifunc=`echo $func | sed -e 's/XX/ti/'`
+ lib2funcs=$lib2funcs $difunc:$difunc:4 $tifunc:$difunc:8
+ done
+ else
+ lib2funcs=$lib2funcs `echo $swfloatfuncs | sed -e 's/XX/si/g'`
+ lib2funcs=$lib2funcs `echo $dwfloatfuncs | sed -e 's/XX/di/g'`
+ fi
+
# Disable SHLIB_LINK if shared libgcc not enabled.
if [ @enable_shared@ = no ]; then
SHLIB_LINK=
*** fi
*** 145,152
# Remove any objects from lib2funcs and LIB2_DIVMOD_FUNCS that are
# defined as optimized assembly code in LIB1ASMFUNCS.
for name in $LIB1ASMFUNCS; do
! lib2funcs=`echo $lib2funcs | sed -e 's/^'$name' //' \
! -e 's/ '$name' / /' \
-e 's/ '$name'$//'`
LIB2_DIVMOD_FUNCS=`echo $LIB2_DIVMOD_FUNCS | sed -e 's/^'$name' //' \
-e 's/ '$name' / /' \
--- 178,185
# Remove any objects from lib2funcs and LIB2_DIVMOD_FUNCS that are
# defined as optimized assembly code in LIB1ASMFUNCS.
for name in $LIB1ASMFUNCS; do
! lib2funcs=`echo $lib2funcs | sed -e 's/^'$name'[ :]//' \
! -e 's/ '$name'[ :]/ /' \
-e 's/ '$name'$//'`
LIB2_DIVMOD_FUNCS=`echo $LIB2_DIVMOD_FUNCS | sed -e 's/^'$name' //' \
-e 's/ '$name' / /' \
*** for ml in $MULTILIBS; do
*** 248,263
#
for name in $lib2funcs; do
if [ $libgcc_s_so ]; then
out=libgcc/${dir}/${name}${objext}
outS=libgcc/${dir}/${name}_s${objext}
echo $outS: $libgcc2_c_dep
! echo $gcc_s_compile $flags -DL$name -c '$(srcdir)/libgcc2.c' \
-o $outS
echo $out: $libgcc2_c_dep
!
Re: Revert patch for MIPS TImode functions for 4.1.1
Mark Mitchell [EMAIL PROTECTED] writes: (My brain failed to digest the fact that the patch was on 4.1 as well as on mainline, perhaps in part because there doesn't seem to be a PR; Richard indicated to me that he would locate or open one now.) Opened as 27681. (And Roger: sorry for all the hassle this patch has caused you. A good deed and all that...) Richard
Re: Revert patch for MIPS TImode functions for 4.1.1
Hi Mark and Richard, On Fri, 19 May 2006, Mark Mitchell wrote: Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change for MIPS on the GCC 4.1 branch? (My brain failed to digest the fact that the patch was on 4.1 as well as on mainline, perhaps in part because there doesn't seem to be a PR; Richard indicated to me that he would locate or open one now.) Please can you explicitly confirm that we want to reintroduce PR target/22209 as a regression from gcc 4.1.0, and break the build of libgfortran on all 64-bit MIPS platforms, including IRIX? The MIPS backend still claims that TImode is scalar_mode_supported_p, and it's therefore possible to write simple C and C++ testcases that will regress with this change. I know my testing of such a reversion will reintroduce at least 4800 new failures in the dejagnu testsuite, for no reported improvement vs gcc 4.1.0. It's a lesser of two evils issue, and it's only further development on mainline, and not a user reported problem, that's revealed the potential fallout in 4.1.0. The tradeoff is between unlinkable code in the default build on the affected platforms, vs. unlinkable code when explicitly using the -msoft-float flag, which isn't tested by the testsuite. I'm happy to revert the changes at a moment's notice, especially if that's what the realease manager and MIPS maintainers want, but I just want to be certain that everyone's aware of the tradeoffs, so that whatever the outcome, it's not my fault. I'll start a bootstrap and regression test of the reversion against the 4.1 branch straight away, it's not clear if recent backports have introduced additional dependencies, but these machines aren't the fastest on the planet, and it's still behind on evaluating the recent set of mainline patches/changes. Roger --
Re: Revert patch for MIPS TImode functions for 4.1.1
Hi Richard, On Fri, 19 May 2006, Richard Sandiford wrote: Mark Mitchell [EMAIL PROTECTED] writes: (My brain failed to digest the fact that the patch was on 4.1 as well as on mainline, perhaps in part because there doesn't seem to be a PR; Richard indicated to me that he would locate or open one now.) Opened as 27681. (And Roger: sorry for all the hassle this patch has caused you. A good deed and all that...) Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS backend's use of the GOFAST libraries which is one of the major blockers of adding -msoft-float tests to the testsuite? :-) My very strong recommendation is to add a target-soft-float predicate to the dejgnu testsuite's require predicates, that'll allow us to test -msoft-float functionality on most platforms, by explicitly disabling the handful of problematic non-libgcc soft FP targets. This will both prevent this sort of regression in the future, and actually allow us to (automatedly) confirm that you patch has improved things. The MIN_UNITS_PER_WORD trick is used on multiple platforms, including PowerPC, IA-64 and s390, so without such tests we've no way of knowing that your recent fix isn't also required on them in addition to MIPS. See, for example, http://gcc.gnu.org/ml/gcc/2003-03/msg01365.html which was the Ulrich's s390 change that inspired my problematic fix for mips.h. Roger --
Re: Revert patch for MIPS TImode functions for 4.1.1
On Fri, 19 May 2006, Roger Sayle wrote: Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS backend's use of the GOFAST libraries which is one of the major blockers The GOFAST support is almost certainly unused and can probably be removed; at least, no-one has cared enough to fix the GOFAST case of bug 24998. (The relevant code to remove is I think the enable_gofast check in config.gcc, the documentation in doc/tm.texi, the file config/gofast.h, all the GOFAST conditionals in fp-bit.c and fp-bit.h, the effectively dead use of config/gofast.h and gofast_maybe_init_libfuncs in sparc/sparc.c, the comment in mips/elforion.h, the support in mips/mips.c, the file mips/t-gofast, and the use of US_SOFTWARE_GOFAST in mips/t-sr71k; the US_SOFTWARE_GOFAST macro can then be poisoned.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Revert patch for MIPS TImode functions for 4.1.1
Roger Sayle wrote: Hi Mark and Richard, On Fri, 19 May 2006, Mark Mitchell wrote: Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change for MIPS on the GCC 4.1 branch? (My brain failed to digest the fact that the patch was on 4.1 as well as on mainline, perhaps in part because there doesn't seem to be a PR; Richard indicated to me that he would locate or open one now.) Please can you explicitly confirm that we want to reintroduce PR target/22209 as a regression from gcc 4.1.0, and break the build of libgfortran on all 64-bit MIPS platforms, including IRIX? Thank you for raising this issue. The other choice may be to delay 4.1.1 until we have sufficient confidence in Richard's patch. Am I correct PR 22209 is only a Fortran problem? This is not a rhetorical question; I'm trying to gather data -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: Am I correct PR 22209 is only a Fortran problem? This is not a rhetorical question; I'm trying to gather data No, you can invoke it via using the attribute mode(TI), yes people are not going to do that but who knows. -- Pinski
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski wrote: On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: Am I correct PR 22209 is only a Fortran problem? This is not a rhetorical question; I'm trying to gather data No, you can invoke it via using the attribute mode(TI) Sure, but I'm not worried about that case. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
On May 19, 2006, at 10:12 AM, Mark Mitchell wrote: Andrew Pinski wrote: On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: Am I correct PR 22209 is only a Fortran problem? This is not a rhetorical question; I'm trying to gather data No, you can invoke it via using the attribute mode(TI) Sure, but I'm not worried about that case. If the back-end was not lying to the front-ends, this would never have been a problem, hint hint. Also why revert a patch which obvious works in the default configurations? -- Pinski
Re: Revert patch for MIPS TImode functions for 4.1.1
On Fri, 19 May 2006, Mark Mitchell wrote: No, you can invoke it via using the attribute mode(TI) Sure, but I'm not worried about that case. That would be the only class of C or C++ failures that I could easily construct by hand. Although the RTL optimizers will introduce TImode moves and temporary registers, it looks like they won't introduce any arithmetic/logical operations without explicit pattern support from the backend. Hence, it's only things like configure scripts that identify the presence of __int128_t and __uint128_t, and then explicitly use 128-bit operations in their source code that will be affected. This is the source of the libgfortran failure, where the runtime library detects these types are available, and uses them. It's not a problem in the gfortran compiler itself, which treats INTEGER*8, exactly the same way the C/C++ treat __int128_t. If libstdc++-3's configure checked for __int128_t and provided a specialized STL instantiation, it would exhibit the same issue. Roger --
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski wrote: Also why revert a patch which obvious works in the default configurations? It eliminates a Fortran problem, but causes a C problem. I'm evaluating the options. It would be helpful if someone has time to apply and test Richard's patch on 4.1, as that would let us know whether that option is viable as well. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski wrote: Also why revert a patch which obvious works in the default configurations? It eliminates a Fortran problem, but causes a C problem. I thought it only caused the problem with C code when supplying -msoft-float which is not a default configuration? It eliminates more than just a Fortran problem, it eliminates a C problem also. -- Pinski
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski wrote: Andrew Pinski wrote: Also why revert a patch which obvious works in the default configurations? It eliminates a Fortran problem, but causes a C problem. I thought it only caused the problem with C code when supplying -msoft-float which is not a default configuration? C code, compiled with -msoft-float, is very common on MIPS, whether or not it's a default configuration. Obviously, if we have to choose, shipping a compiler that works with software floating-point C programs on MIPS is much more important than shipping a compiler that works with Fortran. Of course, we'd rather not have to choose. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
Roger Sayle [EMAIL PROTECTED] writes: Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS backend's use of the GOFAST libraries which is one of the major blockers of adding -msoft-float tests to the testsuite? :-) No. As I've explained earlier this week, -msoft-float code is simply not link-compatible with -mhard-float code. Mark Mitchell [EMAIL PROTECTED] writes: Andrew Pinski wrote: Andrew Pinski wrote: Also why revert a patch which obvious works in the default configurations? It eliminates a Fortran problem, but causes a C problem. I thought it only caused the problem with C code when supplying -msoft-float which is not a default configuration? C code, compiled with -msoft-float, is very common on MIPS, whether or not it's a default configuration. Right. What do people mean by default configuration? The primary interest in MIPS these days is as an embedded platform, and the main bare-metal targets (mips-elf, mips64-elf mipsisa32-elf, mipsisa64-elf) all have -msoft-float multilibs. You don't have to do anything special to get them. Richard
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski [EMAIL PROTECTED] writes: If the back-end was not lying to the front-ends, this would never have been a problem, hint hint. I'm not sure what you mean here. In what way is the back end lying to the front end? Richard
