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
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.
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
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.
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
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.
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 e
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.
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
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 ove
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
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.
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
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
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last
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
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
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
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.
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
rem
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=gcc&view=rev&rev=193283
Log:
Revert sparc "
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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=gcc&view=rev&rev=179667
Log:
Fix VIS3 assembler c
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=gcc&view=rev&rev=180982
Log:
Fix sparc regression due to rece
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()
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
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
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 :-/
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 simpl
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.
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 store
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_R
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 s
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=gcc&view=rev&rev=187120
Log:
Fix long double float miscompila
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=gcc&view=rev&rev=187124
Log:
Fix long double float miscompila
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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=gcc&view=rev&rev=187675
Log:
Fix VIS3 vector shift wr
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
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
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
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=gcc&view=rev&rev=181598
Log:
Revert regression causing ch
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
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.
: 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&action=edit
Distilled test case exh
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&root=gcc&view=rev
Log:
sparc: Fix stack references in return delay sl
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&root=gcc&view=rev
Log:
sparc: Fix stack references in return delay sl
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&root=gcc&view=rev
Log:
gcc/
PR target/80968
* config/sparc
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&root=gcc&view=rev
Log:
sparc: Fix stack references in return delay sl
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&root=gcc&view=rev
Log:
sparc: Further adjustments for alloca epilogue blocka
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&root=gcc&view=rev
Log:
sparc: Further adjustments for alloca epilogue blocka
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&root=gcc&view=rev
Log:
More refinements to fixing sparc's PR targe
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&root=gcc&view=rev
Log:
More refinements to fixing sparc's PR
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.
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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
60 matches
Mail list logo
