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 thi
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 Maciej
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17887
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #5
ty: normal
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&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17887
Maciej W. Rozycki changed:
What|Removed |Added
CC||deji_aking at yahoo dot ca
--- Comme
||ma...@linux-mips.org
--- Comment #4 from Maciej W. Rozycki ---
*** This bug has been marked as a duplicate of bug 17887 ***
onent: 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 contro
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 sup
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 set
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
||ma...@linux-mips.org
Assignee|unassigned at gcc dot gnu.org |matthew.fortune at
imgtec dot com
--- Comment #11 from Maciej W. Rozycki ---
Matthew,
Can you please take care of the backport?
Maciej
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74563
--- Comment #6 from Maciej W. Rozycki ---
Created attachment 41199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41199&action=edit
Possible fix
FYI, I think this has been caused by r227385, see how `_internal'
is used by `mips_expand_epil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79071
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
--- Comment #6 from Maciej W. Rozycki ---
Fixed in binutils now:
commit 65060a78866f374e25f4668d12efc783235d19d1
Author: Maciej W. Rozycki
Date: Wed Jan 18 18:18:21 2017 +
PR gas/20649: MIPS: Fix GOT16/LO16 reloc pairing with comdat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012
Maciej W. Rozycki changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012
Maciej W. Rozycki changed:
What|Removed |Added
CC||matthew.fortune at imgtec dot
com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325
--- Comment #3 from Maciej W. Rozycki ---
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 new ones. Thanks for a quick ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325
--- Comment #1 from Maciej W. Rozycki ---
NB the notes are added by `mips_legitimize_move'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70890
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #9
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 changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
--- Comment #4 from Maciej W. Rozycki ---
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 at 0xcc isn't reordered (in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #2
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 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
--- Comment #5 from Maciej W. Rozycki ---
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 ---
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 changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #1
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
LP" 1
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
: 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
Severity: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139
--- Comment #15 from Maciej W. Rozycki ---
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 even on 32-bit targe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #10 from Maciej W. Rozycki ---
(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' is only ever
assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #8 from Maciej W. Rozycki ---
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-loop-optimizations c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #5 from Maciej W. Rozycki ---
(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 as:
bne$3,$6,$L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
Maciej W. Rozycki changed:
What|Removed |Added
CC||ma...@linux-mips.org
--- Comment #3
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 l
43 matches
Mail list logo
