Bug 91289 - powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
Summary: powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 9.1.0
: P3 normal
Target Milestone: ---
Assignee: Segher Boessenkool
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-29 16:18 UTC by Philipp Spilger
Modified: 2019-11-05 17:28 UTC (History)
2 users (show)

See Also:
Host:
Target: powerpc*-*-*
Build:
Known to work: 4.8.5
Known to fail: 5.1.0, 7.4.0, 8.3.0, 9.2.0
Last reconfirmed: 2019-09-07 00:00:00


Attachments
Preprocessed source triggering the error (75 bytes, text/plain)
2019-07-29 16:18 UTC, Philipp Spilger
Details
Proposed patch (453 bytes, patch)
2019-09-07 14:55 UTC, Segher Boessenkool
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Spilger 2019-07-29 16:18:17 UTC
Created attachment 46640 [details]
Preprocessed source triggering the error

Compilation of
```
int test() { return 0; }
```
with `powerpc-eabi-gcc-9.1.0 -Wall -Wextra -ffreestanding -fstack-limit-symbol=symbol_name -c test.c`

leads to the internal compiler error:

```
test.c: In function 'test':
test.c:3:1: error: insn does not satisfy its constraints:
    3 | }
      | ^
(insn 17 16 18 (set (reg:SI 0 0)
        (lo_sum:SI (reg:SI 0 0)
            (const (plus:SI (symbol_ref:SI ("symbol_name"))
                    (const_int 16 [0x10]))))) "test.c":1:12 700 {elf_low}
     (nil))
during RTL pass: final
test.c:3:1: internal compiler error: in final_scan_insn_1, at final.c:3013
0x5a8c18 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
	../../gcc/gcc/rtl-error.c:108
0x5a8c3e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
	../../gcc/gcc/rtl-error.c:118
0x59c796 final_scan_insn_1
	../../gcc/gcc/final.c:3013
0x7cefc8 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
	../../gcc/gcc/final.c:3153
0x7cf28c final_1
	../../gcc/gcc/final.c:2021
0x7cfcc4 rest_of_handle_final
	../../gcc/gcc/final.c:4659
0x7cfcc4 execute
	../../gcc/gcc/final.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
```

The gcc-9.1.0 is built with the following options: (gcc --verbose)
```
Using built-in specs.
COLLECT_GCC=powerpc-eabi-gcc-9.1.0
COLLECT_LTO_WRAPPER=/fasthome/pspilger/gcc/install/libexec/gcc/powerpc-eabi/9.1.0/lto-wrapper
Target: powerpc-eabi
Configured with: ../gcc/configure --prefix=/fasthome/pspilger/gcc/install --target=powerpc-eabi --enable-languages=c,c++ --disable-shared --enable-lto --with-float=soft --without-headers --disable-threads --disable-decimal-float --disable-multilib --disable-nls --disable-libstdcxx --disable-libgomp --disable-libvtv --disable-libatomic --disable-libmpx --disable-libquadmath --disable-libssp
Thread model: single
gcc version 9.1.0 (GCC) 
```

The problem also occurs with gcc-8.1.0, but does not occur with gcc-4.9.4.
Comment 1 Eric Müller 2019-07-31 11:24:37 UTC
We did a quick search for changes to the "elf_low" insn which is mentioned in 
the error message and found commit 55a56a6f323e876a0368f268f2bf85a5739c7498
("PR target/64180", 2014-12-10 by segher).
 
