From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30652 invoked by alias); 15 Mar 2011 17:20:28 -0000 Received: (qmail 30642 invoked by uid 22791); 15 Mar 2011 17:20:26 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Mar 2011 17:20:22 +0000 From: "jb at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jb at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: jb at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 15 Mar 2011 17:53:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg01594.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #40 from Janne Blomqvist 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.