Bug 35015 - missing cleanup-modules directive in testsuite/gfortran*
Summary: missing cleanup-modules directive in testsuite/gfortran*
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/201...
Keywords: patch
Depends on:
Blocks:
 
Reported: 2008-01-29 14:10 UTC by Bernhard Reutner-Fischer
Modified: 2012-06-01 12:43 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-02-03 14:34:44


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Reutner-Fischer 2008-01-29 14:10:14 UTC
$ wget -P gcc/contrib/ \
http://uclibc.org/~aldot/gcc/gfortran.dg-final.cleanup-mods.awk
$ chmod +x gcc/contrib/gfortran.dg-final.cleanup-mods.awk
$ cd gcc/testsuite
$ $ for i in $(grep --exclude='*.svn*' -rl dg-do gfortran*); do ../contrib/gfortran.dg-final.cleanup-mods.awk $i;done 2> /dev/null

This scripts emits on stdout a diagnostic message about
a) wrong encoding in testcases (CRLF)
b) missing cleanup-module directives

On stderr, this scripts emits sed scripts to automagically
a) fix the wrong encoding
b) add missing cleanup-module directives.

I put it into public domain, but this can be changes if required.
IMHO it would be handy to have this script in gcc/contrib
Comment 1 Tobias Burnus 2008-01-29 15:36:58 UTC
> This scripts emits on stdout a diagnostic message about
> a) wrong encoding in testcases (CRLF)

I think it is OK to mix \n and \r\n in the test suite as both should work. In principle "\r" (old Mac files) should work as well, but seemingly no one has requested this (-> currently unimplemented).
Thus I strongly advice against having only "\n" files.

> b) add missing cleanup-module directives.
> $ for i in $(grep --exclude='*.svn*' -rl dg-do gfortran*); do
> ../contrib/gfortran.dg-final.cleanup-mods.awk $i;done 2> /dev/null

This will find also those which are "dg-do compile" where no .mod is produced ("dg-error" in MODULE) and misses those which do not contain "dg-do compile" as this is the default value.

But in any case the script is useful.
Comment 2 Bernhard Reutner-Fischer 2008-01-29 16:05:24 UTC
You can pass any *.[fF][9]*[05]* and .inc into this script, it will happily scan for any un-cleaned mod. See top of the script for the files i initially fed to it.
Comment 3 Tobias Burnus 2008-01-29 20:15:23 UTC
> You can pass any *.[fF][9]*[05]* and .inc into this script, it will happily
> scan for any un-cleaned mod. See top of the script for the files i initially
> fed to it.

Most (all?) .mod files which are left over come currently from gfortran.fortran-torture/, where dg-cleanup cannot be used.
Comment 4 rep.dot.nop@gmail.com 2008-01-29 20:23:23 UTC
Subject: Re:  missing cleanup-modules directive in
	testsuite/gfortran*

On Tue, Jan 29, 2008 at 08:15:23PM -0000, burnus at gcc dot gnu dot org wrote:
>------- Comment #3 from burnus at gcc dot gnu dot org  2008-01-29 20:15 -------
>> You can pass any *.[fF][9]*[05]* and .inc into this script, it will happily
>> scan for any un-cleaned mod. See top of the script for the files i initially
>> fed to it.
>
>Most (all?) .mod files which are left over come currently from
>gfortran.fortran-torture/, where dg-cleanup cannot be used.

Fair enough. We should thus apply the script to gcc/contrib/ (ok for
adding it?) and consequently close this as fixed.
thanks,
Comment 5 Bernhard Reutner-Fischer 2008-01-29 20:35:16 UTC
Several question marks for someone more familiar with the testsuite..

In the event that we can check against several multilib variants (?) that thus match different dg-require (?), we may (?) eventually check against stale module data if a "board" does not cleanup-modules after itself and each board is run in the same directory (where an old multilib-run may have left old output/modules), no?

If there is a risk that we run into stale data, then board variants, however they may be established, have to cleanup after themselves to prevent wrong positives.
Janis, all, is this something that we can run into and should be concerned about or is it impossible that this szenario triggers, ever?
Comment 6 Francois-Xavier Coudert 2008-02-03 14:34:43 UTC
(In reply to comment #5)
> In the event that we can check against several multilib variants (?) that thus
> match different dg-require (?), we may (?) eventually check against stale
> module data if a "board" does not cleanup-modules after itself and each board
> is run in the same directory (where an old multilib-run may have left old
> output/modules), no?

I don't think so, since each a newer version of the module file is written every time before being read. It still would be nice to have to way to support a cleanup directive in the gfortran.fortran-torture/ directory.
Comment 7 Daniel Franke 2009-01-03 22:48:16 UTC
(In reply to comment #4)
> Fair enough. We should thus apply the script to gcc/contrib/ (ok for
> adding it?) and consequently close this as fixed.
> thanks,

Hasn't been added yet. I think it's still useful. 
Please add.

Before closing, a note to the ML would be nice, so people know that it's available and how to use it - thanks! :)
Comment 8 Bernhard Reutner-Fischer 2012-03-02 07:57:14 UTC
Alternative approach; Handle cleanup-modules in the testsuite implicitly
Comment 9 Tobias Burnus 2012-06-01 12:43:30 UTC
As by default the .mod files of the modules in a test-suite file are removed, I think this PR can be CLOSED. I did so now.