public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/meissner/heads/work032)] PowerPC: PR 97791: Fix an issue with gnu attributes.
@ 2021-01-14 2:44 Michael Meissner
0 siblings, 0 replies; only message in thread
From: Michael Meissner @ 2021-01-14 2:44 UTC (permalink / raw)
To: gcc-cvs
https://gcc.gnu.org/g:c6b99987eaad4579aeec76a04e50fc283b5b1e01
commit c6b99987eaad4579aeec76a04e50fc283b5b1e01
Author: Michael Meissner <meissner@linux.ibm.com>
Date: Wed Jan 13 21:43:37 2021 -0500
PowerPC: PR 97791: Fix an issue with gnu attributes.
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. This is the bug being fixed
in this patch.
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.
gcc/
2021-01-13 Michael Meissner <meissner@linux.ibm.com>
Alan Modra <amodra@gmail.com>
PR gcc/97791
* config/rs6000/rs6000-call.c (init_cumulative_args): Only set
that long double was returned if the type is actually long
double.
(rs6000_function_arg_advance_1): Only set that long double was
passed if the type is actually long double.
Diff:
---
gcc/config/rs6000/rs6000-call.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2308cc8b4a2..519313bc0d6 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -6554,12 +6554,14 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, tree fntype,
if (SCALAR_FLOAT_MODE_P (return_mode))
{
rs6000_passes_float = true;
+
+ /* If GNU attributes are enabled, mark if the function returns
+ long double. We do not mark if the function returns a type
+ such as __ibm128 that uses the same modes as the current long
+ double type, only if an actual long double type was used. */
if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (return_mode)
- || FLOAT128_IEEE_P (return_mode)
- || (return_type != NULL
- && (TYPE_MAIN_VARIANT (return_type)
- == long_double_type_node))))
+ && return_type != NULL
+ && TYPE_MAIN_VARIANT (return_type) == long_double_type_node)
rs6000_passes_long_double = true;
/* Note if we passed or return a IEEE 128-bit type. We changed
@@ -6994,11 +6996,14 @@ rs6000_function_arg_advance_1 (CUMULATIVE_ARGS *cum, machine_mode mode,
if (SCALAR_FLOAT_MODE_P (mode))
{
rs6000_passes_float = true;
+
+ /* If GNU attributes are enabled, mark if the function passes long
+ double. We do not mark if the function returns a type such as
+ __ibm128 that uses the same modes as the current long double type,
+ only if an actual long double type was used. */
if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (mode)
- || FLOAT128_IEEE_P (mode)
- || (type != NULL
- && TYPE_MAIN_VARIANT (type) == long_double_type_node)))
+ && type != NULL
+ && TYPE_MAIN_VARIANT (type) == long_double_type_node)
rs6000_passes_long_double = true;
/* Note if we passed or return a IEEE 128-bit type. We changed the
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-01-14 2:44 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:44 [gcc(refs/users/meissner/heads/work032)] PowerPC: PR 97791: Fix an issue with gnu attributes 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).