--- Comment #14 from ian at airs dot com 2005-11-04 16:09 ---
gcc is free to copy non-volatile variables. It does this in many places and
for many reasons, particularly in the new SSA optimizers in 4.0 and later. I
don't know the details of where it decided to copy the register in
--- Comment #15 from bergner at vnet dot ibm dot com 2005-11-04 17:38
---
For completeness, here is a minimal test case that shows the problem we are
having:
[EMAIL PROTECTED]:~/olaf/PR24644-4 cat bar.c
register struct paca_struct * local_paca asm(r13);
struct paca_struct { volatile
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-04 18:00
---
(In reply to comment #15)
This looks like gcc thinks r13 will be trashed by the call to foo() so it
copies it to a non volatile register for use after the call. Strange that
this
didn't happen before the
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-04 18:06
---
Variable: local_paca, UID 1270, struct paca_struct *, is global, call
clobbered, default def: local_paca_1
But we get:
# TMT.6_8 = V_MAY_DEF TMT.6_7;
# VUSE local_paca_1;
foo ();
I don't understand
--- Comment #3 from olh at suse dot de 2005-11-03 08:24 ---
copying the schedule.o from gcc41 tree to gcc40 tree doesnt help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--- Comment #4 from olh at suse dot de 2005-11-03 12:58 ---
What I have found so far with even more debugging:
4Processor 1 found.
7schedule(2883) swapper(0):c1,j4294892318 c000142ae100
6Brought up 2 CPUs
7_spin_lock_irq(85) swapper(0):c1,j4294892318 l c000142ae100 c
--- Comment #5 from olh at suse dot de 2005-11-03 13:05 ---
Created an attachment (id=10123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10123action=view)
PR24644-2.tar.bz2
rq does change between the context switch.
7schedule(3025) swapper(0):c1,j4294892318 p cffd7040 n
--- Comment #6 from olh at suse dot de 2005-11-03 13:31 ---
c000142ae100 is for cpu1, while c000142a6100 is for cpu0.
cpu1 was never active before, so all task switches were ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--- Comment #7 from olh at suse dot de 2005-11-03 21:30 ---
Created an attachment (id=10135)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10135action=view)
PR24644-3.tar.bz2
revision 102096 works, revision 102098 doesnt.
copying the sched.o from the 102098 tree into the 102096
--- Comment #8 from bergner at vnet dot ibm dot com 2005-11-03 21:48
---
Adding myself to the CC list.
--
bergner at vnet dot ibm dot com changed:
What|Removed |Added
--- Comment #9 from olh at suse dot de 2005-11-03 22:05 ---
Created an attachment (id=10136)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10136action=view)
PR24644-4.tar.bz2
object files and extracted asm functions for easier comparsion
--
--- Comment #10 from ian at airs dot com 2005-11-04 05:48 ---
From IRC, the problem seems to be that gcc is copying the value out of a global
register variable, which it was not doing before. This is not acceptable, as
the global register may be changed on any context switch, and it is
--- Comment #11 from bergner at vnet dot ibm dot com 2005-11-04 05:52
---
I've determined why we're dying, but not sure who is at fault yet. While
scanning through Olaf's assembly diff's, I noticed some code that normally
wouldn't be a problem in user code, but is problamatic in PPC64
--- Comment #12 from olh at suse dot de 2005-11-04 07:18 ---
Yes, adding the volatile fixes it for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--- Comment #13 from olh at suse dot de 2005-11-04 07:45 ---
Why does gcc make copies of r13 anyway, when it could just use it where needed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from olh at suse dot de 2005-11-02 20:49 ---
Created an attachment (id=10115)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10115action=view)
PR24644.tar.bz2
buildscripts, preprocessed files, kernel .config and debug patches, bootlog.
building with -O1 does not fix
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-11-03 06:46
---
Until we have a testcase that actually shows some evidence that the toolchain
is at fault, there is nothing for us to investigate; it could equally well be
that the kernel has a bug.
--
mmitchel at gcc dot gnu
18 matches
Mail list logo
