On Wed, Nov 28, 2012 at 2:24 PM, Jakub Jelinek <ja...@redhat.com> wrote: > 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,
I fully agree about "minimal testsuite". But, for example, porting the asan's gtest test (2+ KLOC) to another harness is probably too much. --kcc >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
