Re: [PATCH] Sync MIPS support from libffi master repository
On 2019-08-08 16:22, Jeff Law wrote: > On 8/8/19 4:18 PM, Aurelien Jarno wrote: > > > > It is used by libgo, but it seems to be the last user. > Ah, yes, I should have remembered libgo. And it links via > ../../blahblah. Thanks for digging into it. > > So, yea, we need it. So I think the best path forward is to just resync > everything to the upstream master. I have noticed that parisc and riscv support have commits that haven't been propagated on the upstream libffi side. Things might be easier to sync if those changes get merged on the libffi side. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Sync MIPS support from libffi master repository
On 2019-08-08 15:00, Jeff Law wrote: > On 8/8/19 2:56 PM, Aurelien Jarno wrote: > > On 2019-08-08 14:41, Jeff Law wrote: > >> On 8/5/19 2:33 PM, Aurelien Jarno wrote: > >>> This updates the libffi MIPS support up to commit 746dbe3a6a79, with the > >>> exception of commit bd72848c7af9 which prefixes the ALIGN macro with > >>> FFI_ for all ports. > >>> > >>> These patches, with the exception of the softfloat one, have been used > >>> on the Debian GCC packages for quite some time. > >>> > >>> libffi/Changelog: > >>> > >>> 2019-08-05 Aurelien Jarno > >>> > >>> Import from upstream > >>> * src/mips/ffi.c (ffi_call_O32, ffi_call_N32, > >>> ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust > >>> interface. > >>> (ffi_call_int): Renamed from ffi_call. > >>> (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions. > >>> (ffi_prep_closure_loc): Define jr instruction for R6. > >>> * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define. > >>> (FFI_TRAMPOLINE_SIZE): Define to 56 for N64. > >>> Test for __linux__ instead of linux. > >>> * src/mips/n32.S (ffi_go_closure_N32): New function. > >>> (ffi_call_N32): Adjust code for softfloat. > >>> (.set mips4): Guard with !defined(__mips_isa_rev) || > >>> (__mips_isa_rev<6). > >>> * src/mips/o32.S (ffi_go_closure_O32): New function. > >>> (ffi_call_O32): Adjust code for softfloat. > >> What's the motivation here? > > > > The original motivation is that it improves go support on MIPS in > > general and fixes it on MIPS R6. > > > > The more recent motivation is that Debian has been patching GCC with > > those changes for quite some time, however we are now requested that > > those patches are merged upstream. > Understood. > > > > >> Would we just be better off moving all of libffi forward rather than > >> just MIPS bits? > > > > Looking at the history, each port has be doing its own sync from libffi. > > Now I agree with you that if possible, moving all of libffi forward > > looks like a good idea. > If we still need libffi, this would be my preference... But... > > > > >> Do we even still need a bundled libffi in GCC anymore? > > > > The issue might be that the last libffi release has been done 5 years > > ago, and most of the recent commits done in the libffi/ directory are > > not present in a released version of libffi. > > > > Otherwise I do not have idea if it is feasible to use the shared libffi > > library. > My point is I'm not even sure we're using libffi within gcc anymore. I > know we used it for Java bits, but that was killed some time ago. Some > quick grepping for lffi, ffi.h and ffitarget.h aren't turning up > anything outside the libffi directory itself. So I really question if > we still need it at all within gcc. It is used by libgo, but it seems to be the last user. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Sync MIPS support from libffi master repository
On 2019-08-08 14:41, Jeff Law wrote: > On 8/5/19 2:33 PM, Aurelien Jarno wrote: > > This updates the libffi MIPS support up to commit 746dbe3a6a79, with the > > exception of commit bd72848c7af9 which prefixes the ALIGN macro with > > FFI_ for all ports. > > > > These patches, with the exception of the softfloat one, have been used > > on the Debian GCC packages for quite some time. > > > > libffi/Changelog: > > > > 2019-08-05 Aurelien Jarno > > > > Import from upstream > > * src/mips/ffi.c (ffi_call_O32, ffi_call_N32, > > ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust > > interface. > > (ffi_call_int): Renamed from ffi_call. > > (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions. > > (ffi_prep_closure_loc): Define jr instruction for R6. > > * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define. > > (FFI_TRAMPOLINE_SIZE): Define to 56 for N64. > > Test for __linux__ instead of linux. > > * src/mips/n32.S (ffi_go_closure_N32): New function. > > (ffi_call_N32): Adjust code for softfloat. > > (.set mips4): Guard with !defined(__mips_isa_rev) || > > (__mips_isa_rev<6). > > * src/mips/o32.S (ffi_go_closure_O32): New function. > > (ffi_call_O32): Adjust code for softfloat. > What's the motivation here? The original motivation is that it improves go support on MIPS in general and fixes it on MIPS R6. The more recent motivation is that Debian has been patching GCC with those changes for quite some time, however we are now requested that those patches are merged upstream. > Would we just be better off moving all of libffi forward rather than > just MIPS bits? Looking at the history, each port has be doing its own sync from libffi. Now I agree with you that if possible, moving all of libffi forward looks like a good idea. > Do we even still need a bundled libffi in GCC anymore? The issue might be that the last libffi release has been done 5 years ago, and most of the recent commits done in the libffi/ directory are not present in a released version of libffi. Otherwise I do not have idea if it is feasible to use the shared libffi library. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
[PATCH] Sync MIPS support from libffi master repository
This updates the libffi MIPS support up to commit 746dbe3a6a79, with the
exception of commit bd72848c7af9 which prefixes the ALIGN macro with
FFI_ for all ports.
These patches, with the exception of the softfloat one, have been used
on the Debian GCC packages for quite some time.
libffi/Changelog:
2019-08-05 Aurelien Jarno
Import from upstream
* src/mips/ffi.c (ffi_call_O32, ffi_call_N32,
ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust
interface.
(ffi_call_int): Renamed from ffi_call.
(ffi_call, ffi_call_go, ffi_prep_go_closure): New functions.
(ffi_prep_closure_loc): Define jr instruction for R6.
* src/mips/ffitarget.h (FFI_GO_CLOSURES): Define.
(FFI_TRAMPOLINE_SIZE): Define to 56 for N64.
Test for __linux__ instead of linux.
* src/mips/n32.S (ffi_go_closure_N32): New function.
(ffi_call_N32): Adjust code for softfloat.
(.set mips4): Guard with !defined(__mips_isa_rev) ||
(__mips_isa_rev<6).
* src/mips/o32.S (ffi_go_closure_O32): New function.
(ffi_call_O32): Adjust code for softfloat.
diff --git a/libffi/src/mips/ffi.c b/libffi/src/mips/ffi.c
index 5d0dd70cb32..70a2081b498 100644
--- a/libffi/src/mips/ffi.c
+++ b/libffi/src/mips/ffi.c
@@ -581,14 +581,15 @@ ffi_status ffi_prep_cif_machdep(ffi_cif *cif)
/* Low level routine for calling O32 functions */
extern int ffi_call_O32(void (*)(char *, extended_cif *, int, int),
extended_cif *, unsigned,
- unsigned, unsigned *, void (*)(void));
+ unsigned, unsigned *, void (*)(void), void *closure);
/* Low level routine for calling N32 functions */
extern int ffi_call_N32(void (*)(char *, extended_cif *, int, int),
extended_cif *, unsigned,
- unsigned, void *, void (*)(void));
+ unsigned, void *, void (*)(void), void *closure);
-void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
+void ffi_call_int(ffi_cif *cif, void (*fn)(void), void *rvalue,
+ void **avalue, void *closure)
{
extended_cif ecif;
@@ -610,7 +611,7 @@ void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue,
void **avalue)
case FFI_O32:
case FFI_O32_SOFT_FLOAT:
ffi_call_O32(ffi_prep_args, &ecif, cif->bytes,
- cif->flags, ecif.rvalue, fn);
+ cif->flags, ecif.rvalue, fn, closure);
break;
#endif
@@ -642,7 +643,7 @@ void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue,
void **avalue)
#endif
}
ffi_call_N32(ffi_prep_args, &ecif, cif->bytes,
- cif->flags, rvalue_copy, fn);
+ cif->flags, rvalue_copy, fn, closure);
if (copy_rvalue)
memcpy(ecif.rvalue, rvalue_copy + copy_offset, cif->rtype->size);
}
@@ -655,11 +656,27 @@ void ffi_call(ffi_cif *cif, void (*fn)(void), void
*rvalue, void **avalue)
}
}
+void
+ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
+{
+ ffi_call_int (cif, fn, rvalue, avalue, NULL);
+}
+
+void
+ffi_call_go (ffi_cif *cif, void (*fn)(void), void *rvalue,
+void **avalue, void *closure)
+{
+ ffi_call_int (cif, fn, rvalue, avalue, closure);
+}
+
+
#if FFI_CLOSURES
#if defined(FFI_MIPS_O32)
extern void ffi_closure_O32(void);
+extern void ffi_go_closure_O32(void);
#else
extern void ffi_closure_N32(void);
+extern void ffi_go_closure_N32(void);
#endif /* FFI_MIPS_O32 */
ffi_status
@@ -698,7 +715,11 @@ ffi_prep_closure_loc (ffi_closure *closure,
/* lui $12,high(codeloc) */
tramp[2] = 0x3c0c | ((unsigned)codeloc >> 16);
/* jr $25 */
+#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
tramp[3] = 0x0328;
+#else
+ tramp[3] = 0x0329;
+#endif
/* ori $12,low(codeloc) */
tramp[4] = 0x358c | ((unsigned)codeloc & 0x);
#else
@@ -726,7 +747,11 @@ ffi_prep_closure_loc (ffi_closure *closure,
/* ori $25,low(fn) */
tramp[10] = 0x3739 | ((unsigned long)fn & 0x);
/* jr $25 */
+#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
tramp[11] = 0x0328;
+#else
+ tramp[11] = 0x0329;
+#endif
/* ori $12,low(codeloc) */
tramp[12] = 0x358c | ((unsigned long)codeloc & 0x);
@@ -762,17 +787,17 @@ ffi_prep_closure_loc (ffi_closure *closure,
* Based on the similar routine for sparc.
*/
int
-ffi_closure_mips_inner_O32 (ffi_closure *closure,
+ffi_closure_mips_inner_O32 (ffi_cif *cif,
+void (*fun)(ffi_cif*, void*, void**, void*),
+ void *user_data,
void *rvalue, ffi_arg *ar,
double *fpr)
{
- ffi_cif *cif;
void **avaluep;
ffi_arg *avalue;
ffi_type **arg_types;
int i, avn, argn, seen_int;
-
Re: Fix gcc-7 and gcc-8 build of GO for Hurd and not kFreeBSD in debian/rules.defs
On 2017-11-20 14:31, Svante Signell wrote: > On Mon, 2017-11-20 at 14:04 +0100, Aurelien Jarno wrote: > > On 2017-11-20 13:20, Svante Signell wrote: > > > On Thu, 2017-11-16 at 20:39 +0100, Svante Signell wrote: > > > > > > Seeing the recent update of debian/rules.defs in gcc-7 a mistake was > > > revealed in the patch debian_rules.defs for both gcc-7 and gcc-8. The > > > correct patch is inlined below: > > > > > > --- a/debian/rules.defs 2017-11-20 12:59:25.0 +0100 > > > +++ b/debian/rules.defs 2017-11-20 13:01:54.0 +0100 > > > @@ -807,7 +807,7 @@ > > > ifeq (,$(filter $(distrelease),lenny etch squeeze dapper hardy jaunty > > > karmic > > > lucid maverick natty oneiric)) > > > go_no_cpus := $(filter-out arm, $(go_no_cpus)) > > > endif > > > -go_no_systems := gnu kfreebsd-gnu > > > +go_no_systems := kfreebsd > > > > > > ifneq ($(with_base_only),yes) > > > ifneq ($(separate_lang),yes) > > > @@ -817,7 +817,7 @@ > > > ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(go_no_cpus))) > > > with_go := disabled for cpu $(DEB_TARGET_ARCH_CPU) > > > endif > > > -ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) > > > +ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) > > > with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) > > > endif > > > ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) > > > > > > Changing back to go_no_systems := kfreebsd-gnu as aurel32 did disables the > > > build of go also for GNU/Hurd. The culprit is to match DEB_TARGET_ARCH_OS > > > to > > > kfreebsd to disable the build of go for GNU/kFreeBSD, not to match > > > DEB_TARGET_GNU_SYSTEM to kfreebsd-gnu, since that will match gnu too :( > > > > I did that change because changing go_no_systems from kfreebsd-gnu to > > kfreebsd is what caused GCC 7 to FTBFS on at least kfreebsd-i386 since > > version 7.2.0-15 (see bug#881656). > > > > Your change also looks fine to me. Should I commit it? > > Yes please. And do this change also for gcc-8, otherwise it will FTBFS on > kFreeBSD too. Done, thanks! -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Fix gcc-7 and gcc-8 build of GO for Hurd and not kFreeBSD in debian/rules.defs
On 2017-11-20 13:20, Svante Signell wrote: > On Thu, 2017-11-16 at 20:39 +0100, Svante Signell wrote: > > Seeing the recent update of debian/rules.defs in gcc-7 a mistake was revealed > in > the patch debian_rules.defs for both gcc-7 and gcc-8. The correct patch is > inlined below: > > --- a/debian/rules.defs 2017-11-20 12:59:25.0 +0100 > +++ b/debian/rules.defs 2017-11-20 13:01:54.0 +0100 > @@ -807,7 +807,7 @@ > ifeq (,$(filter $(distrelease),lenny etch squeeze dapper hardy jaunty karmic > lucid maverick natty oneiric)) > go_no_cpus := $(filter-out arm, $(go_no_cpus)) > endif > -go_no_systems := gnu kfreebsd-gnu > +go_no_systems := kfreebsd > > ifneq ($(with_base_only),yes) > ifneq ($(separate_lang),yes) > @@ -817,7 +817,7 @@ > ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(go_no_cpus))) > with_go := disabled for cpu $(DEB_TARGET_ARCH_CPU) > endif > -ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) > +ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) > with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) > endif > ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) > > Changing back to go_no_systems := kfreebsd-gnu as aurel32 did disables the > build > of go also for GNU/Hurd. The culprit is to match DEB_TARGET_ARCH_OS to > kfreebsd > to disable the build of go for GNU/kFreeBSD, not to match > DEB_TARGET_GNU_SYSTEM > to kfreebsd-gnu, since that will match gnu too :( I did that change because changing go_no_systems from kfreebsd-gnu to kfreebsd is what caused GCC 7 to FTBFS on at least kfreebsd-i386 since version 7.2.0-15 (see bug#881656). Your change also looks fine to me. Should I commit it? -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH, PR59833]: Fix sNaN handling in ARM float to double conversion
On 2016-07-20 11:22, Ramana Radhakrishnan wrote: > On Wed, Jul 20, 2016 at 11:14 AM, Aurelien Jarno wrote: > > On 2016-07-20 11:04, Ramana Radhakrishnan wrote: > >> On Wed, Jul 20, 2016 at 10:56 AM, Aurelien Jarno > >> wrote: > >> > On 2016-07-20 10:10, Ramana Radhakrishnan wrote: > >> >> On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno > >> >> wrote: > >> >> > On ARM soft-float, the float to double conversion doesn't convert a > >> >> > sNaN > >> >> > to qNaN as the IEEE Std 754 standard mandates: > >> >> > > >> >> > "Under default exception handling, any operation signaling an invalid > >> >> > operation exception and for which a floating-point result is to be > >> >> > delivered shall deliver a quiet NaN." > >> >> > > >> >> > Given the soft float ARM code ignores exceptions and always provides a > >> >> > result, a float to double conversion of a signaling NaN should return > >> >> > a > >> >> > quiet NaN. Fix this in extendsfdf2. > >> >> > > >> >> > gcc/ChangeLog: > >> >> > > >> >> > PR target/59833 > >> >> > * config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN. > >> >> > > >> >> > gcc/testsuite/ChangeLog: > >> >> > > >> >> > * gcc.dg/pr59833.c: New testcase. > >> >> > >> >> > >> >> Ok - assuming this was tested appropriately with no regressions. > >> > > >> > Given it only touches arm code, I only tested it on arm and I have seen > >> > no regression. That said I wouldn't be surprised if the new testcase > >> > fails on some other architectures. > >> > >> I was assuming you tested it on ARM :) In this case given the change > >> is only in the backend I would have expected this patch to have been > >> tested for soft-float ARM or an appropriate multilib. Saying what > >> configuration the patch was tested on is useful for the audit trail. > >> For e.g. it's no use testing this patch on armhf ( i.e. > >> --with-float=hard --with-fpu=vfpv3/neon --with-arch=armv7-a) as by > >> default the test would never generate the call to the library function > >> but I'm sure you know all that anyway. > > > > Indeed I should have given more details. I tested it on a Debian armel > > machine, and I configured GCC the same way as the Debian package, that > > is using --with-arch=armv4t --with-float=soft. > > > > I built it once with the new test but without the fix and a second time > > with both the test and the fix. I have verified that the test fails in > > the first case and pass in the second case. > > Thanks for the info - what about all the other regression tests ? Did > you do a full make check and ensure that no other tests regressed in > comparison ? Patches need to be tested against the entire regression > testsuite and not just what was added. Yes, I compared the testsuite result between the two runs, and there are identical beside this new test (hence my "I have seen no regression" in my first answer). Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH, PR59833]: Fix sNaN handling in ARM float to double conversion
On 2016-07-20 11:04, Ramana Radhakrishnan wrote: > On Wed, Jul 20, 2016 at 10:56 AM, Aurelien Jarno wrote: > > On 2016-07-20 10:10, Ramana Radhakrishnan wrote: > >> On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno > >> wrote: > >> > On ARM soft-float, the float to double conversion doesn't convert a sNaN > >> > to qNaN as the IEEE Std 754 standard mandates: > >> > > >> > "Under default exception handling, any operation signaling an invalid > >> > operation exception and for which a floating-point result is to be > >> > delivered shall deliver a quiet NaN." > >> > > >> > Given the soft float ARM code ignores exceptions and always provides a > >> > result, a float to double conversion of a signaling NaN should return a > >> > quiet NaN. Fix this in extendsfdf2. > >> > > >> > gcc/ChangeLog: > >> > > >> > PR target/59833 > >> > * config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN. > >> > > >> > gcc/testsuite/ChangeLog: > >> > > >> > * gcc.dg/pr59833.c: New testcase. > >> > >> > >> Ok - assuming this was tested appropriately with no regressions. > > > > Given it only touches arm code, I only tested it on arm and I have seen > > no regression. That said I wouldn't be surprised if the new testcase > > fails on some other architectures. > > I was assuming you tested it on ARM :) In this case given the change > is only in the backend I would have expected this patch to have been > tested for soft-float ARM or an appropriate multilib. Saying what > configuration the patch was tested on is useful for the audit trail. > For e.g. it's no use testing this patch on armhf ( i.e. > --with-float=hard --with-fpu=vfpv3/neon --with-arch=armv7-a) as by > default the test would never generate the call to the library function > but I'm sure you know all that anyway. Indeed I should have given more details. I tested it on a Debian armel machine, and I configured GCC the same way as the Debian package, that is using --with-arch=armv4t --with-float=soft. I built it once with the new test but without the fix and a second time with both the test and the fix. I have verified that the test fails in the first case and pass in the second case. > I don't know if this would pass or fail on other architectures - if it > fails it indicates a bug in their ports and for them to fix up as > appropriate. > > > > > > Also I have done the copyright assignment for GCC, but I do not have SVN > > write access. Could someone please commit this for me? > > I will take care of it. Thanks again for following up on the patch. Thanks! Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH, PR59833]: Fix sNaN handling in ARM float to double conversion
On 2016-07-20 10:10, Ramana Radhakrishnan wrote: > On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno wrote: > > On ARM soft-float, the float to double conversion doesn't convert a sNaN > > to qNaN as the IEEE Std 754 standard mandates: > > > > "Under default exception handling, any operation signaling an invalid > > operation exception and for which a floating-point result is to be > > delivered shall deliver a quiet NaN." > > > > Given the soft float ARM code ignores exceptions and always provides a > > result, a float to double conversion of a signaling NaN should return a > > quiet NaN. Fix this in extendsfdf2. > > > > gcc/ChangeLog: > > > > PR target/59833 > > * config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/pr59833.c: New testcase. > > > Ok - assuming this was tested appropriately with no regressions. Given it only touches arm code, I only tested it on arm and I have seen no regression. That said I wouldn't be surprised if the new testcase fails on some other architectures. Also I have done the copyright assignment for GCC, but I do not have SVN write access. Could someone please commit this for me? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
[PATCH, PR59833]: Fix sNaN handling in ARM float to double conversion
On ARM soft-float, the float to double conversion doesn't convert a sNaN
to qNaN as the IEEE Std 754 standard mandates:
"Under default exception handling, any operation signaling an invalid
operation exception and for which a floating-point result is to be
delivered shall deliver a quiet NaN."
Given the soft float ARM code ignores exceptions and always provides a
result, a float to double conversion of a signaling NaN should return a
quiet NaN. Fix this in extendsfdf2.
gcc/ChangeLog:
PR target/59833
* config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN.
gcc/testsuite/ChangeLog:
* gcc.dg/pr59833.c: New testcase.
---
gcc/testsuite/gcc.dg/pr59833.c | 18 ++
libgcc/config/arm/ieee754-df.S | 10 +++---
2 files changed, 25 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr59833.c
diff --git a/gcc/testsuite/gcc.dg/pr59833.c b/gcc/testsuite/gcc.dg/pr59833.c
new file mode 100644
index 000..e0e4ed5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr59833.c
@@ -0,0 +1,18 @@
+/* { dg-do run { target { *-*-linux* *-*-gnu* } } } */
+/* { dg-options "-O0 -lm" } */
+/* { dg-require-effective-target issignaling } */
+
+#define _GNU_SOURCE
+#include
+
+int main (void)
+{
+ float sNaN = __builtin_nansf ("");
+ double x = (double) sNaN;
+ if (issignaling(x))
+ {
+__builtin_abort();
+ }
+
+ return 0;
+}
diff --git a/libgcc/config/arm/ieee754-df.S b/libgcc/config/arm/ieee754-df.S
index a2aac70..1ecaa9d 100644
--- a/libgcc/config/arm/ieee754-df.S
+++ b/libgcc/config/arm/ieee754-df.S
@@ -507,11 +507,15 @@ ARM_FUNC_ALIAS aeabi_f2d extendsfdf2
eorne xh, xh, #0x3800 @ fixup exponent otherwise.
RETc(ne)@ and return it.
- teq r2, #0 @ if actually 0
- do_it ne, e
- teqne r3, #0xff00 @ or INF or NAN
+ bicsr2, r2, #0xff00 @ isolate mantissa
+ do_it eq @ if 0, that is ZERO or INF,
RETc(eq)@ we are done already.
+ teq r3, #0xff00 @ check for NAN
+ do_it eq, t
+ orreq xh, xh, #0x0008 @ change to quiet NAN
+ RETc(eq)@ and return it.
+
@ value was denormalized. We can normalize it now.
do_push {r4, r5, lr}
.cfi_adjust_cfa_offset 12 @ CFA is now sp + previousOffset + 12
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH, PR61219]: Fix sNaN handling in ARM float to double conversion
On Tue, Jun 17, 2014 at 11:29:01PM +0100, Ramana Radhakrishnan wrote:
> On Sun, May 18, 2014 at 10:23 PM, Aurelien Jarno wrote:
> > On ARM soft-float, the float to double conversion doesn't convert a sNaN
> > to qNaN as the IEEE Std 754 standard mandates:
> >
> > "Under default exception handling, any operation signaling an invalid
> > operation exception and for which a floating-point result is to be
> > delivered shall deliver a quiet NaN."
> >
> > Given the soft float ARM code ignores exceptions and always provides a
> > result, a float to double conversion of a signaling NaN should return a
> > quiet NaN. Fix this in extendsfdf2.
> >
> >
> > 2014-05-18 Aurelien Jarno
> >
> > PR target/61219
> > * config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN.
>
> Ok if no regressions along with a testcase to catch this case please
> and fixing the PR number
I have added such a testcase in the new version below. I didn't add it
in the target specific subdirectory, as other architectures might be
affected. Actually aarch64 is also affected, though for different
reasons. I have tested that the testcase correctly catch the issue, and
that the whole patch doesn't cause any regression.
Please find the new patch below. If it is fine, I would appreciate if
someone can commit the patch, as I don't have SVN write access (though I
have done the copyright assignment stuff).
> Sorry about the slow review.
No problem, I am also very often short on time.
Aurelien
gcc/testsuite/ChangeLog
2014-06-18 Aurelien Jarno
PR target/59833
* gcc.dg/pr59833.c: New testcase.
Index: gcc/testsuite/gcc.dg/pr59833.c
===
--- gcc/testsuite/gcc.dg/pr59833.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr59833.c (working copy)
@@ -0,0 +1,15 @@
+/* PR target/59833 */
+/* { dg-do run } */
+/* { dg-options "-lm" } */
+
+extern int __issignaling (double);
+
+int
+main ()
+{
+ float sNaN = __builtin_nansf ("");
+ double x = (double) sNaN;
+ if (__issignaling (x))
+ __builtin_abort ();
+ return 0;
+}
libgcc/ChangeLog
2014-06-18 Aurelien Jarno
PR target/59833
* config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN.
Index: libgcc/config/arm/ieee754-df.S
===
--- libgcc/config/arm/ieee754-df.S (revision 211428)
+++ libgcc/config/arm/ieee754-df.S (working copy)
@@ -473,11 +473,15 @@
eorne xh, xh, #0x3800 @ fixup exponent otherwise.
RETc(ne)@ and return it.
- teq r2, #0 @ if actually 0
- do_it ne, e
- teqne r3, #0xff00 @ or INF or NAN
+ bicsr2, r2, #0xff00 @ isolate mantissa
+ do_it eq @ if 0, that is ZERO or INF
RETc(eq)@ we are done already.
+ teq r3, #0xff00 @ check for NAN
+ do_it eq, t
+ orreq xh, xh, #0x0008 @ change to quiet NAN
+ RETc(eq)@ and return it.
+
@ value was denormalized. We can normalize it now.
do_push {r4, r5, lr}
mov r4, #0x380 @ setup corresponding exponent
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH, PR61219]: Fix sNaN handling in ARM float to double conversion
Ping. Note that PR61219 is a duplicate of PR59833, so this patch
actually fix PR59833.
On Sun, May 18, 2014 at 11:23:38PM +0200, Aurelien Jarno wrote:
> On ARM soft-float, the float to double conversion doesn't convert a sNaN
> to qNaN as the IEEE Std 754 standard mandates:
>
> "Under default exception handling, any operation signaling an invalid
> operation exception and for which a floating-point result is to be
> delivered shall deliver a quiet NaN."
>
> Given the soft float ARM code ignores exceptions and always provides a
> result, a float to double conversion of a signaling NaN should return a
> quiet NaN. Fix this in extendsfdf2.
>
>
> 2014-05-18 Aurelien Jarno
>
> PR target/61219
> * config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN.
>
>
> Index: libgcc/config/arm/ieee754-df.S
> ===
> --- libgcc/config/arm/ieee754-df.S(revision 210588)
> +++ libgcc/config/arm/ieee754-df.S(working copy)
> @@ -473,11 +473,15 @@
> eorne xh, xh, #0x3800 @ fixup exponent otherwise.
> RETc(ne)@ and return it.
>
> - teq r2, #0 @ if actually 0
> - do_it ne, e
> - teqne r3, #0xff00 @ or INF or NAN
> + bicsr2, r2, #0xff00 @ isolate mantissa
> + do_it eq @ if 0, that is ZERO or INF,
> RETc(eq)@ we are done already.
>
> + teq r3, #0xff00 @ check for NAN
> + do_it eq, t
> + orreq xh, xh, #0x0008 @ change to quiet NAN
> + RETc(eq)@ and return it.
> +
> @ value was denormalized. We can normalize it now.
> do_push {r4, r5, lr}
> mov r4, #0x380 @ setup corresponding exponent
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH, PR61219]: Fix sNaN handling in ARM float to double conversion
On Mon, May 19, 2014 at 02:08:06PM +0800, Joey Ye wrote:
> If f2d need fix, then please fix d2f too as current implementation for
> both behave similarly.
I have done some tests with double to float conversion, and the NaN
behaviour is correct. This is due to specific code handling that in
d2f:
3: @ chech for NAN
mvnsr3, r2, asr #21
bne 5f @ simple overflow
orrsr3, xl, xh, lsl #12
do_it ne, tt
movne r0, #0x7f00
orrne r0, r0, #0x00c0
RETc(ne)@ return NAN
Aurelien
> On Mon, May 19, 2014 at 5:23 AM, Aurelien Jarno wrote:
> > On ARM soft-float, the float to double conversion doesn't convert a sNaN
> > to qNaN as the IEEE Std 754 standard mandates:
> >
> > "Under default exception handling, any operation signaling an invalid
> > operation exception and for which a floating-point result is to be
> > delivered shall deliver a quiet NaN."
> >
> > Given the soft float ARM code ignores exceptions and always provides a
> > result, a float to double conversion of a signaling NaN should return a
> > quiet NaN. Fix this in extendsfdf2.
> >
> >
> > 2014-05-18 Aurelien Jarno
> >
> > PR target/61219
> > * config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN.
> >
> >
> > Index: libgcc/config/arm/ieee754-df.S
> > ===
> > --- libgcc/config/arm/ieee754-df.S (revision 210588)
> > +++ libgcc/config/arm/ieee754-df.S (working copy)
> > @@ -473,11 +473,15 @@
> > eorne xh, xh, #0x3800 @ fixup exponent otherwise.
> > RETc(ne)@ and return it.
> >
> > - teq r2, #0 @ if actually 0
> > - do_it ne, e
> > - teqne r3, #0xff00 @ or INF or NAN
> > + bicsr2, r2, #0xff00 @ isolate mantissa
> > + do_it eq @ if 0, that is ZERO or INF,
> > RETc(eq)@ we are done already.
> >
> > + teq r3, #0xff00 @ check for NAN
> > + do_it eq, t
> > + orreq xh, xh, #0x0008 @ change to quiet NAN
> > + RETc(eq) @ and return it.
> > +
> > @ value was denormalized. We can normalize it now.
> > do_push {r4, r5, lr}
> > mov r4, #0x380 @ setup corresponding exponent
> >
> > --
> > Aurelien Jarno GPG: 4096R/1DDD8C9B
> > aurel...@aurel32.net http://www.aurel32.net
>
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
[PATCH, PR61219]: Fix sNaN handling in ARM float to double conversion
On ARM soft-float, the float to double conversion doesn't convert a sNaN
to qNaN as the IEEE Std 754 standard mandates:
"Under default exception handling, any operation signaling an invalid
operation exception and for which a floating-point result is to be
delivered shall deliver a quiet NaN."
Given the soft float ARM code ignores exceptions and always provides a
result, a float to double conversion of a signaling NaN should return a
quiet NaN. Fix this in extendsfdf2.
2014-05-18 Aurelien Jarno
PR target/61219
* config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN.
Index: libgcc/config/arm/ieee754-df.S
===
--- libgcc/config/arm/ieee754-df.S (revision 210588)
+++ libgcc/config/arm/ieee754-df.S (working copy)
@@ -473,11 +473,15 @@
eorne xh, xh, #0x3800 @ fixup exponent otherwise.
RETc(ne)@ and return it.
- teq r2, #0 @ if actually 0
- do_it ne, e
- teqne r3, #0xff00 @ or INF or NAN
+ bicsr2, r2, #0xff00 @ isolate mantissa
+ do_it eq @ if 0, that is ZERO or INF,
RETc(eq)@ we are done already.
+ teq r3, #0xff00 @ check for NAN
+ do_it eq, t
+ orreq xh, xh, #0x0008 @ change to quiet NAN
+ RETc(eq)@ and return it.
+
@ value was denormalized. We can normalize it now.
do_push {r4, r5, lr}
mov r4, #0x380 @ setup corresponding exponent
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Fix --with-long-double-128 for sparc32 when defaulting to 64-bit
On Wed, Dec 04, 2013 at 08:53:50AM +0100, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 08:49:32AM +0100, Aurelien Jarno wrote:
> > On sparc, the --with-long-double-128 option doesn't change anything for
> > a 64-bit compiler, as it always default to 128-bit long doubles. For
> > a 32/64-bit compiler defaulting to 32-bit this correctly control the
> > size of long double of the 32-bit compiler, however for a 32/64-bit
> > compiler defaulting to 64-bit, the built-in specs force the
> > -mlong-double-64 option. This makes the option useless in this case.
> >
> > The patch below fixes that by removing the -mlong-double-64 from the
> > built-in spec, using the default instead.
>
> So how do you configure 64/32-bit compiler defaulting to 64-bit, where
> 32-bit defaults to -mlong-double-64?
Naively I would have say by *not* passing --with-long-double-128 to
configure like for a 64/32-bit compiler defaulting to 32-bit, but it
stills defaults to 128-bit long doubles with my patch.
Actually it's also the case for a 64/32-bit compiler defaulting to
32-bit, which make the --with-long-double-128 option completely useless
on sparc64. Whatever the option, the result would always be the same
with the current SVN:
64/32-bit compiler defaulting to 32-bit:
- 128-bit long doubles for -m32
- 128-bit long doubles for -m64
64/32-bit compiler defaulting to 64-bit:
- 64-bit long doubles for -m32
- 128-bit long doubles for -m64
I have to digg a bit more to see how to fix that, but even the current
code is not really consistent.
> > Changelog gcc/
> >
> > 2013-12-04 Aurelien Jarno
> >
> > * config/sparc/linux64.h (CC1_SPEC): When defaulting to 64-bit,
> > don't force -mlong-double-64 when -m32 or -mv8plus is given.
> >
> > Index: gcc/config/sparc/linux64.h
> > ===
> > --- gcc/config/sparc/linux64.h (revision 205647)
> > +++ gcc/config/sparc/linux64.h (working copy)
> > @@ -162,9 +162,9 @@
> > #else
> > #define CC1_SPEC "%{profile:-p} \
> > %{m32:%{m64:%emay not use both -m32 and -m64}} \
> > -%{m32:-mptr32 -mno-stack-bias %{!mlong-double-128:-mlong-double-64} \
> > +%{m32:-mptr32 -mno-stack-bias \
> >%{!mcpu*:-mcpu=cypress}} \
> > -%{mv8plus:-mptr32 -mno-stack-bias %{!mlong-double-128:-mlong-double-64} \
> > +%{mv8plus:-mptr32 -mno-stack-bias \
> >%{!mcpu*:-mcpu=v9}} \
> > %{!m32:%{!mcpu*:-mcpu=ultrasparc}} \
> > %{!mno-vis:%{!m32:%{!mcpu=v9:-mvis}}} \
>
> Jakub
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
[PATCH] Fix --with-long-double-128 for sparc32 when defaulting to 64-bit
On sparc, the --with-long-double-128 option doesn't change anything for
a 64-bit compiler, as it always default to 128-bit long doubles. For
a 32/64-bit compiler defaulting to 32-bit this correctly control the
size of long double of the 32-bit compiler, however for a 32/64-bit
compiler defaulting to 64-bit, the built-in specs force the
-mlong-double-64 option. This makes the option useless in this case.
The patch below fixes that by removing the -mlong-double-64 from the
built-in spec, using the default instead.
Changelog gcc/
2013-12-04 Aurelien Jarno
* config/sparc/linux64.h (CC1_SPEC): When defaulting to 64-bit,
don't force -mlong-double-64 when -m32 or -mv8plus is given.
Index: gcc/config/sparc/linux64.h
===
--- gcc/config/sparc/linux64.h (revision 205647)
+++ gcc/config/sparc/linux64.h (working copy)
@@ -162,9 +162,9 @@
#else
#define CC1_SPEC "%{profile:-p} \
%{m32:%{m64:%emay not use both -m32 and -m64}} \
-%{m32:-mptr32 -mno-stack-bias %{!mlong-double-128:-mlong-double-64} \
+%{m32:-mptr32 -mno-stack-bias \
%{!mcpu*:-mcpu=cypress}} \
-%{mv8plus:-mptr32 -mno-stack-bias %{!mlong-double-128:-mlong-double-64} \
+%{mv8plus:-mptr32 -mno-stack-bias \
%{!mcpu*:-mcpu=v9}} \
%{!m32:%{!mcpu*:-mcpu=ultrasparc}} \
%{!mno-vis:%{!m32:%{!mcpu=v9:-mvis}}} \
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [patch] set MULTIARCH_DIRNAME for multilib architectures
On Wed, Nov 27, 2013 at 12:55:54PM +0100, Bernhard Reutner-Fischer wrote: > On 27 November 2013 11:10, Aurelien Jarno wrote: > > On Thu, Jun 20, 2013 at 02:26:12PM +0200, Matthias Klose wrote: > >> Am 13.06.2013 11:42, schrieb Richard Sandiford: > >> > "Bernhard Reutner-Fischer" writes: > >> >> On 12 June 2013 20:20:50 Richard Sandiford > >> >> wrote: > >> >>> Matthias Klose writes: > >> >>>> Index: config/mips/t-linux64 > >> >>>> === > >> >>>> --- config/mips/t-linux64(revision 200012) > >> >>>> +++ config/mips/t-linux64(working copy) > >> >>>> @@ -24,3 +24,13 @@ > >> >>>> ../lib32$(call > >> >>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ > >> >>>> ../lib$(call > >> >>>> if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ > >> >>>> ../lib64$(call > >> >>>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > >> >>>> + > >> >>>> +ifneq (,$(findstring abin32,$(target))) > >> >>>> +MULTIARCH_DIRNAME = $(call > >> >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) > >> >>>> +else > >> >>>> +ifneq (,$(findstring abi64,$(target))) > >> >>>> +MULTIARCH_DIRNAME = $(call > >> >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > >> >>>> +else > >> >>>> +MULTIARCH_DIRNAME = $(call > >> >>> if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) > >> >>>> +endif > >> >>>> +endif > >> >>> > >> >>> findstring seems a bit fragile for a full triple. I think it would > >> >>> be better to have something similar to the current MIPS_SOFT > >> >>> definition: > >> >>> > >> >>> MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, > >> >>> $(target_cpu_default)) $(filter soft, $(with_float))),soft) > >> >>> > >> >>> but for ABIs. It could then also take with_abi into account. > >> >>> Maybe something like: > >> >>> > >> >>> MIPS_ABI = $(or $(with_abi), \ > >> >>> $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > >> >>> $(target_cpu_default)), n32), \ > >> >>> o32) > >> >>> > >> >>> (completely untested). > >> >> > >> >> Bikeshedding: > >> >> Doko would know, but ISTR that $(or) did not exist in make-3.80 which is > >> >> currently the minimum prerequisite, fwiw. > >> > > >> > Gah, that's a pity. Thanks for the catch though. Maybe firstword > >> > would be OK instead. > >> > > >> > I see I also fell into the usual ABI trap. It wouldn't have affected > >> > the use in this patch, but the default ought to be "32" rather than > >> > "o32". > >> > >> the define is in tm_defines, not target_cpu_default. > >> > >> MIPS_ABI = $(or $(with_abi), \ > >> $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > >> $(tm_defines)), n32), \ > >> 32) > >> > >> However I can't see yet how this should be used. Maybe Aurelian could come > >> up > >> with a tested version of this patch? > >> > > > > How about the patch below? > > > > It first determines the ABI without using $(or), by looking (in this > > order) for $(with_abi), $(tm_defines) and $(target), defaulting to 32 > > if none of the previous matches. > > > > Then the multiarch path is constructed from the ABI. > > > > Index: gcc/config/mips/t-linux64 > > ======= > > --- gcc/config/mips/t-linux64 (révision 205437) > > +++ gcc/config/mips/t-linux64 (copie de travail) > > @@ -24,3 +24,22 @@ > > ../lib32$(call > > if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ > > ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ > > ../lib64$(call > > if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > > + > > +ifneq ($(with_abi),) > > +MIPS_ABI = $(with_abi) > > +endif > > +ifeq ($(MIPS_ABI),) > > +MIPS_ABI=$(if $(strip $(filter MIPS_ABI_DEFAULT=ABI_N32, > > $(tm_defines))),n32) > > +endif > > +ifeq ($(MIPS_ABI),) > > +MIPS_ABI = $(subst abi,,$(subst gnu,,$(lastword $(subst -, ,$(target) > > +endif > > +ifeq ($(MIPS_ABI),) > > +MIPS_ABI=32 > > +endif > > + > > +ifeq ($(MIPS_ABI),32) > > +MULTIARCH_DIRNAME = $(call > > if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) > > +else > > +MULTIARCH_DIRNAME = $(call > > if_multiarch,mips64$(MIPS_EL)-linux-gnuabi$(MIPS_ABI)$(MIPS_SOFT)) > > hm, shouldn't this be gnueabi with an 'e' or is that implied for n64 anyway? > just curious.. > thanks, This is correct, the abis are n32 and 64. MIPS EABI is another ABI which hasn't really existed in practice. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [patch] set MULTIARCH_DIRNAME for multilib architectures
On Thu, Jun 20, 2013 at 02:26:12PM +0200, Matthias Klose wrote: > Am 13.06.2013 11:42, schrieb Richard Sandiford: > > "Bernhard Reutner-Fischer" writes: > >> On 12 June 2013 20:20:50 Richard Sandiford > >> wrote: > >>> Matthias Klose writes: > >>>> Index: config/mips/t-linux64 > >>>> === > >>>> --- config/mips/t-linux64(revision 200012) > >>>> +++ config/mips/t-linux64(working copy) > >>>> @@ -24,3 +24,13 @@ > >>>> ../lib32$(call > >>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ > >>>> ../lib$(call > >>>> if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ > >>>> ../lib64$(call > >>>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > >>>> + > >>>> +ifneq (,$(findstring abin32,$(target))) > >>>> +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) > >>>> +else > >>>> +ifneq (,$(findstring abi64,$(target))) > >>>> +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > >>>> +else > >>>> +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) > >>>> +endif > >>>> +endif > >>> > >>> findstring seems a bit fragile for a full triple. I think it would > >>> be better to have something similar to the current MIPS_SOFT definition: > >>> > >>> MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, > >>> $(target_cpu_default)) $(filter soft, $(with_float))),soft) > >>> > >>> but for ABIs. It could then also take with_abi into account. > >>> Maybe something like: > >>> > >>> MIPS_ABI = $(or $(with_abi), \ > >>> $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > >>> $(target_cpu_default)), n32), \ > >>> o32) > >>> > >>> (completely untested). > >> > >> Bikeshedding: > >> Doko would know, but ISTR that $(or) did not exist in make-3.80 which is > >> currently the minimum prerequisite, fwiw. > > > > Gah, that's a pity. Thanks for the catch though. Maybe firstword > > would be OK instead. > > > > I see I also fell into the usual ABI trap. It wouldn't have affected > > the use in this patch, but the default ought to be "32" rather than "o32". > > the define is in tm_defines, not target_cpu_default. > > MIPS_ABI = $(or $(with_abi), \ > $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > $(tm_defines)), n32), \ > 32) > > However I can't see yet how this should be used. Maybe Aurelian could come up > with a tested version of this patch? > How about the patch below? It first determines the ABI without using $(or), by looking (in this order) for $(with_abi), $(tm_defines) and $(target), defaulting to 32 if none of the previous matches. Then the multiarch path is constructed from the ABI. Index: gcc/config/mips/t-linux64 === --- gcc/config/mips/t-linux64 (révision 205437) +++ gcc/config/mips/t-linux64 (copie de travail) @@ -24,3 +24,22 @@ ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) + +ifneq ($(with_abi),) +MIPS_ABI = $(with_abi) +endif +ifeq ($(MIPS_ABI),) +MIPS_ABI=$(if $(strip $(filter MIPS_ABI_DEFAULT=ABI_N32, $(tm_defines))),n32) +endif +ifeq ($(MIPS_ABI),) +MIPS_ABI = $(subst abi,,$(subst gnu,,$(lastword $(subst -, ,$(target) +endif +ifeq ($(MIPS_ABI),) +MIPS_ABI=32 +endif + +ifeq ($(MIPS_ABI),32) +MULTIARCH_DIRNAME = $(call if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) +else +MULTIARCH_DIRNAME = $(call if_multiarch,mips64$(MIPS_EL)-linux-gnuabi$(MIPS_ABI)$(MIPS_SOFT)) +endif -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [patch] set MULTIARCH_DIRNAME for multilib architectures
On Thu, Jun 20, 2013 at 02:26:12PM +0200, Matthias Klose wrote: > Am 13.06.2013 11:42, schrieb Richard Sandiford: > > "Bernhard Reutner-Fischer" writes: > >> On 12 June 2013 20:20:50 Richard Sandiford > >> wrote: > >>> Matthias Klose writes: > >>>> Index: config/mips/t-linux64 > >>>> === > >>>> --- config/mips/t-linux64(revision 200012) > >>>> +++ config/mips/t-linux64(working copy) > >>>> @@ -24,3 +24,13 @@ > >>>> ../lib32$(call > >>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ > >>>> ../lib$(call > >>>> if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ > >>>> ../lib64$(call > >>>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > >>>> + > >>>> +ifneq (,$(findstring abin32,$(target))) > >>>> +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) > >>>> +else > >>>> +ifneq (,$(findstring abi64,$(target))) > >>>> +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > >>>> +else > >>>> +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) > >>>> +endif > >>>> +endif > >>> > >>> findstring seems a bit fragile for a full triple. I think it would > >>> be better to have something similar to the current MIPS_SOFT definition: > >>> > >>> MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, > >>> $(target_cpu_default)) $(filter soft, $(with_float))),soft) > >>> > >>> but for ABIs. It could then also take with_abi into account. > >>> Maybe something like: > >>> > >>> MIPS_ABI = $(or $(with_abi), \ > >>> $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > >>> $(target_cpu_default)), n32), \ > >>> o32) > >>> > >>> (completely untested). > >> > >> Bikeshedding: > >> Doko would know, but ISTR that $(or) did not exist in make-3.80 which is > >> currently the minimum prerequisite, fwiw. > > > > Gah, that's a pity. Thanks for the catch though. Maybe firstword > > would be OK instead. > > > > I see I also fell into the usual ABI trap. It wouldn't have affected > > the use in this patch, but the default ought to be "32" rather than "o32". > > the define is in tm_defines, not target_cpu_default. > > MIPS_ABI = $(or $(with_abi), \ > $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > $(tm_defines)), n32), \ > 32) > > However I can't see yet how this should be used. Maybe Aurelian could come up > with a tested version of this patch? > I don't have a lot of time right now, will look at that in details next week. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[PATCH] Fix MIPS tri-arch build
Hi all,
Since patch [1] has been applied, that is in GCC 4.7, it's not possible
to build a tri-arch GCC (o32, n32, 64), using mips-linux-gnu as the host
triplet (that is defaulting to o32). In that case mips/t-tpbit is not
included anymore, and while the build succeeds, the resulting
libgcc_s.so.1 has the following functions as undefined:
1697: 0004d940 0 FUNCGLOBAL DEFAULT UND __trunctfsf2
1698: 0004d930 0 FUNCGLOBAL DEFAULT UND __subtf3
1699: 0004d920 0 FUNCGLOBAL DEFAULT UND __floatsitf
1704: 0004d900 0 FUNCGLOBAL DEFAULT UND __fixunstfsi
1716: 0004d8f0 0 FUNCGLOBAL DEFAULT UND __lttf2
1722: 0004d8d0 0 FUNCGLOBAL DEFAULT UND __trunctfdf2
1728: 0004d880 0 FUNCGLOBAL DEFAULT UND __divtf3
1731: 0004d860 0 FUNCGLOBAL DEFAULT UND __addtf3
1737: 0004d830 0 FUNCGLOBAL DEFAULT UND __netf2
1746: 0004d800 0 FUNCGLOBAL DEFAULT UND __floatunsitf
1747: 0004d7f0 0 FUNCGLOBAL DEFAULT UND __eqtf2
1751: 0004d7d0 0 FUNCGLOBAL DEFAULT UND __multf3
The patch below fixes that by including mips/t-tpbit when long double is
16 bytes long, instead of detecting that using the host triplet.
Aurelien
[1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00927.html
2012-04-28 Aurelien Jarno
* config.host (mips64*-*-linux*, mipsisa64*-*-linux*): Remove.
(mips*-*-linux*): Include mips/t-tpbit when long double is
16 bytes long.
Index: libgcc/config.host
===
--- libgcc/config.host (révision 186921)
+++ libgcc/config.host (copie de travail)
@@ -728,15 +728,13 @@
;;
mips*-*-netbsd*) # NetBSD/mips, either endian.
;;
-mips64*-*-linux* | mipsisa64*-*-linux*)
- extra_parts="$extra_parts crtfastmath.o"
- tmake_file="${tmake_file} t-crtfm mips/t-mips16 mips/t-tpbit"
- md_unwind_header=mips/linux-unwind.h
- ;;
mips*-*-linux*)# Linux MIPS, either endian.
extra_parts="$extra_parts crtfastmath.o"
tmake_file="${tmake_file} t-crtfm mips/t-mips16"
md_unwind_header=mips/linux-unwind.h
+ if test "${ac_cv_sizeof_long_double}" = 16; then
+ tmake_file="${tmake_file} mips/t-tpbit"
+ fi
;;
mips*-sde-elf*)
tmake_file="$tmake_file mips/t-crtstuff mips/t-mips16"
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
