diff mbox

patch to fix PR61325

Message ID 5387708E.5020005@redhat.com
State New
Headers show

Commit Message

Vladimir Makarov May 29, 2014, 5:38 p.m. UTC
The following patch PR61325.  The details can be found on

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325

  The patch was bootstrapped and tested on x86/x86-64.

  Committed as rev. 211060 to gcc-4.9 branch and as rev.211061 to trunk.

2014-05-29  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-optimization/61325
        * lra-constraints.c (process_address): Rename to
        process_address_1.
        (process_address): New function.

2014-05-29  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-optimization/61325
        * gcc.target/aarch64/pr61325.c: New.

Comments

James Greenhalgh June 3, 2014, 10:02 p.m. UTC | #1
On Thu, May 29, 2014 at 06:38:22PM +0100, Vladimir Makarov wrote:
>   The following patch PR61325.  The details can be found on
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325
> 
>   The patch was bootstrapped and tested on x86/x86-64.
> 
>   Committed as rev. 211060 to gcc-4.9 branch and as rev.211061 to trunk.
> 
> 2014-05-29  Vladimir Makarov  <vmakarov@redhat.com>
> 
>         PR rtl-optimization/61325
>         * lra-constraints.c (process_address): Rename to
>         process_address_1.
>         (process_address): New function.
> 
> 2014-05-29  Vladimir Makarov  <vmakarov@redhat.com>
> 
>         PR rtl-optimization/61325
>         * gcc.target/aarch64/pr61325.c: New.

Hi Vlad,

This patch appears to cause issues where the ARM backend can get stuck in a
seemingly infinite loop.

Compiling:

./gcc.c-torture/compile/unalign-1.c

Directly With cc1 using command line:

cc1 gcc-clean/gcc/testsuite/gcc.c-torture/compile/unalign-1.c -O3 -mcpu=cortex-a15 -mthumb -mfloat-abi=hard -mfpu=neon-vfpv4

Triggers the issue reproducibly for me across a few ARM configurations.

Reverting this patch fixes the problem.

Interrupting and asking gdb for a backtrace gives this:

#1  0x005597cc in resize_reg_info() () at /home/jamgre01//gcc-clean/gcc/reginfo.c:912
#2  0x004b436c in get_reg_class(int) () at /home/jamgre01//gcc-clean/gcc/lra-int.h:400
#3  0x004b541c in in_class_p(rtx_def*, reg_class, reg_class*) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:265
#4  0x004b6314 in process_addr_reg(rtx_def**, rtx_def**, rtx_def**, reg_class) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:1176
#5  0x004b6aa0 in process_address_1(int, rtx_def**, rtx_def**) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:2829
#6  0x004bb150 in curr_insn_transform() () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:3001
#7  0x004bd884 in lra_constraints(bool) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:4230
#8  0x004aca04 in lra(_IO_FILE*) () at /home/jamgre01//gcc-clean/gcc/lra.c:2333

For completeness, here is the -v output for one recent toolchain I've built.

Using built-in specs.
COLLECT_GCC=build/clean/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/jamgre01/build/clean/install/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: /home/jamgre01//gcc-clean/configure --with-cpu=cortex-a15.cortex-a7 --with-fpu=neon-vfpv4 --with-float=hard --prefix=/home/jamgre01/build//clean//install --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.10.0 20140603 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-v' '-mcpu=cortex-a15.cortex-a7' '-mfloat-abi=hard' '-mfpu=neon-vfpv4' '-mtls-dialect=gnu'
 /home/jamgre01/build/clean/install/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/cc1 -quiet -v -imultilib . -imultiarch arm-linux-gnueabihf -iprefix /home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/ gcc-clean/gcc/testsuite/gcc.c-torture/compile/unalign-1.c -quiet -dumpbase unalign-1.c -mcpu=cortex-a15.cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -mtls-dialect=gnu -auxbase unalign-1 -O3 -version -o /tmp/ccZj6iwS.s
GNU C (GCC) version 4.10.0 20140603 (experimental) (armv7l-unknown-linux-gnueabihf)
	compiled by GNU C version 4.10.0 20140603 (experimental), GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/../../../../armv7l-unknown-linux-gnueabihf/include"
ignoring duplicate directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/../../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include"
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring duplicate directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/../../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include-fixed"
ignoring nonexistent directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/../../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/../../../../armv7l-unknown-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include
 /home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include-fixed
 /usr/local/include
 /home/jamgre01/build/clean/install/bin/../lib/gcc/../../include
 /usr/include/arm-linux-gnueabihf
 /usr/include
End of search list.
GNU C (GCC) version 4.10.0 20140603 (experimental) (armv7l-unknown-linux-gnueabihf)
	compiled by GNU C version 4.10.0 20140603 (experimental), GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Thanks,
James
Christophe Lyon June 4, 2014, 1:13 p.m. UTC | #2
On 4 June 2014 00:02, James Greenhalgh <james.greenhalgh@arm.com> wrote:
> On Thu, May 29, 2014 at 06:38:22PM +0100, Vladimir Makarov wrote:
>>   The following patch PR61325.  The details can be found on
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325
>>
>>   The patch was bootstrapped and tested on x86/x86-64.
>>
>>   Committed as rev. 211060 to gcc-4.9 branch and as rev.211061 to trunk.
>>
>> 2014-05-29  Vladimir Makarov  <vmakarov@redhat.com>
>>
>>         PR rtl-optimization/61325
>>         * lra-constraints.c (process_address): Rename to
>>         process_address_1.
>>         (process_address): New function.
>>
>> 2014-05-29  Vladimir Makarov  <vmakarov@redhat.com>
>>
>>         PR rtl-optimization/61325
>>         * gcc.target/aarch64/pr61325.c: New.
>
> Hi Vlad,
>
> This patch appears to cause issues where the ARM backend can get stuck in a
> seemingly infinite loop.
>
> Compiling:
>
> ./gcc.c-torture/compile/unalign-1.c
>
> Directly With cc1 using command line:
>
> cc1 gcc-clean/gcc/testsuite/gcc.c-torture/compile/unalign-1.c -O3 -mcpu=cortex-a15 -mthumb -mfloat-abi=hard -mfpu=neon-vfpv4
>
> Triggers the issue reproducibly for me across a few ARM configurations.
>

Hello,

On my side, I can see a huge increase in memory use (up to at least
350GB in make check) by GCC since this commit.
(and the Compute Farm admins have started to kill my jobs because they
consume too much memory ;-)

I can see this on several ARM and AArch64 configurations, but not on
armeb, aarch64-bare and arm* when restricting to armv5t.

Christophe.
diff mbox

Patch

Index: lra-constraints.c
===================================================================
--- lra-constraints.c	(revision 210973)
+++ lra-constraints.c	(working copy)
@@ -2784,9 +2784,14 @@ 
 
    Add reloads to the lists *BEFORE and *AFTER.  We might need to add
    reloads to *AFTER because of inc/dec, {pre, post} modify in the
-   address.  Return true for any RTL change.  */
+   address.  Return true for any RTL change.
+
+   The function is a helper function which does not produce all
+   transformations which can be necessary.  It does just basic steps.
+   To do all necessary transformations use function
+   process_address.  */
 static bool
-process_address (int nop, rtx *before, rtx *after)
+process_address_1 (int nop, rtx *before, rtx *after)
 {
   struct address_info ad;
   rtx new_reg;
@@ -2986,6 +2991,18 @@ 
   return true;
 }
 
+/* Do address reloads until it is necessary.  Use process_address_1 as
+   a helper function.  Return true for any RTL changes.  */
+static bool
+process_address (int nop, rtx *before, rtx *after)
+{
+  bool res = false;
+
+  while (process_address_1 (nop, before, after))
+    res = true;
+  return res;
+}
+
 /* Emit insns to reload VALUE into a new register.  VALUE is an
    auto-increment or auto-decrement RTX whose operand is a register or
    memory location; so reloading involves incrementing that location.
@@ -3270,7 +3287,7 @@ 
 	change_p = true;
 	lra_update_dup (curr_id, i);
       }
-
+  
   if (change_p)
     /* If we've changed the instruction then any alternative that
        we chose previously may no longer be valid.  */
Index: testsuite/gcc.target/aarch64/pr61325.c
===================================================================
--- testsuite/gcc.target/aarch64/pr61325.c	(revision 0)
+++ testsuite/gcc.target/aarch64/pr61325.c	(working copy)
@@ -0,0 +1,19 @@ 
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+typedef unsigned int wchar_t;
+typedef long unsigned int size_t;
+
+size_t
+wcstombs(char *s , const wchar_t *pwcs , size_t n)
+{
+  int count = 0;
+  
+  if (n != 0) {
+    do {
+      if ((*s++ = (char) *pwcs++) == 0)
+        break;
+      count++;
+    } while (--n != 0);
+  }
+  return count;
+}