[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134 --- Comment #7 from pkoning at gcc dot gnu.org --- Thanks Jakub. Inspecting the generated assembly language is a sufficient check of the fix in my view. It's interesting that the test case shows the problem only with -O0. When optimizing, things are emitted in a different order (in particular, b then a, I'm not sure why).
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #11 from pkoning at gcc dot gnu.org ---
(In reply to Stephen Casner from comment #9)
A lot of these questions should have answers in the GCC Internals manual, which
is quite good. And also quite dense. I know it a little, enough for a bunch
of cleanup on the pdp11 target in recent years, but I'm certainly not an
expert. The gcc mailing list is where you find experts. Some comments below
for the parts I can answer:
> ...
> 2. Good point about optimization possibly omitting the variables in my test
> case. Of course, the variables were used in my real program where I first
> observed this problem, and I was trying to reduce my test case to the
> minimum. If I had tried optimization and seen them removed, I would have
> expanded the test case.
The test case was fine. What I meant is that when I compiled with -O1, the
back end would emit b followed by a, which wouldn't show the problem because
emitting b would correctly send the .data even in the old code.
>
> 3. The goal that I am working toward is to have gcc and ld work correctly
> for the -msplit option in pdp11-aout. For that case, instructions and data
> are stored in separate, overlapping 64KB address spaces, so even if a
> variable is const it can't go in the .text section.
Yes. Ideally as/ld would support .rodata, but without that it has to be .data.
>...
> 5. Fixing the extra blank line for .globl is also good, but I was unsure why
> the code was as it is. Also I didn't figure out how there was a tab before
> .globl since it wasn't in the string constant.
The assembler doesn't actually care about any of that, so it's just a matter of
aiming for reasonable consistency to make the assembly code somewhat readable.
The code generator isn't all that consistent, but there isn't any reason for
that as far as I am aware.
>...
> 7. Emitting the zero-initialized variable into .data when it happens to
> follow a nonzero-initialized variable is also not correct, or at least
> suboptimal. If there is a vary large uninitialized array, that would make
> the final executable output file much larger. (OK, these days a full 64KB
> is still a pittance, but on principal it's suboptimal.) Therefore,
> switching to .bss in ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL is good.
Yes, if the assembler/linker supports that, but my understanding is that they
do not. It would be lovely if we could have ELF for pdp11...
---
On the linker option tied to -msplit, I haven't used this but the GCC Internals
manual gives the answer, in "18.2 Controlling the Compilation Driver, ‘gcc’" --
LINK_SPEC will do this.
[Bug debug/54508] Wrong debug information emitted if data members not referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508 --- Comment #4 from pkoning at gcc dot gnu.org 2012-10-23 18:44:33 UTC --- Author: pkoning Date: Tue Oct 23 18:44:27 2012 New Revision: 192739 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192739 Log: PR debug/54508 * dwarf2out.c (prune_unused_types_prune): If pruning a class and not all its children were marked, add DW_AT_declaration flag. * g++.dg/debug/dwarf2/pr54508.C: New. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug c/47214] New: False warning "null argument where non-null required"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47214 Summary: False warning "null argument where non-null required" Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 22926 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22926 Test program to show the issue I'm getting null argument warnings when there is an explicit test for non-null right before the statement that provokes the message. The attached test program shows this; when compiled with -Wall -O1 or -Wall -O2 you see two warnings. Both should be suppressed; the "for" end condition is the non-null test, and then in the second case there is an additional test right on the statement that is rejected as well.
[Bug c/47214] False warning "null argument where non-null required"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47214 --- Comment #2 from Paul Koning 2011-01-11 12:00:56 UTC --- Not if you look at that call in isolation, true. But right before it in the test program is a check that does exactly this.
[Bug c++/50189] New: Wrong code error in -O2 compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 Bug #: 50189 Summary: Wrong code error in -O2 compile, target independent Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 25105 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25105 Test program The attached test program compiles to wrong code with GCC 4.5.3 (and 4.5.1) when compiled -O2. GCC 4.6.1 gets it right. I did some digging and determined that the problem shows up in the -fdump-tree-all output in the .068t.vrp1 dump file; the preceding file (.067.mergephi2) is correct. In the generated code that corresponds to the check_pos method, the second compare "if (m_timestamp != a_timestamp)" is transformed into "if (3 == a_timestamp)". If m_timestamp were of time position_t (an enum of range 0..3) that would be correct, but m_timestamp is an unsigned int so it can, and in our application does, have values larger than 3.
[Bug c++/50189] Wrong code error in -O2 compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 --- Comment #1 from Paul Koning 2011-08-25 17:19:23 UTC --- Created attachment 25106 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25106 gcc -v output (configure options etc.
[Bug c++/50189] Wrong code error in -O2 compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 Paul Koning changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Paul Koning 2011-08-25 17:20:41 UTC --- I forgot to mention: the test program was run on Linux-i686, but the problem was originally discovered and also exists on a mips64-netbsdelf targeted gcc 4.5.1.
[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 --- Comment #6 from Paul Koning 2011-09-09 19:11:01 UTC --- I saw the note that PR/49911 is fixed and thought that might mean this one is fixed also. Unfortunately testing shows that is not the case, at least not in 4_5_branch.
[Bug c/50569] New: Wrong code error: memcpy eliminated when it is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569 Bug #: 50569 Summary: Wrong code error: memcpy eliminated when it is needed Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 25382 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25382 Test code that shows the issue This issue shows up in 4.6.1 but is not present in 4.5.1. The attached sample code picks up a buffer pointer from external data structures, copies a block of data to a temporary variable, and then references the temporary. GCC 4.6.1 optimized away the memcpy and instead directly references the original data, which is fine... except that the pointer is "char *" meaning that the data structure in that buffer is not necessarily aligned. And the references through that pointer are written as if the data IS aligned, so on my strict-alignment target (MIPS) I get an alignment exception. GCC 4.5.1 does it right -- it also optimizes away the memcpy but it accesses the original data using unaligned accesses.
[Bug c/50569] Wrong code error: memcpy eliminated when it is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569 Paul Koning changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/50569] Wrong code error: memcpy eliminated when it is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569 --- Comment #3 from Paul Koning 2011-09-29 19:52:47 UTC --- Created attachment 25383 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25383 Test case with main() Here is an updated testcase. This one runs to completion with 4.5.1, aborts with a bus error exception on 4.6.1. I compiled with -mabi=n32 -O1, but as far as I can tell from inspecting the generated code, the choice of ABI is not a factor.
[Bug middle-end/50569] Wrong code error: memcpy eliminated when it is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569 --- Comment #5 from Paul Koning 2011-09-29 20:55:15 UTC --- If the memcpy actually happens, that is the expected result. The issue in the MIPS case is that the memcpy is optimized away, and the source data accessed instead, which would be ok if GCC hadn't lost track of the fact that it's a char* pointer (and, in addition, that all the fields of the struct in question are defined as "packed").
[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 --- Comment #7 from Paul Koning 2011-10-10 20:41:35 UTC --- Re comment 5, does "works by luck" mean that I should not look in trunk for a fix to backport because nothing was actually fixed? Should I just avoid all versions of GCC newer than 4.4? The verdict "works by luck" frankly does not give me any comfort at all.
[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 --- Comment #10 from Paul Koning 2011-10-11 19:03:24 UTC --- Created attachment 25467 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25467 Tentative patch against 4.6.1 I chased the issue for a while, using 4.6.1 as the test version. The problem is in extract_range_from_assert. When processing < <= > >= assertions, it sets the min (for < <=) or max (for > >=) of the calculated range to be the type min or max of the right hand side. In the testcase, we have "m_timestamp > AT_END" where m_timestamp is unsigned int and AT_END is enum with value 2. The highest enum value of that enum type is 3, so if fstrict-enums is in effect, the type max is 3. Result: while the dump file shows the resulting range as [3,+INF] what that actually means is [3,3] because the upper bound of the enum is applied, *not* the upper bound of the variable being compared. The solution is for extract_range_from_assert to pick up type min or type max from the type of the left hand side (here m_timestamp, i.e., unsigned int). So the range still shows as [3,+INF] but now that represents [3,4294967295] and the resulting code is correct. The patch is just one line. The question I have is whether changing the way variable "type" is set is right, because it is also used in the != case and I don't fully understand that one.
[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189 --- Comment #12 from Paul Koning 2011-10-12 14:04:30 UTC --- You said "GCC treats types compatible when they have the same precision". That's where the problem lies, because enums with -fstrict-enums have their precision set to just enough bits to hold the range of values, rather than the precision of the base integer type. So in the test case in question, the variable's precision is 32 bits while the right hand side precision is 2 bits.
[Bug debug/49459] attribute((mode(byte))) in a typedef produces wrong debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459 Paul Koning changed: What|Removed |Added Known to fail||4.1.2 --- Comment #2 from Paul Koning 2011-10-19 17:00:09 UTC --- I see the same issue as far back as 4.1.2. As I mentioned, it works in 3.3.3. I compared readelf outputs. The difference is that in 3.3.3 the typedef points to a DW_TAG_base_type entry, which supplies the size of 1 -- but also makes the type look like "unsigned char" instead of enum. That at least doesn't break the debugger but it isn't ideal either. <1><6d>: Abbrev Number: 6 (DW_TAG_variable) <6e> DW_AT_name: foo <72> DW_AT_decl_file : 1 <73> DW_AT_decl_line : 4 <74> DW_AT_type: <0x3a> <78> DW_AT_external: 1 <79> DW_AT_location: 5 byte block: 3 1 0 0 0 (DW_OP_addr: 1) <1><3a>: Abbrev Number: 4 (DW_TAG_typedef) <3b> DW_AT_name: e1 <3e> DW_AT_decl_file : 1 <3f> DW_AT_decl_line : 1 <40> DW_AT_type: <0x44> <1><44>: Abbrev Number: 5 (DW_TAG_base_type) <45> DW_AT_name: (indirect string, offset: 0x0): unsigned char <49> DW_AT_byte_size : 1 <4a> DW_AT_encoding: 8(unsigned char)
[Bug c/51147] New: attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 Bug #: 51147 Summary: attribute((mode(byte))) on an enum generates wrong code Classification: Unclassified Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 25830 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25830 Test case file In an attempt to work around bug 49459, I tried putting attribute(mode_byte)) on the enum declaration (instead of on the typedef as in that bug). While that fixes the wrong debug output, it instead gives me seriously invalid code. The attached testcase shows the issue. The compiler appears to handle the functions foo and bar as if they return 1 unconditionally, so foo is called, bar is not, and test returns 1 unconditionally. Looking at the tree dump files, I see in the 001t.tu file something odd about the return type of foo() -- it is showing up as an enum (unsigned) whose min value is 0 and max value is -1. I'm not sure how that causes the specific failure but it makes me wonder. The mishandling of the function return values shows up right away (in the 003t.original dump file). The bug has been seen in 4.5.1 and 4.6.1. I also tried 3.3.3 because I happen to have it handy, but there the compiler crashes). A 4.1.2 compiler (stock gcc on my Linux) gets it wrong also, with the addition that it warns "Comparison is always true due to limited range of data type". 4.5.1 does not say so (not even with -Wall). All this is with -O2.
[Bug c/51147] attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 Paul Koning changed: What|Removed |Added Priority|P3 |P2 Known to fail||4.1.2, 4.5.1, 4.6.1 Severity|normal |major
[Bug c/51147] attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 --- Comment #2 from Paul Koning 2011-11-16 01:47:27 UTC --- Thanks, I'll give that a try for another workaround.
[Bug c/51147] attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 --- Comment #3 from Paul Koning 2011-11-18 11:49:56 UTC --- That workaround seems to do the right thing for what I need, so I'm no longer stuck. Thanks for the suggestion.
[Bug target/88435] Compiling with optimizations causes the compiler to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88435 --- Comment #2 from pkoning at gcc dot gnu.org --- I don't see it in the current V9, rev 266823. ./xgcc -B. -O2 -S ~/Documents/pr88435.c -m10 cat pr88435.s .text .even .globl _pollConsole _pollConsole: mov @$-0220,r0 mov $011,r1 L_4: clc ror r0 dec r1 bne L_4 bic $-02,r0 rts pc Clearly this is not optimal -- it shouldn't do this with a shift but rather using a "BIT" instruction. But the code does produce the correct answer and the compiler doesn't fail.
[Bug target/69639] [6/7/8/9 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69639 pkoning at gcc dot gnu.org changed: What|Removed |Added CC||pkoning at gcc dot gnu.org --- Comment #10 from pkoning at gcc dot gnu.org --- I see this issue on my Mac (Mac OS 10.13.3, Apple LLVM version 9.1.0 (clang-902.0.39.1)). It shows up both for the native (x86) target, and the pdp11 target. But the behavior is very strange. If I create a new build directory, configure, make, then try compiling limits-exprparens.c, it works fine. If I then rebuild some files -- for example, by "touch config//.h; make" then the bug appears. This strangeness is reproducible. What's stranger is that doing a "make distclean; configure... ; make" also reproduces the problem; it doesn't make any sense for make distclean to be different from starting with a new empty directory, but it is.
[Bug c/85974] New: Failure to optimize difference of two pointers into a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974 Bug ID: 85974 Summary: Failure to optimize difference of two pointers into a compile time constant Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pkoning at gcc dot gnu.org Target Milestone: --- This issue is exposed by test case testsuite/gcc.c-torture/compile/930326-1.c, on platforms where ptrdiff_t is not "long" (such as pdp11). In that case, the last line: long i = s.f-&s.b; fails with "error: initializer element is not computable at load time". It's not a target bug; the problem can be reproduced for other targets by changing the "long" to "char" in that statement.
[Bug c/86271] New: ICE due to size mismatch when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86271 Bug ID: 86271 Summary: ICE due to size mismatch when inlining Product: gcc Version: 9.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 44308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44308&action=edit Test case for the issue The attached test program causes an ICE when compiled for Intel with -m32. Originally found in pdp11 target, this variant found by Richard Biener who suggested a PR.
[Bug c/86271] ICE due to size mismatch when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86271 --- Comment #1 from pkoning at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc/2018-06/msg00228.html is the discussion and mentions a possible fix.
[Bug target/30974] pdp11-dec-bsd will not successfully build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||pkoning at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from pkoning at gcc dot gnu.org --- Yes, I agree it should be closed. The target can still be resurrected if we want, that doesn't depend on having this bug open. (I don't see a "works as intended" resolution here; that's what I would apply since the drop of support for the bsd flavor was intentional and is documented.)
[Bug c/87794] New: Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87794 Bug ID: 87794 Summary: Excessive alignment permitted for functions and labels Product: gcc Version: 9.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 44922 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44922&action=edit variable and function alignment test case Variable alignment is checked against MAX_OFILE_ALIGNMENT but function and label (-falign-label=n) alignment is not. This causes requests to the target code to generate alignment directives that the output format doesn't support, causing ICE at least in some targets. The attached testalign.c gets an error (on i386) for variable "ag", and on pdp11 also for variable "a4" (since max alignment on pdp11 is 2 bytes). But the corresponding function alignments do not generate error messages. File testalign2.c with -falign-labels=n also passes the requested alignment to the back end without checking it against MAX_OFILE_ALIGNMENT.
[Bug c/87795] New: Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 Bug ID: 87795 Summary: Excessive alignment permitted for functions and labels Product: gcc Version: 9.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: --- Variable alignment is checked against MAX_OFILE_ALIGNMENT but function and label (-falign-label=n) alignment is not. This causes requests to the target code to generate alignment directives that the output format doesn't support, causing ICE at least in some targets. The attached testalign.c gets an error (on i386) for variable "ag", and on pdp11 also for variable "a4" (since max alignment on pdp11 is 2 bytes). But the corresponding function alignments do not generate error messages. File testalign2.c with -falign-labels=n also passes the requested alignment to the back end without checking it against MAX_OFILE_ALIGNMENT.
[Bug c/87795] Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 --- Comment #1 from pkoning at gcc dot gnu.org --- Created attachment 44923 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44923&action=edit variable and function alignment test case
[Bug c/87795] Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 --- Comment #2 from pkoning at gcc dot gnu.org --- Created attachment 44924 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44924&action=edit label alignment test case
[Bug c/87795] Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 --- Comment #6 from pkoning at gcc dot gnu.org --- (In reply to Joel Sherrill from comment #4) > I added myself as a CC because I want to see if these become errors or > warnings. For core parts of RTEMS, I can see wanting these to be errors > since it indicates we did something in core OS code that did not achieve the > desired results. But in application code, it might not be as well considered > or necessary. Interesting point. The current case that is rejected (alignment of variables) is an error, so for consistency I'd say the other cases should do likewise. If there is a desire to make too-large alignment into a warning, that might be better handled as a separate issue. It could be a switch of some sort. If changes are made, they should apply consistently to alignment of all kinds.
[Bug c/87944] New: Wrong code with LRA pushing stack local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944 Bug ID: 87944 Summary: Wrong code with LRA pushing stack local variable Product: gcc Version: 9.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 44977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44977&action=edit Dump file before reload I see this on pdp11, I haven't found a mainline target yet that reproduces it. The issue is on a call that passes the address of a local variable, with arguments pushed on the stack so effectively we get a push(frame_pointer). With frame pointer elimination, that becomes push(stack_pointer). But that's not a legal instruction on this machine, and I created constraints that say so. With the old reload, I see the intended result: copy SP to another register, then push that register. LRA instead adjusts the stack pointer by a word to make room for the argument, then copies the stack pointer to that spot. The result is that the argument is off by one word because it copied the SP after adjustment rather than generating the value before. The offending pdp11 code looks like this: add $-02,sp mov sp,(sp) jsr pc,_strlen what's wanted is something like this: mov sp,r0 mov r0,-(sp) I've seen variations of this issue in LRA; the common thread is that it doesn't aways account for changes in SP when calculating the SP offset for a local variable. I'll attach dump files that show the issue. The issue is with insn 12.
[Bug c/87944] Wrong code with LRA pushing stack local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944 --- Comment #1 from pkoning at gcc dot gnu.org --- Created attachment 44978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44978&action=edit Reload dump
[Bug c/87944] Wrong code with LRA pushing stack local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944 --- Comment #2 from pkoning at gcc dot gnu.org --- Created attachment 44979 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44979&action=edit Test program source
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 --- Comment #1 from pkoning at gcc dot gnu.org --- What is your target? I checked this on linux-x86_64 (native build). I don't see the complaint about line 15 in that run.
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 pkoning at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pkoning at gcc dot gnu.org --- Comment #3 from pkoning at gcc dot gnu.org --- Strange. I'll look.
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 --- Comment #5 from pkoning at gcc dot gnu.org --- Could you post the full config specification and what the build system is? It seems hard to reproduce, and it is rather puzzling for a powerpc build to trigger a check that is explicitly there for pdp11 only.
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332
--- Comment #9 from pkoning at gcc dot gnu.org ---
Comment? I thought the comment is the null string after the regexp to match.
Should it read { target { pdp11-*-* } } with the extra braces?
Other examples show up both with the braces and without, but the example in the
documentation is written without.
[Bug testsuite/88332] [9 regression] gcc.dg/Wattributes-10.c fails starting with r265728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88332 --- Comment #11 from pkoning at gcc dot gnu.org --- Thanks, I had forgotten. Seurer, could you update to r265741 or later and check if that cures the issue?
[Bug target/48990] New: MIPS wrong code error with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990 Summary: MIPS wrong code error with -O1 Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 24241 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24241 preprocessed file (trimmed a bit) that reproduces the bug The attached file compiles wrong code with -march=xlr -msoft-float -mabi=n32 -O1. It compiles correctly with -O2. The error shows up in basic block 3: the branch (beql $2,$0,$L10) has a li $4,32 in its delay slot. That clobbers $4 (A0) in the no-branch case, and A0 is still needed a few lines below. The bug is also present in GCC 4.5.1 In looking at the debug dumps, I see the problem introduced in the "mach" pass -- that pass builds a sequence insn for the branch and the load. I'll try 4.6.0 next.
[Bug target/48990] MIPS wrong code error with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990 --- Comment #1 from Paul Koning 2011-05-13 16:40:55 UTC --- GCC 4.6.0 gets it wrong also, in exactly the same way.
[Bug target/48990] MIPS wrong code error with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990 --- Comment #4 from Paul Koning 2011-05-13 18:16:11 UTC --- Re comment 2: Sorry, my typo, I incorrectly transcribed the .s file. It's a beq, not a beql.
[Bug target/48990] MIPS wrong code error with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990 --- Comment #3 from Paul Koning 2011-05-13 18:14:00 UTC --- The problem also shows up with -mabi=64, but it works correctly for -mabi=32 and -mabi=o64.
[Bug target/48990] MIPS wrong code error with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990 --- Comment #5 from Paul Koning 2011-05-13 18:20:42 UTC --- Created attachment 24242 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24242 Assembly output from -mabi=n32 case, GCC 4.5.1 Here is the assembly file (with -dA so basic block boundaries are marked). The offending instruction is the last one in BB 3; the instruction that requires the original value from A0 is the last one in BB 4.
[Bug target/48990] MIPS wrong code error with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990 --- Comment #6 from Paul Koning 2011-05-13 20:29:50 UTC --- Created attachment 24243 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24243 debug dump from the pass before machdep After some debugging, I see that the problem is that register 4 (A0) is marked dead in the prologue, and then afterwards is still used. This causes the delay slot fill logic to believe it can put li $4,32 into the delay slot -- because it appears not to be needed. So the question now is why that register is marked dead and still used.
[Bug target/48990] MIPS wrong code error with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48990 Paul Koning changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #7 from Paul Koning 2011-05-14 01:57:26 UTC --- It appears I misread the assembly output for 4.5.3. Applying the fix for PR/42775 to my 4.5.1 sources fixed this issue. *** This bug has been marked as a duplicate of bug 42775 ***
[Bug rtl-optimization/42775] [4.4 regression] GCC fails to rebuild itself with STAGE1_CFLAGS=-O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42775 Paul Koning changed: What|Removed |Added CC||pkoning at gcc dot gnu.org --- Comment #12 from Paul Koning 2011-05-14 01:57:26 UTC --- *** Bug 48990 has been marked as a duplicate of this bug. ***
[Bug target/41822] pdp11 code generation bug & temporary fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41822 Paul Koning changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.10.29 00:28:57 CC||pkoning at gcc dot gnu.org AssignedTo|unassigned at gcc dot |pkoning at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Paul Koning 2010-10-29 00:28:57 UTC --- Indeed that's wrong, thanks for the pinpoint diagnosis.
[Bug target/41822] pdp11 code generation bug & temporary fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41822 Paul Koning changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #2 from Paul Koning 2010-10-29 19:50:12 UTC --- Fixed in trunk (4.6.0 development sources), subversion rev 166073.
[Bug c/49459] New: attribute((mode(byte))) in a typedef produces wrong debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459 Summary: attribute((mode(byte))) in a typedef produces wrong debug information Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 24554 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24554 Test case The attached test case shows attribute((mode(byte))) used to produce enums that are one byte long rather than the usual 4. The compiler actually sees the correct value of sizeof() but GDB (7.2) does not. This can be seen by compiling the test case; gdb shows the value of s1 as 1, but sizeof(foo) as 4. When compiled with GCC 3.3.3, s1 and sizeof(foo) both show up as 1, as expected.
[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.
[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 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/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/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/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/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/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/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 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&action=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 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 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&action=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 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 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/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 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/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/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/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 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 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 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 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.
