From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7720 invoked by alias); 18 Mar 2011 15:40:36 -0000 Received: (qmail 7674 invoked by uid 22791); 18 Mar 2011 15:40:35 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Mar 2011 15:40:31 +0000 Received: from eggs.gnu.org ([140.186.70.92]:60822) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Q0bmv-00017C-BV for gcc@gnu.org; Fri, 18 Mar 2011 11:40:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0bmu-0005dq-87 for gcc@gnu.org; Fri, 18 Mar 2011 11:40:29 -0400 Received: from smtp205.alice.it ([82.57.200.101]:38018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0bmu-0005d2-2z for gcc@gnu.org; Fri, 18 Mar 2011 11:40:28 -0400 Received: from [192.168.1.4] (79.52.240.105) by smtp205.alice.it (8.5.124.08) id 4D0D003807C6D247; Fri, 18 Mar 2011 16:40:20 +0100 Message-ID: <4D837CE3.8020605@oracle.com> Date: Fri, 18 Mar 2011 15:40:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8 MIME-Version: 1.0 To: Diego Novillo CC: gcc@gnu.org, libstdc++@gcc.gnu.org Subject: Re: Spurious libstdc++ testsuite failures because of truncated buffered output References: <4D837A7B.8020005@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.101 X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00265.txt.bz2 On 03/18/2011 04:35 PM, Diego Novillo wrote: > I don't really know why the others don't fail, but I will take a look. > In this particular case, the output is truncated after 1,032,134 > bytes are printed. So I can only speculate that no other tests > generate more than this number of bytes in output. I'll take a look. For sure if it's the *overall* number of bytes that matters, working around the issue is simple, because the testcase can be trivially split to 14 separate tests, one for each operation. Paolo.