hppa: Fix REG+D address support before reload

When generating PA 1.x code or code for GNU ld, floating-point
accesses only support 5-bit displacements but integer accesses
support 14-bit displacements.  I mistakenly assumed reload
could fix an invalid 14-bit displacement in a floating-point
access but this is not the case.

2024-03-14  John David Anglin  <danglin@gcc.gnu.org>

gcc/ChangeLog:

	PR target/114288
	* config/pa/pa.cc (pa_legitimate_address_p): Don't allow
	14-bit displacements before reload for modes that may use
	a floating-point load or store.

diff --git a/gcc/config/pa/pa.cc b/gcc/config/pa/pa.cc
index 694123e37c9dd47f35ceaa6e92370b82f63130f7..129289f8e624f065fdcadbbc482b9d1680257060 100644 (file)
--- a/gcc/config/pa/pa.cc
+++ b/gcc/config/pa/pa.cc
@@ -10968,20 +10968,15 @@ pa_legitimate_address_p (machine_mode mode, rtx x, bool strict, code_helper)
 
          /* Long 14-bit displacements always okay for these cases.  */
          if (INT14_OK_STRICT
+             || reload_completed
              || mode == QImode
              || mode == HImode)
            return true;
 
-         /* A secondary reload may be needed to adjust the displacement
-            of floating-point accesses when STRICT is nonzero.  */
-         if (strict)
-           return false;
-
-         /* We get significantly better code if we allow long displacements
-            before reload for all accesses.  Instructions must satisfy their
-            constraints after reload, so we must have an integer access.
-            Return true for both cases.  */
-         return true;
+         /* We have to limit displacements to those supported by
+            both floating-point and integer accesses as reload can't
+            fix invalid displacements.  See PR114288.  */
+         return false;
        }
 
       if (!TARGET_DISABLE_INDEXING