[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #39 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on trunk. Thanks all for testing and suggestions.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #36 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #35) Author: jvdelisle Date: Tue Mar 17 01:22:12 2015 New Revision: 221473 URL: https://gcc.gnu.org/viewcvs?rev=221473root=gccview=rev Log: 2015-03-16 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64432 * gfortran.dg/system_clock_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08 Modified: trunk/gcc/testsuite/ChangeLog Jerry, are you sure that .and.ing the conditions in the testcase is correct, or shouldn't they rather be .or.ed?
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #38 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Wed Mar 18 01:47:12 2015 New Revision: 221482 URL: https://gcc.gnu.org/viewcvs?rev=221482root=gccview=rev Log: 2015-03-17 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64432 * gfortran.dg/system_clock_3.f08: Adjust test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #37 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #36) --snip--- are you sure that .and.ing the conditions in the testcase is correct, or shouldn't they rather be .or.ed? Oh of course. Thanks Harald. I will set it right
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #35 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Mar 17 01:22:12 2015 New Revision: 221473 URL: https://gcc.gnu.org/viewcvs?rev=221473root=gccview=rev Log: 2015-03-16 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64432 * gfortran.dg/system_clock_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #34 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Mar 17 01:04:58 2015 New Revision: 221472 URL: https://gcc.gnu.org/viewcvs?rev=221472root=gccview=rev Log: 2015-03-16 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/64432 * intrinsics/system_clock.c (system_clock4, system_clock8): Cleanup some whitespace. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/system_clock.c
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #33 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Mar 17 01:01:54 2015 New Revision: 221471 URL: https://gcc.gnu.org/viewcvs?rev=221471root=gccview=rev Log: 2015-03-16 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64432 *trans-intrinisic.c (conv_intrinsic_system_clock): Check the smallest kind passed in user arguments and hardcode tesults for KIND=1 or KIND=2 to indicate no clock available. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #32 from Harald Anlauf anlauf at gmx dot de --- Jerry, to give you some positive feedback: I'm now using your latest patch in https://gcc.gnu.org/ml/fortran/2015-03/msg00067.html It works for me. Thanks, Harald
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #31 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I have generated a test case that includes all possible combinations and found some issues with the patch related to Real (KIND 10). I am working this now.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #29 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Clean patch to avoid the errors: variable '*' set but not used
--- ../_clean/gcc/fortran/trans-intrinsic.c2015-01-17 21:48:17.0
+0100
+++ gcc/fortran/trans-intrinsic.c2015-02-22 13:02:40.0 +0100
@@ -2670,23 +2670,15 @@ conv_intrinsic_system_clock (gfc_code *c
{
stmtblock_t block;
gfc_se count_se, count_rate_se, count_max_se;
- tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE;
- tree type, tmp;
- int kind;
+ tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE,
+ arg4 = NULL_TREE;
+ tree tmp;
+ int least, most;
gfc_expr *count = code-ext.actual-expr;
gfc_expr *count_rate = code-ext.actual-next-expr;
gfc_expr *count_max = code-ext.actual-next-next-expr;
- /* The INTEGER(8) version has higher precision, it is used if both COUNT
- and COUNT_MAX can hold 64-bit values, or are absent. */
- if ((!count || count-ts.kind = 8)
- (!count_max || count_max-ts.kind = 8))
-kind = 8;
- else
-kind = gfc_default_integer_kind;
- type = gfc_get_int_type (kind);
-
/* Evaluate our arguments. */
if (count)
{
For the test don't forget that real(10) are not available on some platforms and
that real(16) may have different formats (I won't have access to my G5 until
the end of the coming week - no testing on powerpc).
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #28 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Bootstrapping with the patch in comment 26 fails with
/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin14.1.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs
-I/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/include/x86_64-apple-darwin14.1.0
-I/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs
-c -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. -Ifortran -I../../work/gcc -I../../work/gcc/fortran
-I../../work/gcc/../include -I./../intl -I../../work/gcc/../libcpp/include
-I/opt/mp-new/include -I../../work/gcc/../libdecnumber
-I../../work/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../work/gcc/../libbacktrace -I/opt/mp-new/include -o
fortran/trans-intrinsic.o -MT fortran/trans-intrinsic.o -MMD -MP -MF
fortran/.deps/trans-intrinsic.TPo ../../work/gcc/fortran/trans-intrinsic.c
../../work/gcc/fortran/trans-intrinsic.c: In function 'tree_node*
conv_intrinsic_system_clock(gfc_code*)':
../../work/gcc/fortran/trans-intrinsic.c:2675:8: error: variable 'type' set but
not used [-Werror=unused-but-set-variable]
tree type, tmp;
^
cc1plus: all warnings being treated as errors
../../work/gcc/fortran/trans-intrinsic.c: In function 'tree_node*
conv_intrinsic_system_clock(gfc_code*)':
../../work/gcc/fortran/trans-intrinsic.c:2676:7: error: variable 'kind' set but
not used [-Werror=unused-but-set-variable]
int kind, least, most;
^
cc1plus: all warnings being treated as errors
The following patch (code commented) fixes bootstrap
--- ../_clean/gcc/fortran/trans-intrinsic.c2015-01-17 21:48:17.0
+0100
+++ gcc/fortran/trans-intrinsic.c2015-02-22 11:48:14.0 +0100
@@ -2670,9 +2670,10 @@ conv_intrinsic_system_clock (gfc_code *c
{
stmtblock_t block;
gfc_se count_se, count_rate_se, count_max_se;
- tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE;
- tree type, tmp;
- int kind;
+ tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE,
+ arg4 = NULL_TREE;
+ tree tmp;
+ int least, most;
gfc_expr *count = code-ext.actual-expr;
gfc_expr *count_rate = code-ext.actual-next-expr;
@@ -2680,12 +2681,12 @@ conv_intrinsic_system_clock (gfc_code *c
/* The INTEGER(8) version has higher precision, it is used if both COUNT
and COUNT_MAX can hold 64-bit values, or are absent. */
- if ((!count || count-ts.kind = 8)
+ /* if ((!count || count-ts.kind = 8)
(!count_max || count_max-ts.kind = 8))
kind = 8;
else
-kind = gfc_default_integer_kind;
- type = gfc_get_int_type (kind);
+kind = gfc_default_integer_kind; */
+ /* type = gfc_get_int_type (kind); */
/* Evaluate our arguments. */
if (count)
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #30 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #28 and #29) Thanks for checking and I have the cleanup taken care of. I am making some adjustments to avoid ABI issues as well. Test case will be next.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #27 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #26) Created attachment 34819 [details] Updated full patch. Revised to fix error shown in Comment #22 The new patch does indeed fix the error in comment #22, and it also works for me (e.g. for the original issue). Thanks, Harald
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Attachment #34798|0 |1 is obsolete|| --- Comment #26 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 34819 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34819action=edit Updated full patch. Revised to fix error shown in Comment #22
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #25 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #24) (In reply to Harald Anlauf from comment #22) count_rate(8),count_max(1) =0 127 OK, but the last line looks strange: lacking documentation, I'd expect the rate to be 1, not 0. (Not that I'd use that in real code...). Yes, tha last one is wrong. I will look into it. I found the problem and have it fixed. I am traveling today so will not be able to upload a patch until tomorrow or the next day.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #23 from Harald Anlauf anlauf at gmx dot de ---
(In reply to Jerry DeLisle from comment #21)
Created attachment 34798 [details]
Full Patch
This patch attempts to do it all. I have not tested the mingw/cygwin side of
it.
Any testing/comments welcome
Jerry,
I forgot to mention that the interface of _gfortran_system_clock_{4,8}
changed w.r.t. gcc 4.9 by adding the fourth argument. One needs to make
sure that nobody links an object generated by the newer compiler against
a previous library.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #22 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #21) Created attachment 34798 [details] Full Patch This patch attempts to do it all. I have not tested the mingw/cygwin side of it. Any testing/comments welcome Jerry, I did some simple test and found the following: Cases with a single argument present: % cat gfcbug128f.f90 program gfcbug128e integer(1) :: count_rate_i1, count_max_i1, count_i1 integer(2) :: count_rate_i2, count_max_i2, count_i2 integer(4) :: count_rate_i4, count_max_i4, count_i4 integer(8) :: count_rate_i8, count_max_i8, count_i8 real(4):: count_rate_r4 = 0 real(8):: count_rate_r8 = 0 print *, KIND=1: call system_clock (count=count_i1) print *, count =,count_i1 call system_clock (count_max=count_max_i1) print *, count_max =, count_max_i1 call system_clock (count_rate=count_rate_i1) print *, count_rate=, count_rate_i1 print * print *, KIND=2: call system_clock (count=count_i2) print *, count =,count_i2 call system_clock (count_max=count_max_i2) print *, count_max =, count_max_i2 call system_clock (count_rate=count_rate_i2) print *, count_rate=, count_rate_i2 print * print *, KIND=4: call system_clock (count=count_i4) print *, count =,count_i4 call system_clock (count_max=count_max_i4) print *, count_max =, count_max_i4 call system_clock (count_rate=count_rate_i4) print *, count_rate=, count_rate_i4 call system_clock (count_rate=count_rate_r4) print *, count_rate_real=, count_rate_r4 print * print *, KIND=8: call system_clock (count=count_i8) print *, count =,count_i8 call system_clock (count_max=count_max_i8) print *, count_max =, count_max_i8 call system_clock (count_rate=count_rate_i8) print *, count_rate=, count_rate_i8 call system_clock (count_rate=count_rate_r8) print *, count_rate_real=, count_rate_r8 end Test output: KIND=1: count = 116 count_max = 127 count_rate=1 KIND=2: count = 27083 count_max = 32767 count_rate= 1000 KIND=4: count = 507374028 count_max = 2147483647 count_rate=1000 count_rate_real= 1000.0 KIND=8: count = 1424289032652253 count_max = 9223372036854775807 count_rate= 100 count_rate_real= 100.00 Looks reasonable so far, assuming it behaves as (to be) documented. Further tests with two arguments: % cat gfcbug128g.f90 program gfcbug128g integer(1) :: count_rate_i1, count_max_i1, count_i1 integer(2) :: count_rate_i2, count_max_i2, count_i2 integer(4) :: count_rate_i4, count_max_i4, count_i4 integer(8) :: count_rate_i8, count_max_i8, count_i8 real(4):: count_rate_r4 = 0 real(8):: count_rate_r8 = 0 call system_clock (count=count_i1,count_max=count_max_i2) print *, count(1),count_max(2) =,count_i1, count_max_i2 call system_clock (count=count_i2,count_max=count_max_i1) print *, count(2),count_max(1) =,count_i2, count_max_i1 call system_clock (count=count_i4,count_max=count_max_i2) print *, count(4),count_max(2) =,count_i4, count_max_i2 call system_clock (count=count_i2,count_max=count_max_i4) print *, count(2),count_max(4) =,count_i2, count_max_i4 call system_clock (count=count_i4,count_max=count_max_i8) print *, count(4),count_max(8) =,count_i4, count_max_i8 call system_clock (count=count_i8,count_max=count_max_i4) print *, count(8),count_max(4) =,count_i8, count_max_i4 call system_clock (count=count_i1,count_max=count_max_i8) print *, count(1),count_max(8) =,count_i1, count_max_i8 call system_clock (count=count_i8,count_max=count_max_i1) print *, count(8),count_max(1) =,count_i8, count_max_i1 call system_clock (count_rate=count_rate_i1,count_max=count_max_i2) print *, count_rate(1),count_max(2) =,count_rate_i1, count_max_i2 call system_clock (count_rate=count_rate_i2,count_max=count_max_i1) print *, count_rate(2),count_max(1) =,count_rate_i2, count_max_i1 call system_clock (count_rate=count_rate_i4,count_max=count_max_i2) print *, count_rate(4),count_max(2) =,count_rate_i4, count_max_i2 call system_clock (count_rate=count_rate_i2,count_max=count_max_i4) print *, count_rate(2),count_max(4) =,count_rate_i2, count_max_i4 call system_clock (count_rate=count_rate_i4,count_max=count_max_i8) print *, count_rate(4),count_max(8) =,count_rate_i4, count_max_i8 call system_clock (count_rate=count_rate_i8,count_max=count_max_i4) print *, count_rate(8),count_max(4) =,count_rate_i8, count_max_i4 call system_clock (count_rate=count_rate_i1,count_max=count_max_i8) print *, count_rate(1),count_max(8) =,count_rate_i1, count_max_i8 call system_clock (count_rate=count_rate_i8,count_max=count_max_i1) print *, count_rate(8),count_max(1) =,count_rate_i8, count_max_i1 end Test output: count(1),count_max(2) = 11127 count(2),count_max(1) = 11 127 count(4),count_max(2) =
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #24 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #22) count_rate(8),count_max(1) =0 127 OK, but the last line looks strange: lacking documentation, I'd expect the rate to be 1, not 0. (Not that I'd use that in real code...). Yes, tha last one is wrong. I will look into it. I realize that by adding an additional argument we modify the interface so we may have to do something with symbol versioning. Doing it the way I did eliminates multiple calls but there are always trade-offs
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 34798 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34798action=edit Full Patch This patch attempts to do it all. I have not tested the mingw/cygwin side of it. Any testing/comments welcome
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #20 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #19) (In reply to Jerry DeLisle from comment #17) Created attachment 34765 [details] Handle KIND=1 and KIND=2 Jerry, I applied your patch on top of rev. 220730. Unfortunately it ICEs on the following simple code: Yes, that is an old version. I have changed it quite a lot since that patch. This has been evolving quickly since yesterday. I will not be able to continue until possibly tonight or tomorrow. I posted the results in Comment#18 so that you can see the end result. I will obsolete the patches.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #19 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #17) Created attachment 34765 [details] Handle KIND=1 and KIND=2 Jerry, I applied your patch on top of rev. 220730. Unfortunately it ICEs on the following simple code: integer(4) :: count_rate_i4 call system_clock (count_rate=count_rate_i4) end gfcbug128x.f90:2:0: call system_clock (count_rate=count_rate_i4) 1 internal compiler error: Segmentation fault 0x882b340 crash_signal ../../trunk/gcc/toplev.c:383 0x834b500 conv_intrinsic_system_clock ../../trunk/gcc/fortran/trans-intrinsic.c:9479 0x834b500 gfc_conv_intrinsic_subroutine(gfc_code*) ../../trunk/gcc/fortran/trans-intrinsic.c:9529 0x82ebeba trans_code ../../trunk/gcc/fortran/trans.c:1718 0x831c353 gfc_generate_function_code(gfc_namespace*) ../../trunk/gcc/fortran/trans-decl.c:5850 0x82a461b translate_all_program_units ../../trunk/gcc/fortran/parse.c:5341 0x82a461b gfc_parse_file() ../../trunk/gcc/fortran/parse.c:5538 0x82e6613 gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:228
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #18 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 34771 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34771action=edit A test case Current results with attached test case. $ ./a.out KIND=1: 34 1 127 KIND=1: 34 1. 127 --- KIND=2: 17774 1000 32767 KIND=2: 17774 1000.0 32767 --- KIND=4: 22758766 1000 2147483647 KIND=4: 22758766 1000.0 2147483647 --- KIND=8: 22758766833088 10 9223372036854775807 KIND=8: 22758766851741 10.000 9223372036854775807 --- KIND=10: 22758766876478 10 9223372036854775807 KIND=10: 22758766894351 10.000 9223372036854775807 --- KIND=16: 22758766919976 10 9223372036854775807 KIND=16: 22758766933064 10.00 9223372036854775807
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #17 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 34765 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34765action=edit Handle KIND=1 and KIND=2 This updated patch gives a proposed way to handle KIND=1 and KIND=2. This is done by adding a new KIND=2 function in the library that accepts a fourth argument used to flag when a KIND=1 for any of the arguments. For KIND=1 rate is set to 1, max is set to 127, count rolls over after 127 to 0. For KIND=2 rate is set to 1000, max is 32767 THis is still in testing. I think we can handle the mixed integer and real situations using this fourth argument with different values to designate real KINDs that are encountered. You may notice that if we mix KIND=2 count and limit, with REAL(8) rate, the rate shows way too large. I am working on the mixed integer/real part. I have attached so others can review and comment. I will keep going with the mixed real/integer cases if no objections.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #16 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #15) I was looking at this one just the other day. There are three PRs related to SYSTEM_CLOCK that we should attempt to close. I will look some more tonight. What's missing: - Support for integer(1/2). The standard requires (13.7.167): COUNT (...). It is assigned a processor-dependent value based on the value of the processor clock, or −HUGE (COUNT) if there is no clock. COUNT RATE (...) It is assigned a processor-dependent approximation to the number of processor clock counts per second, or zero if there is no clock. COUNT MAX (...) It is assigned the maximum value that COUNT can have, or zero if there is no clock. We might treat any integer(1/2) argument as there were no corresponding clock. I just don't know how to create the corresponding code to set the result variable appropriately. - The compile-time warning FX mentioned in comment #12. We could split this one off as an enhancement. - A consensus what shall happen for arguments of mixed kinds.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #15 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I was looking at this one just the other day. There are three PRs related to SYSTEM_CLOCK that we should attempt to close. I will look some more tonight.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #14 from Harald Anlauf anlauf at gmx dot de --- Created attachment 34488 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34488action=edit Updated partial patch This modified partial patch addresses the potential performance issue by calling the _4 and/or _8 versions of the library functions when needed, combining multiple arguments of the same kind as in the original code version. Still not done: handling of kind=1,2 arguments. I need a hint how to generate code to set these arguments to those explicit values described by the standard. Harald
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #10 from Harald Anlauf anlauf at gmx dot de --- Created attachment 34374 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34374action=edit Partial patch to handle proposed behavior of system_clock
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #11 from Harald Anlauf anlauf at gmx dot de --- (In reply to Harald Anlauf from comment #10) Created attachment 34374 [details] Partial patch to handle proposed behavior of system_clock The patch in comment #10 is a way to produce behavior similar to Intel: - every argument to SYSTEM_CLOCK is treated separately and independently - tested with integer(4), integer(8) and also real(4/8) for count_rate Note that: - it is imcomplete, ugly - inefficient (calls _gfortran_system_clock_ for each present argument) - does not handle integer(1) and integer(2) properly - needs cleanup It works for me. I.e., for % cat gfcbug128d.f90 program gfcbug128d integer(4) :: count_rate_i4, count_max_i4 integer(8) :: count_rate_i8, count_max_i8 real(4):: count_rate_r4 = 0 real(8):: count_rate_r8 = 0 call system_clock (count_max=count_max_i4) call system_clock (count_rate=count_rate_i4) call system_clock (count_rate=count_rate_r4) print *, count_max_i4, count_rate_i4, count_rate_r4 call system_clock (count_rate=count_rate_i4,count_max=count_max_i4) print *, count_max_i4, count_rate_i4 call system_clock (count_rate=count_rate_r4,count_max=count_max_i4) print *, count_max_i4, count_rate_r4 print * call system_clock (count_max=count_max_i8) call system_clock (count_rate=count_rate_i8) call system_clock (count_rate=count_rate_r8) print *, count_max_i8, count_rate_i8, count_rate_r8 call system_clock (count_rate=count_rate_i8,count_max=count_max_i8) print *, count_max_i8, count_rate_i8 call system_clock (count_rate=count_rate_r8,count_max=count_max_i8) print *, count_max_i8, count_rate_r8 print * call system_clock (count_rate=count_rate_i4,count_max=count_max_i8) print *, count_max_i8, count_rate_i4 call system_clock (count_rate=count_rate_r4,count_max=count_max_i8) print *, count_max_i8, count_rate_r4 print * call system_clock (count_rate=count_rate_i8,count_max=count_max_i4) print *, count_max_i4, count_rate_i8 call system_clock (count_rate=count_rate_r8,count_max=count_max_i4) print *, count_max_i4, count_rate_r8 end it produces: 21474836471000 1000.0 21474836471000 2147483647 1000.0 9223372036854775807 100 100.00 9223372036854775807 100 9223372036854775807 100.00 92233720368547758071000 9223372036854775807 1000.0 2147483647 100 2147483647 100.00 :-)
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #12 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #10) Partial patch to handle proposed behavior of system_clock Thanks for the partial patch. Some quick critique: - it doesn't handle mixed argument kinds (you said you don't care, but others might) - it creates multiple calls to the library (performance issue, especially on a timing routine) - I disagree with the logic for COUNT_RATE: we don't care what kind it is, because any decent kind (32-bit int, 64-bit int, or any real kind) is large enough to store the value. We've got to define an implementation that works for everyone, and for all corner cases. Then we can implement it. I've indicated on comp.lang.fortran what I think is the best strategy: a) if any integer kind is 1 or 2, we emit a warning at compile-time and behave as if no clock is available b) for COUNT_RATE, we treat a real as a wide int (64-bit or more) c) if the kinds of present arguments don't match, issue a compile-time warning d) if all present args are wide, go for high-res, otherwise go for low-res. How does that sound? I will have some time to deal with this in a week.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #13 from Harald Anlauf anlauf at gmx dot de --- (In reply to Francois-Xavier Coudert from comment #12) (In reply to Harald Anlauf from comment #10) Partial patch to handle proposed behavior of system_clock Thanks for the partial patch. Some quick critique: - it doesn't handle mixed argument kinds (you said you don't care, but others might) I originally said that I wouldn't care, but after playing with other compilers I reconsidered (see comment #7). Actually the patch does handle it in the most simple way: all arguments are independent. See the test case in comment #11. (My tentative patch did not remove code that compares the kinds of the arguments etc.) - it creates multiple calls to the library (performance issue, especially on a timing routine) True. But as long as only COUNT is present, there's no performance difference to the old behavior. That's how I use SYSTEM_CLOCK. Optimizations for multiple present arguments are possible but require lengthy coding. I haven't looked at the library code, but calls to determine count_max and count_rate should be extremely cheap. - I disagree with the logic for COUNT_RATE: we don't care what kind it is, because any decent kind (32-bit int, 64-bit int, or any real kind) is large enough to store the value. Probably true for all present and future gfortran implementations. (With crayftn I have seen COUNT_RATE = cpu clockspeed for integer(8), and 2.6 GHz is too large for 32 bit...). Nevertheless, I'd prefer the same COUNT_RATE for default integer(4) and default real(4), and similarly for integer(=8) and real(=8). We've got to define an implementation that works for everyone, and for all corner cases. Then we can implement it. I've indicated on comp.lang.fortran what I think is the best strategy: a) if any integer kind is 1 or 2, we emit a warning at compile-time and behave as if no clock is available OK. This is better than a timer with ridiculously low count_rate/_max. b) for COUNT_RATE, we treat a real as a wide int (64-bit or more) I'd prefer real(4) ~ integer(4), see above reasoning. c) if the kinds of present arguments don't match, issue a compile-time warning OK. (No other compiler I've met complains here, but it's good to warn users to expect trouble). d) if all present args are wide, go for high-res, otherwise go for low-res. That's up to you. But I'd prefer to stay consistent with what other compilers do. (I didn't post the crayftn behavior, but it is sort of similar to what Intel does, except for somewhat odd count_rates.) How does that sound? I will have some time to deal with this in a week.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- also in cp2k we use separate calls for getting the count_rate, count_max and count. I think as long as they are the same kind there should be no problem. *8 arguments resolve to the _8 version and *4 to the _4 version. Both versions ideally have different resolution. I would argue that allowing a single call to system_clock to have integer arguments of different kind is somewhat of a bug in the standard, possibly worthy of a compiler warning. In that case, I would resolve return -HUGE,0,0 i.e. system_clock of this version not supported (also allowed by the standard). Actually, the latter seems like a good idea for integer*1 and integer*2 system_clock calls as well, since the current version is non-conforming. cat test.f90 INTEGER*1 :: count,count_max,count_rate DO CALL SYSTEM_CLOCK(count,count_max,count_rate) write(6,*) count,count_max,count_rate ENDDO END ./a.out | head -14 -24 -1 -13 -24 -1
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- reading the standard, indeed it seems like count_rate can be real as well... same rules here *4 - _4 *8 - _8. As a side remark the following generates a slightly outdated error: cat test.f90 COMPLEX(KIND=4) :: count_rate CALL SYSTEM_CLOCK(count_rate=count_rate) END gfortran test.f90 test.f90:2:29: CALL SYSTEM_CLOCK(count_rate=count_rate) 1 Error: ‘count_rate’ argument of ‘system_clock’ intrinsic at (1) must be INTEGER should be 'INTEGER or REAL'. count and count_max are still integer.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #1 from Harald Anlauf anlauf at gmx dot de ---
Modifying the test code as follows:
% cat gfcbug128b.f90
program gfcbug128b
integer(4) :: count_rate, count_max
call system_clock (count_rate=count_rate,count_max=count_max)
call system_clock (count_rate=count_rate)
call system_clock (count_max=count_max)
end
% head -12 gfcbug128b.f90.003t.original
gfcbug128b ()
{
integer(kind=4) count_max;
integer(kind=4) count_rate;
{
integer(kind=8) count_rate.0;
_gfortran_system_clock_4 (0B, count_rate, count_max);
_gfortran_system_clock_8 (0B, count_rate.0, 0B);
count_rate = (integer(kind=4)) count_rate.0;
_gfortran_system_clock_4 (0B, 0B, count_max);
shows that the logic in trans-intrinsic.c::conv_intrinsic_system_clock
does not cover the case of single arguments:
gfc_expr *count = code-ext.actual-expr;
gfc_expr *count_rate = code-ext.actual-next-expr;
gfc_expr *count_max = code-ext.actual-next-next-expr;
/* The INTEGER(8) version has higher precision, it is used if both COUNT
and COUNT_MAX can hold 64-bit values, or are absent. */
if ((!count || count-ts.kind = 8)
(!count_max || count_max-ts.kind = 8))
kind = 8;
else
kind = gfc_default_integer_kind;
type = gfc_get_int_type (kind);
/* Evaluate our arguments. */
This probably needs to be amended.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #2 from Harald Anlauf anlauf at gmx dot de --- Introduced in r211686. FX?
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #0) I just discovered that the 20141227 snapshot breaks SYSTEM_CLOCK when the COUNT_RATE argument is a 32-bit integer: Confirmed. Probably due to r211686.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-29 CC||janus at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I'm not sure this is a bug, but this was definitely by design (as the comment indicates). I think this is allowed by the successive standards (which are, in any case, very weakly worded). The root of the problem is that we want to allow for SYSTEM_CLOCK to return high-precision values for large integer kinds, and fall back to lower-precision results that fit in fewer bytes for smaller integer kinds. Thus, one should call SYSTEM_CLOCK once with all the necessary arguments, and not multiple times with varying argument types. The only other consistent option I can see would be to simply go for high-resolution results in all cases, but that would mean that SYSTEM_CLOCK with 32-bit integers would wrap around in less than an hour. If you have another idea, please post a list of what you think should happen in all various cases (all possible combinations of arguments have to be allowed).
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #5 from Harald Anlauf anlauf at gmx dot de --- (In reply to Francois-Xavier Coudert from comment #4) I'm not sure this is a bug, but this was definitely by design (as the comment indicates). I think this is allowed by the successive standards (which are, in any case, very weakly worded). Well, let's see: the standard says: 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. You're right, it does not say anything about consistency. Nevertheless, I would prefer if a program that always uses e.g. default integer == integer(4), the low-resolution (msec) version continues to be used consistently. That's what other compilers do and what gfortran = 4.9 did. Also, the presence of a second argument (see comment #1) should not change the behavior. OTOH, it is the responsibility of a user to consistently use arguments of the same type and kind to get consistent behavior. (I.e. not mixing integer and real or integer(4) and integer(8)). I do take care of that. The root of the problem is that we want to allow for SYSTEM_CLOCK to return high-precision values for large integer kinds, and fall back to lower-precision results that fit in fewer bytes for smaller integer kinds. How is this fallback done? Do you truncate the resolution? E.g. high res. - low res.: divide count_rate and count by 1000? Thus, one should call SYSTEM_CLOCK once with all the necessary arguments, and not multiple times with varying argument types. Note that I did *not* call SYSTEM_CLOCK with varying argument types. You're probably not aware of existing (f95) code that deals with the problem of wrapping, which is always present (count does not necessarily start with 0 at start of the program), although not very likely with integer(8)... ;-) The only other consistent option I can see would be to simply go for high-resolution results in all cases, but that would mean that SYSTEM_CLOCK with 32-bit integers would wrap around in less than an hour. No, that doesn't make sense. If you have another idea, please post a list of what you think should happen in all various cases (all possible combinations of arguments have to be allowed). Let's see: - For any number of arguments present (1, 2 or 3) - always integer(4): msec resolution (as before) - always integer(=8): usec resolution (or whatever is possible) - always real: I don't care, but I think it might be a good idea to use the same as for integer of a compatible kind. - different types and/or kinds: I don't care, since one should expect problems (wrapping or truncation) anyway. But presence of non-presence should never make a difference if consistent types and kinds are used.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #6 from Harald Anlauf anlauf at gmx dot de --- (In reply to Harald Anlauf from comment #5) Also, the presence of a second argument (see comment #1) should not change the behavior. To make that explicit: % cat gfcbug128c.f90 program gfcbug128c integer(4) :: count_rate, count_max call system_clock (count_rate=count_rate,count_max=count_max) print *, count_rate, count_max call system_clock (count_rate=count_rate) call system_clock (count_max=count_max) print *, count_rate, count_max end gfortran 5 gives: 1000 2147483647 100 2147483647 any other compiler: 1000 2147483647 1000 2147483647 I'd have a hard time to explain that to anybody.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #7 from Harald Anlauf anlauf at gmx dot de ---
(In reply to Harald Anlauf from comment #5)
(In reply to Francois-Xavier Coudert from comment #4)
If you have another idea, please post a list of what you think should happen
in all various cases (all possible combinations of arguments have to be
allowed).
Let's see:
- For any number of arguments present (1, 2 or 3)
- always integer(4): msec resolution (as before)
- always integer(=8): usec resolution (or whatever is possible)
- always real: I don't care, but I think it might be a good idea
to use the same as for integer of a compatible kind.
- different types and/or kinds: I don't care, since one should
expect problems (wrapping or truncation) anyway.
But presence of non-presence should never make a difference
if consistent types and kinds are used.
I played around with other compilers and posted the result at:
https://groups.google.com/forum/?hl=en#!topic/comp.lang.fortran/5aoFFRNBP0g
The only compiler that allows for different timer resolutions and
produces an at least self-consistent result appears to be Intel.
It actually treats each argument separately: if it is a 4-byte
argument, it returns values referring to the low-res (0.1 msec) version;
for an 8-byte argument one gets the high-res (1 usec) version.
(Confirmed by looking at the explicit assembler code).
That would be even simpler than any of the versions I discussed above.
The actual implementation then might generate a call to
_gfortran_system_clock_{4,8} for each present argument,
with the respective kind taken into account.
