[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327

2020-03-03 Thread dragan.mladjeno...@rt-rk.com
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/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327

2020-03-03 Thread dragan.mladjeno...@rt-rk.com
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=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

2020-01-24 Thread dragan.mladjeno...@rt-rk.com
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=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

2020-01-22 Thread dragan.mladjeno...@rt-rk.com
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] New: The mips-mti-linux-gnu fails to build after r276327

2019-12-18 Thread dragan.mladjeno...@rt-rk.com
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=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 target/91702] [9/10 Regression] ICE with mips16

2019-11-20 Thread dragan.mladjeno...@rt-rk.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91702

--- Comment #5 from Dragan Mladjenovic  ---
Yes, I believe so.

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

2019-10-04 Thread dragan.mladjeno...@rt-rk.com
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/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

2019-09-30 Thread dragan.mladjeno...@rt-rk.com
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/91900] [10 regression] mipsisa64r6-*-* rejects lo clobber

2019-09-30 Thread dragan.mladjeno...@rt-rk.com
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/91702] [9/10 Regression] ICE with mips16

2019-09-18 Thread dragan.mladjeno...@rt-rk.com
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/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

2019-09-18 Thread dragan.mladjeno...@rt-rk.com
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/91769] [9/10 regression] wrong code with -O2 on MIPS

2019-09-17 Thread dragan.mladjeno...@rt-rk.com
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 (, 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, _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

2019-09-04 Thread dragan.mladjeno...@rt-rk.com
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 middle-end/91233] New: Cannot build glibc for mips*r6 since r270955

2019-07-23 Thread dragan.mladjeno...@rt-rk.com
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/89245] [MIPS] v1 is assigned in jalr delay slot for later use at -Os

2019-07-10 Thread dragan.mladjeno...@rt-rk.com
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.

[Bug libgcc/90929] libgcc MIPS __clear_cache shouldn't be a no-op

2019-07-01 Thread dragan.mladjeno...@rt-rk.com
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

2019-03-14 Thread dragan.mladjeno...@rt-rk.com
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 rtl-optimization/88403] New: [Mips,AArch64] The gcse prevents if-conversion

2018-12-07 Thread dragan.mladjeno...@rt-rk.com
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=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)