http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
--- Comment #49 from gcc at breakpoint dot cc 2010-06-28 11:18 ---
>Modified:
>trunk/gcc/ChangeLog
>trunk/gcc/caller-save.c
>trunk/gcc/config/rs6000/e500.h
Is it possible to get this into the 4.4 and 4.5 branch as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=443
--- Comment #48 from amodra at gcc dot gnu dot org 2010-06-22 10:44 ---
Subject: Bug 44364
Author: amodra
Date: Tue Jun 22 10:44:11 2010
New Revision: 161163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161163
Log:
PR target/44364
* config/rs6000/e500.h (HARD_R
--- Comment #47 from Kyle dot D dot Moffett at boeing dot com 2010-06-21
15:55 ---
(In reply to comment #41)
> Created an attachment (id=20877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view) [edit]
> e500.h and caller-save.c patch
>
> The ICE in #38 is due to a
--- Comment #46 from harry dot he at freescale dot com 2010-06-11 01:09
---
Mark, I have reported the issue to CodeSourcery and waiting them to confirm, I
guess our toolchain may need different patches for it, or there is something
wrong in my validation.
--
harry dot he at freescal
--- Comment #45 from mark dot workman at acm dot org 2010-06-10 17:43
---
(In reply to comment #40)
> with my toolchain (From CodeSourcery, 4.4-78), o1test gives correct behavior
> with built-in flags(-te500v2), but wrong behaviors with "-fcaller-saves -O
> -fno-omit-frame-pointer -fno-
--- Comment #44 from harry dot he at freescale dot com 2010-06-10 09:03
---
Thanks for your reminding, Mark.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #43 from mark dot workman at acm dot org 2010-06-09 14:07
---
(In reply to comment #39)
> Hi, Kyle Moffett,
> in testall.c, r9 is used by a register variable, however, in E500ABI
> guide,
> r9 should be used for parameter passing, this test case seems not reasonable.
>
--- Comment #42 from gcc at breakpoint dot cc 2010-06-09 13:52 ---
(In reply to comment #41)
> The ICE in #38 is due to a bug in caller-save.c
Thank you for the very quick fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #41 from amodra at gmail dot com 2010-06-09 13:26 ---
Created an attachment (id=20877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view)
e500.h and caller-save.c patch
The ICE in #38 is due to a bug in caller-save.c
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #40 from harry dot he at freescale dot com 2010-06-09 09:23
---
with my toolchain (From CodeSourcery, 4.4-78), o1test gives correct behavior
with built-in flags(-te500v2), but wrong behaviors with "-fcaller-saves -O
-fno-omit-frame-pointer -fno-dce -fno-split-wide-types". Re
--- Comment #39 from harry dot he at freescale dot com 2010-06-09 08:59
---
Hi, Kyle Moffett,
in testall.c, r9 is used by a register variable, however, in E500ABI guide,
r9 should be used for parameter passing, this test case seems not reasonable.
Harry He
--
http://gcc.gnu.o
--- Comment #38 from gcc at breakpoint dot cc 2010-06-09 07:54 ---
(In reply to comment #28)
> Please bootstrap and test this addition to e500.h
>
> /* When setting up caller-save slots (MODE == VOIDmode) ensure we
>allocate space for DFmode. Save gprs in the correct mode too. */
--- Comment #37 from gcc at breakpoint dot cc 2010-06-09 07:50 ---
Created an attachment (id=20873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20873&action=view)
this fails to compile in -O2 with the fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #36 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
20:34 ---
Ok, I'm pretty sure this is unrelated to this bug, but I still get one
test-failure with PPL 0.10.2. The "interval1" test fails due to the
"test01" subtest, apparently due to very slightly excessive "flo
--- Comment #35 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
15:23 ---
Hrm, well PPL still seems to be failing the "interval1" test, but I'm not sure
that one's related as the part that fails is "test01". More info to
come shortly.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #34 from gcc at breakpoint dot cc 2010-06-08 11:23 ---
(In reply to comment #28)
> #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
> (TARGET_E500_DOUBLE && ((MODE) == VOIDmode || (MODE) == DFmode) \
>? DFmode
--- Comment #33 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
06:48 ---
EGLIBC and PPL are still building; I'm heading to sleep and I'll check on them
later this morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #32 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
05:07 ---
The first working patch (VOIDmode||DFmode) just successfully passed full GMP
and MPFR testsuites on the e500 boards. PPL and EGLIBC are currently
rebuilding.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #31 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
04:24 ---
Alan,
Now that I've corrected all of my compiler issues, your first patch (the one
quoted below) works like a charm. I still need to do the extensive
archive-rebuild and testsuite run to verify that it
--- Comment #30 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
18:56 ---
Ok, the cross-compiler built with this patch fails to build a native GCC for
the target with the following ICE:
../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd128':
../../../src/lib
--- Comment #29 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
18:28 ---
Awesome!!! Both of our testcases that were failing pass with this patch
applied!
I'm not going to call it a 100% victory yet, I want to rebuild our native
compilers and build-and-run the PostgreSQL, GMP
--- Comment #28 from amodra at gmail dot com 2010-06-07 17:05 ---
Please bootstrap and test this addition to e500.h
/* When setting up caller-save slots (MODE == VOIDmode) ensure we
allocate space for DFmode. Save gprs in the correct mode too. */
#define HARD_REGNO_CALLER_SAVE_MODE
--- Comment #27 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
12:49 ---
(In reply to comment #25)
> Yes it seems the patch is not sufficient on 4.4. On mainline the code looks
> good by inspection. (I don't have e500 hardware to run tests on.)
If you'd like login access to
--- Comment #26 from amodra at gmail dot com 2010-06-07 10:29 ---
Doh! No, it's still broken on mainline too. I wasn't testing what I thought I
was...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #25 from amodra at gmail dot com 2010-06-07 09:53 ---
Yes it seems the patch is not sufficient on 4.4. On mainline the code looks
good by inspection. (I don't have e500 hardware to run tests on.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #24 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
05:44 ---
Hmm, unfortunately in my preliminary testing this does not seem to fix either
testcase.
Cheers,
Kyle Moffett
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #23 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
05:36 ---
(In reply to comment #22)
> Adding the following to config/rs6000/e500.h will likely fix the bug.
> Testing..
Oh, very nice! Thanks for the speedy assistance on this! I've got my own test
compiler bui
--- Comment #22 from amodra at gmail dot com 2010-06-07 04:41 ---
Adding the following to config/rs6000/e500.h will likely fix the bug.
Testing..
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
(TARGET_E500_DOUBLE && ((MODE) == DFmode || (MODE) == TFmode \
--- Comment #21 from Kyle dot D dot Moffett at boeing dot com 2010-06-06
15:37 ---
I was trying to strip down the testcase and try to see which optimization flags
caused it. I started from -O2 and tried to see which -O2 flags (in addition to
O1) were needed to cause the problem. From
--- Comment #20 from amodra at gmail dot com 2010-06-06 14:52 ---
My guess is that tc-lossings-floats.c hits an ira related problem, but I'm not
particularly familiar with that area of the compiler so won't look further
myself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #19 from amodra at gmail dot com 2010-06-06 14:11 ---
Confirmed.
Regarding O1test.c:
Wierd set of gcc options, particularly -fno-dce and -fcaller-saves. I can't
see any sane reason why you would use those options on powerpc, unless you were
deliberately stress testing gcc..
--- Comment #18 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
17:24 ---
Created an attachment (id=20841)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20841&action=view)
Minimal test objdump with -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #17 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
17:24 ---
Created an attachment (id=20840)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20840&action=view)
Minimal test with -O1
I've managed to shrink this down to a 44-line testcase that fails with the
op
--- Comment #16 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
02:17 ---
Created an attachment (id=20832)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20832&action=view)
Even tinier tc-lossings-floats.objdump
--
Kyle dot D dot Moffett at boeing dot com changed:
--- Comment #15 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
02:17 ---
Created an attachment (id=20831)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20831&action=view)
Even tinier tc-lossings-floats.c
Spent a bit more time on the testcase and made it even smaller. T
--- Comment #14 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
01:37 ---
Created an attachment (id=20830)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20830&action=view)
Updated tc-lossings-floats.objdump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #13 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
01:37 ---
Created an attachment (id=20829)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20829&action=view)
Updated tc-lossings-floats.c
I sat down with GCC and vim for a couple hours narrowing down Sebastia
--- Comment #12 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
23:18 ---
(From update of attachment 20823)
Scratch my test cases... "register asm(...)" doesn't work the way I thought it
did... Sebastian's test case is the only one that I've found that works.
--
Kyle dot D
--- Comment #11 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:26 ---
Created an attachment (id=20828)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20828&action=view)
Multipart trivial testcase objdump result (Built with -O3)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #10 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:26 ---
Created an attachment (id=20827)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20827&action=view)
Multipart trivial testcase objdump result (Built with -O0)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #9 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:22 ---
Created an attachment (id=20826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20826&action=view)
Multipart trivial testcase (For -O3) part 3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #8 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:22 ---
Created an attachment (id=20825)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20825&action=view)
Multipart trivial testcase (For -O3) part 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #7 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:22 ---
Created an attachment (id=20824)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20824&action=view)
Multipart trivial testcase (For -O3)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #6 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:21 ---
Created an attachment (id=20823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20823&action=view)
Combined trivial testcase (For -O0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #5 from gcc at breakpoint dot cc 2010-06-03 20:17 ---
>So clearly the caller's assembly is wrong; it should be saving all 64-bits of
>r9 (volatile gpr) first.
Yes, that it what I've been pointing out. There is an optimization in the stack
code which uses 32bit stores/loads i
--- Comment #4 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:09 ---
Ok, I have a trivial 19-line testcase that triggers the bug on my native Debian
GCC 4.4.4-2+powerpcspe1 (with PR44169 fix) with -O0 and -O3. The compiler was
built with: --with-cpu=8548 --enable-e500_doub
--- Comment #3 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
19:26 ---
(In reply to comment #0)
> So after looking at the code I saw now the following:
> 1c24 <__floatdidf>:
> 1c6c: 11 23 1a 2c evmergehi r9,r3,r3
>
> This function is touching the complete 6
48 matches
Mail list logo
