[Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

            Bug ID: 98577
           Summary: Wrong "count_rate" values with int32 and real32 if the
                    "count" argument is int64.
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mehdi.chinoune at hotmail dot com
  Target Milestone: ---

program main
  use iso_fortran_env
  implicit none
  integer(int32) :: count_32, count_rate_i32
  integer(int64) :: count_64, count_rate_i64
  real(real32) :: count_rate_r32
  real(real64) :: count_rate_r64
  print*, "count(int_32):"
  call system_clock( count_32, count_rate_i32 )
  print*, "count_rate(int32) = ", count_rate_i32
  call system_clock( count_32, count_rate_i64 )
  print*, "count_rate(int64) = ", count_rate_i64
  call system_clock( count_32, count_rate_r32 )
  print*, "count_rate(real32) = ", count_rate_r32
  call system_clock( count_32, count_rate_r64 )
  print*, "count_rate(real64) = ", count_rate_r64
  print*, "count(int_64):"
  call system_clock( count_64, count_rate_i32 )
  print*, "count_rate(int32) = ", count_rate_i32
  call system_clock( count_64, count_rate_i64 )
  print*, "count_rate(int64) = ", count_rate_i64
  call system_clock( count_64, count_rate_r32 )
  print*, "count_rate(real32) = ", count_rate_r32
  call system_clock( count_64, count_rate_r64 )
  print*, "count_rate(real64) = ", count_rate_r64
end program main

$ gfortran bug_gcc_tic.f90 -o test.x
count(int_32):                                                                 
                                                                               
     count_rate(int32) =         1000                                          
                                                                               
          count_rate(int64) =                  1000                            
                                                                               
               count_rate(real32) =    1000.00000                              
                                                                               
                    count_rate(real64) =    1000.0000000000000                 
                                                                               
                         count(int_64):                                        
                                                                               
                              count_rate(int32) =         1000                 
                                                                               
                                   count_rate(int64) =            1000000000   
                                                                               
                                        count_rate(real32) =    1000.00000     
                                                                               
                                             count_rate(real64) =   
1000000000.0000000

$ ifort bug_gcc_tic.f90 -o test.x
 count(int_32):                                                                
                                                                               
      count_rate(int32) =        10000                                         
                                                                               
           count_rate(int64) =                  10000                          
                                                                               
                count_rate(real32) =    10000.00                               
                                                                               
                     count_rate(real64) =    10000.0000000000                  
                                                                               
                          count(int_64):                                       
                                                                               
                               count_rate(int32) =      1000000                
                                                                               
                                    count_rate(int64) =                1000000 
                                                                               
                                         count_rate(real32) =    1000000.      
                                                                               
                                              count_rate(real64) =   
1000000.00000000

I am reporting this because I got wrong time intervals with
system_clock(int64,real32).

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from anlauf at gcc dot gnu.org ---
This is standard conforming and documented.

See https://gcc.gnu.org/onlinedocs/gfortran/SYSTEM_005fCLOCK.html

COUNT_RATE is system dependent and can vary depending on the kind of the
arguments. For kind=4 arguments (and smaller integer kinds), COUNT represents
milliseconds, while for kind=8 arguments (and larger integer kinds), COUNT
typically represents micro- or nanoseconds depending on resolution of the
underlying platform clock. COUNT_MAX usually equals HUGE(COUNT_MAX). Note that
the millisecond resolution of the kind=4 version implies that the COUNT will
wrap around in roughly 25 days. In order to avoid issues with the wrap around
and for more precise timing, please use the kind=8 version.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

Chinoune <mehdi.chinoune at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #2 from Chinoune <mehdi.chinoune at hotmail dot com> ---
program main
  use iso_fortran_env
  implicit none
  !
  integer(int32) :: count_rate_i32
  integer(int64) :: t1, t2, t3, t4, t5, t6
  real(real32) :: count_rate_r32
  real(real64) :: count_rate_r64
  !
  integer(int32), parameter :: n = 2048
  real(real64), allocatable :: a(:,:), b(:,:), c(:,:)
  integer :: i, j, k
  !
  allocate( a(n,n), b(n,n), c(n,n) )
  call random_number( a )
  call random_number( b )
  !
  call system_clock( t1, count_rate_r32 )
  c = matmul( a, b )
  call system_clock( t2 )
  !
  call system_clock( t3, count_rate_i32 )
  b = matmul( c, a )
  call system_clock( t4 )
  !
  call system_clock( t5, count_rate_r64 )
  a = matmul( b, c )
  call system_clock( t6 )
  !
  print*, "count_rate_r32:", (t2-t1)/count_rate_r32
  print*, "count_rate_i32:", (t4-t3)/real(count_rate_i32,real64)
  print*, "count_rate_r64:", (t6-t5)/count_rate_r64
  !
end program main

$ gfortran-9 -O3 bug_gcc_98577_2.f90 -o test.x
$ ./test.x                                                                     
                                                 count_rate_r32:   478419744.  
                                                                               
                                                      count_rate_i32:  
479128968.57999998                                                             
                                                                  
count_rate_r64:  0.71684850000000000

$ gfortran-10 -O3 bug_gcc_98577_2.f90 -o test.x
$ ./test.x                                                                     
                                                 count_rate_r32:   568052096.  
                                                                               
                                                      count_rate_i32:  
568763156.84800005                                                             
                                                                  
count_rate_r64:  0.71658250000000001

Can you explain these results?!

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #2)
> program main
>   use iso_fortran_env
>   implicit none
>   !
>   integer(int32) :: count_rate_i32
>   integer(int64) :: t1, t2, t3, t4, t5, t6
>   real(real32) :: count_rate_r32
>   real(real64) :: count_rate_r64

(brevity)

> $ gfortran-10 -O3 bug_gcc_98577_2.f90 -o test.x
> $ ./test.x                                                                  
> count_rate_r32:   568052096.                                                
> count_rate_i32:   568763156.84800005                                        
> count_rate_r64:  0.71658250000000001
> 
> Can you explain these results?!

Harald just explained it to you.

% gfcg -o z -Wall a.f90 && ./z
integer
  kind:     1      2           4                    8
 count:  -127 -32767   996821773      996821773517757
  rate:     0      0        1000           1000000000
   max:     0      0  2147483647  9223372036854775807

real:
  kind     4            8           10           16
  rate: 1000.0 1000000000.0 1000000000.0 1000000000.0


For integer(4) and real(4), the number of ticks per second
is 1000, i.e., count_rate.  For integer(4) and real(4), the
count is done in units of 1/1000, i.e., 1/count_rate.

For integer(8) (and integer(16) if support) and real(8),
real(10), and real(16), the number of ticks per second 
is 1000000000.  For integer(8) (and integer(16) if support),
count is done in units of 1/1000000000, ie., 1/count_rate.

In your program when you do your scaling, it is mixing units.

   print*, "count_rate_r32:", (t2-t1)/count_rate_r32

t2-t1 is nanosecond time scale.  count_rate_r32 is millisecond time scale.

   print*, "count_rate_i32:", (t4-t3)/real(count_rate_i32,real64)

t4-t3 is nanosecond time scale.  count_rate_i32 is millisecond time scale.

   print*, "count_rate_r64:", (t6-t5)/count_rate_r64

t6-t5 is nanosecond time scale.  count_rate_r64 is nanosecond time scale.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

--- Comment #4 from Chinoune <mehdi.chinoune at hotmail dot com> ---
(In reply to kargl from comment #3)
> (In reply to Chinoune from comment #2)
> > program main
> >   use iso_fortran_env
> >   implicit none
> >   !
> >   integer(int32) :: count_rate_i32
> >   integer(int64) :: t1, t2, t3, t4, t5, t6
> >   real(real32) :: count_rate_r32
> >   real(real64) :: count_rate_r64
> 
> (brevity)
> 
> > $ gfortran-10 -O3 bug_gcc_98577_2.f90 -o test.x
> > $ ./test.x                                                                  
> > count_rate_r32:   568052096.                                                
> > count_rate_i32:   568763156.84800005                                        
> > count_rate_r64:  0.71658250000000001
> > 
> > Can you explain these results?!
> 
> Harald just explained it to you.
> 
> % gfcg -o z -Wall a.f90 && ./z
> integer
>   kind:     1      2           4                    8
>  count:  -127 -32767   996821773      996821773517757
>   rate:     0      0        1000           1000000000
>    max:     0      0  2147483647  9223372036854775807
> 
> real:
>   kind     4            8           10           16
>   rate: 1000.0 1000000000.0 1000000000.0 1000000000.0
> 
> 
> For integer(4) and real(4), the number of ticks per second
> is 1000, i.e., count_rate.  For integer(4) and real(4), the
> count is done in units of 1/1000, i.e., 1/count_rate.
> 
> For integer(8) (and integer(16) if support) and real(8),
> real(10), and real(16), the number of ticks per second 
> is 1000000000.  For integer(8) (and integer(16) if support),
> count is done in units of 1/1000000000, ie., 1/count_rate.
> 
> In your program when you do your scaling, it is mixing units.
> 
>    print*, "count_rate_r32:", (t2-t1)/count_rate_r32
> 
> t2-t1 is nanosecond time scale.  count_rate_r32 is millisecond time scale.
> 
>    print*, "count_rate_i32:", (t4-t3)/real(count_rate_i32,real64)
> 
> t4-t3 is nanosecond time scale.  count_rate_i32 is millisecond time scale.
> 
>    print*, "count_rate_r64:", (t6-t5)/count_rate_r64
> 
> t6-t5 is nanosecond time scale.  count_rate_r64 is nanosecond time scale.

There is no mention of your claims in the standard:

Fortran 2018:
<<
6.9.186 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX])
 1 Description. Query system clock.
 2 Class. Subroutine.
 3 Arguments.
  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
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
number of processor clock counts per second, or zero if there is no clock for
the invoking image.
  COUNT_MAX (optional) shall be an integer scalar. It is an INTENT (OUT)
argument. It is assigned the maximum value that COUNT can have, or zero if
there is no clock for the invoking image.

 4 Whether an image has no clock, has a single clock of its own, or shares a
clock with another image, is processor dependent.
 5 Example. If the processor clock is a 24-hour clock that registers time at
approximately 18.20648193 ticks per second, at 11:30 A.M. the reference CALL
SYSTEM_CLOCK (COUNT = C, COUNT_RATE = R, COUNT_MAX = M) defines C =
(11×3600+30×60)×18.20648193 = 753748, R = 18.20648193, and M =
24×3600×18.20648193−1 = 1573039.
>>

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
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().

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

Chinoune <mehdi.chinoune at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #7 from Chinoune <mehdi.chinoune at hotmail dot com> ---
ABCDEFGH

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jan 07, 2021 at 06:49:07PM +0000, mehdi.chinoune at hotmail dot com
wrote:
> 
> I am not asking for advice here, I reported a bug with its reproducer.

What bug?

> It is not your concern what kind of integer I choose to use since it is not
> invalid.

Sure, you can use any integer kind.  What you get back is 
processor-dependent.  The gfortran documentation tells you
what that dependence is.

> The standard doesn't say anything about mixing precisions.

I agree.  It says the values returned for COUNT and
COUNT_RATE are processor-dependent.

If COUNT is integer(4), the counting is done in units of milliseconds.
If COUNT is integer(kind>4), the counting is done in units of nanoseconds.

If COUNT_RATE is integer(4) or real(4), it will be set to 1000, because
that's how many milliseconds are in 1 second.
If COUNT_RATE is integer(kind>4) or real(kind>4), it will be set to
1000000000, because that's how many nanoseconds are in 1 second.

These are processor-dependent values chosen by gfortran.

> 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.

You did not define what you mean by "correct value".  If you
meant int64/int32 is supposed to be elapsed time in units of
seconds, I cannot find where the Standard states that.  For
a processor that has more than one count_rate, in the following, 

  integer i,j
  call system_clock(count=i)
  call some_long_time_sub
  call system_clock(count=j)
  print *, j - i
  end 

how is the processor suppose to determine which count_rate
units should be used to do the counting?

It is the programmer's responsibility to read the
documentation provided with the processor to determine
the processor-dependent behavior, and then write code
based on that documentation.

It seems you have an issue with J3.  Perhaps, you need
to send an interpretation request to the Fortran Standard
committee.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |INVALID

--- Comment #9 from kargl at gcc dot gnu.org ---
Change WONTFIX to INVALID.

OP refuses to acknowledge the gfortran documentation clearly spells out the
processor-dependent behavior for system_clock().

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

Chinoune <mehdi.chinoune at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |WONTFIX

--- Comment #10 from Chinoune <mehdi.chinoune at hotmail dot com> ---
Intel Fortran 2021 reports the correct time:

$ ifort -O3 bug_gcc_98577.f90 -o test.x
$ ./test.x
 count_rate_r32:   1.219512    
 count_rate_i32:   1.23957700000000     
 count_rate_r64:   1.24717100000000

$ ifx -O3 bug_count_rate.f90 -o test.x
$ ./test.x
 count_rate_r32:   6.216970    
 count_rate_i32:   6.89329900000000     
 count_rate_r64:   6.90696400000000

Thanks God, It is now available for free.

Unlike the old time when gfortran was the only choice, we have now two other
commercial compilers avialable for free (Intel and Nvidia) + the incoming
LLVM/Flang.

Thanks God, Alhamdu-li-Allah.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |INVALID

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #10)
> Intel Fortran 2021 reports the correct time:
> 
> $ ifort -O3 bug_gcc_98577.f90 -o test.x
> $ ./test.x
>  count_rate_r32:   1.219512    
>  count_rate_i32:   1.23957700000000     
>  count_rate_r64:   1.24717100000000
> 
> $ ifx -O3 bug_count_rate.f90 -o test.x
> $ ./test.x
>  count_rate_r32:   6.216970    
>  count_rate_i32:   6.89329900000000     
>  count_rate_r64:   6.90696400000000
> 
> Thanks God, It is now available for free.
> 
> Unlike the old time when gfortran was the only choice, we have now two other
> commercial compilers avialable for free (Intel and Nvidia) + the incoming
> LLVM/Flang.

Please stop.  Gfortran does not have a bug.  You are dividing 
one processor-dependent value by another processor-dependent
value.  The two processor-dependent values that you have asked
gfortran to return are incompatible.  You have been told that
this behavior is documented, but you refuse to accept it.

Your above test shows only that Intel may have only *ONE* count_rate.
gfortran provides TWO count_rate values that allow both low and high
resolution timing.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

Chinoune <mehdi.chinoune at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |WONTFIX

--- Comment #12 from Chinoune <mehdi.chinoune at hotmail dot com> ---
First example:

$ ifort bug_gcc_tic.f90 -o test.x
$ ./test.x
count(int_32):                                                                 
                                                                               
     count_rate(int32) =        10000                                          
                                                                               
          count_rate(int64) =                  10000                           
                                                                               
               count_rate(real32) =    10000.00                                
                                                                               
                    count_rate(real64) =    10000.0000000000                   
                                                                               
                         count(int_64):                                        
                                                                               
                              count_rate(int32) =      1000000                 
                                                                               
                                   count_rate(int64) =                1000000  
                                                                               
                                        count_rate(real32) =    1000000.       
                                                                               
                                             count_rate(real64) =   
1000000.00000000

Unlike gfortran, count_rate with ifort depends only on the precision of the
first argument of system_clock. It doesn't mixup.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

--- Comment #13 from Chinoune <mehdi.chinoune at hotmail dot com> ---
$ gfortran bug_gcc_tic.f90 -o test.x
count(int_32):                                                                 
                                                                               
     count_rate(int32) =         1000                                          
                                                                               
          count_rate(int64) =                  1000                            
                                                                               
               count_rate(real32) =    1000.00000                              
                                                                               
                    count_rate(real64) =    1000.0000000000000                 
                                                                               
                         count(int_64):                                        
                                                                               
                              count_rate(int32) =         1000                 
                                                                               
                                   count_rate(int64) =            1000000000   
                                                                               
                                        count_rate(real32) =    1000.00000     
                                                                               
                                             count_rate(real64) =   
1000000000.0000000

The odd with gfortran is that it reports the same value for count_rate (1000)
with all the kinds (int32,int64,real32,real64) when the first argument is
int32. but it reports different values when the first argument is int64.

The question:
In which factor does count_rate value depends: its precision, the first
argument precision or just a mixup?

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |INVALID

--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #12)
> First example:
> 
> $ ifort bug_gcc_tic.f90 -o test.x
> $ ./test.x
> count(int_32):                                                              
> count_rate(int32) =        10000                                            
> count_rate(int64) =                  10000                                  
> count_rate(real32) =    10000.00                                            
> count_rate(real64) =    10000.0000000000                                    
> count(int_64):                                                              
> count_rate(int32) =      1000000                                            
> count_rate(int64) =                1000000                                  
> count_rate(real32) =    1000000.                                            
> count_rate(real64) =    1000000.00000000
> 
> Unlike gfortran, count_rate with ifort depends only on the precision of the
> first argument of system_clock. It doesn't mixup.

That is not required by the Fortran Standard, but conforms because
COUNT and COUNT_RATE are processor-dependent.

I also took the opportunity to look at the Intel Fortran documentation at

https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/a-to-z-reference/s-1/system-clock.html

dated 4 dec 2020.  Note, the following hightlighted sentence on
that page:

   "All integer arguments used must have the same integer kind parameter."

That is not required by Fortran Standard.  Why would Intel require
compatible kind type parameters?  Your program in comment #0 does
meet the requirements placed on system_clock() by Intel.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

Chinoune <mehdi.chinoune at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |WONTFIX

--- Comment #15 from Chinoune <mehdi.chinoune at hotmail dot com> ---
Bug is a bug!

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |INVALID

--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #15)
> Bug is a bug!

It's not a bug if the behavior is documented.

What does Intel do with this standard conforming program?

program foo

   use iso_fortran_env, only : int32, int64, real64

   implicit none

   integer(int32) rate4, t1, t2
   integer(int64) rate8, u1, u2
   !
   ! Both Intel and gfortran should give the same timings as
   ! COUNT and COUNT_RATE variables have the same kind type
   ! parameter.  This is documented by both gfortran and Intel.
   !
   print '(A)', 'Behavior documented to give valid timings with gfortran and
Intel'
   call system_clock(count_rate=rate4)
   print '(A,I0)', 'rate4 = ', rate4
   call system_clock(count_rate=rate8)
   print '(A,I0)', 'rate8 = ', rate8

   call system_clock(count=t1)
   call loop
   call system_clock(count=t2)
   print '(A,F0.3,A)', 'time = ', real(t2-t1,real64)/rate4, ' seconds
(int32/int32)'

   call system_clock(count=u1)
   call loop
   call system_clock(count=u2)
   print '(A,F0.3,A)', 'time = ', real(u2-u1,real64)/rate8, ' seconds
(int64/int64)'
   !
   ! gfortran gives an invalid time with the following, but gfortran
   ! also documents the behavior.  What does Intel do?
   !
   print *
   print '(A)', 'Behavior documented to give invalid timings with gfortran'
   call system_clock(count_rate=rate8)
   print '(A,I0)', 'rate8 = ', rate8
   call system_clock(count=t1)
   call loop
   call system_clock(count=t2)
   print '(A,F0.3,A)', 'time = ', real(t2-t1,real64)/rate8, ' seconds
(int32/int64)'

   call system_clock(count_rate=rate4)
   print '(A,I0)', 'rate4 = ', rate4
   call system_clock(count=u1)
   call loop
   call system_clock(count=u2)
   print '(A,F0.3,A)', 'time = ', real(u2-u1,real64)/rate4, ' seconds
(int64/int32)'

   contains

      subroutine loop
         implicit none
         real(real64) dx, x, y
         integer i
         integer, parameter :: n = 100000001
         dx = 1._real64 / (n - 1)
         do i = 1, n
            x = 1000 + (i - 1) * dx
            y = cos(x)
            x = sin(x)
            if (x * y > 2) stop 1
         end do
      end subroutine loop

end program foo

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

--- Comment #17 from Chinoune <mehdi.chinoune at hotmail dot com> ---
Once I reported a bug to gcc/gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 but someone argued that it
was my fault to use "-Ofast" so I rewrite the reproducer in C and reported
again under another category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734. the bug was confirmed and
fixed without someone blaming me for that.
Another when I reported another bug but that "someone" said that my reproducer
is invalid, fortunately some other guys didn't take his opinion under
consideration and they fixed the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736

The problem is that "someone" still there (fortran category) attacking anyone
who dare to report a bug in gfortran.

I concluded that is a waste of time arguing with him.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #18 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Jan 08, 2021 at 06:43:20PM +0000, mehdi.chinoune at hotmail dot com
wrote:
> 
> I concluded that is a waste of time arguing with him.
> 

Did you run the test program from my last comment?

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #19 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Jan 08, 2021 at 06:43:20PM +0000, mehdi.chinoune at hotmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
> 
> --- Comment #17 from Chinoune <mehdi.chinoune at hotmail dot com> ---
> Once I reported a bug to gcc/gfortran
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 but someone argued that it
> was my fault to use "-Ofast" so I rewrite the reproducer in C and reported
> again under another category
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734. the bug was confirmed and
> fixed without someone blaming me for that.

Fortran and C are different languages.  I standby my
assessment.  Options that cause the compiler to knowingly
violate the Fortran Standard and cause unexpected behavior
do not justify a bug.

> Another when I reported another bug but that "someone" said that my reproducer
> is invalid, fortunately some other guys didn't take his opinion under
> consideration and they fixed the bug.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736

Well, I actually I never stated the code was invalid.

In comment #1, I said I "Not sure the code is conforming,
and don't have time to investigate (unless someone is
willing to cough up $$)."  Also, suggested two workarounds
that would get you passed the issue.

