From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13197 invoked by alias); 19 Feb 2012 15:38:31 -0000 Received: (qmail 13189 invoked by uid 22791); 19 Feb 2012 15:38:31 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CX,TW_IB X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 19 Feb 2012 15:38:18 +0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/52219] [4.7 Regression] FAIL: cxg2001 Date: Sun, 19 Feb 2012 15:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-02/txt/msg01892.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 --- Comment #7 from Iain Sandoe 2012-02-19 15:37:47 UTC --- (In reply to comment #6) > cxg2001 has passed my last tests without failure. likewise on all my recent tests on both patched & un-patched trees. I find that the acats tests are quite likely to exhibit random fails on D9 and D10 for parallel tests on loaded machines, but I associate that with the test-environment (repeating make check-ada has always come up clean - except for cases with real bugs). Which is different from the libjava/boehm-gc cases which always exhibit the marginal fails even on a single process test cycle. ==== ... the test looks like it is doing some FP work - so not likely to be subject to the two following phenomena: > Is it in the same class as Thread_Sleep_2 in libjava this randomly fails for a known reason (OS bug), we should probably ask for the Java to be changed so that the timeout has a suitable capture range (it doesn't look like the bug will be fixed in D9 or D10). or thread_leak_test.c in > boehm-gc for which I got ~6 failures out of ~90 regtests? this (I think) is related to operating close to the limit of available stack (but that's unconfirmed and on the TODO to investigate). ===== .. although, it's not impossible that either effect could manifest in cxg2001.a, it seems unlikely. I'd be more inclined to blame expect/tcl/dejgnu + system load. Unless you can repeat the failure.