From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4730 invoked by alias); 13 Jun 2011 18:53:25 -0000 Received: (qmail 4722 invoked by uid 22791); 13 Jun 2011 18:53:24 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,SARE_FWDLOOK,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta15.emeryville.ca.mail.comcast.net (HELO qmta15.emeryville.ca.mail.comcast.net) (76.96.27.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Jun 2011 18:53:09 +0000 Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta15.emeryville.ca.mail.comcast.net with comcast id vVf81g0031afHeLAFWt7mE; Mon, 13 Jun 2011 18:53:07 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta17.emeryville.ca.mail.comcast.net with comcast id vWuo1g00E0BKwT48dWuoWW; Mon, 13 Jun 2011 18:54:49 +0000 Subject: Re: [testsuite]: Skip tests for targets with int < 32 bits Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: <4DF6548C.2030207@gjlay.de> Date: Mon, 13 Jun 2011 19:07:00 -0000 Cc: gcc-patches@gcc.gnu.org, Kaz Kojima , Jakub Jelinek , Rainer Orth Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DF0F48C.2050308@gjlay.de> <691C71AE-DCA3-4061-8904-C6F970618B17@comcast.net> <4DF6548C.2030207@gjlay.de> To: Georg-Johann Lay X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg00991.txt.bz2 On Jun 13, 2011, at 11:18 AM, Georg-Johann Lay wrote: > Who is a "specific maintainer" here? I'd be happy to have the author of the testcase weigh in, or someone that c= ares about int32plus, or the the person that fixed the bug in the compiler = for which the testcase was written... > I found you (and Rainer Orth) as "testsuite" maintainers. > Or does that just refer to the test harness and not to specific test case= s? I consider the situation much like the role of a global write privs person.= They, in theory, can approve a C++ change, but such changes are at least = at times, better reviewed and approved by a C++ person. I'd rather haver a= arm person ok the gcc.target/arm/* testcases, I'd rather have an x86_64 pe= rson review and approve gcc.target/i386, I'd rather have a fortran person r= eview gcc.fotran changes. > Then I observed that > /* { dg-require-effective-target int32plus } */ > does not work as intended for all test cases. Ah, yes, right. Longer term, I think that's a bug we should fix. For now,= as Jakub points out, you need to create a .x file for them. I'd like to s= ee the .x files go away. > For exammple, I added this line to, e.g. > * gcc.c-torture/execute/cmpsi-2.c > * gcc.c-torture/execute/pr45262.c > in trunk r172757 > http://gcc.gnu.org/viewcvs?view=3Drevision&revision=3D172757 >=20 > However, these tests are still executed as you can see in gcc-testresults= for trunk r174959: > http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01429.html I don't understand why you'd propose a change that doesn't work? In genera= l, maintainers rely upon contributors to test and ensure that a change does= something worthwhile. So, yes, I agree with Jakub, this part of the patch= should be reverted, and an .x file created/modified, or possibly the testc= ase modified to be more portable. If you want to enhance the driver to pro= cess the dg stuff, I like that direction. > Is this a bug resp. worth a bug report? If you want, though, I think it might make more sense in a forward looking = design document, or a open projects file. It isn't a bug, because it was n= ever a feature.