Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On Fri, Oct 31 2014, Mark Kettenis wrote:

>> 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.

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?