[Bug target/91702] [9/10 Regression] ICE with mips16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91702 --- Comment #5 from Dragan Mladjenovic --- Yes, I believe so.
[Bug rtl-optimization/92989] New: The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 Bug ID: 92989 Summary: The mips-mti-linux-gnu fails to build after r276327 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: build, ice-checking Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dragan.mladjeno...@rt-rk.com CC: richard.sandiford at arm dot com Target Milestone: --- Target: mips-mti-linux-gnu Created attachment 47520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47520&action=edit Prepossessed reproducer Failure happens during mips16 multilib libstdc++ build. It can be reproduced in a quick way via mipsisa64-elf on current trunk(r279523): ~./gcc/xgcc -B./gcc -std=gnu++98 -fno-implicit-templates -O2 -mips16 -x c++ locale.i -fPIC -mabi=32 -mabicalls -mexplicit-relocs -mno-gpopt -c -o locale.o during RTL pass: reload /media/draganm/NewDisk/workarea_back/src/gcc/libstdc++-v3/src/c++98/locale.cc: In member function ‘void std::locale::_Impl::_M_install_cache(const std::locale::facet*, std::size_t)’: /media/draganm/NewDisk/workarea_back/src/gcc/libstdc++-v3/src/c++98/locale.cc:471:3: internal compiler error: in lra_assign, at lra-assigns.c:1646 471 | } | ^ 0xccc370 lra_assign(bool&) ../../src/gcc/gcc/lra-assigns.c:1646 0xcc6574 lra(_IO_FILE*) ../../src/gcc/gcc/lra.c:2487 0xc78069 do_reload ../../src/gcc/gcc/ira.c:5518 0xc78069 execute ../../src/gcc/gcc/ira.c:5704 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.
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 --- Comment #2 from Dragan Mladjenovic --- Thanks, I've checked https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01209.html, but there are still similar build failures down the line. I have to double-check it and will post any findings later.
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 --- Comment #3 from Dragan Mladjenovic --- Created attachment 47703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47703&action=edit Reproducer for additional failure Toolchain build seems to still contain this failure that can be reproduced with: $ mipsisa64-elf-gcc -std=gnu++11 -O2 -c -x c++ cxx11-locale-inst.i -minterlink-mips16 -mips16 -mips32r2 -mabi=32 -o cxx11-locale-inst.o
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 --- Comment #6 from Dragan Mladjenovic --- Created attachment 47955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47955&action=edit Reproducer for additional failure2 It seems that one file still fails to compile on today's trunk (b07e4e7). Attached the reproducer. Can be reproduced with mipsisa64-elf-gcc same as the last one.
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 Dragan Mladjenovic changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Dragan Mladjenovic --- Reopening. See the previous comment.
[Bug rtl-optimization/88403] New: [Mips,AArch64] The gcse prevents if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88403 Bug ID: 88403 Summary: [Mips,AArch64] The gcse prevents if-conversion Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dragan.mladjeno...@rt-rk.com Target Milestone: --- Created attachment 45183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45183&action=edit mark.c If I compile the marck.c with aarch64-linux-gnu-gcc -O3 or mipsel-linux-gnu-gcc -mips32r6 -mbranch-cost=5 the inner if does not get transformed to use conditional moves. mips32r6 example: li $13,5000# 0x1388 $L4: ... subu$3,$2,$3 bgec$13,$3,$L3 addiu $2,$2,5000 sra $4,$2,31 <-- inserted by gcse $L3: muh $2,$2,$9 sra $2,$2,12 subu$2,$4,$2 ... The if-conversion fails because it refuses to speculate both instructions whose set regs are alive. If I use -fno-gcse or -ftree-loop-if-convert the problem disappears. Is there something that can be done here w/o resolving to ftree-loop-if-convert ? Tried: mipsel-linux-gnu-gcc --version mipsel-linux-gnu-gcc-7 (Debian 7.3.0-28) 7.3.0 xgcc --version xgcc (GCC) 9.0.0 20181203 (experimental)
[Bug middle-end/91233] New: Cannot build glibc for mips*r6 since r270955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91233
Bug ID: 91233
Summary: Cannot build glibc for mips*r6 since r270955
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dragan.mladjeno...@rt-rk.com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: mips
We cannot use lo and hi register in clobber list for inline syscalls [1] since
r270955 for r6 targets. They don't have hi and lo registers available (at least
w/o dsp extension for time being).
~ cat test.c
void test () { __asm__ __volatile__("":::"lo"); }
~ ./gcc/xgcc -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=./gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: mipsisa64-elf
Configured with: ../src/gcc/configure --target=mipsisa64-elf
--enable-languages=c
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190710 (experimental) (GCC)
~ ./gcc/xgcc -Bgcc -mips64r6 -mexplicit-relocs test.c -S -o /dev/null
test.c: In function ‘test’:
test.c:1:16: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the
current target
1 | void test () { __asm__ __volatile__("":::"lo"); }
|^~~
This will also affect other projects that provide a similar form of syscall
wrappers via inline assembly.
Is a reasonable compromise here to error out only if architecturally
unavailable "calle-saved" registers are found in the clobber list?
This should cover this use case and still prevent the backend for erroneously
trying to spill/restore unavailable register if that was the intention of the
original patch.
[1]
https://github.com/bminor/glibc/blob/7628a1b05adb1e4c6857b87c6f8b71a1d0b1d72c/sysdeps/unix/sysv/linux/mips/mips32/sysdep.h#L351
[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474 --- Comment #3 from Dragan Mladjenovic --- You can try manualy rerunning the faulting command after libtool: compile: ... with -save-temps.
[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769
--- Comment #4 from Dragan Mladjenovic ---
Hi,
This fix is propbably nothing more than:
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -4862,7 +4862,7 @@ mips_split_move (rtx dest, rtx src, enum mips_split_type
split_type, rtx insn_)
{
rtx tmp = XEXP (src, 0);
mips_classify_address (&addr, tmp, GET_MODE (tmp), true);
- if (addr.reg && REGNO (addr.reg) != REGNO (dest))
+ if (addr.reg && !reg_overlap_mentioned_p (dest, addr.reg))
validate_change (next, &SET_SRC (set), src, false);
}
else
But I have to regtest it before posting it on the mailing list. There are more
bug reports that are potentialy relate to this particular piece of code, so I
have to check them too.
[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474 --- Comment #5 from Dragan Mladjenovic --- Hi, I wasn't able to reproduce this issue which leds me to believe that this is the r273174 is the probable fix. In either way, it should be backported to gcc-9 branch, but it would be nice if you can confirm if it fixes the problem. Thanks in advance.
[Bug target/91702] [9/10 Regression] ICE with mips16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91702 --- Comment #1 from Dragan Mladjenovic --- Hi, Same as with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474#c5. Chould you perhaps verify if r273174 fixes your issue? Thanks in advance.
[Bug target/91900] [10 regression] mipsisa64r6-*-* rejects lo clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91900 Dragan Mladjenovic changed: What|Removed |Added CC||dragan.mladjeno...@rt-rk.co ||m --- Comment #3 from Dragan Mladjenovic --- Related to BZ91233.
[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474 --- Comment #9 from Dragan Mladjenovic --- Thanks for the confirmation. I've sent a request for backporting r273174 change onto gcc 9 branch. I believe this issue will be updated automatically when the backport lands.
[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769 --- Comment #9 from Dragan Mladjenovic --- Sorry for the delay. I somehow managed to get my git svn rebase to take hours. Both patches have been backported.
[Bug target/89245] [MIPS] v1 is assigned in jalr delay slot for later use at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245 --- Comment #1 from Dragan Mladjenovic --- The issue seems to be that jump pass tail merges two blocks ending in indirect calls to mit_tsi.isra.2 and emit_branch.isra.5 ignoring the REG_CALL_DECL notes attached to them which messes up the resource info later on for delay slot filler.
[Bug libgcc/90929] libgcc MIPS __clear_cache shouldn't be a no-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929 Dragan Mladjenovic changed: What|Removed |Added CC||dragan.mladjeno...@rt-rk.co ||m --- Comment #2 from Dragan Mladjenovic --- For mips64-linux-gnuabi64 the backend emits the direct call to libc's _flush_cache so the __clear_cache is never used. This test invokes __clear_cache explicitly, but there is another issue in that llvm will use __clear_cache libcall for __builtin___clear_cache on mips, so it won't work unless you ship/link the compiler_rt along with it.
[Bug target/89245] [MIPS] v1 is assigned in jalr delay slot for later use at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245 --- Comment #2 from Dragan Mladjenovic --- Fixed by r273314. Sorry for the inconvenience. I did not put a proper back-reference to this issue in the change log.
