https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637
--- Comment #4 from Maciej W. Rozycki ---
Sigh, I keep forgetting we don't have PC-relative memory access machine
instructions. We could have had base=x0 encodings allocated for that,
which are otherwise of rather limited use.
Regardless, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637
--- Comment #2 from Maciej W. Rozycki ---
I think perhaps using constant pools would be the best of both worlds?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631
Maciej W. Rozycki changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17887
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #5
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
Target Milestone: ---
Target: riscv*-*-linux-gnu
As observed in PR fortran/95631 read-only data gets assigned to `.sdata'
rather than `.rodata', which in turn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17887
Maciej W. Rozycki changed:
What|Removed |Added
CC||deji_aking at yahoo dot ca
---
||ma...@linux-mips.org
--- Comment #4 from Maciej W. Rozycki ---
*** This bug has been marked as a duplicate of bug 17887 ***
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
Target Milestone: ---
This is an interesting one. This was mentioned by Eric Korpela here:
<http://www.classiccmp.org/pipermail/cctalk/2020-May/053704.html> as a
language peculiarity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #35 from Maciej W. Rozycki ---
So presumably the actual solution for n32 would be the same as with x32
and SIB, which IIUC cannot rely on hardware wrapping around the address
space either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #34 from Maciej W. Rozycki ---
(In reply to mpf from comment #29)
> I don't remember the detail of this issue but I believe I was convinced that
> it is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The
> PX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #27 from Maciej W. Rozycki ---
Yes, it is the same problem, the same address calculation occurs here,
and the lack of 32-bit address space wraparound is a part of the n32
Linux ABI, which implies support for processors that do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74563
--- Comment #14 from Maciej W. Rozycki ---
Matthew is no longer at Imagination/MIPS and has nothing to do with MIPS
processors anymore. And me neither.
Also I have lost the ability to run GCC regression testing, not at least
without getting
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
Target Milestone: ---
Target: mips*-*-*
Created attachment 44179
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74563
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
Status|NEW |AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74563
--- Comment #6 from Maciej W. Rozycki <ma...@linux-mips.org> ---
Created attachment 41199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41199=edit
Possible fix
FYI, I think this has been caused by r227385, see how `_internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79071
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
CC| |ma...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
--- Comment #6 from Maciej W. Rozycki <ma...@linux-mips.org> ---
Fixed in binutils now:
commit 65060a78866f374e25f4668d12efc783235d19d1
Author: Maciej W. Rozycki <ma...@imgtec.com>
Date: Wed Jan 18 18:18:21 2017 +
PR gas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
CC| |ma...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325
--- Comment #3 from Maciej W. Rozycki <ma...@linux-mips.org> ---
I have pushed it through `mips-mti-linux-gnu' regression testing, with
the big-endian o32 regular MIPS multilib. It does fix the regressions
listed and does not cause any ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325
--- Comment #1 from Maciej W. Rozycki <ma...@linux-mips.org> ---
NB the notes are added by `mips_legitimize_move'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70890
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
CC| |ma...
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
Target Milestone: ---
Target: mips-linux-gnu
PR rtl-optimization/70890 fix (r235825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
CC| |ma...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
--- Comment #4 from Maciej W. Rozycki <ma...@linux-mips.org> ---
Thanks. I didn't expect -W would be required for non-truncated output,
however at this stage it looks anyway like it's GAS which is at fault,
because the GOT16 relocation a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What|Removed |Added
CC| |ma...
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
CC: matthew.fortune at imgtec dot com
Target Milestone: ---
Target: mips-mti-linux-gnu
This is a regression from GCC 5, present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
--- Comment #5 from Maciej W. Rozycki ma...@linux-mips.org ---
But the point is not the missing string, but a missed optimisation.
Has the optimisation been brought back now?
NB I have no way to look into it anymore.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139
--- Comment #16 from Maciej W. Rozycki ma...@linux-mips.org ---
The unwinder issue has been now fixed along PR target/60102, rev. 213596.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969
Maciej W. Rozycki ma...@linux-mips.org changed:
What|Removed |Added
CC||ma...@linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397
Maciej W. Rozycki ma...@linux-mips.org changed:
What|Removed |Added
CC||ma...@linux
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
Host: i686-linux-gnu
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
Host: i686-linux-gnu
Target: powerpc-linux-gnu
I see these failures in 4.9/trunk Power/Linux testing:
FAIL: gcc.dg/vect/no-vfa
: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
Target: powerpc-linux-gnu
Build: i686-pc-linux-gnu
I see these failures in Power/Linux testing with 4.9.1 and also trunk
(5.0
: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: ma...@linux-mips.org
CC: ma...@linux-mips.org, revital.eres at linaro dot org
Target: powerpc-linux-gnu
Created attachment 33252
-- https
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139
--- Comment #15 from Maciej W. Rozycki ma...@linux-mips.org ---
There is no ICE, this is target code in libgcc_s.so.1 calling abort at
run time whenever the DWARF2 unwinder is called. Shall I send you
binaries?
NB SPE GPRs indeed are 64-bit wide
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139
Maciej W. Rozycki ma...@linux-mips.org changed:
What|Removed |Added
CC||ma...@linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #10 from Maciej W. Rozycki ma...@linux-mips.org ---
(In reply to Jakub Jelinek from comment #9)
Jakub,
The fix has corrected the evaluation of `i++' however it has regressed
the evaluation of `i c'. This is because in the loop `i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #8 from Maciej W. Rozycki ma...@linux-mips.org ---
Richard,
I wasn't aware integer promotions applied here, thanks for pointing it
out. New code is therefore correct while old one was not. Unfortunately
neither -fwrapv nor -funsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
Maciej W. Rozycki ma...@linux-mips.org changed:
What|Removed |Added
CC||ma...@linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #5 from Maciej W. Rozycki ma...@linux-mips.org ---
(In reply to Andrew Pinski from comment #4)
Well that corrects how i++ is done.
Old MIPS assembly code produced was AFAICT correct. The loop termination
condition was expressed
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ma...@linux-mips.org
Target: mips-sde-elf, mips-linux-gnu
Created attachment 27342
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27342
MIPS16: Fix truncated DWARF-2 line
43 matches
Mail list logo
