Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Veksler <mveksler@tx.technion.ac.il>
To: Ben Longbons <brlongbons@gmail.com>,  Andrew Pinski <pinskia@gmail.com>
Cc: GDB Development <gdb@sourceware.org>
Subject: Re: [C++] System Requirements
Date: Wed, 18 Dec 2013 12:47:00 -0000	[thread overview]
Message-ID: <52B1993F.9030105@tx.technion.ac.il> (raw)
In-Reply-To: <CA+XNFZMFV=+a4RqesLevBAqBs+0z0Cbyo05tSWGEtVpXvuRfFw@mail.gmail.com>

On 17/12/13 06:02, Ben Longbons wrote:
> On Mon, Dec 16, 2013 at 6:29 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>> I think we should support anything 3.0 and above.  Since we won't be
>> using STL or templates that much.
> Really? I can see quite a few cases where gdb will either have to use
> the STL or reinvent it; the big one is vec.h but it's far from alone.
>
> I know there are reasons to avoid or reimplement specific *parts* of
> the STL, but I haven't seen justification to avoid it in general.
>
> And I think that it is quite dangerous to try to support building gdb
> on a platform that its developers do not regularly use. gcc 4.4 is
> common; 4.[678] is rising, and 4.1 looks supportable, just not by me.
> I can't even build gcc 4.2 or earlier on any of my systems, though I
> admit I haven't deeply investigated what makes them different from 4.3
>
> Anyway, this sounds like a topic for the not-yet written thread [C++]
> Style Guide ... the only thing I've heard is that gdb is *not* going
> to follow gcc, because it has different requirements, such as
> exceptions (which, incidentally, must happen before anything else in
> step 5).
>
>
> But back on topic ... I started this thread intending to ask "which
> versions of GCC do we *need* to support?", not "which versions of GCC
> can we afford to support?" ... I never expected anyone to defend
> versions before 3.4
>
> A lower GCC version requirement means that gdb maintainers will have
> to spend more time trying to work around the quirks of older GCC
> versions and trying to badly reimplement features that are already in
> later GCC versions.
>
Andrew was right, and I was wrong. I confused between the pain
I had when I supported  gcc-2.95 (or was it egcs?) with the smaller
pain of supporting gcc-3.2/gcc-3.3. It was too long ago to
remember all the gory details.

Nevertheless, supporting pre-gcc-3.4 compilers is still a pain.
Not only because language semantics is different (two-phase
name lookup in templates vs. one) but because you can't easily
build old compilers on modern machines. And if you don't test
your  code with a pre-gcc-3.4 then your code won't work with
earlier compilers.

Michael


  reply	other threads:[~2013-12-18 12:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-14  0:34 Ben Longbons
2013-12-14  0:40 ` Ben Longbons
2013-12-15 12:28   ` Michael Veksler
2013-12-17  2:29     ` Andrew Pinski
2013-12-17  4:02       ` Ben Longbons
2013-12-18 12:47         ` Michael Veksler [this message]
2013-12-18 19:16           ` Ben Longbons
2013-12-15 15:31 ` Jan Kratochvil
2013-12-15 17:04   ` Ben Longbons
2013-12-15 19:53     ` Mark Kettenis
2013-12-16 13:03       ` Ivo Raisr
2013-12-16 13:52         ` Phi Debian
2013-12-17  5:35           ` Sergio Durigan Junior
2013-12-16 19:10     ` Eli Zaretskii
2013-12-16 20:09       ` Ben Longbons
2013-12-16 19:05 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52B1993F.9030105@tx.technion.ac.il \
    --to=mveksler@tx.technion.ac.il \
    --cc=brlongbons@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=pinskia@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox