On Sun, 23 Feb 2003, Terry Lambert wrote: > 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.
That is a feature :-). > 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. I doubt that it is a problem with 64-bitness. Handling 64 bits just takes more code, and the macro is apparently used a lot (it is used deeply nested so it is not obvious how often it is expanded). I suspect the problem is more from increased register pressure that happens to afect the current compiler more. > > 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? I hope so. The result doesn't always fit in 32 bits when the file system size exceeds about 1TB. Discarding nonzero high bits probably causes corrupt file systems. > 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? Kirk committed a quick fix. The bug is unlikely to matter in boot code. Root file systems shouldn't be larger than 1TB. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
