--- 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 ;
# VUSE ;
foo ();
I don't understand why because to me r13
--- 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 #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 { volatil
--- 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 this
--- 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
--- 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 #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 #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 #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=10136&action=view)
PR24644-4.tar.bz2
object files and extracted asm functions for easier comparsion
--
http://gcc.gnu.org/bugzilla/show_b
--- 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 #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=10135&action=view)
PR24644-3.tar.bz2
revision 102096 works, revision 102098 doesnt.
copying the sched.o from the 102098 tree into the 102096 t
--- 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 #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=10123&action=view)
PR24644-2.tar.bz2
rq does change between the context switch.
<7>schedule(3025) swapper(0):c1,j4294892318 p cffd704
--- Comment #4 from olh at suse dot de 2005-11-03 12:58 ---
What I have found so far with even more debugging:
<4>Processor 1 found.
<7>schedule(2883) swapper(0):c1,j4294892318 c000142ae100
<6>Brought up 2 CPUs
<7>_spin_lock_irq(85) swapper(0):c1,j4294892318 l c000142ae100 c
c00
--- 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 #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
--- 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=10115&action=view)
PR24644.tar.bz2
buildscripts, preprocessed files, kernel .config and debug patches, bootlog.
building with -O1 does not fi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
18 matches
Mail list logo
