On Jun 29, 2012, at 8:45 AM, Janis Johnson wrote:
> Something like:
>
> target { selector } xfail { selector }
>
> where "target" is the first argument, "xfail" is the third.
Forcing (requiring) an ordering would be bad.
> Selectors can be lists of target triplets, but those can be within
> br
On 06/28/2012 08:02 PM, Mike Stump wrote:
> On Jun 28, 2012, at 10:26 AM, Janis Johnson wrote:
>> No, there is no way to combine "target" and "xfail",
>
> Ah... Grrr I hate non-composability. Given that, I think the original
> patch is fine, subject of course to the wants and wishes of vec
On Jun 28, 2012, at 10:26 AM, Janis Johnson wrote:
> No, there is no way to combine "target" and "xfail",
Ah... Grrr I hate non-composability. Given that, I think the original
patch is fine, subject of course to the wants and wishes of vect people.
On 06/27/2012 05:05 PM, Mike Stump wrote:
> On Jun 27, 2012, at 3:36 PM, Janis Johnson wrote:
>> These scans from gcc.dg/vect/vect-50.c, and others similar to them in
>> other vect tests, hurt my brain:
>>
>> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2
>> "vect" { xfai
On Jun 27, 2012, at 3:36 PM, Janis Johnson wrote:
> These scans from gcc.dg/vect/vect-50.c, and others similar to them in
> other vect tests, hurt my brain:
>
> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2
> "vect" { xfail { vect_no_align } } } } */
> /* { dg-final {
These scans from gcc.dg/vect/vect-50.c, and others similar to them in
other vect tests, hurt my brain:
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect"
{ xfail { vect_no_align } } } } */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect