| Message ID | 4FEB8ADF.1000305@mentor.com |
|---|---|
| State | New |
| Headers | show |
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 { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { target vect_hw_misalign } } } */ > > Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the > gcc test summary. I'm pretty sure the following accomplishes the same > goal: > > /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */ I don't think so? The first sets the xfail status for the testcase. If you change the condition, you can't the xfail state for some targets, which would be wrong (without a vec person chiming in). I'd like to think you can compose the two with some spelling... I just don't think this one is it.? I grepped around and found: /* { dg-message "does break strict-aliasing" "" { target { *-*-* && lp64 } xfail *-*-* } 8 } */ which might have the right way to spell it, though, I always test to ensure the construct does what I want. > That is, run the check everywhere We don't want to run the test on other than vect_hw_misalign targets, right?
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" { xfail { vect_no_align } } } } */ >> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { target vect_hw_misalign } } } */ >> >> Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the >> gcc test summary. I'm pretty sure the following accomplishes the same >> goal: >> >> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */ > > I don't think so? The first sets the xfail status for the testcase. If you change the condition, you can't the xfail state for some targets, which would be wrong (without a vec person chiming in). The two checks are run separately. The first one runs everywhere and is expected to fail for vect_no_align. The second is only run for vect_hw_misalign. Targets for which vect_no_align is false and vect_hw_misliang is true get two PASS reports. > I'd like to think you can compose the two with some spelling... I just don't think this one is it.? No, there is no way to combine "target" and "xfail", although since we intercept them we could presumably come up with a way to do that, with syntax and semantics we design. > I grepped around and found: > > /* { dg-message "does break strict-aliasing" "" { target { *-*-* && lp64 } xfail *-*-* } 8 } */ > > which might have the right way to spell it, though, I always test to ensure the construct does what I want. Nope. That should be flagged as an error by dg-message but it's passed through GCC's process-message which ignore errors (a bug) and simply ignores the directive. I'm currently trying a fix to not ignore errors from dg-error/dg-warning/dg-message and will then fix up the broken tests. >> That is, run the check everywhere > > We don't want to run the test on other than vect_hw_misalign targets, right? > I don't know, but right now it's run everywhere at least once. Janis
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/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 vect people. I should have said that *currently* there is no way to combine them. We override dg-process-target and can come up with a way to provide both "target" and "xfail" in the target-selector. Something like: target { selector } xfail { selector } where "target" is the first argument, "xfail" is the third. Selectors can be lists of target triplets, but those can be within braces making them a single argument. What do you think? Janis
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 > braces making them a single argument. What do you think? I love composability. The exact syntax I think falls out from the implementation... I'd leave that to the implementor.
Index: gcc.dg/vect/vect-50.c =================================================================== --- gcc.dg/vect/vect-50.c (revision 189025) +++ gcc.dg/vect/vect-50.c (working copy) @@ -61,8 +61,7 @@ align the store will not force the two loads to be aligned). */ /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */ -/* { 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" { target vect_hw_misalign } } } */ +/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && {! vect_hw_misalign } } } } } */ /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { xfail { vect_no_align || {! vector_alignment_reachable} } } } } */ /* { dg-final { scan-tree-dump-times "Alignment of access forced using versioning." 3 "vect" { target vect_no_align } } } */ /* { dg-final { scan-tree-dump-times "Alignment of access forced using versioning." 1 "vect" { target { {! vector_alignment_reachable} && { {! vect_no_align } && {! vect_hw_misalign } } } } } } */
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" { target vect_hw_misalign } } } */ Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the gcc test summary. I'm pretty sure the following accomplishes the same goal: /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */ That is, run the check everywhere and expect it to fail for effective targets for which vect_no_align is true and vect_hw_misalign is false. Tested on i686-pc-linux-gnu and arm-none-eabi. I'm enough confused that I'm not going to call this one obvious, it needs a sanity check from someone else; OK for trunk? Janis 2012-06-27 Janis Johnson <janisjo@codesourcery.com> * gcc.dg/vect/vect-50.c: Combine two scans.