From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8717 invoked by alias); 3 Nov 2014 11:02:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 8705 invoked by uid 89); 3 Nov 2014 11:02:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp14.uk.ibm.com Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 03 Nov 2014 11:02:22 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 3 Nov 2014 11:02:18 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 3 Nov 2014 11:02:16 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9DA2E1B08023 for ; Mon, 3 Nov 2014 11:02:21 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sA3B2GiQ58392656 for ; Mon, 3 Nov 2014 11:02:16 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sA3B2Dw2021501 for ; Mon, 3 Nov 2014 04:02:15 -0700 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-196.boeblingen.de.ibm.com [9.152.212.196]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sA3B2BVw021330; Mon, 3 Nov 2014 04:02:11 -0700 From: Andreas Arnez To: Mark Kettenis Cc: dje@google.com, sandra@codesourcery.com, gdb-patches@sourceware.org Subject: Re: GCC switch to C11 causes many testsuite compiler diagnostics References: <544BD7E6.1050602@codesourcery.com> <201410251728.s9PHSg6v018247@glazunov.sibelius.xs4all.nl> <87zjcd8r1r.fsf@br87z6lw.de.ibm.com> <201410311923.s9VJNYFW025974@glazunov.sibelius.xs4all.nl> Date: Mon, 03 Nov 2014 11:02:00 -0000 In-Reply-To: <201410311923.s9VJNYFW025974@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Fri, 31 Oct 2014 20:23:34 +0100 (CET)") Message-ID: <87wq7czgwe.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14110311-0017-0000-0000-000001B0E85C X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00035.txt.bz2 On Fri, Oct 31 2014, Mark Kettenis wrote: >> Date: Fri, 31 Oct 2014 12:02:11 -0700 >> From: Doug Evans >> >> On Thu, Oct 30, 2014 at 9:23 AM, Andreas Arnez wrote: >> > On Sat, Oct 25 2014, Mark Kettenis wrote: >> > >> >>> Date: Sat, 25 Oct 2014 11:03:34 -0600 >> >>> From: Sandra Loosemore >> >>> >> >>> Comparing my latest nios2 test results (with Pedro's thread patch) with >> >>> those from a checkout a couple weeks old, I noticed I had some new >> >>> ERRORs due to apparent compilation failures. I tracked this down to the >> >>> recent change on GCC mainline (r216247) to make the default C dialect >> >>> GNU11, which enables -Wimplicit-int and -Wimplicit-function-declaration >> >>> by default. I started working on a patch to fix the offending >> >>> testcases, but realized that there are hundreds of them. :-( >> >>> >> >>> So, before I invest a lot more time on this, is updating the GDB >> >>> testsuite to use a more modern C dialect the Right Thing To Do? I'm >> >>> also wondering if it's really necessary to support compilers that can't >> >>> handle function prototypes in the testsuite (not defining PROTOTYPES >> >>> seems to be the default, in fact). >> >> >> >> We've quite deliberately kept around a variety of C dialects and >> >> coding styles to make sure GDB works with whatever style people use. >> >> Having the majority of the tests use K&R style function declarations >> >> is probably not so useful anymore. But there are some tests that >> >> deliberately use K&_R style code to test whether GDB handles them >> >> properly. So blind conversion is probably not a good idea. >> > >> > Do you know off hand which tests deliberately use K&R style code? Maybe >> > you'd like to verify that none of them is deleted by this patch series: >> > >> > https://sourceware.org/ml/gdb-patches/2014-10/msg00802.html >> >> fwiw, I think this is the way to proceed. >> >> Find/pick a few tests that are explicitly for K&R, mark them as such, >> and move on. >> Life's short and there are so many vastly more important things to do than >> worry about losing some K&R coverage. If an issue turns up, we'll have >> real data to support a real K&R test. > > FWIW, those that explicitly and unconditionally use "set prototypes 0" > are deliberately testing K&R stuff. Did the 'prototypes' variable have any implied effect at some point? Currently that doesn't seem to be the case (unless I missed something). I see the following uses of the 'prototypes' variable: * callfuncs.exp: Set to '1' if and only if the HP aCC compiler is used (why?). If set, a certain test case is XFAILed with PR5318 (why?). * structs2.exp: Set to '1' unless the compiler yields diagnostics, in which case the compilation is retried with -DNO_PROTOTYPES -- in vain, because NO_PROTOTYPES is not evaluated by structs2.c. The 'prototypes' variable is also never evaluated. * varargs.exp: Set to '0' and never evaluated. * reread.exp: Set to '1' and never evaluated. * Test cases 'callfwmall.exp' and 'solib-d.exp' in the gdb.hp directory. In solib-d.exp the variable is only set to '0' and never evaluated, while callfwmall.exp uses the 'prototypes' variable in the same way as callfuncs.exp. Out of the above, my patch series only touches the callfuncs.exp test case. > And it would probably make sense to run callfuncs.exp in both modes on > all platforms. OK, I can provide a patch for that. I assume the special handling for the HP aCC compiler as well as the conditional XFAILs can be removed nowadays?