https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109762
--- Comment #1 from Dave Murphy ---
Created attachment 55014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55014&action=edit
proposed patch
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: davem at devkitpro dot org
Target Milestone: ---
Created attachment 55013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55013&action=edit
prepr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #17 from Dave Murphy ---
(In reply to Jonathan Wakely from comment #16)
> I don't think the patch is sufficient, I think I had a complete one.
Shall I leave this or submit the patch I made as a starting point for review?
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davem at devkitpro dot org
Target Milestone: ---
The following code compiles fine as C but produces " error: 'idx' is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #12 from Dave Murphy ---
Naive patch based on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c7
gets my canadian crosses building.
diff --git a/libstdc++-v3/include/c_compatibility/fenv.h
b/libstdc++-v3/include/c_compatibility
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.
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: davem at devkitpro dot org
Target Milestone: ---
The following code produces an alignment exception on powerpc 750 and I presume
on other powerpc ISAs where unaligned floating
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=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 #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 #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 #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 #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 #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 #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
: 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=69706
--- Comment #7 from davem at gcc dot gnu.org ---
I'm leaning towards fixing both the ICE and the ABI bug.
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=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
--- 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=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
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=59758
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
--- Comment #10 from David S. Miller ---
Created attachment 32723
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32723&action=edit
Fix for libsanitizer build on sparc
This adjusted patch fixes the build for me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
--- Comment #9 from David S. Miller ---
The next problem you'll run into is that the shmid additions for sparc weren't
done correctly in the patch. Where you see 's64', it should be 'long', and
where you see 'u64' it should be 'unsigned long'.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
David S. Miller changed:
What|Removed |Added
CC||davem at davemloft dot net
--- Comment
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=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
--- 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=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 #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=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=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=43350
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last
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=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 #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 #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 #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 #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 #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 #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 #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 #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 #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=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=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=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=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
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
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=51920
davem at gcc dot gnu.org changed:
What|Removed |Added
CC||davem at gcc dot gnu.org
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=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=51251
--- Comment #3 from David S. Miller 2011-11-21
05:06:09 UTC ---
BTW, Joel, you might want to check out "-mdebug=options" :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51251
--- Comment #2 from David S. Miller 2011-11-21
05:05:02 UTC ---
I'll take a look at this. The branch prediction tags are guarded by either
TARGET_V9 or TARGET_ARCH64, but not TARGET_VIS.
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=50989
--- Comment #2 from David S. Miller 2011-11-03
21:53:54 UTC ---
Can you multiarch a 64-bit sparc build from 32-bit rtems?
Probably not... but if that were possible you'd need to
check host_address like we do for Linux.
So, change looks fine as-i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #55 from Dave Murphy 2011-10-29
23:27:02 UTC ---
(In reply to comment #54)
> I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson. It works
> for -march=armv4t and -march=armv5t, but not for -march=armv5te:
For what i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50683
--- Comment #6 from David S. Miller 2011-10-17
01:52:02 UTC ---
I would suggest against a gcc workaround, let's just fix binutils.
I have posted a fix to the binutils list for testing.
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=50655
--- Comment #3 from David S. Miller 2011-10-07
16:45:52 UTC ---
Thanks, I'll add the necessary register directives and work on making the
testcases conditional on assembler support.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655
--- Comment #1 from David S. Miller 2011-10-07
15:01:55 UTC ---
Please try to figure out why the configure test is not detecting VIS3
instruction capabilities in your assembler. That's why the VIS3 tests are
failing.
The combined-1.c test is no
--- Comment #7 from davem at davemloft dot net 2010-04-03 01:51 ---
Ok, once I straightened out all of the locale issues the abi_check
failure went away. Closing.
--
davem at davemloft dot net changed:
What|Removed |Added
--- Comment #5 from davem at davemloft dot net 2010-04-02 21:42 ---
I've double checked that I have the locales and everything installed.
I'm building a fixed setup now, and I validated that "gnu" instead of
"generic" is now choosen for the c++local
--- Comment #3 from davem at davemloft dot net 2010-04-02 20:25 ---
Sorry, I overlooked that I'd been building with --disable-nls, I'll
rebuild with --enable-nls and see how things look after that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43623
--- Comment #1 from davem at davemloft dot net 2010-04-02 01:02 ---
Created an attachment (id=20281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20281&action=view)
libstdc++ abi_check failure log on sparc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43623
bol differences.
--
Summary: FAIL: abi_check sparc
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davem at da
--- Comment #33 from davem at davemloft dot net 2010-03-25 18:51 ---
All of the GLIBC failures went away with this fix, thanks Jakub.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #26 from davem at davemloft dot net 2010-03-25 03:41 ---
I'll run this patch through my tests, thanks Jakub.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #19 from davem at davemloft dot net 2010-03-24 17:59 ---
Created an attachment (id=20186)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20186&action=view)
Distilled test case.
The expression that causes problems is:
if (__builtin_expect (integer, 0) &&a
--- Comment #17 from davem at davemloft dot net 2010-03-24 17:22 ---
I get the same two instruction change you saw with "0 &&" and it
makes the test pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #16 from davem at davemloft dot net 2010-03-24 17:08 ---
I'm trying to distill a test case currently and also something broke bootstrap
on sparc in the past day or two (I think it's the IRA change) which I want
to track down first.
I'll play with your patch
--- Comment #13 from davem at davemloft dot net 2010-03-24 16:55 ---
I'm not passing anything special to the build, just stock "-O2" with
a 32-bit compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #10 from davem at davemloft dot net 2010-03-24 06:43 ---
Created an attachment (id=20179)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20179&action=view)
source that emitted miscompiled function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #8 from davem at davemloft dot net 2010-03-24 06:02 ---
Created an attachment (id=20178)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20178&action=view)
miscompiled function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #7 from davem at davemloft dot net 2010-03-24 06:01 ---
Created an attachment (id=20177)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20177&action=view)
correctly compiled function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #6 from davem at davemloft dot net 2010-03-24 06:00 ---
In the regex cases, glibc/posix/regexec.c:merge_state_with_log() is what
gets miscompiled.
I will attach match_good.s and match_bad.s
match_good.s is a working compile of this function, using gcc-4.3.2
match_bad.s is
--- Comment #5 from davem at davemloft dot net 2010-03-24 03:01 ---
Yes, the failures mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01086.html
are the same exact ones I am seeing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
--- Comment #3 from davem at gcc dot gnu dot org 2010-03-23 20:40 ---
Sorry, it's taking a long time to sort out the test case. The
GLIBC regex code is huge and non-trivial.
However I did track down that it might be dependent upon optimization
options, for example I can reproduce
glibc regex testsuite failures
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davem at gcc dot gnu dot org
GCC build tr
--- Comment #19 from davem at gcc dot gnu dot org 2010-03-12 21:00 ---
Like Eric I'm still seeing this fail on mainline on 32-bit sparc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
--- Comment #13 from davem at gcc dot gnu dot org 2010-03-12 20:58 ---
I'm still seeing this fail on 32-bit sparc with mainline:
home/davem/src/GIT/GCC/gcc/gcc/testsuite/gcc.dg/pr34668-2.c: In function
'set_conv_libfunc':
/home/davem/src/GIT/GCC/gcc/gcc/testsuite/gcc.d
--- Comment #3 from davem at gcc dot gnu dot org 2010-02-10 00:49 ---
I've root caused this to the Linux kernel not 16-byte aligning thread
stacks when using the clone() system call (it was enforcing only 8-byte
alignment), and also signal stacks.
The seconday mem TFmode stack slo
--- Comment #2 from davem at gcc dot gnu dot org 2010-02-09 22:13 ---
Reading further, the Sparc 64-bit ABI requires that the every stack frame
be 16 byte aligned. And if that were the case this problem would never
happen.
Will try to determine how the stack is becomming only 8-byte
--- Comment #1 from davem at gcc dot gnu dot org 2010-02-09 22:08 ---
Ok, I now know a lot more about this bug. It's effects were masked
before gcc-4.4 because we used to have the TFmode secondary reload
slot in every stack frame. That got removed by my commit:
2009-01-04 Da
iority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davem at gcc dot gnu dot org
GCC build triplet: sparc-unknown-linux-gnu
GCC host triplet: sparc-unknown-linux-gnu
GCC target triplet: sparc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43004
1 - 100 of 105 matches
Mail list logo
