[Bug fortran/56408] New: Fix dependency handling of testsuite/gfortran.dg

[Bug fortran/56408] New: Fix dependency handling of testsuite/gfortran.dg

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

             Bug #: 56408
           Summary: Fix dependency handling of testsuite/gfortran.dg
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


There are several test cases, which depend on the execution order. Currently,
tests use the execution order - but this does not work. In some cases, 
dg-additional-sources is used, but that is also not universally applicatable.

One solution would be to create a new subdirectory for those and handle it as
with LTO

See also http://gcc.gnu.org/ml/fortran/2013-02/msg00106.html

Affected (besides others):
* gfortran.dg/binding_label_tests_11_main.f03
* gfortran.dg/binding_label_tests_11.f03
(grep for "keep-modules" to find some more.)

"Would it be possible to re-arrange gfortran.dg so it explicitly builds
dependencies?  Both lto.exp and pch.exp already handle this."

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-20 13:13:30 UTC ---
Given that you can use dg.exp=nameoftest.f90 and run only that single test, I
think dg-additional-sources should be the way to go in those cases.

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-02-20 13:48:32 UTC ---
(In reply to comment #1)
> Given that you can use dg.exp=nameoftest.f90 and run only that single test, I
> think dg-additional-sources should be the way to go in those cases.

Reconsidering it, I think you are right.

As dg-additional-sources appends the other file, one has to use
dg-additional-sources on the file which provides the module. And in the file
which requires the module, one has to use:
! { dg-do compile  { target skip-all-targets } }


Probably affected:

binding_label_tests_10.f03
binding_label_tests_11.f03
binding_label_tests_13.f03
class_45a.f03
class_4a.f03
class_4b.f03
coarray_29_1.f90
test_common_binding_labels_2.f03
test_common_binding_labels_3.f03
whole_file_28.f90
whole_file_30.f90

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-02-20 14:50:04 UTC ---
Created attachment 29510
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29510
Draft patch (fails due to issues mentioned in comment 3)

(In reply to comment #2)
> (In reply to comment #1)
> > Given that you can use dg.exp=nameoftest.f90 and run only that single test,
> > I think dg-additional-sources should be the way to go in those cases.

Actually, it currently doesn't work:

One cannot combine "! { do-do compile }" with dg-additional-sources. "dg-do
compile" uses "-S" with the "-o" option, but that does not support multiple
files. And using, e.g., "dg-do link" is not possible if one of the files has a
"dg-error".

Hence, the following test cases cannot be converted (they use "dg-error"):
- gfortran.dg/binding_label_tests_10.f03
- gfortran.dg/binding_label_tests_11.f03
- gfortran.dg/binding_label_tests_13.f03
- gfortran.dg/test_common_binding_labels_2.f03
- gfortran.dg/test_common_binding_labels_3.f03

The following could use "dg-do link" (they currently all uses "dg-do compile"):
- gfortran.dg/coarray_29_1.f90
- gfortran.dg/whole_file_28.f90
- gfortran.dg/whole_file_30.f90

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-20 14:54:54 UTC ---
So can the modules be just moved into their own separate files and #included
(or INCLUDEd)?
Or add something like dg-additional-sources for module compilations, where
dg.exp would compile those files ahead of compiling the particular testcase,
and the testcase would contain dg-final cleanup lines for all those modules (so
every test would be self-contained).

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-02-20 15:29:07 UTC ---
(In reply to comment #4)
> So can the modules be just moved into their own separate files and #included
> (or INCLUDEd)?

No. Those tests require that there is more than one translation unit. With
"include" one has effectively one one TU.


> Or add something like dg-additional-sources for module compilations, where
> dg.exp would compile those files ahead of compiling the particular testcase,
> and the testcase would contain dg-final cleanup lines for all those modules 
> (so every test would be self-contained).

Well, that's essentially what is currently (with the patch), except that one
runs into the "-o" issue.

I think it should be also solvable with the current dg-additional-sources -
either relying on having the ".s" in the current working directory (i.e.
getting rid of the "-o".) -- Or by compiling separately for the
dg-additional-sources (for "dg-do compile"). Probably, the former is not an
option.


Currently, it is handled as:

proc gfortran_target_compile { source dest type options } {
...
    set options [dg-additional-files-options $options $source]
    return [target_compile $source $dest $type $options]
}

The "dg-additional-files-options" adds the additional sources to $options.

Maybe, an option would be to do

  if { $type == "compile" } {
    set result [target_compile $source $dest $type $options]
    foreach srcfile $additional_sources {
      lappend result [target_compile $srcfile $dest $type $options]
    }
    return $result
  }

Or something like that. (It probably needs some refinement as
"dg-additional-files-options" also supports downloading etc. I am also not sure
whether "foreach" properly splits the files in '{ dg-additional-sources
"class_4b.f03 class_4c.f03" }', though it might do so.)

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-02-20 16:32:18 UTC ---
Created attachment 29511
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29511
Draft patch (not working) for testsuite/lib

(In reply to comment #5)
> Maybe, an option would be to do
...

I have now tried my proposal, however, my patch (see attachment) doesn't work.
The problem is that the additional file is seemingly not read when checking
whether the output contains the pattern. (Additionally, it writes to the
original ".s" ($source.s) not to the one of the additional sources; I don't
know whether that's good (for cleanup) or bad (for pattern matching).)

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-13
     Ever confirmed|0                           |1

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Related to the thread 

[PATCH] gcc parallel make check

especially https://gcc.gnu.org/ml/fortran/2014-09/msg00114.html.

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Sep 16 09:35:00 2014
New Revision: 215293

URL: https://gcc.gnu.org/viewcvs?rev=215293&root=gcc&view=rev
Log:
    PR fortran/56408
    * gfortran.dg/dg.exp (dg-compile-aux-modules): Workaround
    missing nexted dg-test call support in dejaGNU 1.4.4.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/dg.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is it fixed or not after r215293?

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Is it fixed or not after r215293?

No answer after over eight months. Closing as FIXED. Please open new PRs for
remaining issues.