[Bug target/113947] Switch pdp11 to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113947 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-15 Ever confirmed|0 |1
[Bug target/96050] PDP-11: 32-bit MOV from offset(Rn) overrides Rn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96050 --- Comment #1 from pkoning at gcc dot gnu.org --- There certainly are some missing earlyclobbers in the MD file. Someone else reported bad code from this and a patch to add the missing "&" fixed those. Curious that it doesn't for your test case; it suggests that there is an additional issue that needs to be understood.
[Bug c++/103806] internal compiler error: in vague_linkage_p, at cp/decl2.c:2192 for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103806 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #3 from pkoning at gcc dot gnu.org --- At the moment there is no support for other than C. It would be nice for that to change; it's not particularly practical without first doing ELF. That has been prototyped but that work is not available, but it can probably be redone with a reasonable amount of effort.
[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801 pkoning at gcc dot gnu.org changed: What|Removed |Added CC||pkoning at gcc dot gnu.org --- Comment #5 from pkoning at gcc dot gnu.org --- There is no pdp11 support in newlib (and never was as far as I know; it's not a matter of it having been "removed"). I've played with creating one, but not enough to submit the result. But that doesn't make the pdp11 target meaningless or say it needs to be removed. The only consequence of the lack of an off the shelf library package is that you can't run the execution testsuite. But you can, for example, run the compile part of the testsuite.
[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841 pkoning at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from pkoning at gcc dot gnu.org --- Fixed by the patch from Mikael Petterson.
[Bug target/93719] Unable to find a register to spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93719 --- Comment #1 from pkoning at gcc dot gnu.org --- This works with -mlra, so given the deprecation of old reload the right answer seems to be to close this as fixed.
[Bug target/59172] pdp11-aout makes a wrong code at the epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from pkoning at gcc dot gnu.org --- It works properly in the current release.
[Bug target/59178] Stack corruption on register save/restore when using frame pointer on pdp-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59178 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from pkoning at gcc dot gnu.org --- It works properly in the current version -- I see stack push in the prologue and matching stack pop operations in the epilogue.
[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841 pkoning at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-07-13 Status|UNCONFIRMED |ASSIGNED CC||pkoning at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/108388] LRA generates RTL that violates constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388 pkoning at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from pkoning at gcc dot gnu.org --- Looks good. I confirmed that pdp11 GCC with default LRA now builds properly, and my standard test run of the GCC test suite (compile tests) looks good. Essentially the same pass/fail numbers (mostly pass, though I have work to do) as in runs last year with reload as the default.
[Bug rtl-optimization/108388] New: LRA generates RTL that violates constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388 Bug ID: 108388 Summary: LRA generates RTL that violates constraints Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pkoning at gcc dot gnu.org Target Milestone: --- Created attachment 54259 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54259=edit Reproducer for this issue In gcc for pdp11-aout, compiling with LRA enabled (-mlra) and optimization (-Os or -O2) I get an ICE when building libgcc2. The issue appears to be that LRA first assigns a hard register for the destination of an addhi3 RTL, specifically R5. R5 is the frame register, but it can be eliminated. The source is an address computed from the frame pointer, i.e., a (plus (r5) (const int something)). The machine is a two-operand machine, so in patterns like addhi3 the operand descriptor for operand 1 (first source) requires it to be the same as operand 0 (destination). So far so good. The assigned register indeed satisfies that constraint. But apparently after that point LRA decides to eliminate the frame register, so it simply replaces that frame-related reference in the source by a stack pointer based reference, of the form (plus (sp) (const int something-else)). At this point we have a constraint violation because operands 0 and 1 are now different (r5 and sp respectively). Correct code would require copying sp into some other register then doing the addhi3 with that register. The code compiles correctly with old reload (the default, in the currently committed pdp11 target).
[Bug c/107476] Spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107476 --- Comment #1 from pkoning at gcc dot gnu.org --- I should mention that I reproduced this (a) on an M1 Mac running gcc (GCC) 13.0.0 20220827 (experimental), and also on an x86 Linux running gcc (GCC) 12.2.0.
[Bug c/107476] New: Spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107476 Bug ID: 107476 Summary: Spurious stringop-overflow warning Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pkoning at gcc dot gnu.org Target Milestone: --- Created attachment 53803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53803=edit Reproducer. Compile with -O3 The attached code produces a stringop-overflow warning complaining that the code is writing into offset 1 of a one entry array (ttix_buf, reference in ttix_svc). In fact it does not, since the index is the control variable in a for loop that ends on a < one check. Curiously, if I increase the size of the ttix_buf array, I still see the error at size 2 or 3, but no complaints at size 4 or above.
[Bug target/99645] pdp-11 target produces inefficient code for sign extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99645 pkoning at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-19
[Bug target/96050] PDP-11: 32-bit MOV from offset(Rn) overrides Rn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96050 pkoning at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-03-19 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug target/93719] Unable to find a register to spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93719 pkoning at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-19
[Bug target/84438] Another code pattern that breaks PDP11 with -m10: including reproducer code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84438 pkoning at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-03-19 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug target/87821] pdp11 ICE on overaligned local variable: REG_POINTER used with unexpected rtx code 'const_int' in mark_reg_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87821 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-19 Ever confirmed|0 |1
[Bug target/59847] cast to long makes compiler crash if using option pdp-11/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59847 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-19 Ever confirmed|0 |1
[Bug target/59172] pdp11-aout makes a wrong code at the epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172 pkoning at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-19
[Bug target/99645] New: pdp-11 target produces inefficient code for sign extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99645 Bug ID: 99645 Summary: pdp-11 target produces inefficient code for sign extend Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pkoning at gcc dot gnu.org Target Milestone: --- This issue was revealed by bug 84437. The reproducer given there now produces "correct" code but it's quite inefficient because it uses a shift by 15 for sign extend. On pdp11 that's not the best answer.
[Bug target/84437] long long casting breaks PDP-11 with -m10 model option (includes trivial reproducer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84437 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from pkoning at gcc dot gnu.org --- Agreed, this is fixed in the current code, shift handling was cleaned up as part of the CCmode change. That said, the code produces the right answer but it does it in a bad way, because the port does not provide a pattern for this sign extend. The GCC default is to use a shift, which for a pdp-11 is not the best answer.
[Bug rtl-optimization/59942] pdp11-aout-gcc: PDP-11/10 code generation crashes when trying to do multiple shifts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59942 pkoning at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from pkoning at gcc dot gnu.org --- Thanks all. I confirmed this is fixed in the recent code, and also ran a longer test case supplied my Mattis. The shift handling got a major rewrite the last time I did significant surgery on the target, as part of the CCmode transition.
