From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10708 invoked by alias); 23 May 2007 14:35:06 -0000 Received: (qmail 10594 invoked by uid 48); 23 May 2007 14:34:55 -0000 Date: Wed, 23 May 2007 14:35:00 -0000 Message-ID: <20070523143455.10593.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug testsuite/32057] Random failure on gfortran.dg/secnds.f In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dominiq at lps dot ens dot fr" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg02041.txt.bz2 ------- Comment #1 from dominiq at lps dot ens dot fr 2007-05-23 15:34 ------- > I assume the dummy loop is used for delay. I don't think it is that reliable. I think you are right about the delay, but not about the real problem: you have the same with secnds-1.f which does not cantain the loop. The goal of the tests is not to measure some time, but to check that intervals are properly ordered, i.e., t1<=dat1<=t1a and t2a<=dat2-dat1<= t2. I have started to investigate the problem, see the thread: http://gcc.gnu.org/ml/fortran/2007-05/msg00216.html I have started to prepare a report of my findings, but I got distracted because gcc is no longer building on Darwin. The main cause of failures is because the tests do not account for round off errors. This can easily handled for first test by comparing to the nearest values from below and above: the failure rate seems below a couple ppb (part per billion) measured on secnds-1.f, using a naive way to measure it. I think this is due to the fact that t1 and t1a are absolute times. For the second test I had to use wider tolerances (such as spacing(24.0*3600.0)) and even so I get some errors on Pentium machines ~1/10000. After having removed this main source of failure I have found three more: (1) the tests do not handle timing around midnight when the counts go from 86400.0 to 0.0, (2) there is a rounding problem in secnds such that secnds(86400.0) returns 86400.0 during the 3ms before midnight, (3) on some machine the clock synchronization put the tests in jeopardy when the clock has a negative "lag": the value returned "after" is before the value returned "before"! I think this is a detectable but unrecoverable error and, when detected, the tests should be skipped and repeated. I have a fix for the two other cases, although (2) should probably handled at the secnds level. In top of the report, I have started to prepare a program to do some testing on platforms I have no access to (I have used PPC Darwin, and AMD64 and Pentium Linux). I was planning to join it to the report (Encouragements are welcome !-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057