public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/meissner/heads/work032)] PowerPC: PR 97791: Do not gnu attributes on moves
@ 2021-01-14 2:45 Michael Meissner
0 siblings, 0 replies; only message in thread
From: Michael Meissner @ 2021-01-14 2:45 UTC (permalink / raw)
To: gcc-cvs
https://gcc.gnu.org/g:84ae44abc7a79b9c2e6d9f18a30516d3e8f65b1f
commit 84ae44abc7a79b9c2e6d9f18a30516d3e8f65b1f
Author: Michael Meissner <meissner@linux.ibm.com>
Date: Wed Jan 13 21:45:20 2021 -0500
PowerPC: PR 97791: Do not gnu attributes on moves
There are many issues with the current implementation of GNU attributes to mark
functions that use long double. The idea of .gnu_attributes was to mark
objects with ABI requirements.
This patch fixes a small subset of the GNU attributes problems. It does not
fix all of the problems.
The current problems with GNU attributes are:
1) Probably the most annoying bug is that they apply at an object level.
So for example libgcc_s.so.1 is marked as using IBM long double causing
warnings when linking against code that uses 64-bit long doubles even
though such code won't use any of the libgcc 128-bit long double
functions.
a) Versions of ld prior to 2.35 did not check shared library
.gnu_attributes, a bug that might allow a user to link a
soft-float shared library with hard-float code.
2) The original implementation Alan Modra wrote in 2016 to mark relocatable
object files with attributes had, and still has, bugs.
a) It is possible for an object to be marked as using IBM long
double when a function has a long double parameter that is not
used.
b) It is possible for an object to not be marked as using IBM long
double when it does. For example, a function with a pointer to
long double parameter is not recognized as using long double.
This is conceptually difficult to fix. Does merely passing a
pointer to another function constitute a use? What about a
pointer to a union containing a long double?
c) An object that defines a global long double variables is not
marked.
d) Variable argument functions that process a long double in an
argument corresponding to the ellipsis are not marked.
3) One of the problems with GNU attributes is that it would signal a long
double was used when in reality an alternate type was returned or passed,
such as passing __ibm128 or __float128 that just happens to use the same
representation as the current long double type.
4) In an attempt to fix some of these problems, Mike Meissner applied a patch
to rs6000_emit_move that set the long double attribute whenever a move to or
from a register involved a long double mode, but that has bugs too.
a) With -mlong-double-64 an object that moves doubles to or from a
register would by marked as using 64-bit long double.
b) Functions that only use long double internally would wrongly
cause their object to be marked with the long double attribute.
c) 2c is not fixed by this patch, unless code in the object uses
the global variable.
This patch eliminates the code in rs6000_emit_move to set the long double
attribute. This eliminates the false positives that occur when a type uses a
mode that is the same mode as the long double type. However, to catch the
cases where long double is used without being passed or returned, we would need
to implement a GIMPLE pass that looked for explicit long double usage.
This patch also changes the the 3 tests that tested this move support to be
'XFAIL' until we flag long double usage correctly.
gcc/
2021-01-13 Michael Meissner <meissner@linux.ibm.com>
PR gcc/97791
* config/rs6000/rs6000.c (rs6000_emit_move): Delete code that sets
whether long double was passed based on the modes used in moves.
gcc/testsuite/
2021-01-13 Michael Meissner <meissner@linux.ibm.com>
PR target/97791
* gcc.target/powerpc/gnuattr1.c: Mark as XFAIL.
* gcc.target/powerpc/gnuattr2.c: Mark as XFAIL.
* gcc.target/powerpc/gnuattr3.c: Mark as XFAIL.
Diff:
---
gcc/config/rs6000/rs6000.c | 17 -----------------
gcc/testsuite/gcc.target/powerpc/gnuattr1.c | 9 +++++++--
gcc/testsuite/gcc.target/powerpc/gnuattr2.c | 9 +++++++--
gcc/testsuite/gcc.target/powerpc/gnuattr3.c | 9 +++++++--
4 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 47a56912e27..6f48dd6566d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -10077,23 +10077,6 @@ rs6000_emit_move (rtx dest, rtx source, machine_mode mode)
&& GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT)
gcc_unreachable ();
-#ifdef HAVE_AS_GNU_ATTRIBUTE
- /* If we use a long double type, set the flags in .gnu_attribute that say
- what the long double type is. This is to allow the linker's warning
- message for the wrong long double to be useful, even if the function does
- not do a call (for example, doing a 128-bit add on power9 if the long
- double type is IEEE 128-bit. Do not set this if __ibm128 or __floa128 are
- used if they aren't the default long dobule type. */
- if (rs6000_gnu_attr && (HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT))
- {
- if (TARGET_LONG_DOUBLE_128 && (mode == TFmode || mode == TCmode))
- rs6000_passes_float = rs6000_passes_long_double = true;
-
- else if (!TARGET_LONG_DOUBLE_128 && (mode == DFmode || mode == DCmode))
- rs6000_passes_float = rs6000_passes_long_double = true;
- }
-#endif
-
/* See if we need to special case SImode/SFmode SUBREG moves. */
if ((mode == SImode || mode == SFmode) && SUBREG_P (source)
&& rs6000_emit_move_si_sf_subreg (dest, source, mode))
diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c b/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
index cf46777849a..9c7680aabae 100644
--- a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
+++ b/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
@@ -1,11 +1,16 @@
/* { dg-do compile { target { powerpc*-linux-* } } } */
/* { dg-require-effective-target powerpc_vsx_ok } */
/* { dg-options "-O2 -mvsx -mlong-double-64" } */
-/* { dg-final { scan-assembler "gnu_attribute 4, 9" } } */
+/* { dg-final { scan-assembler "gnu_attribute 4, 9" {xfail *-*-*} } } */
/* Check that if we can do the long double operation without doing an emulator
call, such as with 64-bit long double support, that we still set the
- appropriate .gnu_attribute. */
+ appropriate .gnu_attribute.
+
+ However, the code that did this in rs6000_emit_move has been removed because
+ it could not differentiate between long double and another type that uses
+ the same mode. This test is marked as xfail until a gimple pass is added to
+ track the use of long double types. */
long double a;
diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr2.c b/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
index 32a4ba255a8..4ca60d63261 100644
--- a/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
+++ b/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
@@ -1,13 +1,18 @@
/* { dg-do compile { target { powerpc*-linux-* && lp64 } } } */
/* { dg-require-effective-target powerpc_p9vector_ok } */
/* { dg-options "-O2 -mpower9-vector -mabi=ieeelongdouble -Wno-psabi" } */
-/* { dg-final { scan-assembler "gnu_attribute 4, 13" } } */
+/* { dg-final { scan-assembler "gnu_attribute 4, 13" {xfail *-*-*} } } */
/* Check that if we can do the long double operation without doing an emulator
call, such as with IEEE 128-bit hardware support on power9, that we still
set the appropriate .gnu_attribute. The && lp64 is needed, because we can't
enable the IEEE 128-bit hardware instructions on ISA 3.0 (power9) in 32-bit,
- because we don't have a TImode available. */
+ because we don't have a TImode available.
+
+ However, the code that did this in rs6000_emit_move has been removed because
+ it could not differentiate between long double and another type that uses
+ the same mode. This test is marked as xfail until a gimple pass is added to
+ track the use of long double types. */
long double a;
diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr3.c b/gcc/testsuite/gcc.target/powerpc/gnuattr3.c
index bd5a64fe330..7eb3ebc3c43 100644
--- a/gcc/testsuite/gcc.target/powerpc/gnuattr3.c
+++ b/gcc/testsuite/gcc.target/powerpc/gnuattr3.c
@@ -1,11 +1,16 @@
/* { dg-do compile { target { powerpc*-linux-* } } } */
/* { dg-require-effective-target powerpc_vsx_ok } */
/* { dg-options "-O2 -mvsx -mabi=ibmlongdouble -Wno-psabi" } */
-/* { dg-final { scan-assembler "gnu_attribute 4, 5" } } */
+/* { dg-final { scan-assembler "gnu_attribute 4, 5" {xfail *-*-*} } } */
/* Check that if we can do the long double operation without doing an emulator
call, such as with copysign, that we still set the appropriate
- .gnu_attribute. */
+ .gnu_attribute.
+
+ However, the code that did this in rs6000_emit_move has been removed because
+ it could not differentiate between long double and another type that uses
+ the same mode. This test is marked as xfail until a gimple pass is added to
+ track the use of long double types. */
long double a, b, c;
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-01-14 2:45 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-14 2:45 [gcc(refs/users/meissner/heads/work032)] PowerPC: PR 97791: Do not gnu attributes on moves Michael Meissner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).