After reverting this commit (based on "gcc-9_1_0-release") we do not encounter
the problem anymore; the generated assembly looks okay.
Comment 2 Philipp Spilger 2019-07-31 11:35:44 UTC
Only reverting the "elf_low" insn changes of this commit leads to no encounter of the problem, i.e. the following diff "resolves" the problem on gcc-9_1_0-release.

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index ad80592765d0..f797008eac9b 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -10138,11 +10138,13 @@
   "lis %0,%1@ha")
 
 (define_insn "elf_low"
-  [(set (match_operand:SI 0 "gpc_reg_operand" "=r")
-	(lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b")
+  [(set (match_operand:SI 0 "gpc_reg_operand" "=r,r")
+	(lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b,!*r")
 		   (match_operand 2 "" "")))]
    "TARGET_ELF && !TARGET_64BIT && !flag_pic"
-   "la %0,%2@l(%1)")
+   "@
+    la %0,%2@l(%1)
+    addic %0,%1,%K2")
 
 (define_insn "*pltseq_tocsave_<mode>"
   [(set (match_operand:P 0 "memory_operand" "=m")
Comment 3 Segher Boessenkool 2019-09-07 12:35:01 UTC
Confirmed.  Any target.  Needs -O0 -m32 -fstack-limit-symbol=symbol_name .
Comment 4 Segher Boessenkool 2019-09-07 12:41:11 UTC
(I don't have working GCC 5 and GCC 6 compilers handy, but based on comment 1,
I've marked those versions as failing as well).
Comment 5 Segher Boessenkool 2019-09-07 13:33:55 UTC
(BTW, using addic here is wrong: addic clobbers CA, which may not be free).
Comment 6 Segher Boessenkool 2019-09-07 14:55:26 UTC
Created attachment 46853 [details]
Proposed patch

Could you try this patch?
Comment 7 Alan Modra 2019-09-10 14:23:07 UTC
I doubt the patch will work in all cases.  r11 might be in use.

BTW, trashing CA in the prologue won't matter since XER is volatile over function calls.  So addic could be used.  (I know, just not in elf_low so there would be a bit of messing around to use addsi3_carry.)
Comment 8 Alan Modra 2019-09-10 14:30:39 UTC
Ah, no addsi3_carry won't work.  You'll need a special version of elf_low that trashes CA.
Comment 9 Segher Boessenkool 2019-09-10 14:55:18 UTC
My patch do not clobber r11, that's the point of it :-)
Comment 10 Segher Boessenkool 2019-09-10 14:59:51 UTC
The prologue is not necessarily inserted as the first bb, so it's not clear
to me that CA is never live there.

The code copying r11 to r0, and back, is removed by the usual optimisations
btw, in all normal cases.
Comment 11 Philipp Spilger 2019-09-10 16:30:08 UTC
(In reply to Segher Boessenkool from comment #6)
> Created attachment 46853 [details]
> Proposed patch
> 
> Could you try this patch?

The proposed patch works back-ported to 8.1 (residing in rs6000.c then) during compile-time (i.e. nothing breaks) and functionally for an example use case. Will try on vanilla 9.1.
Comment 12 Segher Boessenkool 2019-09-10 17:00:10 UTC
Thanks for testing!
Comment 13 Alan Modra 2019-09-10 23:52:19 UTC
(In reply to Segher Boessenkool from comment #9)
> My patch do not clobber r11, that's the point of it :-)

Eh, I shouldn't look at patches late at night.  Even simple ones.
Comment 14 Segher Boessenkool 2019-10-26 16:39:31 UTC
Author: segher
Date: Sat Oct 26 16:38:59 2019
New Revision: 277472

URL: https://gcc.gnu.org/viewcvs?rev=277472&root=gcc&view=rev
Log:
rs6000: Fix allocate_stack in a corner case (PR91289)

When we have -fstack-limit-symbol with sysv we can end up with a non-
existing instruction (you cannot add an immediate to register 0).  Fix
this by using register 11 instead.  It might be used for something else
already though, so save and restore its value around this.  In
optimizing compiles these extra moves are usually removed again: the
restore by cprop_hardreg, and then the save by rtl_dce.


	PR target/91289
	* config/rs6000/rs6000-logue.c (rs6000_emit_allocate_stack): Don't add
	an immediate to r0; use r11 instead.  Save and restore r11 to r0 around
	this.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000-logue.c
Comment 15 Segher Boessenkool 2019-10-26 16:43:35 UTC
Fixed on trunk (so far).
Comment 16 Segher Boessenkool 2019-11-05 17:17:38 UTC
Author: segher
Date: Tue Nov  5 17:17:03 2019
New Revision: 277855

URL: https://gcc.gnu.org/viewcvs?rev=277855&root=gcc&view=rev
Log:
backport for PR91289

	Backport from trunk
	2019-10-26  Segher Boessenkool  <segher@kernel.crashing.org>

	PR target/91289
	* config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Don't add an
	immediate to r0; use r11 instead.  Save and restore r11 to r0 around
	this.

Modified:
    branches/gcc-9-branch/gcc/ChangeLog
    branches/gcc-9-branch/gcc/config/rs6000/rs6000.c
Comment 17 Segher Boessenkool 2019-11-05 17:20:31 UTC
Author: segher
Date: Tue Nov  5 17:20:00 2019
New Revision: 277856

URL: https://gcc.gnu.org/viewcvs?rev=277856&root=gcc&view=rev
Log:
backport for PR91289

	Backport from trunk
	2019-10-26  Segher Boessenkool  <segher@kernel.crashing.org>

	PR target/91289
	* config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Don't add an
	immediate to r0; use r11 instead.  Save and restore r11 to r0 around
	this.

Modified:
    branches/gcc-8-branch/gcc/ChangeLog
    branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
Comment 18 Segher Boessenkool 2019-11-05 17:28:58 UTC
Fixed on trunk, 9, 8.  Closing.