As asan/tsan functionality is getting into trunk, we need to set up testings as soon as possible to avoid bitrot.
Kostya can probably shed some lights on the test case requirements, and we can continue discussions on how to extend dejagnu to import those tests. thanks, David On Fri, Oct 12, 2012 at 9:46 AM, Diego Novillo <dnovi...@google.com> wrote: > On 2012-10-12 12:40 , Jakub Jelinek wrote: >> >> On Fri, Oct 12, 2012 at 11:51:22AM -0400, Diego Novillo wrote: >>> >>> On 2012-10-12 11:01 , Rainer Orth wrote: >>>> >>>> Diego Novillo <dnovi...@google.com> writes: >>>> >>>>> 3- To run ASAN's testsuite, I propose a simple wrapper script that >>>>> executes >>>>> it using the just-built gcc. I don't think it's worth the pain to >>>>> convert >>>>> the testsuite into DejaGNU. >>>> >>>> >>>> If the testsuite is not converted (which can be ugly for maintainers >>>> since it needs separate mechanisms for everything Dejagnu already deals >>>> with, like timeouts, target-specific skipping), at the very least make >>> >>> >>> The thing is that if we convert the testsuite, then taking pristine >>> tarballs is out of the question and we end up with a library like >>> boehm-gc or zlib. I would prefer to have something completely >>> separate that we can just drop in. >> >> >> I don't see how can their testcase be used if not converted to Dejagnu >> though, most of their testcases are full of LLVM testcase markup >> (// RUN, // CHECK*, etc.). So, if we import the library unmodified, >> we'll need to setup some directory under gcc/testsuite/ for asan tests >> and arrange for *.exp to find the libraries. > > > Hm, perhaps that would be the way then. Have the testsuite in > gcc/testsuite/asan and only run it if ASAN was configured. We could adapt > the basic tests from libasan and over time add more into gcc/testsuite/asan. > > > Would that work? > > > Diego.
