https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577

--- Comment #6 from Chinoune <mehdi.chinoune at hotmail dot com> ---
(In reply to Steve Kargl from comment #5)
> On Thu, Jan 07, 2021 at 05:28:15PM +0000, mehdi.chinoune at hotmail dot com
> wrote:
> > There is no mention of your claims in the standard:
> > 
> 
> I know what the standard says.
> 
> > Fortran 2018:
> >   COUNT (optional) shall be an integer scalar. It is an INTENT (OUT) 
> > argument.
> > It is assigned a processor-dependent value based on the value of a processor
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> This is kinda of important.
> 
> > clock, or −HUGE (COUNT) if there is no clock for the invoking image. The
> > processor-dependent value is incremented by one for each clock count until 
> > the
> > value COUNT_MAX is reached and is reset to zero at the next count. It lies 
> > in
> > the range 0 to COUNT_MAX if there is a clock.
> >   COUNT_RATE (optional) shall be an integer or real scalar. It is an INTENT
> > (OUT) argument. It is assigned a processor-dependent approximation to the
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> This is kinda of important.
> 
> To understand what processor-dependent choices gfortran
> made, you need to read the gfortran documentation where
> the millisecond/nanosecond scaling/counting is discussed.
> A fixed count_rate of 1000 and millisecond resolution worked
> well 25 years.  On modern hardware and depending on what 
> you want to time, a count_rate of 1000 and millisecond
> resolution is unusable as it is not fine-grained enough. 
> Setting the count_rate to a fixed 100000000 for nanosecond
> counting on modern hardware is possible, but counting 
> with integer(4) would give you 2.147483647 seconds before
> the counter wraps around.  Not exactly usable for many.
> 
> If all you want to do is time a loop, use cpu_time().

I am not asking for advice here, I reported a bug with its reproducer.
It is not your concern what kind of integer I choose to use since it is not
invalid.
The standard doesn't say anything about mixing precisions.
I didn't say that gfortran should report 1000 or 10000 or 14659827, I know It
is a processor-dependent.
The problem is that gfortran doesn't give the correct values for
count/count_rate when it is int64/int32 or int64/real32 which doesn't have any
basis in the standard.

Please, stop trolling.

Reply via email to