c-c++-common testsuite
Often I want to test the exactly same testcase in C and C++, so I find myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be possible to have a shared testsuite dir that is run for both C and C++ languages? (possibly with different default configurations, like adding -Wc++-compat to the commandline for C runs). Cheers, Manuel.
Re: c-c++-common testsuite
On Fri, 7 Aug 2009, Manuel López-Ibáñez wrote: > Often I want to test the exactly same testcase in C and C++, so I find > myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be > possible to have a shared testsuite dir that is run for both C and C++ > languages? (possibly with different default configurations, like > adding -Wc++-compat to the commandline for C runs). You'd need to have two .exp files (one in a gcc.something directory and one in a g++.something directory) that look somewhere other than $srcdir/$subdir to find the test source files. $srcdir in the .exp files should refer to the gcc/testsuite directory so you should be able to write the .exp files to look in $srcdir/c-c++-common (say) to find the source files to use in the tests. -- Joseph S. Myers jos...@codesourcery.com
Re: c-c++-common testsuite
On Fri, 2009-08-07 at 00:06 +0200, Manuel López-Ibáñez wrote: > Often I want to test the exactly same testcase in C and C++, so I find > myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be > possible to have a shared testsuite dir that is run for both C and C++ > languages? (possibly with different default configurations, like > adding -Wc++-compat to the commandline for C runs). I've been thinking about that lately, it would be useful for several kinds of functionality. We'd want effective targets for the language for using different options and for providing different error/warning checks for each language. I haven't looked into how to handle it with DejaGnu, maybe something like gcc.shared and a [symbolic] link to it called g++.shared; do links work with Subversion? Janis
Re: c-c++-common testsuite
On Thu, 6 Aug 2009, Janis Johnson wrote: > I've been thinking about that lately, it would be useful for several > kinds of functionality. We'd want effective targets for the language > for using different options and for providing different error/warning > checks for each language. I haven't looked into how to handle it with > DejaGnu, maybe something like gcc.shared and a [symbolic] link to it > called g++.shared; do links work with Subversion? Whether or not links work with Subversion, they don't in my experience work well with "diff" (it likes to dereference them when comparing two trees, so showing diffs to the same files more than once) and I wouldn't recommend relying on storage of links or other special sorts of files in a particular version control system, so possibly constraining future conversions to other systems. It's quite possible links are also problematic on some supported build systems. -- Joseph S. Myers jos...@codesourcery.com
Re: c-c++-common testsuite
Joseph S. Myers wrote: > On Thu, 6 Aug 2009, Janis Johnson wrote: > >> I've been thinking about that lately, it would be useful for several >> kinds of functionality. We'd want effective targets for the language >> for using different options and for providing different error/warning >> checks for each language. I haven't looked into how to handle it with >> DejaGnu, maybe something like gcc.shared and a [symbolic] link to it >> called g++.shared; do links work with Subversion? > > Whether or not links work with Subversion, they don't in my experience > work well with "diff" (it likes to dereference them when comparing two > trees, so showing diffs to the same files more than once) and I wouldn't > recommend relying on storage of links or other special sorts of files in a > particular version control system, so possibly constraining future > conversions to other systems. It's quite possible links are also > problematic on some supported build systems. I think MinGW would end up copying all the files into the linked tree. Possibly we could modify the algorithm that enumerates directories matching "$tool.*" to look for (e.g.) "*$tool.*" and then name directories like "c.c++.dg"? cheers, DaveK
Re: c-c++-common testsuite
On Fri, 7 Aug 2009, Dave Korn wrote: > Possibly we could modify the algorithm that enumerates directories matching > "$tool.*" to look for (e.g.) "*$tool.*" and then name directories like > "c.c++.dg"? The algorithm is hardcoded in core DejaGnu (runtest.exp). -- Joseph S. Myers jos...@codesourcery.com
Re: c-c++-common testsuite
On Thu, Aug 06, 2009 at 05:38:01PM -0700, Janis Johnson wrote: > I've been thinking about that lately, it would be useful for several > kinds of functionality. We'd want effective targets for the language > for using different options and for providing different error/warning > checks for each language. I haven't looked into how to handle it with > DejaGnu, maybe something like gcc.shared and a [symbolic] link to it > called g++.shared; do links work with Subversion? It should be easy with DejaGNU; does changing $tests in e.g. g++.dg/dg.exp successfully pick up files from another directory? -- Daniel Jacobowitz CodeSourcery
Re: c-c++-common testsuite
2009/8/7 Janis Johnson :
> On Fri, 2009-08-07 at 00:06 +0200, Manuel López-Ibáñez wrote:
>> Often I want to test the exactly same testcase in C and C++, so I find
>> myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be
>> possible to have a shared testsuite dir that is run for both C and C++
>> languages? (possibly with different default configurations, like
>> adding -Wc++-compat to the commandline for C runs).
>
> I've been thinking about that lately, it would be useful for several
> kinds of functionality. We'd want effective targets for the language
> for using different options and for providing different error/warning
> checks for each language. I haven't looked into how to handle it with
> DejaGnu, maybe something like gcc.shared and a [symbolic] link to it
> called g++.shared; do links work with Subversion?
Janis, it would be extremely useful to have dg-options that are only
enabled for certain languages, so I can do
/* { dg-options "-std=c99" { dg-require-effective-target c } } */
/* { dg-options "" { dg-require-effective-target c++ } } */
Would this be hard to implement? Any ideas?
As for how to run the shared tests, Joseph suggestion works, but I
think it is better to just run the common tests from each dg.exp file
Index: gcc/testsuite/gcc.dg/dg.exp
===
--- gcc/testsuite/gcc.dg/dg.exp (revision 150491)
+++ gcc/testsuite/gcc.dg/dg.exp (working copy)
@@ -30,7 +30,11 @@ dg-init
# Main loop.
dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cSi\]]] \
"" $DEFAULT_CFLAGS
+# C/C++ common tests.
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/*.\[cSi\]]] \
+ " -Wc++-compat " ""
+
# All done.
dg-finish
Index: gcc/testsuite/g++.dg/dg.exp
===
--- gcc/testsuite/g++.dg/dg.exp (revision 150491)
+++ gcc/testsuite/g++.dg/dg.exp (working copy)
@@ -47,7 +47,11 @@ set tests [prune $tests $srcdir/$subdir/
set tests [prune $tests $srcdir/$subdir/graphite/*]
# Main loop.
dg-runtest $tests "" $DEFAULT_CXXFLAGS
+# C/C++ common tests.
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/*.\[cSi\]]] \
+ "" ""
+
# All done.
dg-finish
so people can run c-c++-common testcases by doing simply
make -C gcc check-gcc RUNTESTFLAGS=dg.exp='*Wconversion*'
Cheers,
Manuel.
Re: c-c++-common testsuite
On Fri, 2009-08-07 at 15:48 +0200, Manuel López-Ibáñez wrote:
> Janis, it would be extremely useful to have dg-options that are only
> enabled for certain languages, so I can do
>
> /* { dg-options "-std=c99" { dg-require-effective-target c } } */
> /* { dg-options "" { dg-require-effective-target c++ } } */
>
> Would this be hard to implement? Any ideas?
This seems to work fine (added to target-supports.exp), except that
you'd use them in your example as just "c" and "c++".
# Return 1 if the language for the compiler under test is C.
proc check_effective_target_c { } {
global tool
if [string match $tool "gcc"] {
return 1
}
return 0
}
# Return 1 if the language for the compiler under test is C++.
proc check_effective_target_c++ { } {
global tool
if [string match $tool "g++"] {
return 1
}
return 0
}
