[Bug target/71571] New: [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571
Bug ID: 71571
Summary: [CRIS] Multiple inheritance non-virtual PIC thunk
causes crash
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at davidrobins dot net
Target Milestone: ---
Created attachment 38719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38719&action=edit
Add nop for ba (branch) delay slot in PIC multiple inheritance thunk
The jump to the primary function in the generated non-virtual thunk for the
CRIS platform is missing the delay slot instruction (an instruction following
the jump that is executed before it) in PIC mode, so it runs the following
instruction in the text segment instead. (This following instruction is
frequently the next function's preamble, usually a sub from $sp, which causes a
crash in a subsequent return or other stack lookup.)
We initially saw this problem on a vendor-provided (Axis) GCC 4.3.1, but it
repros on current SVN (r237536 when I checked it out). Details of GCC build:
gcc version 7.0.0 20160616 (experimental) (GCC)
Host: x86_64-unknown-linux-gnu
Target: crisv32-axis-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/opt/cross
--target=crisv32-axis-linux-gnu --enable-languages=c,c++ --disable-multilib
The build command-line is: /opt/cross/bin/crisv32-axis-linux-gnu-g++ -fPIC
-save-temps -o test main.cpp (substitute main.ii)
I am attaching:
* a repro program, main.ii; after reduction it (probably) doesn't crash but
the thunk with branch ("ba") without a delay-slot instruction can be seen in
the assembly,
* a slightly larger repro, crash.ii, that reliably crashes (due to an
$sp-modifying instruction following the branch); this requires additional g++
options -O2 -fno-inline (the -O2 to eliminate a dword stored in memory after
the ba instruction, and -fno-inline to prevent the thunk from being an inline
copy of the function it would jump to)
* a patch to fix the problem.
Runs of "make check-gcc-c++ RUNTESTFLAGS=--target_board=cris-sim" with/without
the fix do not differ in passes/failures. I would like to add a test for this
issue but am unsure as to the correct way of doing so; crash.ii could be used
in an execute test, or is checking the output assembly better, or something
else?
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #1 from David B. Robins --- Created attachment 38720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38720&action=edit Small repro - emits branch (ba) without delay-slot instruction
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #2 from David B. Robins --- Created attachment 38721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38721&action=edit Larger repro - crashes reliably - requires additional -O2 -fno-inline
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 David B. Robins changed: What|Removed |Added Target||crisv32-axis-linux-gnu Host||x86_64-unknown-linux-gnu Known to fail||4.3.1, 7.0 Build||x86_64-unknown-linux-gnu Severity|normal |major
[Bug target/80433] New: [CRIS] ICE at -O2: unrecognized insn (post_inc on acr) building glibc sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80433 Bug ID: 80433 Summary: [CRIS] ICE at -O2: unrecognized insn (post_inc on acr) building glibc sha512.c Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc at davidrobins dot net Target Milestone: --- Created attachment 41202 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41202&action=edit Preprocessed sha512.c from glibc. Compiling attached preprocessed glibc (2.9) sha512.c as: crisv32-linux-gnu-gcc sha512.i -S -O2 -o sha512.S results in: sha512.c: In function _sha512_process_block_: sha512.c:206:1: error: unrecognizable insn: } ^ (insn 652 650 648 9 (set (reg:DI 10 r10) (mem:DI (post_inc:SI (reg:SI 15 acr)) [1 MEM[base: _195, offset: 0B]+0 S8 A8])) "sha512.c":165 -1 (expr_list:REG_INC (reg:SI 15 acr) (nil))) sha512.c:206:1: internal compiler error: in extract_insn, at recog.c:2311 0xa7ffd8 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-svn/gcc/rtl-error.c:108 0xa80009 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-svn/gcc/rtl-error.c:116 0xa4a861 extract_insn(rtx_insn*) ../../gcc-svn/gcc/recog.c:2311 0xa4a8d1 extract_insn_cached(rtx_insn*) ../../gcc-svn/gcc/recog.c:2201 0x7d4fd7 cleanup_subreg_operands(rtx_insn*) ../../gcc-svn/gcc/final.c:3152 0xa744ce reload(rtx_insn*, int) ../../gcc-svn/gcc/reload1.c:1235 0x92211d do_reload ../../gcc-svn/gcc/ira.c:5469 0x92211d execute ../../gcc-svn/gcc/ira.c:5641 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. No error at lower optimization levels. I have also attached the .271r.ira and .272r.reload pass output files. Output of crisv32-linux-gnu-gcc -v: Using built-in specs. COLLECT_GCC=crisv32-linux-gnu-gcc COLLECT_LTO_WRAPPER=/opt/cross/cris/6.3/libexec/gcc/crisv32-linux-gnu/7.0.1/lto-wrapper Target: crisv32-linux-gnu Configured with: ../gcc-svn/configure --prefix=/opt/cross/cris/6.3 --without-headers --target=crisv32-linux-gnu --enable-languages=c,c++ --disable-multilib : (reconfigured) ../gcc-svn/configure --prefix=/opt/cross/cris/6.3 --target=crisv32-linux-gnu --enable-languages=c,c++ --disable-multilib : (repeat same a few more times) Thread model: posix gcc version 7.0.1 20170411 (experimental) (GCC)
[Bug target/80433] [CRIS] ICE at -O2: unrecognized insn (post_inc on acr) building glibc sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80433 --- Comment #1 from David B. Robins --- Created attachment 41203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41203&action=edit Pass register context for post_inc reload; allow GENNONACR_REGS as preferred. I am attaching a potential fix in hopes it will help; I would be surprised if I've uncovered a new issue in the reload code, but the change to pass the register class for the code rather than the outer matches a few other cases and fits the issue I'm seeing with the crisv32 ACR register being selected for a post_inc insn that isn't supposed to use it. (Not attaching aforementioned pass output files due to size, and because they can easily be reproduced by attached source and above command.)
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #6 from David B. Robins --- Created attachment 38734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38734&action=edit Test case (for gcc/testsuite/g++.dg/inherit)
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #7 from David B. Robins --- I have verified that the pr71571.C test case attached does expose the bug on trunk and that it passes with the above fix. (Note "-O2 -fno-inline" are required to ensure a crash; see earlier comment; in 4.3.1 "-O2" sufficed, either because it did not inline these thunks or used different criteria.)
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #10 from David B. Robins --- My apologies, I saw the example you pointed at was from torture/ but missed/forgot that you had also wanted the new test there. I moved the file to torture and removed -O2 -fno-inline and I didn't get the failure. I did get it when I added back only -fno-inline, which at least no longer depends on a specific optimization level: FAIL: g++.dg/torture/pr71571.C -O2 execution test FAIL: g++.dg/torture/pr71571.C -O3 -g execution test FAIL: g++.dg/torture/pr71571.C -Os execution test FAIL: g++.dg/torture/pr71571.C -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: g++.dg/torture/pr71571.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test I also confirmed that it passed in the new location with the "fix to be committed" fix.
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #12 from David B. Robins --- Note that it does still need -fno-inline. I know why it doesn't crash with -O0: there is a text-section constant inserted after the thunk, and it's inlined at higher optimization levels. The instruction said constant maps to is either harmless or forbidden as a delay slot instruction. So the underlying issue still occurs but the crash doesn't. At higher optimization levels the function is also inlined in the thunk (that didn't happen on 4.3.1). This also seems somewhat fragile - the crash is dependent on what's next in the generated code - which is why I wasn't sure about what sort of test to add. I am OK with my name/email being included in the ChangeLog, thank you.