In comment #2, you stated "You introduced a regression
and it is your duty to fix it."

In comment #3, I clearly stated "When it comes to gfortran,
I have no duty to you or anyone else.  I have neither the
time nor now the inclination to look at this bug (unless
someone coughs up $$$$ (price just went up ;))."

At this point, I stopped looking at the bug because I
have a real job that pays me $ to feed my family, and
I found the tone of your comment #3 to b rude.  

So, in summary you once again are bending what is written
to your reality.

> The problem is that "someone" still there (fortran category)
> attacking anyone who dare to report a bug in gfortran.

You are not being attacked.  You are being educated on
what processor-dependent behavior means, and you have been
told that the gfortran documentation tells you what the
processor-dependent behavior is.  If you refuse to learn,
neither I nor anyone else can help you.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

Chinoune <mehdi.chinoune at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |tkoenig at gcc dot gnu.org
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #20 from Chinoune <mehdi.chinoune at hotmail dot com> ---
won't fix.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[kargl at gcc dot gnu.org]

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

--- 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 = 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))
= 4, and you get milliseconds.  For the second, kind(t2) = 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 = matmul( a, b )
  call system_clock(t2)

will give you the wrong timing with both gfortran and Intel, or 
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.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #22 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Resolving as invalid. Steve explained it quite well.

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[mehdi.chinoune at hotmail dot com]

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

Chinoune <mehdi.chinoune at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |WONTFIX

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |INVALID