http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #34 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-14 11:42:47 UTC --- (In reply to comment #31) > > That being said, I'd prefer to postpone this fix to stage 1 due to > > > > - I'm currently moving flats so my stuff is all over and I'm very busy > > - AFAIU 4.6 release is imminent? > > - I lack the ability to test all weird and wonderful targets. > > - This close to release I'd very much like to avoid regressions in primary > > or > > secondary targets. > > - As can be seen in the reopening of this PR, for less used targets there > > might > > anyway be a month latency between something landing in trunk and getting > > test > > reports. > > Not really: the delay was caused because the test system broke and it > took me quite some time to get myself a replacement. Normally, I > bootstrap everywhere once a week and analyse results. Ok, that's nice to hear. Of course, it doesn't change the fact that this time it did take a month, and, one might add, at almost the worst possible moment. ;) > > Thus, I'd suggest fixing this in stage 1, then, after getting reports that > > the > > fix works, backport hopefully in time for 4.6.1. > > > > Of course, the above is only my own justifications and constraints; if > > someone > > else wants to fix it ASAP, go right ahead. > > 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. > 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). As I mentioned previously, I'd prefer to commit it after the 4.6 release, but if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6. > (and quite > late in the release cycle, I might say). Yes, it started out as a simple patch which turned into a morass of system-dependent stuff wrt. where clock_gettime lives and various levels of weakref support. Sorry about that.
