On Dec 1, 2014, at 2:52 AM, Marek Polacek <pola...@redhat.com> wrote:
> On Sun, Nov 30, 2014 at 11:00:12PM -0500, Jason Merrill wrote:
>> On 11/27/2014 08:57 AM, Marek Polacek wrote:
>>> -/* { dg-error "is not a constant expression" "" { target c++ } 12 } */
>>> +/* { dg-error "" "" { xfail { *-*-* } } 11 } */
>>
>> Please keep the expected message.
>
> Done in the below.
>
> 2014-12-01 Marek Polacek <pola...@redhat.com>
>
> PR sanitizer/63956
> * ubsan.c (is_ubsan_builtin_p): Check also built-in class.
> cp/
> * constexpr.c: Include ubsan.h.
> (cxx_eval_call_expression): Bail out for IFN_UBSAN_{NULL,BOUNDS}
> internal functions and for ubsan builtins.
> * error.c: Include internal-fn.h.
> (dump_expr): Add printing of internal functions.
> testsuite/
> * c-c++-common/ubsan/shift-5.c: Add fails.
Do you see:
PASS: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 11)
XFAIL: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 11)
PASS: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 14)
XFAIL: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 14)
PASS: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 17)
XFAIL: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 17)
PASS: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 20)
XFAIL: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 20)
PASS: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 34)
XFAIL: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 34)
PASS: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 37)
XFAIL: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 37)
on x86_64 on linux?
If so, this really isn’t cool. You cannot have the same name as both pass and
fail. At the heart of regression analysis is the notion that no test that
passed before now fails. One can run contrib/compare_tests to see if a patch
one is working on has any regressions in it, the beauty of the script is it
will tell you in plain language if there are any regressions or not. The
standard for gcc is, no regressions.
Could you find a way to fix this? Splitting into C and C++ test cases might be
one way. Fixing any expected failures might be another.
