From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20476 invoked by alias); 10 Oct 2007 15:04:37 -0000 Received: (qmail 20468 invoked by uid 22791); 10 Oct 2007 15:04:36 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 Oct 2007 15:04:32 +0000 Received: (qmail 5305 invoked from network); 10 Oct 2007 15:04:31 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Oct 2007 15:04:31 -0000 To: Pierre Muller Cc: gdb-patches@sourceware.org Subject: Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors References: <000001c80b14$db947450$92bd5cf0$@u-strasbg.fr> <20071010120140.GB10228@caradoc.them.org> From: Jim Blandy Date: Wed, 10 Oct 2007 15:27:00 -0000 In-Reply-To: <20071010120140.GB10228@caradoc.them.org> (Daniel Jacobowitz's message of "Wed, 10 Oct 2007 08:01:40 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00243.txt.bz2 'Daniel Jacobowitz' writes: >> 1) inline 9 Do not use the inline attribute; >> since the compiler generally ignores this, better >> algorithm selection is needed to improved performance >> This problem is limited to three files: >> vec.c (1) vec.h (7) and xtensa-tdep.c (1). >> It could be easily removed, but I was wondering if >> there was a special reason why vec.h >> had some many. > > No really good reason. The above is someone's particular opinion on > the inline keyword (probably Andrew's, as he wrote the ARI stuff, but > I don't know for sure who - maybe someone else on the list knows). > vec.c / vec.h were written by Nathan for GCC, and the GCC project has > a very different opinion on the use of the inline keyword. > > Perhaps the fact that the compiler sources think inline is worthwhile > should give us a hint... Yeah, I'm not sure I agree with the ARI's opinion either. GDB has plenty of room for algorithmic improvements, but if adding an 'inline' to a particular function made it go faster, why not use it? Well, this is exactly why the ARI explicitly forbids us from taking it seriously: to encourage people to disagree, debate and refine. I think that check should go.