From owner-freebsd-current Sun Feb 23 22: 5:54 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6732937B401 for ; Sun, 23 Feb 2003 22:05:52 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id A330843FB1 for ; Sun, 23 Feb 2003 22:05:49 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0040.cvx22-bradley.dialup.earthlink.net ([209.179.198.40] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nBk8-0005OC-00; Sun, 23 Feb 2003 22:05:37 -0800 Message-ID: <3E59B5DA.66EDBC85@mindspring.com> Date: Sun, 23 Feb 2003 22:04:10 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: David Syphers , Kirk McKusick , freebsd-current@FreeBSD.ORG Subject: Re: BOOT2_UFS=UFS1_ONLY works for today's current References: <20030224144742.L5105-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4032de80802fffe81eab1086343700649548b785378294e88350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > > Personally, I think the changes should be #ifdef'ed the current > > version of GCC; when GCC rev's, hopefully its 64 bit operations > > handling will have improved. > > This would wrong, since ufs2 depends on the changes to actually work > for file systems larger than about 1TB. If it's not going to compile correctly, it's not going to work. What we are bitching about here is that someone wants to use 64 bit operations that GCC can't handle. Waving our hands isn't going to make the problem go away, and adding code that doesn't compile correctly with the current compiler won't, either. > Blaming gcc's 64-bit operations seems to be wrong anyway. gcc actually > has good handling of (32, 32) -> 64 bit operations which are the only > types involved here in at least fs.h, boot2 still fits for me when it > is compiled the previous version of gcc. It has 19 bytes to spare: So we're agreed: it's a GCC issue, which is resolved by downgrading the compiler, or by upgrading it, after the new version is fixed (which is the direction I suggested going). > % -#define cgbase(fs, c) ((ufs2_daddr_t)((fs)->fs_fpg * (c))) > % +#define cgbase(fs, c) (((ufs2_daddr_t)(fs)->fs_fpg) * (c)) > % #define cgdmin(fs, c) (cgstart(fs, c) + (fs)->fs_dblkno) /* 1st data */ > > This changes a (32, 32) -> 32 bit (possibly overflowing) operation to a > (32, 32) -> 64 bit (never overflowing) operation. The 1386 hardware > already does the wider operation so all gcc has to do is not discard the > high 32-bits, which it does reasonably well. So it is agreed that this is good? [ ... rest of patches == "style bugs" ... ] > All of these changes add style bugs IMO. Except for the change to > cgbase(), they add redundant parentheses around "(cast)(foo)->bar", > but properly parenthesized macros are hard enough to read with only > non-redundant parentheses. The change to cgbase() moves parentheses > so that they are redundant instead of just wrong. OK... so what should be done? Just the cgbase() change? Does this fix the compiler revision dependent problem in such a way that the code does not need to be conditionalized on the compiler revision to avoid being broken? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message