From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31499 invoked by alias); 10 Dec 2001 18:59:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31073 invoked from network); 10 Dec 2001 18:58:01 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 10 Dec 2001 18:58:01 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id KAA22259; Mon, 10 Dec 2001 10:57:56 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma022233; Mon, 10 Dec 01 10:57:51 -0800 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.27.78]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id fBAIvuS00920; Mon, 10 Dec 2001 10:57:56 -0800 (PST) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) with ESMTP id fBAIq7A14336; Mon, 10 Dec 2001 10:52:07 -0800 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Mon, 10 Dec 2001 11:11:00 -0000 From: Linus Torvalds To: Franz Sirl cc: Richard Henderson , Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work In-Reply-To: <200112101938.4189@enzo.bigblue.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-12/txt/msg00514.txt.bz2 On Mon, 10 Dec 2001, Franz Sirl wrote: > > > > Which part of FAT-FS actually tries to do a signed division? > > It's this code fragment: > > inode->i_blocks = ((inode->i_size + inode->i_blksize - 1) > & ~(inode->i_blksize - 1)) / 512; > > that is in inode.c/fat_read_root() and fat_fill_inode(). It's inode->i_size > that is of type loff_t here. Hmm, ok. I've never really liked the signedness of "loff_t" (or "off_t"), as negative numbers are illegal anyway, and are really only used for "seek offset" case. It might be a good idea to make the in-kernel sizes all be unsigned, to avoid things like this being problematic. For fat, the inode size is actually limited to 32 bits, so the above is definitely _always_ a unsigned number, and a relatively small one at that. So unsigned vs signed doesn't matter, but on the whole I'd prefer to default to unsigned which tends to be faster anyway, and has less surprising behaviour in case of bugs.. > It calculates the number of blocks here, so the rounding up might be wanted... Yes, it does the rounding up by hand, but it does _not_ need or want the "negative division" rounding part. > Hehe, yeah, exactly :-). Anyway, Richard's patch works fine and gcc3 now is > able to optimize the divdi3 call away. Good. The code looks correct, even if I have this feeling that the kernel might want changing too.. Linus