From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D4E5C385781F; Sat, 9 Jan 2021 03:43:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4E5C385781F From: "kargl at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64. Date: Sat, 09 Jan 2021 03:43:31 +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: 10.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kargl at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2021 03:43:31 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98577 --- Comment #21 from kargl at gcc dot gnu.org --- (In reply to Chinoune from comment #20) > won't fix. This is hilarious! Now, I know why you are so confused. >>From your code in comment #2 call system_clock( t1, count_rate_r32 ) c =3D matmul( a, b ) call system_clock( t2 ) t1 and t2 are integer(8) and count_rate_r32 is integer(4). In the first call to system_clock(), the clock rate is set 1000 and t1 counts ticks on the millisecond time scale. In the second call to system_clock(), t2 counts ticks on the nanosecond time scale. gfortran uses the least kind type parameter of the actual arguments to determine which time scale to use. So, for the first call of system_clock(), min(kind(t1), kind(count_rate_r32)) =3D 4, and you get milliseconds. For the second, kind(t2) =3D 8, and you get nanoseconds. Intel, which appears to be your gold standard, chooses to use the kind type parameter of the first argument. Both implementations are correct because ...... these are processor-dependent values. To paraphrase, Steve Lionel (former Intel Fortran compiler engineer), asks "why one would mix types?" See comp.lang.fortran for his comment. Note, the sequence call system_clock(count_rate_r32) call system_clock(t1) c =3D matmul( a, b ) call system_clock(t2) will give you the wrong timing with both gfortran and Intel, or=20 will give a correct relative timing. So, to summarize, you are seeing processor-dependent behavior. There is no bug, here. There is nothing to fix.=