From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8242 invoked by alias); 8 Sep 2007 16:08:55 -0000 Received: (qmail 8229 invoked by uid 22791); 8 Sep 2007 16:08:54 -0000 X-Spam-Check-By: sourceware.org Received: from nikam-dmz.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Sep 2007 16:08:47 +0000 Received: from localhost (occam.ms.mff.cuni.cz [195.113.18.121]) by nikam.ms.mff.cuni.cz (Postfix) with ESMTP id B2B975B84D; Sat, 8 Sep 2007 18:08:44 +0200 (CEST) Received: by localhost (Postfix, from userid 16202) id 89D9B939EA; Sat, 8 Sep 2007 18:08:44 +0200 (CEST) Date: Sat, 08 Sep 2007 16:28:00 -0000 From: Jan Hubicka To: Andrew Haley Cc: Jan Hubicka , Jan Hubicka , gcc-patches@gcc.gnu.org, richard@codesourcery.com Subject: Re: Lazy construction of libcalls Message-ID: <20070908160844.GG10905@kam.mff.cuni.cz> References: <20070821170529.GQ27714@kam.mff.cuni.cz> <87wsvlhyds.fsf@firetop.home> <20070824135925.GB4947@kam.mff.cuni.cz> <87sl69huzx.fsf@firetop.home> <20070904081644.GB26095@atrey.karlin.mff.cuni.cz> <18146.31326.53954.878500@zebedee.pink> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18146.31326.53954.878500@zebedee.pink> User-Agent: Mutt/1.5.9i Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-09/txt/msg00695.txt.bz2 > Jan Hubicka writes: > > > Jan Hubicka writes: > > > >> Jan Hubicka writes: > > > >> > While comparing the tables produced by new and old code, I noticed that > > > >> > "ffs" for SI used to be called "ffssi3" but now it is "ffs". > > > >> > I believe it was inteded to be called ffs because of: > > > >> > optab_handler (ffs_optab, int_mode)->libfunc = init_one_libfunc ("ffs"); > > > >> > that however later get overwriten by initialization code. > > > >> > > > >> Actually, this was deliberate. All libgccs have word and doubleword > > > >> ffs functions, but not all C libraries have "ffs". So we wanted the > > > >> libgcc versions to take precedence over the C library fallback. See: > > > >> > > > >> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01165.html > > > >> > > > >> for details. > > > > > > > > OK, so the initialization of libgcc always overwrite the ffs > > > > initialization, so simply removing the line above would work? > > > > > > Not for 64-bit targets with a 32-bit int, since __builtin_ffs() takes > > > an int argument. We could of course add an SImode libgcc function for > > > those targets, but the patch above was just supposed to make better > > > use of what we already had. > > > > Thanks for explanation - I've now added a guard > > if (INT_TYPE_SIZE < BITS_PER_WORD) > > into my local copy that should do what described again. I am re-testing now, > > OK with that change? > > This breaks ARM EABI. The symptom is that we generate signed instead > of unsigned libcalls for a % b where a and b are usigned ints. > > The problem is here in sign_expand_binop(), where we generate a fake > optab: > > /* Try widening to a signed int. Make a fake signed optab that > hides any signed insn for direct use. */ > wide_soptab = *soptab; > optab_handler (&wide_soptab, mode)->insn_code = CODE_FOR_nothing; > > We later call expand_binop (mode, &wide_soptab ... which in turn > calls optab_libfunc (binoptab, mode) which calls optab->libcall_gen() > and inserts the fake optab into the hash table. This means that the > hash table ->optab points into the stack. We don't want to do this, > I'm sure. Uh, sure... > > I suspect the easiest way to fix this is by setting libcall_gen to > NULL in the fake optab. Thanks, that seems like correct fix to me. Honza