[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #12 from davem at gcc dot gnu.org --- I think that case vector stuff was written by Richard Henderson FWIW.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #8 from davem at gcc dot gnu.org --- I cannot think of any specific reason why the jump tables were put into the text section. I even tried to consider relocation ramifications. Maybe this makes GOT OP linker optimizations more likely when -fPIC?
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #10 from davem at gcc dot gnu.org --- Author: davem Date: Mon Jun 12 19:32:49 2017 New Revision: 249135 URL: https://gcc.gnu.org/viewcvs?rev=249135=gcc=rev Log: More refinements to fixing sparc's PR target/80968. PR target/80968 * config/sparc/sparc.md (return expander): Emit frame blockage if function uses alloca. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/sparc/sparc.md
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #9 from davem at gcc dot gnu.org --- Author: davem Date: Mon Jun 12 19:30:45 2017 New Revision: 249134 URL: https://gcc.gnu.org/viewcvs?rev=249134=gcc=rev Log: More refinements to fixing sparc's PR target/80968. gcc/ PR target/80968 * config/sparc/sparc.md (return expander): Emit frame blockage if function uses alloca. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #8 from davem at gcc dot gnu.org --- Author: davem Date: Fri Jun 9 19:24:51 2017 New Revision: 249074 URL: https://gcc.gnu.org/viewcvs?rev=249074=gcc=rev Log: sparc: Further adjustments for alloca epilogue blockage. gcc/ PR target/80968 * config/sparc/sparc.c (sparc_flat_expand_epilogue): Don't emit frame blockage here. (sparc_expand_epilogue): Do it here. * config/sparc/sparc.md (return expander): Emit frame blockage for alloca here too. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/sparc/sparc.c branches/gcc-6-branch/gcc/config/sparc/sparc.md
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #7 from davem at gcc dot gnu.org --- Author: davem Date: Fri Jun 9 19:21:15 2017 New Revision: 249072 URL: https://gcc.gnu.org/viewcvs?rev=249072=gcc=rev Log: sparc: Further adjustments for alloca epilogue blockage. gcc/ PR target/80968 * config/sparc/sparc.c (sparc_flat_expand_epilogue): Don't emit frame blockage here. (sparc_expand_epilogue): Do it here. * config/sparc/sparc.md (return expander): Emit frame blockage for alloca here too. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sparc/sparc.c branches/gcc-5-branch/gcc/config/sparc/sparc.md
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #5 from davem at gcc dot gnu.org --- Author: davem Date: Tue Jun 6 18:54:55 2017 New Revision: 248931 URL: https://gcc.gnu.org/viewcvs?rev=248931=gcc=rev Log: sparc: Fix stack references in return delay slot. gcc/ PR target/80968 * config/sparc/sparc.c (sparc_expand_prologue): Emit frame blockage if function uses alloca. gcc/testsuite/ * gcc.target/sparc/sparc-ret-3.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sparc/sparc.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #4 from davem at gcc dot gnu.org --- Author: davem Date: Tue Jun 6 18:52:22 2017 New Revision: 248930 URL: https://gcc.gnu.org/viewcvs?rev=248930=gcc=rev Log: gcc/ PR target/80968 * config/sparc/sparc.c (sparc_expand_prologue): Emit frame blockage if function uses alloca. gcc/testsuite/ * gcc.target/sparc/sparc-ret-3.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/sparc/sparc.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #3 from davem at gcc dot gnu.org --- Author: davem Date: Tue Jun 6 18:42:52 2017 New Revision: 248929 URL: https://gcc.gnu.org/viewcvs?rev=248929=gcc=rev Log: sparc: Fix stack references in return delay slot. gcc/ PR target/80968 * config/sparc/sparc.c (sparc_expand_prologue): Emit frame blockage if function uses alloca. gcc/testsuite/ * gcc.target/sparc/sparc-ret-3.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/sparc/sparc.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #2 from davem at gcc dot gnu.org --- Author: davem Date: Tue Jun 6 17:02:22 2017 New Revision: 248926 URL: https://gcc.gnu.org/viewcvs?rev=248926=gcc=rev Log: sparc: Fix stack references in return delay slot. gcc/ PR target/80968 * config/sparc/sparc.c (sparc_expand_prologue): Emit frame blockage if function uses alloca. gcc/testsuite/ * gcc.target/sparc/sparc-ret-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/testsuite/ChangeLog
[Bug target/80968] New: [SPARC] Stack frame reference allowed in delay slot of return instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 Bug ID: 80968 Summary: [SPARC] Stack frame reference allowed in delay slot of return instruction. Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: davem at gcc dot gnu.org Target Milestone: --- Created attachment 41467 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41467=edit Distilled test case exhibiting return delay slot bug. When alloca() is used, gcc can allow a reference to that memory in the delay slot of a return instruction which deallocates that stack frame. This was seen in lib/libcrc32c.c:crc32c() in the Linux kernel. If an interrupt arrives exactly at that delay slot load instruction the value can be corrupted. A distilled version of that code is attached. When compiled with "-m64 -O2" you will see something like: sub %sp, %g1, %sp add %sp, 2230, %i5 and %i5, -8, %i5 ... return %i7+8 lduw [%o5+16], %o0 Seems like we need something like stack tie pattern like other backends use to block code movement like this, and emit it right before the epilogue sequence.
[Bug target/69706] internal compiler error: in extract_constrain_insn, at recog.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706 --- Comment #7 from davem at gcc dot gnu.org --- I'm leaning towards fixing both the ICE and the ABI bug.
[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622 --- Comment #4 from davem at gcc dot gnu.org --- I've decided the revert LRA support for now. Debugging this failure is going to be extremely time consuming, and in the meantime it's better to have the build working properly.
[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622 davem at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from davem at gcc dot gnu.org --- Trunk should be bootstrapping properly again.
[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622 --- Comment #3 from davem at gcc dot gnu.org --- I can reproduce and am looking into this, thanks.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 davem at gcc dot gnu.org changed: What|Removed |Added CC||davem at gcc dot gnu.org --- Comment #2 from davem at gcc dot gnu.org --- Can you contribute something other than a knee-jerk reactionary posting of that submission rules URL? Those requirements are entirely impractical. I checked things in directly to the gcc repo because a sparc gcc-4.9 build failure persisted for 9 months, which is proof that this proceedure for sanitizer development is completely not tenable. A sanitizer developer was CC:'d on the gcc bugzilla in question, and I even posted a working version of that developers patch and attached it to that bug. Nothing was done for 4 months after that. After consulting with Richard Henderson I just checked it in. And I will continue to do the same in the future, I apologize in advance if fixing the build in gcc after waiting for upstream to do something about it for months upsets you.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #4 from davem at gcc dot gnu.org --- You cannot have it both ways. If you demand people go through upstream, you have to be responsive to fixing build failures yourselves. Because it is the sanitizer developers who introduced this build failure that stood for 9 months in a release of gcc. This current situation is completely unacceptable, and if you are going to get into a commit war with me when I am simply trying to fix the build which you both broke and refused to fix for 9+ months, that's extremely anti-social and demonstrates how the current situation is not working and is bad for gcc development overall.
[Bug sanitizer/59758] [4.9/5 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758 davem at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from davem at gcc dot gnu.org --- Fixed in 4.9 branch and the trunk.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #28 from davem at gcc dot gnu.org 2012-11-07 08:42:17 UTC --- Author: davem Date: Wed Nov 7 08:42:09 2012 New Revision: 193283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193283 Log: Revert sparc U constraint removal. PR bootstrap/55211 Revert: * config/sparc/constraints.md (U): Delete. * config/sparc/sparc.md: Use 'r' constraint instead of 'U'. * config/sparc/sync.md: Likewise. And revert parts of: * doc/md.texi: Sync sparc constraint documentation with reality. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/constraints.md trunk/gcc/config/sparc/sparc.md trunk/gcc/config/sparc/sync.md trunk/gcc/doc/md.texi
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 davem at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #29 from davem at gcc dot gnu.org 2012-11-07 08:45:02 UTC --- Fixed in mainline.
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 --- Comment #3 from davem at gcc dot gnu.org 2012-11-06 18:00:30 UTC --- Unfortunately I'm not familiar enough with the i386 backend to say whether the situation is identical there for x32 code generation. But if it were the case, it would not surprise me.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #24 from davem at gcc dot gnu.org 2012-11-06 18:07:46 UTC --- On several occasions, in both public and private emails, I have in fact expressed my displeasure with how the configure system and the sparc backend treat things based upon the target triplet. I've always, and consistently, expressed my position that when configure sees plain sparc gcc should generate 32-bit code by default. And when it sees sparc64 it should generate 64-bit code by default. Finally, I've always stated that there should be an easy way to modify this default (after installation) on a system wide basis (f.e. via a file under sysroot). Back to the bug. I do builds with --with-cpu=niagara4 so that more of the VIS patterns and new code gets exercised. Among other things, this changes the heuristics for various things like block moves. This unaligned load is part of a block move resulting from a structure copy. In any event, I can reproduce it by using --with-cpu=v8, so I can debug it properly. I hope to have this fixed by the end of today.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #25 from davem at gcc dot gnu.org 2012-11-06 22:32:40 UTC --- Just an update. I know what the exact problem is. Actually it's a combination of things. Because of the way that IRA maintains it's hard reg sets, it can end up thinking that odd integer registers are legitimate to allocate for DImode values. Specifically, when an allocno's -profitable_regs is populated, it sets bits for both registers in a DImode pair (actually this happens when populating ira_useful_class_mode_regs[][], which in turn get copied into the initial value of -profitable_regs). Then during allocation, the bits are tested individually. So say that all the integer register pairs are set in the profitable_regs reg set. Then %o0 is allocated for an SImode value. IRA thinks that it's ok to allocate %o1 for a DImode pseudo because %o1 and %o2 are set in the hard register set. Even if the above problem is solved, the next problem we run into has to do with argument passing. Normally if we have something like (set (reg:DI %o1) ...) it will get split up into two SImode moves. But this cannot happen if the SET_SRC is a non-offsetable MEM. We relied upon the constraint that got removed to force a reload in this situation. I am going to do one of two possible things tonight to solve this. I'll either create a new register class for these even DImode hard regs, or I'll simply revert my change.
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 --- Comment #6 from davem at gcc dot gnu.org 2012-11-07 05:44:52 UTC --- That's basically what -m32 -mcpu=v9 is Jan. The compiler just isn't taking advantage of it as well as it can due to how the sparc backend is designed. We have access to 16 64-bit registers at all times. Please, drop this discussion, when I get a large block of time I'll work on improving the sparc backend in this area. This discussion is just consuming my time and making it take longer for me to get to that task. Thanks.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #26 from davem at gcc dot gnu.org 2012-11-07 07:11:44 UTC --- Ok, it seems it is not possible to expression the even integer register condition using register classes. Therefore I will revert the U constraint removal. I tried creating a DI32_REGS register class that only contained the even integer registers. But this doesn't work because the test of whether a hard register is within a class requires that all of the registers that are a part of the DImode register pair are in the class. So you'd need to include both the even and odd registers, which defeats the entire point of trying to express this using a register class. Longer term we do need a fix for this. It is very clear that IRA is allocating odd registers at times for DImode pseudos on 32-bit, and the only reason it works is that things get fixed up later by either reload or the DImode splitters. If we extended define_register_constraint such that extra conditions could be specified, we could get IRA to do the right thing and also have reload fix up the unavoidable cases where we must use odd numbered registers for DImode values on 32-bit such as argument passing.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #5 from davem at gcc dot gnu.org 2012-11-05 18:22:17 UTC --- I'm really surprised to see the integer ldd/std patterns matching in a 64-bit build.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #6 from davem at gcc dot gnu.org 2012-11-05 18:24:11 UTC --- Oh I see, you're forcing v8 in the configure line. It's so much easier to sparc32 bash before running configure so that the build/host/target ends up being correct and not sparc64-something.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #8 from davem at gcc dot gnu.org 2012-11-05 19:16:14 UTC --- Thanks for tracking this down, I'll fix or revert.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #9 from davem at gcc dot gnu.org 2012-11-05 21:38:40 UTC --- I'm having a hard time reproducing this, I've tried 32-bit bootstraps with several variations of your listed configure command line. But meanwhile I want some clarification on your environment. Is uname outputting sparc or sparc64 when you run configure? It really needs to be the former if you are telling the compiler to output 32-bit code by default (which is what --with-cpu=v8 does). Thanks.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #12 from davem at gcc dot gnu.org 2012-11-05 21:50:38 UTC --- That configuration doesn't make any sense. It's going to pass -m64 down into the libgcc2 build, then the internal --with-cpu=v8 setting is going to override all that. The correct thing to do is to execute configure in the correct environment, or pass an explicit build triplet.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #14 from davem at gcc dot gnu.org 2012-11-05 22:04:10 UTC --- The bug does not trigger using that var-tracking test file using a properly configures 32-bit compiler, I just checked. This sparc64+--with-cpu=v8 is not a legal configuration, it worked by luck and duct-tape previously.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #17 from davem at gcc dot gnu.org 2012-11-05 22:21:32 UTC --- If sparc+--with-cpu=v8 and sparc64+--with-cpu=v8 were equal then my build would trigger the problem too :-) I'll look more deeply into this, thanks Eric.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #19 from davem at gcc dot gnu.org 2012-11-06 01:43:40 UTC --- I always use --enable-targets=all
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #20 from davem at gcc dot gnu.org 2012-11-06 01:44:09 UTC --- Eric, I checked, and that is not how Debian builds their gcc. They build with sparc-unknown-linux as the triplet. So they configure their compiler correctly, and I still contend that nobody should use this sparc64+--with-cpu=v8 thing. davem@patience:~/src/GIT/GCC/build-sparc64-linux/gcc$ /usr/lib/gcc/sparc-linux-gnu/4.6.3/cc1plus -version GNU C++ (Debian 4.6.3-8) version 4.6.3 (sparc-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 C-c C-c davem@patience:~/src/GIT/GCC/build-sparc64-linux/gcc$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6/lto-wrapper Target: sparc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-8' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-8) davem@patience:~/src/GIT/GCC/build-sparc64-linux/gcc$
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #21 from davem at gcc dot gnu.org 2012-11-06 01:49:28 UTC --- And now I remember more about this. They did that utterly stupid sparc64+--with-cpu=v8 thing exactly because --enable-targets=all didn't exist for sparc way back when. Then I added support for --enable-targets=all, so they didn't need to do that senseless configuration to get what they want.
[Bug bootstrap/55211] [4.8 regression] sparc64-linux bootstrap fails with SIGILL while compiling __mulvti3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211 --- Comment #22 from davem at gcc dot gnu.org 2012-11-06 04:15:21 UTC --- Ok IRA is where the allocation of %o1 for DImode is performed. I'll try to figure out why it isn't consulting HARD_REGNO_MODE_OK to validate this choice.
[Bug target/43350] sparcv9 mode does not seem to produce LDX/STX insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350 davem at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2012-11-06 Ever Confirmed|0 |1 --- Comment #1 from davem at gcc dot gnu.org 2012-11-06 04:23:51 UTC --- The problem is that the compiler is very constrained about how it can or cannot use 64-bit operations in 32-bit v9 mode. When we do use 64-bit instructions, we do so in a very hackish way in 32-bit mode. We first allocate a safe 64-bit register (the OS only guarentees that %o0-%o7 and %g1-%g7 integer registers will have their full 64-bits saved if a trap or context switch occurs) and then we construct the 64-bit value from the 2 32-bit source operand pieces of each 64-bit input. Then we decompose the 64-bit safe register back into the 32-bit components of the output. We have some tricks and a very simplistic data flow analyzer that allows avoiding some aspects of the above work. This is suboptimal, but what it means is that by the time we do moves, we have the 64-bit values in 32-bit component registers, so stx/ldx isn't really an option. The basic issue is that it's an enormous task exposing to the compiler that we really can do full 64-bit operations in these registers. That is a huge amount of delicate work, and therefore this is really a feature request rather than a bug report, so I'm closing this.
[Bug target/51106] [4.6 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106 davem at gcc dot gnu.org changed: What|Removed |Added CC||davem at gcc dot gnu.org --- Comment #20 from davem at gcc dot gnu.org 2012-10-27 23:08:50 UTC --- This issue still exists in mainline, there seems to be no objection to Andrey's suggested fix, could someone please commit it?
[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 davem at gcc dot gnu.org changed: What|Removed |Added CC||davem at gcc dot gnu.org --- Comment #10 from davem at gcc dot gnu.org 2012-10-09 16:40:45 UTC --- This happens on sparc too, I'm doing a test bootstrap with your patch right now.
[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 --- Comment #11 from davem at gcc dot gnu.org 2012-10-09 17:12:25 UTC --- I can confirm that the patch fixes the sparc bootstrap.
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 --- Comment #4 from davem at gcc dot gnu.org 2012-05-19 06:19:16 UTC --- Author: davem Date: Sat May 19 06:19:10 2012 New Revision: 187675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187675 Log: Fix VIS3 vector shift wrong code generation on sparc. Backport r185385 from mainline. 2012-03-14 Richard Guenther rguent...@suse.de PR middle-end/52584 * tree-vect-generic.c (type_for_widest_vector_mode): Take element type instead of mode, use build_vector_type_for_mode instead of the langhook, build a vector of proper signedness. (expand_vector_operations_1): Adjust. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-generic.c
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #11 from davem at gcc dot gnu.org 2012-05-03 22:19:42 UTC --- Author: davem Date: Thu May 3 22:19:35 2012 New Revision: 187120 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187120 Log: Fix long double float miscompilations on sparc 64-bit. PR target/52684 * config/sparc/sparc.c (emit_soft_tfmode_libcall): If we pass a MEM directly into a libcall, mark it's MEM_EXPR as addressable. (sparc_emit_float_lib_cmp): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #12 from davem at gcc dot gnu.org 2012-05-03 22:34:41 UTC --- Author: davem Date: Thu May 3 22:34:34 2012 New Revision: 187124 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187124 Log: Fix long double float miscompilations on sparc 64-bit. PR target/52684 * config/sparc/sparc.c (emit_soft_tfmode_libcall): If we pass a MEM directly into a libcall, mark it's MEM_EXPR as addressable. (sparc_emit_float_lib_cmp): Likewise. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sparc/sparc.c
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 davem at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from davem at gcc dot gnu.org 2012-05-03 22:54:33 UTC --- Fixed in mainline and the 4.7 branch.
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #6 from davem at gcc dot gnu.org 2012-05-02 07:01:24 UTC --- Created attachment 27283 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27283 Simplest test case. Build with -O1 -ffloat-store -m64 on sparc This is the most simplest test case which generates a long double soft-fp libcall on sparc64, and DSE erroneously eliminates the stores that setup the arguments.
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #7 from davem at gcc dot gnu.org 2012-05-02 07:01:52 UTC --- Created attachment 27284 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27284 DSE debugging dump of t1.c testcase.
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #8 from davem at gcc dot gnu.org 2012-05-02 07:23:56 UTC --- I can't see how the current DSE code can properly handle this case, and I'm surprised this doesn't trigger more often. The outgoing args are stored to offsets of FRAME_POINTER_REGNUM, even though this is before reload. This causes DSE to set -frame_related However I can't see anything that takes into account that these locations in the frame are read by the CALL_INSN. There is some weird commentary in the description of the insn_info-frame_read field in dse.c which talks about how the stores related to outgoing arguments are stack pointer based and thus deemed of non-constant base in this pass but as explained above that is simply not true here.
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #9 from davem at gcc dot gnu.org 2012-05-02 08:09:46 UTC --- Ok, after further study, I think I'm going to propose to fix this in DSE as follows. When we see a CALL in dse.c:scan_insn(), if FRAME_POINTER_REGNUM == ARG_POINTER_REGNUN then we will set insn_info-frame_read to true. A quick test shows that this is sufficient to avoid the erroneous store removals.
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #10 from davem at gcc dot gnu.org 2012-05-03 05:18:11 UTC --- Created attachment 27298 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27298 Proposed fix. It turns out to in the end be a sparc specific problem. This makes sure, in the sparc backend, that we mark the MEM_EXPR of a MEM addressable if we pass it directly into a libcall.
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684
--- Comment #3 from davem at gcc dot gnu.org 2012-05-01 22:27:11 UTC ---
Sadly, the bug is even more severe.
Even something as simple as:
long double f(long double a, long double b)
{
return a + b;
}
will be miscompiled with -O1 -ffloat-store on 64-bit. The problem
is that the call instructions emitted lack the reg use notes so that
the compiler can see the stack frame inputs to the libcall. Strangely,
the notes are created properly on 32-bit.
Then DSE thinks that the stack stores can be eliminated and proceeds
to kill those insns off.
Also, code generation is significantly better with -ffloat-store
enabled. If you don't believe me, see for yourself.
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #4 from davem at gcc dot gnu.org 2012-05-01 22:44:08 UTC --- Ok, I see why 32-bit works. On 32-bit we use real libfuncs in the optabs, so the compiler can see all the typing information and emit the proper information to stick into the CALL_INSN_FUNCTION_USAGE lists. But when we emit soft TFmode libcalls by hand, as on 64-bit, this information is lost. So DSE has nothing to work with and can't see that the temporary stack slots are inputs to the libcall. We'll have to tack on our own reg use notes by hand in functions like emit_soft_tfmode_libcall() and sparc_emit_float_lib_cmp().
[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #5 from davem at gcc dot gnu.org 2012-05-01 23:12:46 UTC --- Strange, I added code to tack the function usage information onto TFmode libcalls, but DSE still removes the stack slot stores :-/
[Bug target/52684] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 --- Comment #1 from davem at gcc dot gnu.org 2012-04-29 20:48:49 UTC --- Created attachment 27263 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27263 Testcase distilled from glibc's math/libm-test.inc compare_float_internal() This is distilled from glibc's math/libm-test.inc:compare_float_internal() when built for long double. The problem is that, with -ffloat-store, the compiler eliminates the stores into the stack that setup the stack slots for the arguments passed into _Qp_div().
[Bug target/52684] New: glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 Bug #: 52684 Summary: glibc long double math tests fail on sparc 64-bit Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@gcc.gnu.org When built with gcc-4.7, several glibc long double math tests fail on 64-bit sparc. This might be more fallout from the rewrite of the sparc movcc patterns, but that's just a hunch.
[Bug target/52684] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 davem at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-23 Ever Confirmed|0 |1
[Bug target/51920] 64-bit gcc.target/sparc/vec-init-1-vis1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51920 davem at gcc dot gnu.org changed: What|Removed |Added CC||davem at gcc dot gnu.org --- Comment #1 from davem at gcc dot gnu.org 2012-01-20 18:59:11 UTC --- Strange, I would expect a compiler error rather then it emitting an invalid odd register. The output operand of all insns generating 'fpmerge' only accept the proper 'e' constraint.
[Bug testsuite/51251] conflicting -mcpu switches during testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51251 --- Comment #9 from davem at gcc dot gnu.org 2011-11-21 19:11:56 UTC --- In addition to the comments so far about what the testsuite framework should be doing, I also think the sparc option processing is currently doing the right thing given the input seen here. If you say -mcpu=cypress -mvis which is what the command line amounts to, it meant to enable VIS and that requires turning on V9 also which is what the option processing in the sparc backend does.
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #21 from davem at gcc dot gnu.org 2011-11-21 21:50:46 UTC --- Author: davem Date: Mon Nov 21 21:50:41 2011 New Revision: 181598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181598 Log: Revert regression causing changes to store_bit_field_1. Revert 2011-11-16 Andreas Krebbel andreas.kreb...@de.ibm.com PR middle-end/50325 * expmed.c (store_bit_field_1): Use extract_bit_field on big endian targets if the source cannot be exactly covered by word mode chunks. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c
[Bug target/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #17 from davem at gcc dot gnu.org 2011-11-04 20:26:07 UTC --- Author: davem Date: Fri Nov 4 20:25:59 2011 New Revision: 180982 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180982 Log: Fix sparc regression due to recent movcc pattern changes. PR target/49965 * config/sparc/sparc.c (sparc_expand_conditional_move): Handle the fact that sparc_emit_float_lib_cmp modifies the comparison in operands[1]. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c
[Bug target/50655] Many of the new VIS2/VIS3 tests FAIL on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655 --- Comment #5 from davem at gcc dot gnu.org 2011-10-07 17:23:53 UTC --- Author: davem Date: Fri Oct 7 17:23:47 2011 New Revision: 179667 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179667 Log: Fix VIS3 assembler check and conditionalize testsuite on VIS3 support. gcc/ PR 50655 * configure.ac: Add .register directives to VIS3 test. * configure: Regenerate. gcc/testsuite/ PR 50655 * gcc.target/sparc/sparc.exp: Add vis3 target test. * gcc.target/sparc/cmask.c: Use it. * gcc.target/sparc/fhalve.c: Likewise. * gcc.target/sparc/fnegop.c: Likewise. * gcc.target/sparc/fpadds.c: Likewise. * gcc.target/sparc/fshift.c: Likewise. * gcc.target/sparc/fucmp.c: Likewise. * gcc.target/sparc/lzd.c: Likewise. * gcc.target/sparc/vis3misc.c: Likewise. * gcc.target/sparc/xmul.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sparc/cmask.c trunk/gcc/testsuite/gcc.target/sparc/fhalve.c trunk/gcc/testsuite/gcc.target/sparc/fnegop.c trunk/gcc/testsuite/gcc.target/sparc/fpadds.c trunk/gcc/testsuite/gcc.target/sparc/fshift.c trunk/gcc/testsuite/gcc.target/sparc/fucmp.c trunk/gcc/testsuite/gcc.target/sparc/lzd.c trunk/gcc/testsuite/gcc.target/sparc/sparc.exp trunk/gcc/testsuite/gcc.target/sparc/vis3misc.c trunk/gcc/testsuite/gcc.target/sparc/xmul.c
