I just noticed that this was in reply to that earlier email. Basically, I've got one laptop and an ok but not spectacular internet connection which will get substantially worse tomorrow and then non-existant a couple days after that, so it would be a big pain for me to try to get two different states for the hypothetically uninitialized variable at the same time. If you could just try a bunch of machines until you find a couple that happen to do different things, hopefully they'll do those different things a few times in a row and we can get a trace out of it. Otherwise I'd just be surfing through a ton of code looking for a needle in a haystack.
Gabe Gabe Black wrote: > If that's restricted to x86 parser I wrote an email about that earlier. > I don't know exactly what's wrong, but if you can get two machines to > pass and fail at the same time and send me a tracediff it would really > help. I don't think this is something that should hold back the release > of the repository since x86 isn't quite ready for prime time yet anyway. > > Gabe > > Ali Saidi wrote: >> It failed in the regression on zizzer 3 days ago and it passed today. >> The only difference between those two repos is some different >> copyright text in comments, so it I would guess initialized variable >> or something? >> >> Ali >> >> On Jun 8, 2008, at 3:34 PM, Gabe Black wrote: >> >>> I only have access to one machine at the moment (my laptop), so if you >>> could find two computers where this passes and doesn't at least >>> semi-repeatably and tracediff them, I might be able figure this out in >>> the near future. >>> >>> Gabe >>> >>> Gabe Black wrote: >>>> Hopefully not. I'd say it's unlikely but I definitely wouldn't say >>>> it's >>>> impossible. For that few of instructions it might be fstat or >>>> something >>>> like that passing through some host state which changes execution >>>> in the >>>> guest slightly. I think I had problems with parser behaving strangely >>>> before as well either in x86 or in SPARC, although I unfortunately >>>> don't >>>> remember very well. I sort of remember that the regressions failed >>>> for >>>> the same version the outputs came from and on the same machine >>>> which I >>>> may have mentioned in a changeset comment when I reupdated them. The >>>> reason I think uninitialized state is unlikely is that there aren't >>>> that >>>> many microops that things are built from, and for the most part >>>> that's >>>> about as far as the manually written C++ gets. There are a lot of >>>> moving >>>> parts, though, so I wouldn't rule out that some combination of stuff >>>> makes something not get initialized. >>>> >>>> Gabe >>>> >>>> Ali Saidi wrote: >>>>> I ran a full regression of the new tree manually. The only thing >>>>> that >>>>> reported a difference was x86/parser. That particular benchmarks >>>>> seems >>>>> to change it stats by 20 instructions kind of frequently. There must >>>>> be some uninitialized state or something about 32bit vs 64bit >>>>> compiles? >>>>> >>>>> Ali >>>>> >>>>> _______________________________________________ >>>>> m5-dev mailing list >>>>> m5-dev@m5sim.org >>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> _______________________________________________ >>>> m5-dev mailing list >>>> m5-dev@m5sim.org >>>> http://m5sim.org/mailman/listinfo/m5-dev >>> _______________________________________________ >>> m5-dev mailing list >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
