[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

["jb at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #40 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-15 17:19:43 UTC ---
(In reply to comment #37)
> >> I'd really like to see this fixed before 4.6.0: it is a regression from
> >> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively
> >> minor gain on other platforms.
> >
> > Well, do we really have any actual gfortran users on Tru64? Whereas a
> > high-resolution monotonic clock, while admittedly not a huge feature per se, is
> > something that is now available to gfortran users on some rather more popular
> > platforms.
> 
> Why would they tell me: `Hey, I'm using gfortran on Tru64 UNIX and all
> is fine.'?   You will only learn if things break.

While I have no proof, I find it difficult to imagine that we have a
significant amount of bleeding edge users that upgrade to the latest and
greatest gcc release on an expensive platform where new hw isn't sold since
many years, and the OS is scheduled to go EOL in a year or so. So while IMHO it
would be nice if we could get a fix into 4.6, I don't think it's the end of the
world if these users, if they exist at all, will have to wait until 4.6.1.

> >>  If all else fails, I'd go as far as
> >> advocating to revert the patch that introduced clock_gettime
> >
> > There has been a number of patches in this area more or less related to
> > clock_gettime, so IMHO fixing it properly is simpler and less prone to
> > introduce new regressions. My previous message in this PR hopefully does
> > exactly this and introduces a patch which should fix it along the lines
> > previously discussed. As my normal gcc development machine is packed in a box,
> > I haven't been able to test it. Also, note that it won't apply cleanly as the
> > paths are messed up (but the contents should otherwise apply fine). 
> 
> There have been some subsequent suggestions/updates, so I'm uncertain if
> I should test this patch or wait for an update.

The suggestion are only for the potential corner case where CLOCK_* are not
preprocessor macros but e.g. enums. In any case, this is fixed in the updated
patch I just posted, so feel free to try that one.

> Now that 4.6 has branched, it's safer to commit to mainline after some
> testing and only backport to 4.6 after it has proven correct.

I agree.

>  If all
> else fails, one could apply a hack to 4.6 along the lines of
> 
> #if defined(__alpha__) && defined(__osf__)
> #undef HAVE_CLOCK_GETTIME
> #endif
> 
> or some configure.ac equivalent.  Ugly but still better than completely
> breaking Fortran.

Yes, that's a possibility. OTOH I think my patch should be fairly simple and
safe, but ultimately that's up to the reviewer(s) to decide.