[gcc(refs/users/meissner/heads/work032)] PowerPC: PR 97791: Fix an issue with gnu attributes.

[gcc(refs/users/meissner/heads/work032)] PowerPC: PR 97791: Fix an issue with gnu attributes.

[Michael Meissner]

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