Two glitches while testing gcc version 4.3.0 20070216

[Brooks Moses]

Steve Kargl wrote:
> On Sat, Feb 17, 2007 at 12:12:36PM -0800, Brooks Moses wrote:
>> Steve Kargl wrote:
>>> It's simply a timing problem.  secnds.exe is trying to make a timing
>>> measurement and the tolerance is IMHO too strict.
>>
>> Theoretically, though, the patch he's referring to (which I put in) 
>> should have fixed that problem, by eliminating tolerances -- it calls 
>> SECNDS, calls DATEANDTIME, and calls SECNDS again, and checks that the 
>> DATEANDTIME value is between the two SECNDS values.  So it shouldn't be 
>> doing that any more.
> 
> I'm not convinced. :)

Me, either.  I'm using "it shouldn't be doing that" in the sense of the 
joke about the typical computer-scientist response to something 
unexpected, not in complete seriousness.  Obviously it _is_ doing it, 
whatever I think.  :)

>> However, after submitting the patch, I did discover with my 
>> "instrumented" version of the testcase that it will very occasionally 
>> still fail; the intermediate DATEANDTIME result was 40ms ahead of the 
>> first SECNDS result, but the SECNDS result was only 20ms ahead.  Since 
>> it's never happened again for me, I haven't looked closer to see if 
>> there's a "real" reason for it, but my guess is that it's a rounding issue.
> 
> You can make 3 system calls in less than 20 ms, and we're
> rounding to ms resolution.

I think part of the problem is also that we don't actually have ms 
resolution there -- when I was testing this version and the old version, 
the differences in the times were coming out in multiples of a value 
slightly less than 20ms.  Usually the multiplier was zero, too.

>> Maybe I should put a loop into the testcase to run it two or three times 
>> and only abort if all of the passes fail.
> 
> Yep. The old-time spin loop.

We've actually nearly got that now -- secnds.f uses -O0 as an additional 
compiler option, but dejagnu still loops through all of the optimization 
levels, so it's effectively running six identical tests.

(Actually, since the only difference between that and secnds_1.f is that 
secnds.f has a delay loop, and secnds_1.f doesn't force -O0, I'm 
thinking they really should be combined; the optimizer will kill the 
delay loop at anything but -O0, and all we lose is one pass through the 
no-delay version at -O0.)

- Brooks