Great, thanks a lot. I was able to build with
'CC=/usr/bin/gcc-4.4 CXX=/usr/bin/g++-4.4' and get a binary that passes this
test on the head, so it's definitely the compiler. I also ran tracediff and
it looks like it's an off-by-one thing with %fp; here's the first error:
-931697720: system.cpu T0 : 0xff1aa5b8 : stdf %fp, [%f29 + -0x20] :
MemWrite : D=0x423000000000197a A=0xfeffa280
+931697720: system.cpu T0 : 0xff1aa5b8 : stdf %fp, [%f29 + -0x20] :
MemWrite : D=0x4230000000001979 A=0xfeffa280
(The good gcc-4.4 version is second, so the '1979' is the correct value
here.)
I ran one more tracediff with '--debug-flag=All --trace-start=931600000' to
see if anything else turns up sooner, and got this:
@@ -1380553 +1380553 @@
931697014: system.cpu.[tid:0]: Reading float reg 3 (3) bits as 0, 0.
931697014: system.cpu.[tid:0]: Reading float reg 2 (2) bits as 0x3e300000,
0.171875.
931697014: global: FSR read as: 0xc0000000
-931697014: system.cpu.[tid:0]: Setting float reg 12 (12) bits to 0, 0.
+931697014: system.cpu.[tid:0]: Setting float reg 12 (12) bits to
0x80000000, -0.
931697014: system.cpu.[tid:0]: Setting float reg 13 (13) bits to 0, 0.
931697014: global: FSR written with: 0xc0000000
931697014: system.cpu + A16 T0 : 0xff1aa434 : fsubd
%f31,%f30,%f12 : FloatAdd : D=0x00000000c0000000
@@ -1380951 +1380951 @@
931697038: system.cpu.[tid:0]: Reading float reg 5 (5) bits as 0, 0.
931697038: system.cpu.[tid:0]: Reading float reg 4 (4) bits as 0, 0.
931697038: system.cpu.[tid:0]: Reading float reg 13 (13) bits as 0, 0.
-931697038: system.cpu.[tid:0]: Reading float reg 12 (12) bits as 0, 0.
+931697038: system.cpu.[tid:0]: Reading float reg 12 (12) bits as
0x80000000, -0.
931697038: global: FSR read as: 0xc0000000
931697038: system.cpu.[tid:0]: Setting float reg 18 (18) bits to 0, 0.
931697038: system.cpu.[tid:0]: Setting float reg 19 (19) bits to 0, 0.
@@ -1381022 +1381022 @@
931697042: system.cpu.[tid:0]: Reading float reg 10 (10) bits as
0x41300000, 11.
931697042: global: FSR read as: 0xc0000000
931697042: system.cpu.[tid:0]: Setting float reg 16 (16) bits to
0x41300000, 11.
-931697042: system.cpu.[tid:0]: Setting float reg 17 (17) bits to 0xe685,
8.26948e-41.
+931697042: system.cpu.[tid:0]: Setting float reg 17 (17) bits to 0xe684,
8.26934e-41.
931697042: global: FSR written with: 0xc0000000
931697042: system.cpu + A16 T0 : 0xff1aa4a4 : faddd %f3,%f2,%f16
: FloatAdd : D=0x00000000c0000000
931697042: Event_18: AtomicSimpleCPU tick event scheduled @ 931697043
Could it be some kind of FP rounding error? It's not clear how that would
end up affecting %fp though. (Actually, looking at this a little closer,
are we even disassembling that correctly? Seems to me it should be 'stdf
%f29, [%fp + -0x20]'.)
I won't have time to look into this further anytime soon, but I hope this
will give someone else (Gabe?) enough to go on to get this figured out.
Thanks,
Steve
On Sun, Oct 23, 2011 at 7:50 PM, Ali Saidi <[email protected]> wrote:
> I've installed it.
>
> Ali
>
> On Oct 23, 2011, at 7:18 PM, Steve Reinhardt wrote:
>
> > This makes sense, since the time the regression started failing is
> > consistent with when gcc was upgraded on zizzer.
> >
> > I see there is a gcc-4.4 package available for ubuntu 11.04 (which zizzer
> is
> > running)... is there more to it than installing that package and
> recompiling
> > to get a workable binary to run tracediff with?
> >
> > I'd try myself but I've forgotten my zizzer password (again!) so I can't
> > sudo. It's tough when you've had the same password for ten years then
> you
> > change it but don't use the new one much...
> >
> > Steve
> >
> > On Sun, Sep 25, 2011 at 1:14 PM, Ali Saidi <[email protected]> wrote:
> >
> >> Yes.. What Gabe said. With gcc 4.5 (version zizzer now runs) I cannot
> find
> >> a version of the repository that passes sparc boot. I'm pretty sure
> it's an
> >> annoying compiler issue, but there are some annoyances is figuring out
> where
> >> to look at Gabe points out. If you're stats changes work on everything
> else,
> >> I'm happy to see them committed while this issue goes on in the
> background.
> >>
> >> Thanks,
> >>
> >> Ali
> >>
> >> Sent from my ARM powered device
> >>
> >> On Sep 25, 2011, at 3:06 PM, Gabe Black <[email protected]> wrote:
> >>
> >>> We (Ali and I) have each looked at that before, and we think it depends
> >>> on the compiler version. Something changes when you have a new enough
> >>> gcc and then the behavior of SPARC changes. I think the new behavior is
> >>> broken and the old behavior is correct, but I'd have to look at it
> >>> again. I haven't looked into it farther than that yet because I'd want
> >>> to tracediff between versions built with different compilers. Since
> they
> >>> would need to find different versions of libraries and can't just run
> >>> from the same command line, it's logistically annoying.
> >>>
> >>> Gabe
> >>>
> >>> On 09/25/11 09:52, nathan binkert wrote:
> >>>> I'm trying to get my python stats changes into the tree, but it
> >>>> appears that one of the regression tests no longer works (zizzer
> >>>> agrees with me):
> >>>>
> >>>>
> >>
> SPARC_FS/tests/opt/long/80.solaris-boot/sparc/solaris/t1000-simple-atomic
> >>>>
> >>>>
> >>>> Gabe, I think you're the only one that's been messing with SPARC. Can
> >>>> you take a look?
> >>>>
> >>>> Nate
> >>>> _______________________________________________
> >>>> gem5-dev mailing list
> >>>> [email protected]
> >>>> http://m5sim.org/mailman/listinfo/gem5-dev
> >>>
> >>> _______________________________________________
> >>> gem5-dev mailing list
> >>> [email protected]
> >>> http://m5sim.org/mailman/listinfo/gem5-dev
> >>>
> >> _______________________________________________
> >> gem5-dev mailing list
> >> [email protected]
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> > _______________________________________________
> > gem5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/gem5-dev
> >
>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
