Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Fri, 31 Oct 2014 12:02:11 -0700
> From: Doug Evans <dje@google.com>
> 
> On Thu, Oct 30, 2014 at 9:23 AM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:
> > On Sat, Oct 25 2014, Mark Kettenis wrote:
> >
> >>> Date: Sat, 25 Oct 2014 11:03:34 -0600
> >>> From: Sandra Loosemore <sandra@codesourcery.com>
> >>>
> >>> 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.  And it would probably make sense
to run callfuncs.exp in both modes on all platforms.