--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
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=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=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=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=51251
--- Comment #3 from David S. Miller 2011-11-21
05:06:09 UTC ---
BTW, Joel, you might want to check out "-mdebug=options" :-)
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 #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
--- 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 #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 #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
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=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
--- 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.
25 matches
Mail list logo
