Cactus does not detect `gettimeofday` timer

[Erik Schnetter]

The gettimeofday timer is not available any more in Cactus. This is the main timer used by Cactus to measure elapsed time.

PR https://bitbucket.org/cactuscode/cactus/pull-requests/153 corrects this.

[Roland Haas]

The current code works for me (e.g. on the Delta Cluster at UIUC, and also on Summit). I get:

/* Timing stuff */
#define HAVE_TIME_GETTIMEOFDAY 1
#define GETTIMEOFDAY_NEEDS_TIMEZONE 1
#define HAVE_TIME_GETRUSAGE 1

in cctk_Config.h for both. On my M1 based macOS testing system with Homebrew it does indeed fail:

/* Timing stuff */
/* #undef HAVE_TIME_GETTIMEOFDAY */
/* #undef GETTIMEOFDAY_NEEDS_TIMEZONE */
#define HAVE_TIME_GETRUSAGE 1

So, since we have just entered code freeze for the release in May, I would not want to touch anything in configure if possible. While the change looks harmless, and indeed:

#include <sys/time.h>
int main(void) {
  gettimeofday(0,0);
  return 0;
}

is much nicer code (and closer to how the actual arguments to TRY_LINK are defined) than

int main(void) {
  #include <sys/time.h>
  gettimeofday(0,0);
  return 0;
}

I would rather not risk changing anything if only macOS system are affected. Since there are no macOS production clusters, any timing obtained on them is not really useful to guide decisions for code optimization anyway I would think.

I would be happy to include the change in master just after the release and backport if no issues are found with it after a while. Though note that also the change to PAPI that is reported in#2714 was applied to master just after the last release, always broke on Linux and was never reported. So master seems to not be used very much anymore it seems.

Out of curiosity:

int main(void) {
  #include <sys/time.h>
  gettimeofday(0,0);
  return 0;
}

actually forbidden? Ie does the C standard require that the includes happen at file level? There is in principle nothing wrong with declare function prototypes in local scope, and an #include is just a textual replacement, so valid inside of a function.

‌

[Erik Schnetter]

Yes, this is forbidden. Consider e.g. a global variable declaration, or the definition of an inline function. These have very different meaning when inside a function, or are not allowed.

[Roland Haas]

The global variable declaration I don’t buy. Since those look like:

extern int errno

whether they are in the function or not does not matter (and the extern is required for the declaration otherwise it would be a repeated definition each time the header file is included). Same with function prototypes:

int printf(fmt, ...);

is valid inside of main. Inline function definitions being forbidden seems correct, yes, those cannot be nested in main.

It is, in any case, bad practise to have the header includes in main, even if it may have been allowable at one point in C’s history.

Would it be ok to apply this after the release unless there is urgent need to have this fixed right now?

[Roland Haas]

There is one other “odd' uses of AC_TRY_XXX in Cactus (not failures like this one thoug in CCTK_CHECK_C_INLINE we have

 AC_TRY_COMPILE(, [} $ac_kw int foo() {], [cctk_cv_c_inline=$ac_kw; break])

which probably would be nicer if it did:

AC_TRY_COMPILE($ac_kw int foo(){return 0;}], [], [cctk_cv_c_inline=$ac_kw; break])

since it does not “trick” autoconf by closing the autoconf created main function with the leading }.

[Roland Haas]

With ##2722 we need to test on all clusters anyway and might just as well include this as well.

[Roland Haas]

Applied as git hash 8a5bfc47 "Cactus: Regenerate configure" of cactus

[Roland Haas]

Thank you for the patch.