On Tue, Jan 28, 2014 at 3:45 AM, Richard Smith <[email protected]> wrote:
> On Mon Jan 27 2014 at 5:39:25 AM, Alexey Samsonov <[email protected]> > wrote: > >> Interesting. We need the inverse of "REQUIRES" keyword. For example, we >> can have smth. like >> // UNSUPPORTED: asan >> that would tell lit to ignore this test if "asan" is in >> config.available_features. >> >> I'm not aware of such a feature in lit. Daniel, do you think it's worth >> implementing it? >> > > We could add a "not_asan" feature and use "REQUIRES: not_asan" > Alright, for now I've added "not_asan" feature and fixed the test in r200291. > (or maybe add support to lit for negative requirements), or perhaps for > this test we should "REQUIRES: stack" and provide "stack" unless we know > we're in a stack-space-constrained environment? > > >> On Fri, Jan 10, 2014 at 11:24 PM, [email protected] >> <[email protected]>wrote: >> >> >> >> On Tue Mar 26 2013 at 1:48:29 AM, Alexey Samsonov <[email protected]> >> wrote: >> >> Author: samsonov >> Date: Tue Mar 26 03:45:29 2013 >> New Revision: 177997 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=177997&view=rev >> Log: >> Actually mark ASan-unfriendly test as XFAIL >> >> Modified: >> cfe/trunk/test/Index/annotate-deep-statements.cpp >> >> Modified: cfe/trunk/test/Index/annotate-deep-statements.cpp >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/ >> annotate-deep-statements.cpp?rev=177997&r1=177996&r2=177997&view=diff >> ============================================================ >> ================== >> --- cfe/trunk/test/Index/annotate-deep-statements.cpp (original) >> +++ cfe/trunk/test/Index/annotate-deep-statements.cpp Tue Mar 26 >> 03:45:29 2013 >> @@ -3,6 +3,9 @@ >> // rdar://11979525 >> // Check that we don't get stack overflow trying to annotate an >> extremely deep AST. >> >> +// AddressSanitizer increases stack usage. >> +// XFAIL: asan >> >> >> This test is XPASSing for me under ASan. I assume it's because my machine >> happens to have a higher stack limit. Is there anything we can do to make >> this more reliable? >> >> >> + >> struct S { >> S &operator()(); >> }; >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >> >> >> -- >> Alexey Samsonov, MSK >> > -- Alexey Samsonov, MSK
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
