On Sat, Dec 1, 2012 at 1:17 PM, Janus Weil <ja...@gcc.gnu.org> wrote: > Hi all, > > here is a straightforward patch for the intrinsic procedure > SYSTEM_CLOCK. It does two things: > 1) It reduces the resolution of the int8 version from 1 nanosecond to > 1 microsecond (COUNT_RATE = 1000000). > 2) It adds an int16 version with nanosecond precision. > > The motivation for item #1 was mainly that the actual precision is > usually not better than 1 microsec anyway (unless linking with -lrt). > This results in SYSTEM_CLOCK giving values whose last three digits are > zero. One can argue that this is not a dramatic misbehavior, but it > has disadvantages for certain applications, like e.g. using > SYSTEM_CLOCK to initialize the random seed in a Monte-Carlo > simulation. In general, I would say that the value of COUNT_RATE > should not be larger than the actual precision of the clock used. > > Moreover, the microsecond resolution for int8 arguments has the > advantage that it is compatible with ifort's behavior. Also I think a > resolution of 1 microsecond is sufficient for most applications. If > someone really needs more, he can now use the int16 version (and link > with -lrt). > > Regtested on x86_64-unknown-linux-gnu (although we don't actually seem > to have any test cases for SYSTEM_CLOCK yet). Ok for trunk? > > Btw, does it make sense to also add an int2 version? If yes, which > resolution? Note that most other compilers seem to have an int2 > version of SYSTEM_CLOCK ...
No, not Ok. IIRC there was some discussion about COUNT_RATE back when the nanosecond resolution system_clock feature was developed, and one idea was to have different count rates depending on whether clock_gettime is available, as you also suggest in the PR. In the end it was decided to keep a constant count rate as a consistent rate was seen as more important than "wasting" a few of the least significant bits when nanosecond resolution is not available, since int8 has sufficient range for several centuries even with nanosecond resolution. Anyway, I don't feel particularly strongly about this, and if there now is a consensus to have a changing count rate, I can live with that. But, I do object to providing only microsecond resolution for the int8 version. Nanosecond resolution is indeed not necessary in most cases, but like the saying goes, "Precision, like virginity, is never regained once lost.". Reducing the resolution is a regression for those users who have relied on this feature; I, for one, have several test and benchmark programs which depend on nanosecond resolution for the int8 system_clock. OTOH, if one wants a microsecond count rate, converting the count value is just a single statement following the system_clock call. Needing to link with librt in order to access clock_gettime is an unfortunate wart in glibc, but other C libraries exist out there (heck, given the success of Android, glibc is certainly a minority even if you limit yourself to Linux), and of those that provide clock_gettime, most have it directly in libc and not in a separate library. As for the int16 and int2 variants, F2003 requires that the arguments can be of any kind. AFAICS, this means that different arguments can be of different kind. So in order to avoid a combinatorial explosion, the only sensible way is for the frontend to create temporaries of suitable kind, then call an appropriate library function etc. As mentioned, int8 already provides several centuries range with nanosecond resolution, and thus I see no reason to provide a int16 version, but rather the frontend should create int8 temporaries, call system_clock_8, then copy the results back to the actual int16 arguments. F2003 requires than all supported kinds should work, which would include kinds 1 and 2, although those versions obviously suffer from a lack of either range, precision or both, to the extent that they are quite useless in practice. I think they could be handled by just setting count to -huge(), count_rate and count_max to 0 in the frontend and not bothering to make a library call at all. Also, F2003 specifies than COUNT_RATE can be of type real as well; I think this should be handled similarly, by the frontend copying the result from an integer temporary. So in the end I don't think we need new library entry points, but rather the temporary variable handling stuff in the frontend. -- Janne Blomqvist
