From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17308 invoked by alias); 18 Dec 2013 12:47:02 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 17299 invoked by uid 89); 18 Dec 2013 12:47:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailgw12.technion.ac.il Received: from mailgw12.technion.ac.il (HELO mailgw12.technion.ac.il) (132.68.225.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2013 12:47:00 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMBAEngsFKERAHAl2dsb2JhbABZhxq1bIEfFg4BAQEBAQgWBzyCJQEBAQEDIxVAARALDgoCAgUWCwICCQMCAQIBDzYGAQwBBQIBAYdsAxGwcZFrDVeGJReBKYtWghMHgm6BSAEDliuIMIYViGc X-IPAS-Result: AiMBAEngsFKERAHAl2dsb2JhbABZhxq1bIEfFg4BAQEBAQgWBzyCJQEBAQEDIxVAARALDgoCAgUWCwICCQMCAQIBDzYGAQwBBQIBAYdsAxGwcZFrDVeGJReBKYtWghMHgm6BSAEDliuIMIYViGc Received: from techunix.technion.ac.il ([132.68.1.192]) by mailgw12.technion.ac.il with ESMTP; 18 Dec 2013 14:46:56 +0200 Received: from [127.0.0.1] (techunix.technion.ac.il [132.68.1.192]) by techunix.technion.ac.il (Postfix) with ESMTP id 897172A009C; Wed, 18 Dec 2013 14:46:56 +0200 (IST) Message-ID: <52B1993F.9030105@tx.technion.ac.il> Date: Wed, 18 Dec 2013 12:47:00 -0000 From: Michael Veksler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Longbons , Andrew Pinski CC: GDB Development Subject: Re: [C++] System Requirements References: <52ADA077.7020406@tx.technion.ac.il> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00047.txt.bz2 On 17/12/13 06:02, Ben Longbons wrote: > On Mon, Dec 16, 2013 at 6:29 PM, Andrew Pinski 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