c-c++-common testsuite

c-c++-common testsuite

[Manuel López-Ibáñez]

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

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 838 bytes --]

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
joseph@codesourcery.com

Re: c-c++-common testsuite

[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

Re: c-c++-common testsuite

[Joseph S. Myers]

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
joseph@codesourcery.com

Re: c-c++-common testsuite

[Dave Korn]

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

[Joseph S. Myers]

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
joseph@codesourcery.com

Re: c-c++-common testsuite

[Daniel Jacobowitz]

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

[Manuel López-Ibáñez]

2009/8/7 Janis Johnson <janis187@us.ibm.com>:
> 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

[Janis Johnson]

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
}