From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15358 invoked by alias); 4 Jan 2015 22:53:16 -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 Received: (qmail 15298 invoked by uid 48); 4 Jan 2015 22:53:08 -0000 From: "anlauf at gmx dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate Date: Sun, 04 Jan 2015 22:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gmx dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: fxcoudert at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg00186.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #13 from Harald Anlauf --- (In reply to Francois-Xavier Coudert from comment #12) > (In reply to Harald Anlauf from comment #10) > > Partial patch to handle proposed behavior of system_clock > > Thanks for the partial patch. Some quick critique: > - it doesn't handle mixed argument kinds (you said you don't care, but > others might) I originally said that I wouldn't care, but after playing with other compilers I reconsidered (see comment #7). Actually the patch does handle it in the most simple way: all arguments are independent. See the test case in comment #11. (My tentative patch did not remove code that compares the kinds of the arguments etc.) > - it creates multiple calls to the library (performance issue, especially > on a timing routine) True. But as long as only COUNT is present, there's no performance difference to the old behavior. That's how I use SYSTEM_CLOCK. Optimizations for multiple present arguments are possible but require lengthy coding. I haven't looked at the library code, but calls to determine count_max and count_rate should be extremely cheap. > - I disagree with the logic for COUNT_RATE: we don't care what kind it is, > because any "decent" kind (32-bit int, 64-bit int, or any real kind) is > large enough to store the value. Probably true for all present and future gfortran implementations. (With crayftn I have seen COUNT_RATE = cpu clockspeed for integer(8), and 2.6 GHz is too large for 32 bit...). Nevertheless, I'd prefer the same COUNT_RATE for default integer(4) and default real(4), and similarly for integer(>=8) and real(>=8). > We've got to define an implementation that works for everyone, and for all > corner cases. Then we can implement it. I've indicated on comp.lang.fortran > what I think is the best strategy: > > a) if any integer kind is 1 or 2, we emit a warning at compile-time and > behave as if no clock is available OK. This is better than a timer with ridiculously low count_rate/_max. > b) for COUNT_RATE, we treat a real as a "wide" int (64-bit or more) I'd prefer real(4) ~ integer(4), see above reasoning. > c) if the kinds of present arguments don't match, issue a compile-time > warning OK. (No other compiler I've met complains here, but it's good to warn users to expect trouble). > d) if all present args are wide, go for high-res, otherwise go for low-res. That's up to you. But I'd prefer to stay consistent with what other compilers do. (I didn't post the crayftn behavior, but it is sort of similar to what Intel does, except for somewhat odd count_rates.) > How does that sound? > > > I will have some time to deal with this in a week.