Ubuntu
ghostscript package

Compiler gets stuck (or extremely slow) on ppc64el

Bug #1862053 reported by Till Kamppeter
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gcc
Fix Released
Medium
gcc-9 (Ubuntu)
Fix Released
Undecided
Unassigned
ghostscript (Ubuntu)
Fix Released
High
Unassigned

Bug Description

I have uploaded Ghostscript 9.50 to focal and it built without any problem on all architectures but ppc64el. On ppc64el the compiler seems to get stuck (or extremely slow) on one of the files of Ghostscript (devices/vector/gdevpdfb.c, I tried twice). This leads to the build process being killed after 150 minutes.

See

https://launchpad.net/ubuntu/+source/ghostscript/9.50~dfsg-5/+build/18661407

and

https://launchpadlibrarian.net/463662514/buildlog_ubuntu-focal-ppc64el.ghostscript_9.50~dfsg-5_BUILDING.txt.gz

Till Kamppeter (till-kamppeter)
Changed in gcc (Ubuntu):
importance: Undecided → High
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

As of doko's request I am attaching the pre-processed source file devices/vector/gdevpdfb.c to this bug report, generated by the original gcc command line (from the Makefile output) with "-save-temp" added on a ppc64el server, coming out as gdevpdfb.i in the root directory of the source tree.

Command line:

gcc -save-temps -DHAVE_MKSTEMP -DHAVE_FILE64 -DHAVE_FSEEKO -DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_BSWAP32 -DHAVE_BYTESWAP_H -DHAVE_STRERROR -DHAVE_ISNAN -DHAVE_ISINF -DHAVE_PREAD_PWRITE=1 -DGS_RECURSIVE_MUTEXATTR=PTHREAD_MUTEX_RECURSIVE -fPIC -O2 -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -D__USE_UNIX98=1 -g -O3 -fdebug-prefix-map=/home/ubuntu/ubuntu/ghostscript/ghostscript-9.50~dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -DHAVE_RESTRICT=1 -DUSE_LIBPAPER -I/usr/include/powerpc64le-linux-gnu -fno-strict-aliasing -DHAVE_POPEN_PROTO=1 -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/lib/ghostscript/9.50\" -I./soobj -I./base -I./soobj -I./devices -I./devices/vector -o ./soobj/gdevpdfb.o -c ./devices/vector/gdevpdfb.c

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Also the manual initiation of the ghostscript package build ("dpkg-buildpackage -rfakeroot") on the ppc64el server hung at the same point (devices/vector/gdevpdfb.c) and the command line for conserving the pre-processed file also, but the hang seems after the pre-processing, as the *.i file looks complete for me.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

I have now investigated further, by trying to compile the pre-processed *.i source file. This naturally does not need any -D... and -I... command line arguments.

So I started with this command line:

gcc -c gdevpdfb.i

which did well. Then I added from the full command line each bunch of arguments which are not -D... or -I...:

gcc -fPIC -O2 -fPIC -Wdate-time -c gdevpdfb.i

gcc -fPIC -O2 -Wdate-time -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -c gdevpdfb.i

gcc -fPIC -O2 -Wdate-time -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -g -O3 -fdebug-prefix-map=`pwd`=. -fstack-protector-strong -Wformat -Werror=format-security -c gdevpdfb.i

and at the last of these it hung again, So I tried to remove arguments and saw -O3 as a good candidate, and, yes, removing it made gcc finish. Seems that -O3 is the culprit!

So let us try the complete command line but without -O3:

gcc -fPIC -O2 -Wdate-time -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -g -fdebug-prefix-map=`pwd`=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -o gdevpdfb.o -c gdevpdfb.i

This also completes.

And back into the ghostscript source tree to do the whole thing:

gcc -save-temps -DHAVE_MKSTEMP -DHAVE_FILE64 -DHAVE_FSEEKO -DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_BSWAP32 -DHAVE_BYTESWAP_H -DHAVE_STRERROR -DHAVE_ISNAN -DHAVE_ISINF -DHAVE_PREAD_PWRITE=1 -DGS_RECURSIVE_MUTEXATTR=PTHREAD_MUTEX_RECURSIVE -fPIC -O2 -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -D__USE_UNIX98=1 -g -fdebug-prefix-map=/home/ubuntu/ubuntu/ghostscript/ghostscript-9.50~dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -DHAVE_RESTRICT=1 -DUSE_LIBPAPER -I/usr/include/powerpc64le-linux-gnu -fno-strict-aliasing -DHAVE_POPEN_PROTO=1 -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/lib/ghostscript/9.50\" -I./soobj -I./base -I./soobj -I./devices -I./devices/vector -o ./soobj/gdevpdfb.o -c ./devices/vector/gdevpdfb.c

but without -O3, this also works.

So the workaround is not using -O3 on ppc64el, but the bug is still there. gcc needs to get fixed.

Changed in gcc (Ubuntu):
status: New → Confirmed
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

The whole ghostscript builds when stripping off "-O3" from the CFLAGS defaults:

export DEB_CFLAGS_STRIP="-O3"
dpkg-buildpackage -rfakeroot

Till Kamppeter (till-kamppeter)
Changed in ghostscript (Ubuntu):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Found that Ubuntu's Ghostscript had already an exception rule for not using -O3 on ppc64el which got lost with the sync. Re-introducing it and reporting to Debian ...

Changed in ghostscript (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Debian is not using the exception rule for not using -O3 on ppc64el in their Ghostscript package, simply due to the fact that the whole Debian is done with -O2 by default, on all architectures.

Are there also problems with -O3 on ppc64el with other packages than Ghostscript? Should we perhaps use -O2 as general default for ppc64el?

Revision history for this message
In , Matthias Klose (doko) wrote :
Download full text (3.5 KiB)

Created attachment 47813
preprocessed source

seen with gcc-9 and trunk 20200204, building ghostscript and icu with -O3 on powerpc64le-linux-gnu. Falling back to -O2 lets the build succeed, a -O3 build on x86_64-linux-gnu succeeds.

Program received signal SIGTSTP, Stopped (user).
push_to_sequence (first=0x7ffff320d580) at ../../src/gcc/emit-rtl.c:5574
5574 ../../src/gcc/emit-rtl.c: No such file or directory.
(gdb) bt
#0 push_to_sequence (first=0x7ffff320d580) at ../../src/gcc/emit-rtl.c:5574
#1 0x0000000010843000 in process_address_1 (nop=nop@entry=0,
    check_only_p=check_only_p@entry=false, before=before@entry=0x7fffffffdbf0,
    after=after@entry=0x7fffffffdbe8) at ../../src/gcc/lra-constraints.c:3434
#2 0x000000001084527c in process_address (after=<optimized out>, before=<optimized out>,
    check_only_p=<optimized out>, nop=<optimized out>) at ../../src/gcc/lra-constraints.c:3637
#3 curr_insn_transform (check_only_p=check_only_p@entry=false)
    at ../../src/gcc/lra-constraints.c:3952
#4 0x000000001084ad10 in lra_constraints (first_p=<optimized out>)
    at ../../src/gcc/lra-constraints.c:5025
#5 0x0000000010833940 in lra (f=<optimized out>) at ../../src/gcc/lra.c:2437
#6 0x00000000107d893c in do_reload () at ../../src/gcc/ira.c:5518
#7 (anonymous namespace)::pass_reload::execute (this=<optimized out>) at ../../src/gcc/ira.c:5704
#8 0x0000000010928280 in execute_one_pass (pass=pass@entry=0x11d106f0)
    at ../../src/gcc/passes.c:2500
#9 0x0000000010929314 in execute_pass_list_1 (pass=0x11d106f0) at ../../src/gcc/passes.c:2588
#10 0x000000001092932c in execute_pass_list_1 (pass=0x11d0f4f0) at ../../src/gcc/passes.c:2589
#11 0x00000000109293b8 in execute_pass_list (fn=<optimized out>, pass=<optimized out>)
    at ../../src/gcc/passes.c:2599
#12 0x00000000104f4a2c in cgraph_node::expand (this=0x7ffff6ee7d28) at ../../src/gcc/context.h:48
#13 0x00000000104f600c in expand_all_functions () at ../../src/gcc/cgraphunit.c:2454
#14 symbol_table::compile (this=this@entry=0x7ffff52f0000) at ../../src/gcc/cgraphunit.c:2804
#15 0x00000000104f8c54 in symbol_table::compile (this=0x7ffff52f0000)
    at ../../src/gcc/cgraphunit.c:2984
#16 symbol_table::finalize_compilation_unit (this=0x7ffff52f0000)
    at ../../src/gcc/cgraphunit.c:2984
#17 0x0000000010a321bc in compile_file () at ../../src/gcc/toplev.c:483
#18 0x0000000010187c8c in do_compile () at ../../src/gcc/toplev.c:2273
#19 toplev::main (this=0x7fffffffe6a0, argc=<optimized out>, argv=<optimized out>)
    at ../../src/gcc/toplev.c:2412
#20 0x0000000010189e78 in main (argc=<optimized out>, argv=0x7fffffffeac8)
    at ../../src/gcc/main.c:39

GCC defaults to hardening options and is configured using
--enable-languages=c,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=powerpc64le-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --enable-default-pie --with-system-zl...

Read more...

Revision history for this message
In , Matthias Klose (doko) wrote :

memory usage stays constant at about 2GB, the package build gets cancelled after 150 minutes.

Revision history for this message
In , Seurer-v (seurer-v) wrote :

How are you configuring ghostscript when you build it? I get a link error involving png:
./obj/pngrutil.o: In function `png_read_filter_row':
pngrutil.c:(.text+0x8948): undefined reference to `png_init_filter_functions_vsx'

Bug Watch Updater (bug-watch-updater)
Changed in gcc:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

I cannot recreate this with trunk or GCC 9 from today. DO you have extra patches applied or ???

Revision history for this message
In , Matthias Klose (doko) wrote :

the file from icu 65.1 is built using

g++ -v -Wdate-time -g -O3 -fstack-protector-strong -Wformat -Werror=format-security -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -c -o genmbcs.o genmbcs.ii

no specific patches applied for the trunk. The compiler defaults to PIE, and the usual hardening defaults:

/usr/lib/gcc/powerpc64le-linux-gnu/10/cc1plus -fpreprocessed genmbcs.ii -msecure-plt -quiet -dumpbase genmbcs.ii -mcpu=power8 -auxbase-strip genmbcs.o -g -O3 -Wdate-time -Wformat=1 -Werror=format-security -Wextra -Wall -Wpedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -version -fstack-protector-strong -fasynchronous-unwind-tables -fstack-protector-strong -Wformat-security -fstack-clash-protection

Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

Confirmed. With the options in Comment 4, I'm able to recreate the hang/infinite loop. I'll have a look.

Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

So we are in an infinite loop in process_address() calling process_address_1(). I've hacked in some code to ICE if we loop for too long and I'm currently using creduce to minimize the test case.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ghostscript - 9.50~dfsg-5ubuntu1

---------------
ghostscript (9.50~dfsg-5ubuntu1) focal; urgency=medium

  * Re-introduced exception rule for building with only -O2 instead
    of -O3 on ppc64el (see also LP: #1862053).

 -- Till Kamppeter <email address hidden> Fri, 7 Feb 2020 19:09:58 +0100

Changed in ghostscript (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

Here's the minimal test case using options -O3 -mcpu=power8 -fstack-protector-strong:

void bar();
char b;
void
foo (void)
{
  char a;
  int d = b;
  char *e = &a;
  while (d)
    *e++ = --d;
  bar ();
}

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

On the #c7 testcase, this started with r8-6072-ga3a821c903c9fa2288712d31da2038d0297babcb (so I wonder why this isn't a 8/9/10 Regression).

Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

(In reply to Jakub Jelinek from comment #8)
> On the #c7 testcase, this started with
> r8-6072-ga3a821c903c9fa2288712d31da2038d0297babcb (so I wonder why this
> isn't a 8/9/10 Regression).

I'm not sure Kelvin's patch is to blame. I think it's just exposing a latent issue.

Bug Watch Updater (bug-watch-updater)
Changed in gcc:
status: New → Confirmed
Revision history for this message
Matthias Klose (doko) wrote :

this is only *worked around* in ghostscript, not fixed.

Changed in ghostscript (Ubuntu):
status: Fix Released → Confirmed
no longer affects: gcc (Ubuntu)
Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

Ok, after debugging, this looks to be a bug in rs6000_legitimate_address_p().
At the beginning of LRA, we have the following insn:

(insn 520 67 71 5 (set (mem:V16QI (and:DI (reg/f:DI 110 sfp)
                (const_int -16 [0xfffffffffffffff0])) [0 MEM <vector(16) char> [(char *)&a + 16B]+0 S16 A128])
        (reg:V16QI 303 [ vect__2.13 ])) "bug.i":10:10 1103 {vsx_movv16qi_64bit}
     (expr_list:REG_DEAD (reg:V16QI 303 [ vect__2.13 ])
        (nil)))

lra_eliminate() then converts that to:

(insn 520 67 71 5 (set (mem:V16QI (and:DI (plus:DI (reg/f:DI 110 sfp)
                    (const_int 112 [0x70]))
                (const_int -16 [0xfffffffffffffff0])) [0 MEM <vector(16) char> [(char *)&a + 16B]+0 S16 A128])
        (reg:V16QI 303 [ vect__2.13 ])) "bug.i":10:10 1103 {vsx_movv16qi_64bit}
     (expr_list:REG_DEAD (reg:V16QI 303 [ vect__2.13 ])
        (nil)))

which isn't valid and needs fixing...which is fine. process_address() then gives us:

(insn 520 67 71 5 (set (mem:V16QI (and:DI (reg:DI 633)
                (const_int -16 [0xfffffffffffffff0])) [0 MEM <vector(16) char> [(char *)&a + 16B]+0 S16 A128])
        (reg:V16QI 303 [ vect__2.13 ])) "bug.i":10:10 1103 {vsx_movv16qi_64bit}
     (expr_list:REG_DEAD (reg:V16QI 303 [ vect__2.13 ])
        (nil)))

...with pseudo 633 being set to plus:DI (reg/f:DI 110 sfp) (const_int 112 [0x70])
which is also good. The bug comes when we now pass insn 520 to rs6000_legitimate_address_p() and we hit the following code:

  /* If this is an unaligned stvx/ldvx type address, discard the outer AND. */
  if (VECTOR_MEM_ALTIVEC_P (mode)
      && GET_CODE (x) == AND
      && CONST_INT_P (XEXP (x, 1))
      && INTVAL (XEXP (x, 1)) == -16)
    x = XEXP (x, 0);

Our mode is V16QI, so we should execute this code, but we don't. The problem is that VECTOR_MEM_ALTIVEC_P(mode) checks for "rs6000_vector_unit[(MODE)] == VECTOR_ALTIVEC" and V16QI mode returns VECTOR_VSX, so we fail to fall into the code above and end up telling LRA this isn't a valid address. LRA then attempts to spill this again and again and...

The following patch fixes the bug for me and I'm regtesting it now:

--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -8808,7 +8808,7 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x, bool reg_ok_strict)
   bool quad_offset_p = mode_supports_dq_form (mode);

   /* If this is an unaligned stvx/ldvx type address, discard the outer AND. */
- if (VECTOR_MEM_ALTIVEC_P (mode)
+ if (VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)
       && GET_CODE (x) == AND
       && CONST_INT_P (XEXP (x, 1))
       && INTVAL (XEXP (x, 1)) == -16)

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

The master branch has been updated by Peter Bergner <email address hidden>:

https://gcc.gnu.org/g:b82d426662469ee8b78ec7e8f74abe950485c9d5

commit r10-6760-gb82d426662469ee8b78ec7e8f74abe950485c9d5
Author: Peter Bergner <email address hidden>
Date: Thu Feb 20 11:08:02 2020 -0600

    rs6000: Fix infinite loop building ghostscript and icu [PR93658]

    Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec
    address as being invalid, which causes LRA's process_address() to go into
    an infinite loop spilling the same address over and over again.

    gcc/
     PR target/93658
     * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
     vector modes.

    gcc/testsuite/
     PR target/93658
     * gcc.target/powerpc/pr93658.c: New test.

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

The master branch has been updated by Peter Bergner <email address hidden>:

https://gcc.gnu.org/g:e6f24f824beb8ba6805702e287bbd6153b472488

commit r10-6762-ge6f24f824beb8ba6805702e287bbd6153b472488
Author: Peter Bergner <email address hidden>
Date: Thu Feb 20 11:25:12 2020 -0600

    rs6000: Fix infinite loop building ghostscript and icu [PR93658]

    Previous push didn't get the ChangeLog entries or the actual fix.
    Push those now.

    gcc/
     PR target/93658
     * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
     vector modes.

    gcc/testsuite/
     PR target/93658
     * gcc.target/powerpc/pr93658.c: New test.

Bug Watch Updater (bug-watch-updater)
Changed in gcc:
status: Confirmed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-9 - 9.2.1-29ubuntu1

---------------
gcc-9 (9.2.1-29ubuntu1) focal; urgency=medium

  * Merge with Debian; remaining changes:
    - Build from upstream sources.
    - Disable the LTO build on arm64, armhf for now, takes 24+ hours ...

gcc-9 (9.2.1-29) unstable; urgency=medium

  * Update to git 20200220 from the gcc-9 branch.
    - Fix PR middle-end/92768, PR middle-end/90313, PR tree-optimization/93434,
      PR tree-optimization/92710, PR tree-optimization/92420, PR target/90724,
      PR target/93724 (x86), PR target/93743 (x86), PR tree-optimization/93744,
      PR target/93704 (SPARC), PR rtl-optimization/88879, PR middle-end/90648,
      PR tree-optimization/93381, PR tree-optimization/93439,
      PR middle-end/93054, PR debug/92763, PR tree-optimization/92704,
      PR middle-end/92674, PR target/93696 (x86), PR target/93670 (x86),
      PR target/93637 (x86), PR target/65782 (x86), PR libgomp/93515,
      PR libgomp/93515, PR middle-end/93555, PR middle-end/93505,
      PR target/93418 (x86), PR rtl-optimization/93402, PR target/85667,
      PR rtl-optimization/91838, PR c/93576, PR c++/61414, PR c++/93557,
      PR c++/91118, PR fortran/93580, PR fortran/93463, PR libgcc/85334,
      PR fortran/93714.
  * Fix PR target/93658 (PPC), proposed patch. LP: #1862053.

 -- Matthias Klose <email address hidden> Thu, 20 Feb 2020 10:20:02 +0100

Changed in gcc-9 (Ubuntu):
status: New → Fix Released
Revision history for this message
Matthias Klose (doko) wrote :

reverted the work-around in ghostscript

Changed in ghostscript (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

Simple backports to GCC 8 and 9 exposed some bugs that have already been fixed on trunk. The following patch resubmission includes those extra fixes that need backports too:

    https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01253.html

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

The releases/gcc-9 branch has been updated by Peter Bergner <email address hidden>:

https://gcc.gnu.org/g:066184a282b622ac6880150eb4e42fe57881b606

commit r9-8269-g066184a282b622ac6880150eb4e42fe57881b606
Author: Peter Bergner <email address hidden>
Date: Sun Feb 23 18:22:57 2020 -0600

    rs6000: Fix infinite loop building ghostscript and icu [PR93658]

    Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec
    address as being invalid, which causes LRA's process_address() to go into
    an infinite loop spilling the same address over and over again.
    Include Mike's earlier commits that fix bugs this patch exposes.

     Backport from master
     2020-02-20 Peter Bergner <email address hidden>

     PR target/93658
     * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
     vector modes.

     * gcc.target/powerpc/pr93658.c: New test.

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

The releases/gcc-8 branch has been updated by Peter Bergner <email address hidden>:

https://gcc.gnu.org/g:53efbfe030a5fda41e5e7856d76ea827dd09f49c

commit r8-10050-g53efbfe030a5fda41e5e7856d76ea827dd09f49c
Author: Peter Bergner <email address hidden>
Date: Sun Feb 23 22:04:44 2020 -0600

    rs6000: Fix infinite loop building ghostscript and icu [PR93658]

    Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec
    address as being invalid, which causes LRA's process_address() to go into
    an infinite loop spilling the same address over and over again.
    Include Mike's earlier commits that fix bugs this patch exposes.

     Backport from master
     2020-02-20 Peter Bergner <email address hidden>

     PR target/93658
     * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
     vector modes.

     * gcc.target/powerpc/pr93658.c: New test.
     * gcc.target/powerpc/vsx-vector-6-le.c: Update fragile insn count.

Revision history for this message
In , Bergner-gcc (bergner-gcc) wrote :

Fixed everywhere.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Caused PR93974.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

The fixes have been reverted for 9.3/8.4.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

GCC 9.3.0 has been released, adjusting target milestone.

Bug Watch Updater (bug-watch-updater)
Changed in gcc:
status: In Progress → Confirmed
Revision history for this message
In , Rguenth (rguenth) wrote :

GCC 9.4 is being released, retargeting bugs to GCC 9.5.

Revision history for this message
In , Rguenth (rguenth) wrote :

Fixed for GCC 10.

Bug Watch Updater (bug-watch-updater)
Changed in gcc:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.