Hello,

this is the variant intended for the 4.8/4.9 branches of the patch:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00994.html

As discussed, it does *not* actually change ABI, but only warn when
encountering a situation where the ABI will change in a future GCC.
(Avoiding the specific term "GCC 4.10" here since I'm not certain
whether the next GCC release will in fact be called that ...)

Tested on powerpc64-linux and powerpc64le-linux; also verified using
the ABI compat suite (against an unpatched GCC) that this patch does
not change the ABI.

OK for 4.8/4.9 once the mainline patch is in?

Bye,
Ulrich


gcc/ChangeLog:

        * config/rs6000/rs6000.c (rs6000_function_arg): If a float argument
        does not fit fully into floating-point registers, and there is still
        space in the register parameter area, issue -Wpsabi note that the ABI
        will change in a future GCC release.

gcc/testsuite/ChangeLog:

        * gcc.target/powerpc/ppc64-abi-warn-1.c: New test.


Index: gcc-4_9-branch/gcc/config/rs6000/rs6000.c
===================================================================
--- gcc-4_9-branch.orig/gcc/config/rs6000/rs6000.c
+++ gcc-4_9-branch/gcc/config/rs6000/rs6000.c
@@ -10225,6 +10225,7 @@ rs6000_function_arg (cumulative_args_t c
          rtx r, off;
          int i, k = 0;
          unsigned long n_fpreg = (GET_MODE_SIZE (elt_mode) + 7) >> 3;
+         int fpr_words;
 
          /* Do we also need to pass this argument in the parameter
             save area?  */
@@ -10253,6 +10254,37 @@ rs6000_function_arg (cumulative_args_t c
              rvec[k++] = gen_rtx_EXPR_LIST (VOIDmode, r, off);
            }
 
+         /* If there were not enough FPRs to hold the argument, the rest
+            usually goes into memory.  However, if the current position
+            is still within the register parameter area, a portion may
+            actually have to go into GPRs.
+
+            Note that it may happen that the portion of the argument
+            passed in the first "half" of the first GPR was already
+            passed in the last FPR as well.
+
+            For unnamed arguments, we already set up GPRs to cover the
+            whole argument in rs6000_psave_function_arg, so there is
+            nothing further to do at this point.
+
+            GCC 4.8/4.9 Note: This was implemented incorrectly in earlier
+            GCC releases.  To avoid any ABI change on the release branch,
+            we retain that original implementation here, but warn if we
+            encounter a case where the ABI will change in the future.  */
+         fpr_words = (i * GET_MODE_SIZE (elt_mode)) / (TARGET_32BIT ? 4 : 8);
+         if (i < n_elts && align_words + fpr_words < GP_ARG_NUM_REG
+             && cum->nargs_prototype > 0)
+            {
+             static bool warned;
+             if (!warned && warn_psabi)
+               {
+                 warned = true;
+                 inform (input_location,
+                         "the ABI of passing homogeneous float aggregates"
+                         " will change in a future GCC release");
+               }
+           }
+
          return rs6000_finish_function_arg (mode, rvec, k);
        }
       else if (align_words < GP_ARG_NUM_REG)
Index: gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/ppc64-abi-warn-1.c
===================================================================
--- /dev/null
+++ gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/ppc64-abi-warn-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { powerpc*-*-linux* && lp64 } } } */
+/* { dg-options "-mabi=elfv2" } */
+
+struct f8
+  {
+    float x[8];
+  };
+
+void test (struct f8 a, struct f8 b) /* { dg-message "note: the ABI of passing 
homogeneous float aggregates will change" } */
+{
+}
+
-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Reply via email to