GCC switch to C11 causes many testsuite compiler diagnostics

GCC switch to C11 causes many testsuite compiler diagnostics

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

-Sandra

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Mark Kettenis]

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

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Andreas Arnez]

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

--
Andreas

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Doug Evans]

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.

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Mark Kettenis]

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

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Doug Evans]

On Fri, Oct 31, 2014 at 12:23 PM, Mark Kettenis <mark.kettenis@xs4all.nl> 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.  And it would probably make sense
> to run callfuncs.exp in both modes on all platforms.

Ah, righto.

Can we migrate all other tests?

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Andreas Arnez]

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?

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Andreas Arnez]

On Sat, Oct 25 2014, Sandra Loosemore wrote:

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

The warnings appear in our S390 testing as well, so I've been working on
a fix already, as announced here:

  https://sourceware.org/ml/gdb-testers/2014-q4/msg00037.html

In the meantime I've completed a patch set; maybe you'd like to check
that it does fix the warnings on NIOS2:

  https://sourceware.org/ml/gdb-patches/2014-10/msg00802.html

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

AFAIK there's no need to support pre-C89 compilers that can't handle
function prototypes.  GDB itself can't be compiled with such a compiler,
and many GDB test cases wouldn't work either.

--
Andreas

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Stan Shebs]

On 10/30/14, 9:07 AM, Andreas Arnez wrote:
> On Sat, Oct 25 2014, Sandra Loosemore wrote:
> 
>> 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.  :-(
> 
> The warnings appear in our S390 testing as well, so I've been working on
> a fix already, as announced here:
> 
>   https://sourceware.org/ml/gdb-testers/2014-q4/msg00037.html
> 
> In the meantime I've completed a patch set; maybe you'd like to check
> that it does fix the warnings on NIOS2:
> 
>   https://sourceware.org/ml/gdb-patches/2014-10/msg00802.html
> 
>>
>> 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).
> 
> AFAIK there's no need to support pre-C89 compilers that can't handle
> function prototypes.  GDB itself can't be compiled with such a compiler,
> and many GDB test cases wouldn't work either.
> 
> --
> Andreas

I looked at your patch, but haven't replied because I'm still waffling
about it.

In theory, GDB could be handed an executable that was built in 1988 and
most debugging actions would work.  In practice, the old executable is
unlikely to run on any modern hardware, and we've already decided not to
expend much effort to support old hardware.

Where things are a little murkier is K&R-style source code.  There was a
lot out there at one time, but most (all?) maintained sources have been
converted sometime in the intervening quarter-century.

Perhaps the thing to do is pose this as a trivia quiz - what K&R sources
are still being built and debugged on today's systems?

Stan
stan@codesourcery.com

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Sergio Durigan Junior]

On Thursday, October 30 2014, Stan Shebs wrote:

> Perhaps the thing to do is pose this as a trivia quiz - what K&R sources
> are still being built and debugged on today's systems?

FWIW, I remember GDB itself has some K&R prototypes on some *-exp.y
files until a few years ago.

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Joel Brobecker]

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

Generally speaking, I don't see a problem with modifying the code
in testcases to conform to the new warnings, but we need to verify
that it does not undo something that was specifically done for that
testcase.

Perhaps what we could do instead, is look at compiling the code
with switches that turn those off by default in the testsuite
directory? (I think this could be done in gdb_compile?) Not completely
obvious, but perhaps less time-consuming and boring than doing
mechanical updates of a lot of testcases...

Before you go ahead and implement anything, you might want to wait
to see what others think of the idea. I wouldn't say that this is
obviously the best compromise...

-- 
Joel