Here a bug that looks like it might have been introduced
with the import of ntp4 and/or gcc4.

-------------------------------------------------------
$ ntpq -c "rv 0 clock"
assID=0 status=06e4 leap_none, sync_ntp, 14 events,
event_peer/strat_chg,
clock=c892289d.7fffffff  Sun, Aug 20 2006  2:17:33.500
-------------------------------------------------------
               ^^^^^^^^                            ^^^

On alpha, when the fractional part of the time stamp is
greater than 0x80000000, it is truncated to 0x7fffffff.

This is actually what ntpd returns and not a bug in ntpq(8).
By contrast, ntptime(8) returns the correct time stamp.

NetBSD/alpha is 4.99.1.
gcc version 4.1.2 20060628 prerelease (NetBSD nb2 20060711).

It is probably not "just" an optimization bug, -O0 still does
the wrong thing. But forcing gcc to commit the assignment in
get_systime() with a dummy asm statement works, like this:

Index: systime.c
=============================================================
RCS file: /cvsroot/src/dist/ntp/libntp/systime.c,v
retrieving revision 1.5
diff -u -r1.5 systime.c
--- systime.c   11 Jun 2006 19:34:10 -0000      1.5
+++ systime.c   20 Aug 2006 01:36:24 -0000
@@ -111,6 +111,7 @@
        }
        dtemp *= FRAC;
        now->l_uf = (u_int32)dtemp;
+       asm(""::"r"(now->l_uf));
 }

It would be great if someone who understands gcc internals can
come up with a test case that triggers it so we can report it to
the gcc team.

-Tobias