Go C++ only

Go C++ only

[Pedro Alves]

Hi all,

As last discussed, the general consensus was to make 7.12
the last gdb version that supports building with a C compiler.

I've been holding proposing to drop C-mode support in master
with the idea that that would help with all the bugfix
backporting going on.  I've had to explain this several times
recently, as people are eager to use C++ features.  Multiple
times this week, even.

At this point the backporting rate is quite low though, so
maybe it no longer makes that much sense to hold C++ back,
at least in new code.

What do people think?  Time to march ahead?

Thanks,
Pedro Alves

Re: Go C++ only

[Dmitry Samersoff]

[-- Attachment #1.1: Type: text/plain, Size: 906 bytes --]

Pedro,

I'm not a gdb developer but I'm *for* this changes.

+1

-Dmitry


On 2016-09-01 20:32, Pedro Alves wrote:
> Hi all,
> 
> As last discussed, the general consensus was to make 7.12
> the last gdb version that supports building with a C compiler.
> 
> I've been holding proposing to drop C-mode support in master
> with the idea that that would help with all the bugfix
> backporting going on.  I've had to explain this several times
> recently, as people are eager to use C++ features.  Multiple
> times this week, even.
> 
> At this point the backporting rate is quite low though, so
> maybe it no longer makes that much sense to hold C++ back,
> at least in new code.
> 
> What do people think?  Time to march ahead?
> 
> Thanks,
> Pedro Alves
> 


-- 
Dmitry Samersoff
Saint Petersburg, Russia, http://devnull.samersoff.net
* There will come soft rains  ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Go C++ only

[Simon Marchi]

On 2016-09-01 13:32, Pedro Alves wrote:
> Hi all,
> 
> As last discussed, the general consensus was to make 7.12
> the last gdb version that supports building with a C compiler.
> 
> I've been holding proposing to drop C-mode support in master
> with the idea that that would help with all the bugfix
> backporting going on.  I've had to explain this several times
> recently, as people are eager to use C++ features.  Multiple
> times this week, even.
> 
> At this point the backporting rate is quite low though, so
> maybe it no longer makes that much sense to hold C++ back,
> at least in new code.
> 
> What do people think?  Time to march ahead?
> 
> Thanks,
> Pedro Alves

Are there some guidelines about which C++ features we can use or not?  
Perhaps some precisions about the coding style, for C++-specific 
constructs (e.g. initializer lists).  I suppose we'll end up copying 
what GCC does for the most part, but it should be clear.

Thanks!

Simon

Re: Go C++ only

[Joel Brobecker]

> As last discussed, the general consensus was to make 7.12
> the last gdb version that supports building with a C compiler.
> 
> I've been holding proposing to drop C-mode support in master
> with the idea that that would help with all the bugfix
> backporting going on.  I've had to explain this several times
> recently, as people are eager to use C++ features.  Multiple
> times this week, even.
> 
> At this point the backporting rate is quite low though, so
> maybe it no longer makes that much sense to hold C++ back,
> at least in new code.

I don't have a strong opinion, but can we perhaps try a compromise
where we would be using C++ features only in new units (unlikely to be
backported)? Even though the backporting rate is indeed probably low,
it would still be nice to make it as easy as possible. Or is this
not really a practical suggestion?

-- 
Joel

Re: Go C++ only

[Pedro Alves]

On 09/01/2016 07:07 PM, Simon Marchi wrote:

> Are there some guidelines about which C++ features we can use or not? 

I think the biggest guideline so far is that people still want to build
gdb on systems with compilers that predate C++11, so we're stuck with 
C++03 for the moment.

> Perhaps some precisions about the coding style, for C++-specific
> constructs (e.g. initializer lists). 

List initialization is C++11, so it's out, at least for now.

> I suppose we'll end up copying
> what GCC does for the most part, but it should be clear.

Right, the proposal is to follow GCC's conventions:

 https://sourceware.org/gdb/wiki/cxx-conversion#Coding_conventions

Naturally we'll need to update the coding standards
pages to mention C++ and point at that:

 https://sourceware.org/gdb/wiki/Internals%20Coding-Standards

Thanks,
Pedro Alves

Re: Go C++ only

[Simon Marchi]

On 2016-09-01 14:22, Pedro Alves wrote:
> On 09/01/2016 07:07 PM, Simon Marchi wrote:
> 
>> Are there some guidelines about which C++ features we can use or not?
> 
> I think the biggest guideline so far is that people still want to build
> gdb on systems with compilers that predate C++11, so we're stuck with
> C++03 for the moment.
> 
>> Perhaps some precisions about the coding style, for C++-specific
>> constructs (e.g. initializer lists).
> 
> List initialization is C++11, so it's out, at least for now.

Oh, I meant the list of members to initialize in a constructor (the list 
after the colon), that's not C++11 I believe.  I see it's all discussed 
in the gcc coding convention page.

And to complete my answer on the original subject, I think it's fine to 
wait until 7.12 is out before checking in anything that is C++-only.  
The wait has been long already, a few weeks won't change much :).

Re: Go C++ only

[Andrew Pinski]

On Thu, Sep 1, 2016 at 11:22 AM, Pedro Alves <palves@redhat.com> wrote:
> On 09/01/2016 07:07 PM, Simon Marchi wrote:
>
>> Are there some guidelines about which C++ features we can use or not?
>
> I think the biggest guideline so far is that people still want to build
> gdb on systems with compilers that predate C++11, so we're stuck with
> C++03 for the moment.
>
>> Perhaps some precisions about the coding style, for C++-specific
>> constructs (e.g. initializer lists).
>
> List initialization is C++11, so it's out, at least for now.
>
>> I suppose we'll end up copying
>> what GCC does for the most part, but it should be clear.
>
> Right, the proposal is to follow GCC's conventions:
>
>  https://sourceware.org/gdb/wiki/cxx-conversion#Coding_conventions
>
> Naturally we'll need to update the coding standards
> pages to mention C++ and point at that:
>
>  https://sourceware.org/gdb/wiki/Internals%20Coding-Standards

Note the only feature I want to use right now is bool instead of char
or int were the value is a boolean.  This is new code and back-porting
is a simple change to char instead of bool so it is not normally a big
issue.

Thanks,
Andrew Pinski

>
> Thanks,
> Pedro Alves
>

Re: Go C++ only

[Pedro Alves]

On 09/01/2016 07:33 PM, Simon Marchi wrote:
> On 2016-09-01 14:22, Pedro Alves wrote:

>>> Perhaps some precisions about the coding style, for C++-specific
>>> constructs (e.g. initializer lists).
>>
>> List initialization is C++11, so it's out, at least for now.
> 
> Oh, I meant the list of members to initialize in a constructor (the list
> after the colon), that's not C++11 I believe.  I see it's all discussed
> in the gcc coding convention page.

Ah, whooops, sorry.  So that's I think the one detail that if you look 
at gcc's code, you'll notice that in practice it deviates a little from 
what the docs say.  Most of the gcc code I looked at I think simply follows
what emacs with "c-set-style gnu" prefers, which is to indent
the initializer list by a couple spaces.  Some random examples:

class pass_parallelize_loops : public gimple_opt_pass
{
public:
  pass_parallelize_loops (gcc::context *ctxt)
    : gimple_opt_pass (pass_data_parallelize_loops, ctxt),
      oacc_kernels_p (false)
  {}

[...]

class example_base
{
 public:
  example_base ()
    : m_kind (0),
      m_a (ggc_cleared_alloc <test_struct> ())
  {}

[...]

bit_field_mode_iterator
::bit_field_mode_iterator (HOST_WIDE_INT bitsize, HOST_WIDE_INT bitpos,
			   HOST_WIDE_INT bitregion_start,
			   HOST_WIDE_INT bitregion_end,
			   unsigned int align, bool volatilep)
: m_mode (GET_CLASS_NARROWEST_MODE (MODE_INT)), m_bitsize (bitsize),
  m_bitpos (bitpos), m_bitregion_start (bitregion_start),
  m_bitregion_end (bitregion_end), m_align (align),
  m_volatilep (volatilep), m_count (0)
{


While their docs say:

"(...) place the colon of the initializer clause at the beginning of a line.

    gnuclass::gnuclass ()
    : base1 (), base2 (), member1 (), member2 (), member3 (), member4 ()
    { 
      ...
    };

I think that we should this a documentation bug, and that it's better
to follow gcc's _actual_ style in practice.  Why fight
against emacs, right?  :-)

Thanks,
Pedro Alves

Re: Go C++ only

[Pedro Alves]

On 09/01/2016 07:33 PM, Simon Marchi wrote:
> 
> And to complete my answer on the original subject, I think it's fine to
> wait until 7.12 is out before checking in anything that is C++-only. 
> The wait has been long already, a few weeks won't change much :).

OTOH, there's most likely going to be a 7.12.1 too, so even though
we can aim at avoiding major impact on backports, it's looking like
the "7.12" milestone ends up being artificial.

Thanks,
Pedro Alves

Re: Go C++ only

[Eli Zaretskii]

> From: Andrew Pinski <pinskia@gmail.com>
> Date: Thu, 1 Sep 2016 11:36:34 -0700
> Cc: Simon Marchi <simon.marchi@polymtl.ca>, GDB Development <gdb@sourceware.org>
> 
> Note the only feature I want to use right now is bool instead of char
> or int were the value is a boolean.

You have bool in C.

Re: Go C++ only

[Pedro Alves]

On 09/01/2016 08:00 PM, Eli Zaretskii wrote:
>> From: Andrew Pinski <pinskia@gmail.com>
>> Date: Thu, 1 Sep 2016 11:36:34 -0700
>> Cc: Simon Marchi <simon.marchi@polymtl.ca>, GDB Development <gdb@sourceware.org>
>>
>> Note the only feature I want to use right now is bool instead of char
>> or int were the value is a boolean.
> 
> You have bool in C.

That's C99 only and requires including <stdbool.h>.  Defining
it ourselves is likely to cause conflict problems.  The best way to
make use of that would probably be to pull in gnulib's stdbool module,
though ISTR that's been tried and it caused trouble too.
It's just easier to wait for C++.

Thanks,
Pedro Alves

Re: Go C++ only

[Yao Qi]

On Thu, Sep 1, 2016 at 7:17 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>
> I don't have a strong opinion, but can we perhaps try a compromise
> where we would be using C++ features only in new units (unlikely to be
> backported)? Even though the backporting rate is indeed probably low,
> it would still be nice to make it as easy as possible. Or is this
> not really a practical suggestion?
>

I agree.  If we think the patch is likely to be backported, such as bug fix,
C++ feature is not allowed in the patch.

-- 
Yao (齐尧)

Re: Go C++ only

[Pedro Alves]

On 09/02/2016 11:01 AM, Yao Qi wrote:
> On Thu, Sep 1, 2016 at 7:17 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>
>> I don't have a strong opinion, but can we perhaps try a compromise
>> where we would be using C++ features only in new units (unlikely to be
>> backported)? Even though the backporting rate is indeed probably low,
>> it would still be nice to make it as easy as possible. Or is this
>> not really a practical suggestion?
>>
> 
> I agree.  If we think the patch is likely to be backported, such as bug fix,
> C++ feature is not allowed in the patch.

Agreed.

Sergio, can you switch the buildbot builder that is catching C
build regressions to test the 7.12 branch instead of master?

Thanks,
Pedro Alves

Re: Go C++ only

[Sergio Durigan Junior]

On Friday, September 02 2016, Pedro Alves wrote:

> On 09/02/2016 11:01 AM, Yao Qi wrote:
>> On Thu, Sep 1, 2016 at 7:17 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>>
>>> I don't have a strong opinion, but can we perhaps try a compromise
>>> where we would be using C++ features only in new units (unlikely to be
>>> backported)? Even though the backporting rate is indeed probably low,
>>> it would still be nice to make it as easy as possible. Or is this
>>> not really a practical suggestion?
>>>
>> 
>> I agree.  If we think the patch is likely to be backported, such as bug fix,
>> C++ feature is not allowed in the patch.
>
> Agreed.
>
> Sergio, can you switch the buildbot builder that is catching C
> build regressions to test the 7.12 branch instead of master?

Hm, I can try, yes.  I'll let you know if it works.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: Go C++ only

[Sergio Durigan Junior]

On Friday, September 02 2016, Pedro Alves wrote:

> On 09/02/2016 11:01 AM, Yao Qi wrote:
>> On Thu, Sep 1, 2016 at 7:17 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>>
>>> I don't have a strong opinion, but can we perhaps try a compromise
>>> where we would be using C++ features only in new units (unlikely to be
>>> backported)? Even though the backporting rate is indeed probably low,
>>> it would still be nice to make it as easy as possible. Or is this
>>> not really a practical suggestion?
>>>
>> 
>> I agree.  If we think the patch is likely to be backported, such as bug fix,
>> C++ feature is not allowed in the patch.
>
> Agreed.
>
> Sergio, can you switch the buildbot builder that is catching C
> build regressions to test the 7.12 branch instead of master?

Right, I've made a few modifications on the config files and the C-only
builder should now be building only changes to the 7.12 branch.

Let me know if it works, or if you need something else.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/