[patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests
The attached diff file begins some test suite cleanup. The patch removes extra spaces between dg-do and the run directive, I only have gone through gfortran.dg and not its sub-directories. Interestingly, one of the tests fails when this space is removed. I fixed that by adding in a -O in the dg-options. The PR is not about the extra spaces. Interestingly it is recommended in comment #3 that the -O0 which are superfluous be removed everywhere. I plan to make additional passes through the tests to clean out the -O and -O0 directives as suggested and see what the result is. I also plan to go through the sub-directories as well. (ie more patches will follow as I have time.) The effect of removing the extra space is additional tests on the test case are run. [aside: I found one test case that had its executable bit set so I corrected it as well.] Regression tested on x86-64-linux-gnu. OK for trunk? Author: Jerry DeLisle Date: Sat Oct 19 19:29:22 2024 -0700 Fortran: Remove extra space from dg-do run directives. gcc/testsuite/ChangeLog: PR fortran/28031 * gfortran.dg/ISO_Fortran_binding_4.f90: Delete extra space in dg-do run directive. * gfortran.dg/abort_shouldfail.f90: Likewise. * gfortran.dg/adjustl_1.f90: Likewise. * gfortran.dg/allocate_with_mold_3.f90: Likewise. * gfortran.dg/allocate_with_source_6.f90: Likewise. * gfortran.dg/altreturn_9_0.f90: Likewise. * gfortran.dg/array_constructor_52.f90: Likewise. * gfortran.dg/array_constructor_53.f90: Likewise. * gfortran.dg/array_simplify_2.f90: Likewise. * gfortran.dg/array_simplify_3.f90: Likewise. * gfortran.dg/block_14.f90: Likewise. * gfortran.dg/bound_9.f90: Likewise. * gfortran.dg/bounds_check_20.f90: Likewise. * gfortran.dg/c_funptr_1_mod.f90: Likewise. * gfortran.dg/char_result_mod_19.f90: Likewise. * gfortran.dg/coarray_data_1.f90: Likewise. * gfortran.dg/contiguous_8.f90: Likewise. * gfortran.dg/cray_pointers_2.f90: Likewise. * gfortran.dg/cshift_1.f90: Likewise. * gfortran.dg/cshift_2.f90: Likewise. * gfortran.dg/data_derived_1.f90: Likewise. * gfortran.dg/dec_union_12.f90: Remove executable bit from file permissions. * gfortran.dg/dependency_50.f90: Likewise. * gfortran.dg/dependency_51.f90: Likewise. * gfortran.dg/dependency_54.f90: Likewise. * gfortran.dg/derived_init_5.f90: Likewise. * gfortran.dg/dim_sum_1.f90: Likewise. * gfortran.dg/dim_sum_2.f90: Likewise. * gfortran.dg/dim_sum_3.f90: Likewise. * gfortran.dg/eoshift_3.f90: Likewise. * gfortran.dg/eoshift_4.f90: Likewise. * gfortran.dg/eoshift_5.f90: Likewise. * gfortran.dg/eoshift_6.f90: Likewise. * gfortran.dg/execute_command_line_3.f90: Likewise. * gfortran.dg/findloc_5.f90: Likewise. * gfortran.dg/implied_do_io_4.f90: Likewise. * gfortran.dg/implied_do_io_5.f90: Likewise. * gfortran.dg/implied_do_io_6.f90: Likewise. * gfortran.dg/inline_matmul_1.f90: Likewise. * gfortran.dg/inline_matmul_10.f90: Likewise. Add -O option. * gfortran.dg/inline_matmul_11.f90: Likewise. * gfortran.dg/inline_matmul_17.f90: Likewise. * gfortran.dg/inline_matmul_18.f90: Likewise. * gfortran.dg/inline_matmul_19.f90: Likewise. * gfortran.dg/inline_matmul_20.f90: Likewise. * gfortran.dg/inline_matmul_3.f90: Likewise. * gfortran.dg/inline_matmul_4.f90: Likewise. * gfortran.dg/inline_matmul_5.f90: Likewise. * gfortran.dg/inline_matmul_7.f90: Likewise. * gfortran.dg/inline_matmul_8.f90: Likewise. * gfortran.dg/inline_matmul_9.f90: Likewise. * gfortran.dg/intent_out_12.f90: Likewise. * gfortran.dg/internal_readwrite_4.f90: Likewise. * gfortran.dg/is_contiguous_2.f90: Likewise. * gfortran.dg/is_contiguous_3.f90: Likewise. * gfortran.dg/matmul_15.f90: Likewise. * gfortran.dg/matmul_16.f90: Likewise. * gfortran.dg/matmul_19.f90: Likewise. * gfortran.dg/matmul_blas_1.f: Likewise. * gfortran.dg/matmul_bounds_14.f: Likewise. * gfortran.dg/matmul_bounds_15.f: Likewise. * gfortran.dg/matmul_bounds_16.f: Likewise. * gfortran.dg/matmul_const.f90: Likewise. * gfortran.dg/maxloc_4.f90: Likewise. * gfortran.dg/maxval_parameter_1.f90: Likewise. * gfortran.dg/min_max_type.f90: Likewise. * gfortran.dg/min_max_type_2.f90: Likewise. * gfortran.dg/minloc_4.f90: Likewise.
Re: 8.260 STAT example fails if compiled with -std=f2008
On Sat, Oct 19, 2024 at 05:38:30PM +, Wyche, George G PW wrote: > > My Fortran project is based on -std=f2008. The GNU Fortran (For GCC version > 15.0.0) manual's 8.260 STAT example does not link if -std=f2008 is on the > command line: gfortran -std=f2008 test_stat.f90; ./a.out > The ld error is "undefined reference to `stat_'" > > This is with gfortran -version 12.2.0 and ld -version 2.40 > > Removing -std=f2008, and the example works as expected. > FX has already addressed the questions. Here's the F2023 standardese about the issue: A standard-conforming processor may allow additional forms and relationships provided that such additions do not conflict with the standard forms and relationships. However, a standard-conforming processor may allow additional intrinsic procedures even though this could cause a conflict with the name of a procedure in a standard- conforming program. If such a conflict occurs and involves the name of an external procedure, the processor is permitted to use the intrinsic procedure unless the name has the EXTERNAL attribute (8.5.9) where it is used. A standard-conforming program shall not use nonstandard intrinsic procedures or modules that have been added by the processor. Note the last sentence. STAT() is nonstandard intrinsic procedure. You used -std=f2008, which causes gfortran to ignore all such procedure unless the -fall-intrinsics option is used. -- Steve
Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests
On 10/20/24 1:16 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.10.24 um 21:53 schrieb Jerry D:
On 10/20/24 12:23 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.10.24 um 18:56 schrieb Jerry D:
The attached diff file begins some test suite cleanup.
The patch removes extra spaces between dg-do and the run directive, I
only have gone through gfortran.dg and not its sub-directories.
Interestingly, one of the tests fails when this space is removed. I
fixed that by adding in a -O in the dg-options.
There was already a discussion of the "two spaces" vs. "one space"
version of dg-do run; see e.g. the thread starting here:
https://gcc.gnu.org/pipermail/fortran/2024-March/060363.html
(see also Andrew's remark:
https://gcc.gnu.org/pipermail/fortran/2024-April/060400.html)
I learned that the "two spaces" hack^Wversion has its (undocumented)
uses, namely a test is only run once. Has anybody attempted to adjust
the testsuite documentation? I find the possibility to run a certain
test only once interesting, especially if only a runtime library feature
is tested, and this saves (a little) testsuite execution time, which I
find to have been increasing quite a lot recently.
(One of the possible solutions was to have the two spaces, but also
a comment that no cycling is intended. As long are there is no other
solution to this hack.)
I am aware of Andrews comment here. This is my first exploration of the
issue. I agree it is a hack and useful. The problem I see is that some
cases are deliberate and others by accident of typing.
Indeed, it should always be clear from looking at a testcase to tell
what was meant. This is why I always add e.g. a "dg-do compile" even
when this is the default.
I wonder if a better way to do this is a new directive such as "dg-do
run-once" At least then it would be clear what is happening. Adding a
comment on top of two spaces is like a hack on a hack.
Yes, "dg-do run-once" was what I was going to suggest. Including an
optional comment explaining why it would be sufficient to just run
a particular test once.
I found the relevant 'code' in gfortran-dg.exp:
# look if this is dg-do run test, in which case
# we cycle through the option list, otherwise we don't
if [expr [search_for $test "dg-do run"]] {
set option_list $torture_with_loops
} else {
set option_list [list { -O } ]
}
I think I can tweak this to add in the case of "dg-do run-once"
I will give it a try and report back here.
The PR is not about the extra spaces. Interestingly it is recommended
in comment #3 that the -O0 which are superfluous be removed
everywhere. I plan to make additional passes through the tests to
clean out the -O and -O0 directives as suggested and see what the
result is. I also plan to go through the sub-directories as well. (ie
more patches will follow as I have time.)
I think that reviewing the appropriateness of the specifications of the
tests is a good thing. That should happen before plainly changing the
dg-directives.
Agree
One thing to remember: in the gfortran frontend, cycling through the
optimization levels switches several flags controlling e.g. frontend
optimization, matmul inlining, ... In particular the test
gcc/testsuite/gfortran.dg/inline_matmul_1.f90
*requires* matmul inlining. So you want either run this test only
with options that enable this inlining. Optimization is not the point
here. And one of the essential points of this test is the last line:
! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "optimized" } }
Now if you explicitly add -O, what is the point of cycling through the
optimization levels?
In this one case it was a hack until I figure out a better way to do it
other than two blank spaces. :) In the PR I mentioned not wanting to get
into the test machinery. I suspect this will be necessary.
Yes. Just go ahead... ;-)
Always easier said then done, but I will see what happens. ;-)
Jerry
Cheers,
Harald
--- snip ---
Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests
Hi Jerry!
Am 20.10.24 um 18:56 schrieb Jerry D:
The attached diff file begins some test suite cleanup.
The patch removes extra spaces between dg-do and the run directive, I
only have gone through gfortran.dg and not its sub-directories.
Interestingly, one of the tests fails when this space is removed. I
fixed that by adding in a -O in the dg-options.
There was already a discussion of the "two spaces" vs. "one space"
version of dg-do run; see e.g. the thread starting here:
https://gcc.gnu.org/pipermail/fortran/2024-March/060363.html
(see also Andrew's remark:
https://gcc.gnu.org/pipermail/fortran/2024-April/060400.html)
I learned that the "two spaces" hack^Wversion has its (undocumented)
uses, namely a test is only run once. Has anybody attempted to adjust
the testsuite documentation? I find the possibility to run a certain
test only once interesting, especially if only a runtime library feature
is tested, and this saves (a little) testsuite execution time, which I
find to have been increasing quite a lot recently.
(One of the possible solutions was to have the two spaces, but also
a comment that no cycling is intended. As long are there is no other
solution to this hack.)
The PR is not about the extra spaces. Interestingly it is recommended in
comment #3 that the -O0 which are superfluous be removed everywhere. I
plan to make additional passes through the tests to clean out the -O and
-O0 directives as suggested and see what the result is. I also plan to
go through the sub-directories as well. (ie more patches will follow as
I have time.)
I think that reviewing the appropriateness of the specifications of the
tests is a good thing. That should happen before plainly changing the
dg-directives.
One thing to remember: in the gfortran frontend, cycling through the
optimization levels switches several flags controlling e.g. frontend
optimization, matmul inlining, ... In particular the test
gcc/testsuite/gfortran.dg/inline_matmul_1.f90
*requires* matmul inlining. So you want either run this test only
with options that enable this inlining. Optimization is not the point
here. And one of the essential points of this test is the last line:
! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "optimized" } }
Now if you explicitly add -O, what is the point of cycling through the
optimization levels?
Cheers,
Harald
The effect of removing the extra space is additional tests on the test
case are run. [aside: I found one test case that had its executable bit
set so I corrected it as well.]
Regression tested on x86-64-linux-gnu. OK for trunk?
Author: Jerry DeLisle
Date: Sat Oct 19 19:29:22 2024 -0700
Fortran: Remove extra space from dg-do run directives.
gcc/testsuite/ChangeLog:
PR fortran/28031
* gfortran.dg/ISO_Fortran_binding_4.f90: Delete extra space
in dg-do run directive.
* gfortran.dg/abort_shouldfail.f90: Likewise.
* gfortran.dg/adjustl_1.f90: Likewise.
* gfortran.dg/allocate_with_mold_3.f90: Likewise.
* gfortran.dg/allocate_with_source_6.f90: Likewise.
* gfortran.dg/altreturn_9_0.f90: Likewise.
* gfortran.dg/array_constructor_52.f90: Likewise.
* gfortran.dg/array_constructor_53.f90: Likewise.
* gfortran.dg/array_simplify_2.f90: Likewise.
* gfortran.dg/array_simplify_3.f90: Likewise.
* gfortran.dg/block_14.f90: Likewise.
* gfortran.dg/bound_9.f90: Likewise.
* gfortran.dg/bounds_check_20.f90: Likewise.
* gfortran.dg/c_funptr_1_mod.f90: Likewise.
* gfortran.dg/char_result_mod_19.f90: Likewise.
* gfortran.dg/coarray_data_1.f90: Likewise.
* gfortran.dg/contiguous_8.f90: Likewise.
* gfortran.dg/cray_pointers_2.f90: Likewise.
* gfortran.dg/cshift_1.f90: Likewise.
* gfortran.dg/cshift_2.f90: Likewise.
* gfortran.dg/data_derived_1.f90: Likewise.
* gfortran.dg/dec_union_12.f90: Remove executable bit from
file
permissions.
* gfortran.dg/dependency_50.f90: Likewise.
* gfortran.dg/dependency_51.f90: Likewise.
* gfortran.dg/dependency_54.f90: Likewise.
* gfortran.dg/derived_init_5.f90: Likewise.
* gfortran.dg/dim_sum_1.f90: Likewise.
* gfortran.dg/dim_sum_2.f90: Likewise.
* gfortran.dg/dim_sum_3.f90: Likewise.
* gfortran.dg/eoshift_3.f90: Likewise.
* gfortran.dg/eoshift_4.f90: Likewise.
* gfortran.dg/eoshift_5.f90: Likewise.
* gfortran.dg/eoshift_6.f90: Likewise.
* gfortran.dg/execute_command_line_3.f90: Likewise.
* gfortran.dg/findloc_5.f90: Likewise.
* gfortran.dg/implied_do_io_4.f90: Likewise.
* gfortran.dg/implied_do_io_5.f90: Likewise.
*
Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests
On 10/20/24 12:23 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.10.24 um 18:56 schrieb Jerry D:
The attached diff file begins some test suite cleanup.
The patch removes extra spaces between dg-do and the run directive, I
only have gone through gfortran.dg and not its sub-directories.
Interestingly, one of the tests fails when this space is removed. I
fixed that by adding in a -O in the dg-options.
There was already a discussion of the "two spaces" vs. "one space"
version of dg-do run; see e.g. the thread starting here:
https://gcc.gnu.org/pipermail/fortran/2024-March/060363.html
(see also Andrew's remark:
https://gcc.gnu.org/pipermail/fortran/2024-April/060400.html)
I learned that the "two spaces" hack^Wversion has its (undocumented)
uses, namely a test is only run once. Has anybody attempted to adjust
the testsuite documentation? I find the possibility to run a certain
test only once interesting, especially if only a runtime library feature
is tested, and this saves (a little) testsuite execution time, which I
find to have been increasing quite a lot recently.
(One of the possible solutions was to have the two spaces, but also
a comment that no cycling is intended. As long are there is no other
solution to this hack.)
I am aware of Andrews comment here. This is my first exploration of the
issue. I agree it is a hack and useful. The problem I see is that some
cases are deliberate and others by accident of typing.
I wonder if a better way to do this is a new directive such as "dg-do
run-once" At least then it would be clear what is happening. Adding a
comment on top of two spaces is like a hack on a hack.
The PR is not about the extra spaces. Interestingly it is recommended
in comment #3 that the -O0 which are superfluous be removed
everywhere. I plan to make additional passes through the tests to
clean out the -O and -O0 directives as suggested and see what the
result is. I also plan to go through the sub-directories as well. (ie
more patches will follow as I have time.)
I think that reviewing the appropriateness of the specifications of the
tests is a good thing. That should happen before plainly changing the
dg-directives.
Agree
One thing to remember: in the gfortran frontend, cycling through the
optimization levels switches several flags controlling e.g. frontend
optimization, matmul inlining, ... In particular the test
gcc/testsuite/gfortran.dg/inline_matmul_1.f90
*requires* matmul inlining. So you want either run this test only
with options that enable this inlining. Optimization is not the point
here. And one of the essential points of this test is the last line:
! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "optimized" } }
Now if you explicitly add -O, what is the point of cycling through the
optimization levels?
In this one case it was a hack until I figure out a better way to do it
other than two blank spaces. :) In the PR I mentioned not wanting to get
into the test machinery. I suspect this will be necessary.
Cheers,
Harald
--- snip ---
Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests
Hi Jerry!
Am 20.10.24 um 21:53 schrieb Jerry D:
On 10/20/24 12:23 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.10.24 um 18:56 schrieb Jerry D:
The attached diff file begins some test suite cleanup.
The patch removes extra spaces between dg-do and the run directive, I
only have gone through gfortran.dg and not its sub-directories.
Interestingly, one of the tests fails when this space is removed. I
fixed that by adding in a -O in the dg-options.
There was already a discussion of the "two spaces" vs. "one space"
version of dg-do run; see e.g. the thread starting here:
https://gcc.gnu.org/pipermail/fortran/2024-March/060363.html
(see also Andrew's remark:
https://gcc.gnu.org/pipermail/fortran/2024-April/060400.html)
I learned that the "two spaces" hack^Wversion has its (undocumented)
uses, namely a test is only run once. Has anybody attempted to adjust
the testsuite documentation? I find the possibility to run a certain
test only once interesting, especially if only a runtime library feature
is tested, and this saves (a little) testsuite execution time, which I
find to have been increasing quite a lot recently.
(One of the possible solutions was to have the two spaces, but also
a comment that no cycling is intended. As long are there is no other
solution to this hack.)
I am aware of Andrews comment here. This is my first exploration of the
issue. I agree it is a hack and useful. The problem I see is that some
cases are deliberate and others by accident of typing.
Indeed, it should always be clear from looking at a testcase to tell
what was meant. This is why I always add e.g. a "dg-do compile" even
when this is the default.
I wonder if a better way to do this is a new directive such as "dg-do
run-once" At least then it would be clear what is happening. Adding a
comment on top of two spaces is like a hack on a hack.
Yes, "dg-do run-once" was what I was going to suggest. Including an
optional comment explaining why it would be sufficient to just run
a particular test once.
The PR is not about the extra spaces. Interestingly it is recommended
in comment #3 that the -O0 which are superfluous be removed
everywhere. I plan to make additional passes through the tests to
clean out the -O and -O0 directives as suggested and see what the
result is. I also plan to go through the sub-directories as well. (ie
more patches will follow as I have time.)
I think that reviewing the appropriateness of the specifications of the
tests is a good thing. That should happen before plainly changing the
dg-directives.
Agree
One thing to remember: in the gfortran frontend, cycling through the
optimization levels switches several flags controlling e.g. frontend
optimization, matmul inlining, ... In particular the test
gcc/testsuite/gfortran.dg/inline_matmul_1.f90
*requires* matmul inlining. So you want either run this test only
with options that enable this inlining. Optimization is not the point
here. And one of the essential points of this test is the last line:
! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "optimized" } }
Now if you explicitly add -O, what is the point of cycling through the
optimization levels?
In this one case it was a hack until I figure out a better way to do it
other than two blank spaces. :) In the PR I mentioned not wanting to get
into the test machinery. I suspect this will be necessary.
Yes. Just go ahead... ;-)
Cheers,
Harald
--- snip ---
