On Wed, Nov 28, 2012 at 02:10:05PM +0400, Konstantin Serebryany wrote:
> I'd like to understand our long-term strategy wrt the asan/tsan tests in gcc.
> Most of the tests we have today are not specific to the compiler and
> so can potentially be used with any compiler.
> The problem is the testing harness (FileCheck/gtest vs dejagnu).
> I understand that using alien testing harnesses in the gcc tree might
> be unacceptable,
Yes, it is.
> but the other choice is doubled maintenance burden for tests.
There is no problem if somebody at google or elsewhere keeps running
say the llvm asan/tsan tests against gcc (but guess it needs to be adjusted
for that anyway, in the // RUN comments the tests are invoking
clang/clang++ etc., you'd need to either use a symlink clang -> gcc and
similar, or adjust comments), but we need some minimal testsuite inside of
gcc for the features, as GCC developers can't be required to run extra
testsuites and we need some way to ensure we don't regress, e.g. because of
an unrelated change etc. I guess changes to existing llvm tests can be
monitored from time to time and the corresponding tests in gcc adjusted,
and also new tests could be ported as time permits.
And once we have a working testsuite, generally all bugfixes/new features
for the compiler should be acompanied by testcases.
Jakub
