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