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

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.

-Ben


  reply	other threads:[~2013-12-17  4:02 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 [this message]
2013-12-18 12:47         ` Michael Veksler
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='CA+XNFZMFV=+a4RqesLevBAqBs+0z0Cbyo05tSWGEtVpXvuRfFw@mail.gmail.com' \
    --to=brlongbons@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=mveksler@tx.technion.ac.il \
    --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