* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
@ 2021-01-07 11:36 ` anlauf at gcc dot gnu.org
2021-01-07 13:03 ` mehdi.chinoune at hotmail dot com
` (22 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-01-07 11:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
2021-01-07 11:36 ` [Bug fortran/98577] " anlauf at gcc dot gnu.org
@ 2021-01-07 13:03 ` mehdi.chinoune at hotmail dot com
2021-01-07 16:32 ` kargl at gcc dot gnu.org
` (21 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-07 13:03 UTC (permalink / raw)
To: gcc-bugs
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?!
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
2021-01-07 11:36 ` [Bug fortran/98577] " anlauf at gcc dot gnu.org
2021-01-07 13:03 ` mehdi.chinoune at hotmail dot com
@ 2021-01-07 16:32 ` kargl at gcc dot gnu.org
2021-01-07 17:28 ` mehdi.chinoune at hotmail dot com
` (20 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-01-07 16:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (2 preceding siblings ...)
2021-01-07 16:32 ` kargl at gcc dot gnu.org
@ 2021-01-07 17:28 ` mehdi.chinoune at hotmail dot com
2021-01-07 18:01 ` sgk at troutmask dot apl.washington.edu
` (19 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-07 17:28 UTC (permalink / raw)
To: gcc-bugs
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.
>>
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (3 preceding siblings ...)
2021-01-07 17:28 ` mehdi.chinoune at hotmail dot com
@ 2021-01-07 18:01 ` sgk at troutmask dot apl.washington.edu
2021-01-07 18:49 ` mehdi.chinoune at hotmail dot com
` (18 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-01-07 18:01 UTC (permalink / raw)
To: gcc-bugs
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().
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (4 preceding siblings ...)
2021-01-07 18:01 ` sgk at troutmask dot apl.washington.edu
@ 2021-01-07 18:49 ` mehdi.chinoune at hotmail dot com
2021-01-07 18:56 ` mehdi.chinoune at hotmail dot com
` (17 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-07 18:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (5 preceding siblings ...)
2021-01-07 18:49 ` mehdi.chinoune at hotmail dot com
@ 2021-01-07 18:56 ` mehdi.chinoune at hotmail dot com
2021-01-07 20:27 ` sgk at troutmask dot apl.washington.edu
` (16 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-07 18:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (6 preceding siblings ...)
2021-01-07 18:56 ` mehdi.chinoune at hotmail dot com
@ 2021-01-07 20:27 ` sgk at troutmask dot apl.washington.edu
2021-01-07 20:37 ` kargl at gcc dot gnu.org
` (15 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-01-07 20:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (7 preceding siblings ...)
2021-01-07 20:27 ` sgk at troutmask dot apl.washington.edu
@ 2021-01-07 20:37 ` kargl at gcc dot gnu.org
2021-01-08 6:18 ` mehdi.chinoune at hotmail dot com
` (14 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-01-07 20:37 UTC (permalink / raw)
To: gcc-bugs
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().
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (8 preceding siblings ...)
2021-01-07 20:37 ` kargl at gcc dot gnu.org
@ 2021-01-08 6:18 ` mehdi.chinoune at hotmail dot com
2021-01-08 7:21 ` kargl at gcc dot gnu.org
` (13 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-08 6:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (9 preceding siblings ...)
2021-01-08 6:18 ` mehdi.chinoune at hotmail dot com
@ 2021-01-08 7:21 ` kargl at gcc dot gnu.org
2021-01-08 8:04 ` mehdi.chinoune at hotmail dot com
` (12 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-01-08 7:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (10 preceding siblings ...)
2021-01-08 7:21 ` kargl at gcc dot gnu.org
@ 2021-01-08 8:04 ` mehdi.chinoune at hotmail dot com
2021-01-08 8:27 ` mehdi.chinoune at hotmail dot com
` (11 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-08 8:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (11 preceding siblings ...)
2021-01-08 8:04 ` mehdi.chinoune at hotmail dot com
@ 2021-01-08 8:27 ` mehdi.chinoune at hotmail dot com
2021-01-08 16:12 ` kargl at gcc dot gnu.org
` (10 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-08 8:27 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (12 preceding siblings ...)
2021-01-08 8:27 ` mehdi.chinoune at hotmail dot com
@ 2021-01-08 16:12 ` kargl at gcc dot gnu.org
2021-01-08 16:42 ` mehdi.chinoune at hotmail dot com
` (9 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-01-08 16:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (13 preceding siblings ...)
2021-01-08 16:12 ` kargl at gcc dot gnu.org
@ 2021-01-08 16:42 ` mehdi.chinoune at hotmail dot com
2021-01-08 16:59 ` kargl at gcc dot gnu.org
` (8 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-08 16:42 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (14 preceding siblings ...)
2021-01-08 16:42 ` mehdi.chinoune at hotmail dot com
@ 2021-01-08 16:59 ` kargl at gcc dot gnu.org
2021-01-08 18:43 ` mehdi.chinoune at hotmail dot com
` (7 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-01-08 16:59 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (15 preceding siblings ...)
2021-01-08 16:59 ` kargl at gcc dot gnu.org
@ 2021-01-08 18:43 ` mehdi.chinoune at hotmail dot com
2021-01-08 18:55 ` sgk at troutmask dot apl.washington.edu
` (6 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-08 18:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (16 preceding siblings ...)
2021-01-08 18:43 ` mehdi.chinoune at hotmail dot com
@ 2021-01-08 18:55 ` sgk at troutmask dot apl.washington.edu
2021-01-08 19:19 ` sgk at troutmask dot apl.washington.edu
` (5 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-01-08 18:55 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (17 preceding siblings ...)
2021-01-08 18:55 ` sgk at troutmask dot apl.washington.edu
@ 2021-01-08 19:19 ` sgk at troutmask dot apl.washington.edu
2021-01-09 2:34 ` mehdi.chinoune at hotmail dot com
` (4 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-01-08 19:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (18 preceding siblings ...)
2021-01-08 19:19 ` sgk at troutmask dot apl.washington.edu
@ 2021-01-09 2:34 ` mehdi.chinoune at hotmail dot com
2021-01-09 3:43 ` kargl at gcc dot gnu.org
` (3 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2021-01-09 2:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (19 preceding siblings ...)
2021-01-09 2:34 ` mehdi.chinoune at hotmail dot com
@ 2021-01-09 3:43 ` kargl at gcc dot gnu.org
2021-01-09 9:00 ` tkoenig at gcc dot gnu.org
` (2 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-01-09 3:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (20 preceding siblings ...)
2021-01-09 3:43 ` kargl at gcc dot gnu.org
@ 2021-01-09 9:00 ` tkoenig at gcc dot gnu.org
2023-05-14 16:01 ` mehdi.chinoune at hotmail dot com
2023-05-14 16:37 ` tkoenig at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2021-01-09 9:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (21 preceding siblings ...)
2021-01-09 9:00 ` tkoenig at gcc dot gnu.org
@ 2023-05-14 16:01 ` mehdi.chinoune at hotmail dot com
2023-05-14 16:37 ` tkoenig at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: mehdi.chinoune at hotmail dot com @ 2023-05-14 16:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Chinoune <mehdi.chinoune at hotmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |WONTFIX
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
2021-01-07 4:12 [Bug fortran/98577] New: Wrong "count_rate" values with int32 and real32 if the "count" argument is int64 mehdi.chinoune at hotmail dot com
` (22 preceding siblings ...)
2023-05-14 16:01 ` mehdi.chinoune at hotmail dot com
@ 2023-05-14 16:37 ` tkoenig at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2023-05-14 16:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread