From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by sourceware.org (Postfix) with ESMTPS id 185863858D3C; Fri, 9 Jun 2023 17:49:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 185863858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=axis.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=axis.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1686332971; x=1717868971; h=from:to:cc:in-reply-to:subject:mime-version: content-transfer-encoding:references:message-id:date; bh=5bLZWwm2Ezk3enA2MZm1AyKFOHX8XJ1EtK7JWywD294=; b=fuNEaDCCnYxVj2k53yMLxLVoI8aXvIiywkocUdUqObii3b9KweYLw9ij c93jLaYwERVaRjugDTjRXmlIIYMd4Jn/IXmlU/4tj2xYrDZqdbmWmq7TX QNiXpX1LG5sxvCUYPdlrR6ENNMjXxu6xRP1Swa9tg6bt+M2W7mtML9p4F 8s57QIaKB6Wp7dRDjU37co39/pXatENp9i2aiykAzujo3MvkK9CWxd3M2 gQyToxlNbPVtwI92NNHRZ3oslri/PPkZoKt+MOxxLVwty11/R+RJ8qOEp HHSmNeDpsXEdM73ivwnBsVm1GDZqnvcXq4OqTw6lWUZOrr7qbcJTvIw+W A==; From: Hans-Peter Nilsson To: Mike Stump CC: , , In-Reply-To: <7F48B21B-835B-4741-9B9E-660A2D302A67@comcast.net> (message from Mike Stump on Fri, 9 Jun 2023 10:18:45 -0700) Subject: Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT References: <20230609162026.CC34320433@pchp3.se.axis.com> <7F48B21B-835B-4741-9B9E-660A2D302A67@comcast.net> Message-ID: <20230609174929.9E0D720432@pchp3.se.axis.com> Date: Fri, 9 Jun 2023 19:49:29 +0200 X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Mike Stump > Date: Fri, 9 Jun 2023 10:18:45 -0700 > On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > > > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes > > about 10 minutes to run for cris-elf in the "gdb simulator" > > I'd let the libstdc++ people comment on specific things. > I'll comment on general things. We could let line count > (or word count or character count) scale the timeout in > part, we could record times in a db and put an expected > run time into test cases or in an along side db. We could > have factors for slow systems, slow simulators. A 5 GHz > x86_64 will likely be faster that a 40 year old pdp11. We > can have these scale factors trigger off OS, cpu > statically, and/or we can do a quick bogomips calculation > and let that scale it and record that scaling factor in > the build tree. Wild plans, but with some points. Beware that uniform testing IMO weighs in much heavier than uniform test-time. Like, arm-eabi, rv32-elf and cris-elf, having common main factors, should test the same code and the same number of iterations, preferably regardless of simulator quality. (FWIW, I consider the cris-elf gdb simulator is *fast* - before 2021 or when built --disable-sim-hardware.) > A wealth of possibilities. And complexity! > Solutions that require maintenance or test case > modification are annoying. Yeah, but that maintenance annoyance unfortunately includes initial setup. You propose quite a major shift there. It sounds good, but sorry, but I must settle for just editing the test-case some way. brgds, H-P