[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
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 think run-time enforcement of the immutability of constant data is important for some use cases and possibly even required by some programming languages (Ada?).
[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
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?
[Bug fortran/95631] Unable to redefine a literal with `-std=legacy'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631 Maciej W. Rozycki changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #5 from Maciej W. Rozycki --- Thanks for the clarification, and quoting the relevant pieces of the respective standards in particular. I have marked the relevant duplicates, and hopefully the somewhat more meaningful bug summary will serve in the future. It may be worth adding this test case to the test suite, though for that I gather we'd have to trap that SIGSEGV and convert it to a successful return, whereas running through would have to exit unsuccessfully. Regrettably my Fortran fu is too weak to come up with a signal handler quickly. NB numerous computer systems do not support memory protection and have no way to mark a segment read-only, and may otherwise either not support instrumentation at all or it can be disabled for performance reasons, so the phenomenon observed/reported may indeed have been just a peculiarity of the implementation. I have filed PR target/95637 for the `.sdata' assignment of read-only data with `riscv*-*-linux-gnu' targets. *** This bug has been marked as a duplicate of bug 17887 ***
[Bug fortran/17887] g77 generates code that results in segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17887 Maciej W. Rozycki changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #5 from Maciej W. Rozycki --- *** Bug 95631 has been marked as a duplicate of this bug. ***
[Bug target/95637] New: Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637
Bug ID: 95637
Summary: Read-only data assigned to `.sdata' rather than
`.rodata'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: 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', which in turn causes invalid attempts to modify it
not to be trapped at run time.
A test case from the PR referred is:
C
C CHANGE THE VALUE OF 4
C
CALL INC(4)
WRITE (*, 30) 4
30FORMAT ('2+2=',I4)
END
SUBROUTINE INC(I)
I = I + 1
END
which is supposed to trap on the modification of literal 4 in INC.
Instead the program runs to completion and prints:
2+2= 5
I have no C language test case at hand, but I guess it does not matter,
this one is sweet and simple.
[Bug fortran/17887] g77 generates code that results in segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17887 Maciej W. Rozycki changed: What|Removed |Added CC||deji_aking at yahoo dot ca --- Comment #4 from Maciej W. Rozycki --- *** Bug 37974 has been marked as a duplicate of this bug. ***
[Bug fortran/37974] gfortran runtime segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37974 Maciej W. Rozycki changed: What|Removed |Added Resolution|INVALID |DUPLICATE CC||ma...@linux-mips.org --- Comment #4 from Maciej W. Rozycki --- *** This bug has been marked as a duplicate of bug 17887 ***
[Bug fortran/95631] New: Unable to redefine a literal with `-std=legacy'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631
Bug ID: 95631
Summary: Unable to redefine a literal with `-std=legacy'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 of up to at least FORTRAN 77. Which is given the
following program:
C
C CHANGE THE VALUE OF 4
C
CALL INC(4)
WRITE (*, 30) 4
30FORMAT ('2+2=',I4)
END
SUBROUTINE INC(I)
I = I + 1
END
the supposed output is:
2+2= 5
Eric says:
'Most languages will give you some way to shoot yourself in the foot. The
question is how much work do you need to do? In FORTRAN the easiest method
was changing the value of a literal in a subroutine call. It is standard
compliant behavior that goes back to at least FORTRAN IV. Current
compliers and converters go to pains to make sure it still happens. Not
sure if it is still present in f90 and beyond. At least modern compilers
for other languages will give you a "potential foot shooting warning",
although in C++ that warning statement could take 200 kB.'
However when this program is built with GCC like this and run on an
`x86_64-linux-gnu' system, it causes SIGSEGV at the incrementation:
$ gfortran -Wall -W -Wextra -pedantic -std=legacy -O2 -g -o four four.f
$ ./four
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7f0e8c9f5b90 in ???
#1 0x7f0e8c9f4dc5 in ???
#2 0x7f0e8c66683f in ???
#3 0x4011b1 in inc_
at /home/macro/src/four.f:11
#4 0x4011b1 in MAIN__
at /home/macro/src/four.f:5
#5 0x40109c in main
at /home/macro/src/four.f:8
$
The reason is the literal to be incremented (4) has been assigned to
`.rodata'. There is no warning issued with the compilation either.
Conversely with the `riscv64-linux-gnu' target the literal gets assigned
to `.sdata' and the program executes as expected:
$ ./four
2+2= 5
$
but I take it it is by chance rather than design (no `.srodata' has been
defined, for obvious reasons).
My Fortran experience is so-so, but I did some language standard
examination and indeed it says something like:
"INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The
argument corresponding to an INTENT (INOUT) dummy argument always shall
be definable, while an argument corresponding to a dummy argument without
an INTENT attribute need be definable only if the dummy argument is
actually redefined."
which essentially means that the actual argument associated with I in the
call to INC here has to be a variable rather than a literal.
My understanding however is we still intend to support peculiar old
programs if built with the `-std=legacy' level. If not, then perhaps we
ought to at least give that "potential foot shooting warning" Eric talks
about?
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
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.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
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 control bit forces address calculations i.e. base + imm or base + reg to > be performed with 32-bit rules but allows 64 instruction usage. Since there > is a processor mode that is perfectly capable of meeting the requirements of > a program with 64bit data and 32bit pointers then the solution is to set PX > for N32 rather than UX. This is impractical because as I say Linux has to support processors that have no CP0.Status.PX bit and do have to rely on CP0.Status.UX instead. NB Richard, n32 is 64-bit mode, pretty much like x86's x32, except that invented some 20 years earlier. So regs are already DImode as are stack slots, etc.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
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 support such a wraparound in hardware (no CP0.Status.PX bit). You may try experimenting with ISA/ASE selection options, so that LWX is not considered a valid instruction by GCC. Otherwise I can't help with finding a workaround as I don't know one offhand and I'm not involved with MIPS development anymore, sorry. And neither is Doug BTW. This really ought to be fixed properly in GCC.
[Bug target/74563] [6 regression] Classic MIPS16 (non-MIPS16e) function return broken
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 up from scratch, including QEMU, as I don't own or have access to actual MIPS16 hardware. I could mechanically apply the change if it gets approved for the release branch and someone else runs verification (but then they could probably commit themselves, this being the easiest part).
[Bug target/85909] New: [MIPS] Inconsistent operand constraints error with complex double inline asm operands and o32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85909 Bug ID: 85909 Summary: [MIPS] Inconsistent operand constraints error with complex double inline asm operands and o32 ABI Product: gcc Version: 9.0 Status: UNCONFIRMED 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?id=44179=edit Source to reproduce the problem The program attached (a GDB test case) fails to build with the o32 ABI (`-mips32r2 -mfp64'; fiddle with _MIPS_FPSET #ifdef to reproduce with `-mfp32' too) reporting: mips-fpregset-core.c: In function 'main': mips-fpregset-core.c:66:3: error: inconsistent operand constraints in an 'asm' asm ( ^~~ It builds just fine with the n32 and n64 ABIs and produces correct code.
[Bug target/74563] [6 regression] Classic MIPS16 (non-MIPS16e) function return broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74563 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added Status|NEW |ASSIGNED CC| |ma...@linux-mips.org Assignee|unassigned at gcc dot gnu.org |matthew.fortune at imgtec dot com --- Comment #11 from Maciej W. Rozycki <ma...@linux-mips.org> --- Matthew, Can you please take care of the backport? Maciej
[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken
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'
is used by `mips_expand_epilogue':
/* simple_returns cannot rely on values that are only available
on paths through the epilogue (because return paths that do
not pass through the epilogue may nevertheless reuse a
simple_return that occurs at the end of the epilogue).
Use a normal return here instead. */
rtx reg = gen_rtx_REG (Pmode, GP_REG_FIRST + 7);
pat = gen_return_internal (reg);
and what looks like an inadvertent addition of:
operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
there:
@@ -6522,12 +6543,10 @@
[(any_return)
(use (match_operand 0 "pmode_register_operand" ""))]
""
-{
- if (TARGET_MICROMIPS)
-return "%*jr%:\t%0";
- else
-return "%*j\t%0%/";
-}
+ {
+operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
+return mips_output_jump (operands, 0, -1, false);
+ }
[(set_attr "type""jump")
(set_attr "mode""none")])
Patch attached may fix it, untested.
[Bug testsuite/79071] Add test case for PR/65618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79071 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added CC| |ma...@linux-mips.org Component|rtl-optimization|testsuite --- Comment #2 from Maciej W. Rozycki <ma...@linux-mips.org> --- I somehow understood PR rtl-optimization/65618 only addressed the bootstrap failure somehow and not the actual code generation bug. Given that the actual bug has been fixed, any test case can only serve a verification rather than debugging purpose. I think it would still be good if it did that and was integrated with our test suite so that we are alerted in the future with regular testing if the problem has reappeared, without having to go through a native bootstrap. Moving to the testsuite component then. Sorry about the confusion.
[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot
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/20649: MIPS: Fix GOT16/LO16 reloc pairing with comdat sections
[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-24 Ever confirmed|0 |1
[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added CC||matthew.fortune at imgtec dot com --- Comment #5 from Maciej W. Rozycki <ma...@linux-mips.org> --- I have been able to reproduce the bug now -- to trigger it you need to request classic SVR4 code either by means of compiler defaults or with the use of the `-mplt' option, in which case a pair of single-word FPU accesses is produced for $f15: first SWC1 to save it, and then LWC1 to restore it from the stack frame, as follows: swc1$f15,224($sp)# 1178 *movsi_internal/15 [length = 4] lwc1$f15,224($sp)# 1179 *movsi_internal/13 [length = 4] Notice the integer mode used. I haven't investigated it further. You need all of `-mips32r2 -mfpxx -mno-plt' to trigger it. It does *not* trigger if `-fPIC' or `-fPIE' is used in place of `-mno-plt'.
[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added CC| |ma...@linux-mips.org --- Comment #2 from Maciej W. Rozycki <ma...@linux-mips.org> --- I can't reproduce your problem with either test case and: mips-mti-linux-gnu-gcc (GCC) 7.0.0 20161117 (experimental) -- code produced assembles correctly and visual inspection of the assembly reveals no odd-numbered FGR operands throughout. Would you therefore please reconfirm this issue still triggers with current HEAD, and if so, then report the details of your compilation as shown with the `-v' flag added to your invocation line?
[Bug rtl-optimization/78325] [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures
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 new ones. Thanks for a quick action!
[Bug rtl-optimization/78325] [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures
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'.
[Bug rtl-optimization/70890] [7 regression] r235660 miscompiles stage2 compiler on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70890 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added CC| |ma...@linux-mips.org --- Comment #9 from Maciej W. Rozycki <ma...@linux-mips.org> --- This has caused PR rtl-optimization/78325. Perhaps the fix has to be reverted and a different solution found as the MIPS target does need these notes for PIC call annotation even though the register is dead.
[Bug rtl-optimization/78325] New: [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325 Bug ID: 78325 Summary: [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures Product: gcc Version: 7.0 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) causes REG_EQUIV notes to be removed from PIC call register loads in the MIPS new ABIs for function calls to local symbols which use GOT_PAGE/GOT_OFST relocations. These notes are used in `mips_pic_call_symbol_from_set' to determine the actual symbol referred in call insns and use it to produce a suitable R_MIPS_JALR relocation. Consequently the relocations are not output anymore causing these regression test failures: FAIL: gcc.target/mips/call-5.c -O2 scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t FAIL: gcc.target/mips/call-5.c -O3 -g scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t FAIL: gcc.target/mips/call-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t FAIL: gcc.target/mips/call-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t FAIL: gcc.target/mips/call-6.c -O2 scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t FAIL: gcc.target/mips/call-6.c -O3 -g scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t FAIL: gcc.target/mips/call-6.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t FAIL: gcc.target/mips/call-6.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler \\.reloc\t1f,R_MIPS_JALR,staticfunc\n1:\tjalrc?\t and the linker cannot perform the branch optimisation intended, which is especially relevant for function calls to local symbols. With r235825 reverted on top of current trunk these regressions are gone.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added CC| |ma...@linux-mips.org --- Comment #11 from Maciej W. Rozycki <ma...@linux-mips.org> --- TBH this does look like trying to rely on UB to me, as per section 6.5.6 "Additive operators" clause 8 of the C language standard, which states (among others): "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined." Here under the triggering conditions the pointer the integer is added to with LDXC1 does not point to an element of the array operated on (or to one past the last), so the hardware operation matches the standard's semantics WRT overflow and I don't think we ought to be pushing it. So it looks like a middle end bug to me and the backend is fine in faithfully assuming its RTL pattern won't be passed operands leading to UB. Have I missed anything? Maciej
[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot
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 at 0xcc isn't reordered (in the relocation table) ahead the LO16 relocation at 0x60. Could you therefore please file a bug against GAS at <https://sourceware.org/bugzilla/> and attach the generated assembly which has triggered this problem? I'll take it from there. This bug can now be closed although I can't seem able to do that for some reason. NB it would be good to have links both ways recorded between the bug entries, so please record a link here once you've got the other bug's ID.
[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300 Maciej W. Rozycki <ma...@linux-mips.org> changed: What|Removed |Added CC| |ma...@linux-mips.org --- Comment #2 from Maciej W. Rozycki <ma...@linux-mips.org> --- Thank you for your bug report. The SVR4 MIPS psABI (o32) mandates that a HI16 or a local GOT16 relocation is immediately followed by a matching LO16 relocation. To address the very scenario described here however as a GNU extension we support an arbitrary number of HI16 or GOT16 relocations followed by a matching LO16 relocation. This is explicitly noted in BFD sources: "The ABI requires that the *LO16 immediately follow the *HI16. However, as a GNU extension, we permit an arbitrary number of *HI16s to be associated with a single *LO16. This significantly simplies the relocation handling in gcc." and has been like this since forever. The pairing is supposed to be done by the assembler so as long it has been done correctly there's nothing for the linker to complain about. I see in the Debian bug report referred that this error only happens with `gold', so I am highly suspicious that this is a `gold' bug. To ensure all is in order would you therefore please send me the output of `readelf -r src.o' and double-check your results with both `ld' and `gold'?
[Bug target/74563] New: [5 regression] Classic MIPS16 (non-MIPS16e) function return broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74563
Bug ID: 74563
Summary: [5 regression] Classic MIPS16 (non-MIPS16e) function
return broken
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: major
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 GCC 6 and in current trunk.
Non-leaf classic MIPS16 (non-MIPS16e) function epilogue uses $7 as the
return register, because there is no hardware instruction available to
load $31 directly from the stack. This used to work up to GCC 5, but
now function epilogue still loads $7 with the return address, however
it then uses JR $31 to attempt a function return. This obviously
cannot work as in a non-leaf function typically $31 does not hold the
return address anymore.
To reproduce this simple program can be used:
$ cat jal16.c
void f2(void);
void f1(void)
{
f2();
}
$ gcc -mips1 -mips16 -O2 -S jal16.c
$ cat jal16.s
With GCC 5 I get this correct result:
.file 1 "jal16.c"
.section .mdebug.abi32
.previous
.nanlegacy
.module fp=32
.module nooddspreg
.abicalls
.option pic0
.text
.align 2
.globl f1
.setmips16
.setnomicromips
.entf1
.type f1, @function
f1:
.frame $sp,32,$31 # vars= 0, regs= 1/0, args= 16, gp= 8
.mask 0x8000,-4
.fmask 0x,0
addiu $sp,-32
sw $31,28($sp)
jal f2
lw $7,28($sp)
.setnoreorder
.setnomacro
j $7
addiu $sp,32
.setmacro
.setreorder
.endf1
.size f1, .-f1
.ident "GCC: (GNU) 5.4.1 20160810"
With GCC 6 I get this bad one instead:
.file 1 "jal16.c"
.section .mdebug.abi32
.previous
.nanlegacy
.module fp=32
.module nooddspreg
.abicalls
.option pic0
.text
.align 2
.globl f1
.setmips16
.setnomicromips
.entf1
.type f1, @function
f1:
.frame $sp,32,$31 # vars= 0, regs= 1/0, args= 16, gp= 8
.mask 0x8000,-4
.fmask 0x,0
addiu $sp,-32
sw $31,28($sp)
jal f2
lw $7,28($sp)
.setnoreorder
.setnomacro
jr $31
addiu $sp,32
.setmacro
.setreorder
.endf1
.size f1, .-f1
.ident "GCC: (GNU) 6.1.1 20160810"
Notice the difference:
--- jal16-gcc5.s2016-08-11 14:22:24.996749000 +0100
+++ jal16-gcc6.s2016-08-11 18:59:38.472543000 +0100
@@ -23,11 +23,11 @@
lw $7,28($sp)
.setnoreorder
.setnomacro
- j $7
+ jr $31
addiu $sp,32
.setmacro
.setreorder
.endf1
.size f1, .-f1
- .ident "GCC: (GNU) 5.4.1 20160810"
+ .ident "GCC: (GNU) 6.1.1 20160810"
This is a fatal bug making the MIPS16 compiler unusable and therefore
requiring hightened attention, although only affecting an ISA level
which is not as important these days anymore, so setting severity to
major rather than critical/blocker.
[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1
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.
[Bug target/58139] PowerPC volatile VSX register live across call
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.
[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969 Maciej W. Rozycki ma...@linux-mips.org changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #31 from Maciej W. Rozycki ma...@linux-mips.org --- PR 61397 is another fallout, on Power.
[Bug target/61397] [5 regression] FAIL: gcc.target/powerpc/p8vector-ldst.c scan-assembler lxsdx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397 Maciej W. Rozycki ma...@linux-mips.org changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #1 from Maciej W. Rozycki ma...@linux-mips.org --- Also in 4.9.1, regressed from 4.9.0.
[Bug regression/63175] New: [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 Bug ID: 63175 Summary: [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 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-linux-gnu Target: powerpc-linux-gnu I see this failure in Power/Linux testing with 4.9.1 and also trunk (5.0), so presumably the regression happened sometime between 4.8 and 4.9: FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1 This test passed with 4.8. This is with powerpc-linux-gnu. Looking at the generated assembly the quality of code has indeed regressed, copying between `pin' and `pout' in `main1' is no longer optimised away. This happens for AltiVec multilibs only, seen with: -mcpu=603e -mcpu=603e -msoft-float -mcpu=7400 -maltivec -mabi=altivec -mcpu=e6500 -maltivec -mabi=altivec -mcpu=e6500 -m64 -maltivec -mabi=altivec option selections here. Options used to configure the compiler: --build=i686-pc-linux-gnu --target=powerpc-linux-gnu --with-cpu-32=603e --with-cpu-64=e5500 --with-long-double-128
[Bug regression/63177] New: Power/Linux no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63177 Bug ID: 63177 Summary: Power/Linux no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal 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-vect-depend-2.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/no-vfa-vect-depend-3.c scan-tree-dump-times vect vectorized 1 loops 4 These are new test cases as of 4.9. Only seen with AltiVec multilibs: -mcpu=603e -mcpu=603e -msoft-float -mcpu=7400 -maltivec -mabi=altivec -mcpu=e6500 -maltivec -mabi=altivec -mcpu=e6500 -m64 -maltivec -mabi=altivec Options used to configure the compiler: --build=i686-pc-linux-gnu --target=powerpc-linux-gnu --with-cpu-32=603e --with-cpu-64=e5500 --with-long-double-128
[Bug regression/63150] New: [4.9 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 Bug ID: 63150 Summary: [4.9 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times * 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 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), so presumably the regression happened sometime between 4.8 and 4.9: FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times lwbrx 6 FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times stwbrx 6 These tests passed with 4.8. This is with powerpc-linux-gnu. I've looked at generated assembly and actually 2 out of 6 cases fail: load64_reverse_2 and store64_reverse_2, the remaining 4 are fine. In all cases code produced looks correct, so this is a missed optimisation rather a code correctness issue. Options used to configure the compiler: --build=i686-pc-linux-gnu --target=powerpc-linux-gnu --with-cpu-32=603e --with-cpu-64=e5500 --with-long-double-128 Actually even with 4.8 code that the test case accepts it looks like we've got another missed optimisation here because we do: lwbrx 8,0,9 lwbrx 7,0,10 mr 4,8 mr 3,7 blr while we could do: lwbrx 4,0,9 lwbrx 3,0,10 blr instead. But that's of course a different matter.
[Bug testsuite/62028] New: Power64/Linux: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62028 Bug ID: 62028 Summary: Power64/Linux: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0 Product: gcc Version: 4.10.0 Status: UNCONFIRMED 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 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33252action=edit Test case source I observe this failure: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0 in 64-bit Power/Linux testing. The test case (source attached) has a loop in `foo' that gets conditionally unrolled on 64-bit Power (but not on 32-bit Power where this test case passes): the incoming value of `ctr' is checked and if less than or equal to 2, then the unrolled loop is branched to, otherwise execution falls through to the regular loop. It is this unrolled loop that the SMS pass catches and handles I believe which is probably correct. What I am not sure of is whether this loop unrolling makes sense performance-wise, especially considering the code size increase from handling the two cases separately; someone with a better understanding of Power pipelines would have to have a look into it. Given the above I can't decide if it's the test case that is wrong and should e.g. exclude 64-bit Power or if this is a genuine failure. The test case binary executes successfully: PASS: gcc.dg/sms-8.c execution test so if a failure, then this is a missed optimisation rather than a code correctness issue. Options used to configure the compiler: --build=i686-pc-linux-gnu --target=powerpc-linux-gnu --with-cpu-32=603e --with-cpu-64=e5500 --with-long-double-128 Options used to build the test case: -O2 -fdiagnostics-color=never -fdump-rtl-sms -ffat-lto-objects -fmodulo-sched -fmodulo-sched-allow-regmoves -fno-diagnostics-show-caret -m64 The same issue triggers if: -mcpu=e6500 is additionally used with the test case.
[Bug target/58139] PowerPC volatile VSX register live across call
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 even on 32-bit targets with the extra 32 bits only used for SPE data types, traditionally V2SI mode integers. This makes a change in the ABI though such that any GPRs stored in stack frames are held there as 64-bit quantities, with `evstdd' and `evldd' intructions used to manipulate them. For regular, non-vector integer operations GPRs remain 32-bit, with the most significant 32 bits unused. So this may or may not be a latent bug for SPE that, if so, I'd love to see fixed in trunk, however speaking of 4.8 this is a serious regression as the DWARF2 unwinder used to work and now it does not, making exception handling non-functional. Of course if you are able to fix 4.8 properly right away, then it would be most welcome!
[Bug target/58139] PowerPC volatile VSX register live across call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139 Maciej W. Rozycki ma...@linux-mips.org changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #13 from Maciej W. Rozycki ma...@linux-mips.org --- This breaks Power SPE targets, at least the Linux OS, almost surely EABI too. Seen in 4.8 powerpc-linux-gnu g++ and libstdc++ testing as some 700 regressions e.g. with these compiler options: -mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe The cause is a DWARF2 unwinder abort triggered by: gcc_assert (size == sizeof(_Unwind_Word)); in _Unwind_SetSpColumn and the cause is with this change applied `size' is 8 whereas `sizeof(_Unwind_Word)' is 4. Previously `size' was 4. For 4.8 please revert unless a better fix can be made within the available time frame. Let me know if I can assist with testing.
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
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' is only ever assigned values that are lower than or equal to the value of `c' and here the `int' type can represent all values representable with the `signed short' and `unsigned short' types. Specifically, assuming the properties of the MIPS target, where `int' is 32-bit wide and `short' is 16-bit wide, we have the following cases of the `c' input value here: 1. 0 -- the loop is not entered because `i' is preset to 0 and equals `c' right away. 2. [1,32767] -- `i' is incremented from 0 until it reaches the value of `c', at which point the loop terminates. 3. [32768,65535] -- `i' is incremented from 0 up to 32767, at which point it wraps around to -32768 and continues being incremented to 32767 again. And so on, and so on. It never reaches the value of `c' or any higher value and therefore the loop never terminates. Based on the above observations it is enough to check for `i == c' as the loop termination condition. So I think this is still a performance regression from the user's point of view even though I realise this may not necessarily be an optimisation GCC has been previously designed for. Therefore I'd prefer to keep the bug open until/unless we decide it's impractical to implement a code transformation that would restore previous performance. Maciej
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
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-loop-optimizations changes anything. Maciej
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 Maciej W. Rozycki ma...@linux-mips.org changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #3 from Maciej W. Rozycki ma...@linux-mips.org --- Caused by: r193882 | rguenth | 2012-11-28 09:27:10 + (Wed, 28 Nov 2012) | 19 lines 2012-11-28 Richard Biener rguent...@suse.de PR c/35634 * gimple.h (gimplify_self_mod_expr): Declare. * gimplify.c (gimplify_self_mod_expr): Export. Take a different type for performing the arithmetic in. (gimplify_expr): Adjust. * tree-vect-loop-manip.c (vect_can_advance_ivs_p): Strip sign conversions we can re-apply after adjusting the IV. c-family/ * c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions here and use a type with proper overflow behavior for types that would need to be promoted for the arithmetic. * gcc.dg/torture/pr35634.c: New testcase. * g++.dg/torture/pr35634.C: Likewise. * gcc.dg/vect/pr18536.c: Mark worker function noinline.
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
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 as: bne$3,$6,$L3 that represented (i != c) rather than (i c), but we start `i' from 0 and increment by one at a time, so both expressions are equivalent in this context. Here I believe the following C language standard clause applies[1]: Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type. so for both operands the expression is supposed to use the unsigned short type, that is 16-bit on the MIPS target. There are no 16-bit ALU operations defined in the MIPS architecture though, so at the assembly (and therefore machine-level) level both `c' and `i' were sign-extended to 32-bits: andi$5,$5,0x seh$6,$5 and: seh$3,$3 respectively (of course ANDI is redundant here, there's no need to zero-extend before sign-extending, SEH does not require it), before the BNE comparison quoted above was made. That correctly mimicked 16-bit operations required by the language here (of course zero-extension of both `c' and `i' would do as well). Now after the change `c' is zero-extended only (no sign-extension afterwards): andi$5,$5,0x while `i' is still sign-extended: seh$3,$3 Then the loop termination condition is expressed as: slt$6,$3,$5 bne$6,$0,$L3 instead. Notice the SLT instruction, that accurately represents the (i c) termination condition, however using *signed* arithmetic. Which means that for `c' equal e.g. to 32768 the loop will never terminate. I believe this is not what the clause of the C language standard quoted above implies. For unsigned arithmetic SLTU would have to be used instead. So it looks to me like the performance regression merely happens to be a visible sign of a bigger correctness problem. Have I missed anything? [1] Programming languages -- C, ISO/IEC 9899:1999(E), Section 6.3.1.8 Usual arithmetic conversions.
[Bug target/53276] New: DWARF-2 line information truncated for MIPS16 thunks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53276
Bug #: 53276
Summary: DWARF-2 line information truncated for MIPS16 thunks
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
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 information
Recording the bug here so that it's not lost. This was originally reported
here:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01067.html
I have now regression-tested the fix proposed against 4.8.0 20120501, using the
mips-sde-elf target (thanks, Richard, for fixing it), for MIPS32 and MIPS16
multilibs, both endiannesses, with the gcc, g++, libstdc++ and gdb test suites.
I have tested a little-endian n64 MIPS64 multilib as well, but due to
limitations of my environment I could only cover gcc, g++ and libstdc++ test
suites (i.e. no gdb, and no big-endian testing either). All the tests were
successful.
Until recently MIPS16 thunks were not covered by any testing at all, this bug
could have only been triggered manually when doing actual debugging. I have
recently fixed numerous bugs in GDB related to MIPS16 thunk support and as a
part of that added a test case that verifies correct GDB support. GDB relies
on correct line information for function prologues and therefore this bug now
triggers in that test case.
You can restrict the GDB test suite to run gdb.arch/mips16-thunks.exp only to
save time if you want to verify correct support; that test case relies on
MIPS16 execution support in the target -- that includes a MIPS16 execution unit
in the processor used (note QEMU support may not necessarily be reliable enough
to run that test case; I don't know for sure) as well as in the environment
(that includes the rest of the toolchain, any libraries involved and the OS, as
may be necessary). If successful, the test case should score 140 passes.
The original report now follows, I have attached the original fix proposal for
easier retrieval as well.
--
From ma...@codesourcery.com Wed Dec 14 02:58:18 2011
Message-ID: alpine.deb.1.10.1112132001040.5...@tp.orcam.me.uk
Date: Wed, 14 Dec 2011 02:58:03 +
From: Maciej W. Rozycki ma...@codesourcery.com
To: gcc-patc...@gcc.gnu.org
Cc: Richard Sandiford rdsandif...@googlemail.com, Catherine Moore
c...@codesourcery.com
Subject: [PATCH] MIPS16: Fix truncated DWARF-2 line information
Hi,
I've noticed in the presence of a specific MIPS16 function thunk, GCC
fails to emit suitable DWARF-2 location directives, which in turn causes
DWARF-2 line records to provide truncated information. This is probably
best illustrated with an example.
Given the following source code:
$ cat sinfrob16.c
int i;
double sinfrob16(double d)
{
i++;
return d;
}
we get this:
$ mips-linux-gnu-gcc -mips16 -Wa,-call_nonpic -fPIC -G0 -g -S sinfrob16.c
$ cat sinfrob16.s
.section .mdebug.abi32
.previous
.gnu_attribute 4, 1
.abicalls
.text
$Ltext0:
.cfi_sections.debug_frame
.commi,4,4
.align2
.globlsinfrob16
$LFB0 = .
.file 1 sinfrob16.c
.loc 1 4 0
.cfi_startproc
# Stub function for sinfrob16 (double)
.section.mips16.fn.sinfrob16,ax,@progbits
.align2
.setnomips16
.ent__fn_stub_sinfrob16
.type__fn_stub_sinfrob16, @function
__fn_stub_sinfrob16:
.setnoreorder
.cpload$25
.setreorder
.reloc0,R_MIPS_NONE,sinfrob16
la$25,__fn_local_sinfrob16
mfc1$5,$f12
mfc1$4,$f13
jr$25
.end__fn_stub_sinfrob16
__fn_local_sinfrob16 = sinfrob16
.text
.setmips16
.entsinfrob16
.typesinfrob16, @function
sinfrob16:
.frame$17,8,$31# vars= 0, regs= 2/0, args= 0, gp= 0
.mask0x8002,-4
.fmask0x,0
li$2,%hi(_gp_disp)
addiu$3,$pc,%lo(_gp_disp)
sll$2,16
addu$2,$3
save8,$17,$31
$LCFI0 = .
.cfi_def_cfa_offset 8
.cfi_offset 31, -4
.cfi_offset 17, -8
move$17,$sp
$LCFI1 = .
.cfi_def_cfa_register 17
move$28,$2
.loc 1 5 0
move$2,$28
move$24,$2
.loc 1 4 0
sw$5,12($17)
sw$4,8($17)
.loc 1 5 0
move$3,$24
lw$2,%got(i)($3)
lw$2,0($2)
addiu$2,1
move$3,$24
lw$3,%got(i)($3)
move$24,$3
move$3,$24
sw$2,0($3)
.loc 1 6 0
lw$3,12($17)
lw$2,8($17)
move$25,$3
move$24,$2
move$3,$25
move$2,$24
move$25,$3
move$24,$2
.loc 1 7 0
move$3,$25
move$2
