On Fri, 29 Dec 2000, Stefan Traby wrote:
> On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:
>
> > Too bad. Maybe somebody should tell gcc maintainers about programmers that
> > know more than the compiler again.
>
> I know that {p,}gcc-2.95.2{,.1} are not officially supported.
Hmm, I use gcc-2.95.2 myself on some machines, and while I'm not 100%
comfortable with it, it does count as "supported" even if it has known
problems with "long long". pgcc isn't.
> Did you know that it's impossible to compile nfsv4 because of
> register allocation problems with long long since (long long) month ?
lockd v4 (for NFS v3), I assume.
No, I wasn't aware of this particular bug.
> The following does not hurt, it's just a fix for a broken
> compiler:
Ugh, that's ugly.
Can you test if it is sufficient to just simplify the math a bit, instead
of uglyfing that function more? The nlm4_encode_lock() function already
tests for NLM4_OFFSET_MAX explicitly for both start and end, so it should
be ok to just re-code the function to not do the extra "loff_t_to_s64()"
stuff, and simplify it enough that the compile rwill be happy to compile
the simpler function. Something along the lines of
if (.. NLM4_OFFSET_MAX tests ..)
..
*p++ = htonl(fl->fl_pid);
start = fl->fl_start;
len = fl->fl_end - start;
if (fl->fl_end == OFFSET_MAX)
len = 0;
p = xdr_encode_hyper(p, start);
p = xdr_encode_hyper(p, len);
return p;
Where it tries to minimize the liveness of the 64-bit values, and tries to
avoid extra complications.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 21:00:12 EST