| Message ID | 4E03DD02.6010706@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On 24/06/11 01:40, Janis Johnson wrote: > Test gcc.target/arm/pr42093.c, added by Ramana, requires support for > arm_thumb2 but fails for those targets. The patch for which it was > added modified support for thumb1. Should the test instead require > arm_thumb1_ok, as in this patch? No this is for a Thumb2 defect so the test is valid for Thumb2 - we shouldn't be generating a tbb / tbh with signed offsets and that's what was happening there. This test I think ends up being fragile because the generation of tbb / tbh depends on how the blocks have been laid out . It would be interesting to try and get a test that works reliably in T2 . cheers Ramana > > Janis
On 24/06/11 14:18, Ramana Radhakrishnan wrote: > On 24/06/11 01:40, Janis Johnson wrote: >> Test gcc.target/arm/pr42093.c, added by Ramana, requires support for >> arm_thumb2 but fails for those targets. The patch for which it was >> added modified support for thumb1. Should the test instead require >> arm_thumb1_ok, as in this patch? > > No this is for a Thumb2 defect so the test is valid for Thumb2 - we > shouldn't be generating a tbb / tbh with signed offsets and that's what > was happening there. > > This test I think ends up being fragile because the generation of tbb / > tbh depends on how the blocks have been laid out . It would be > interesting to try and get a test that works reliably in T2 . > > cheers > Ramana > >> >> Janis > > > Perhaps -fno-reorder-blocks could be used to make it less fragile. R.
On 07/01/2011 02:02 AM, Richard Earnshaw wrote: > On 24/06/11 14:18, Ramana Radhakrishnan wrote: >> On 24/06/11 01:40, Janis Johnson wrote: >>> Test gcc.target/arm/pr42093.c, added by Ramana, requires support for >>> arm_thumb2 but fails for those targets. The patch for which it was >>> added modified support for thumb1. Should the test instead require >>> arm_thumb1_ok, as in this patch? >> >> No this is for a Thumb2 defect so the test is valid for Thumb2 - we >> shouldn't be generating a tbb / tbh with signed offsets and that's what >> was happening there. >> >> This test I think ends up being fragile because the generation of tbb / >> tbh depends on how the blocks have been laid out . It would be >> interesting to try and get a test that works reliably in T2 . >> >> cheers >> Ramana >> >>> >>> Janis >> >> >> > Perhaps -fno-reorder-blocks could be used to make it less fragile. > > R. > It passes for all thumb2 targets with that option. Janis
On 01/07/11 20:56, Janis Johnson wrote: > On 07/01/2011 02:02 AM, Richard Earnshaw wrote: >> On 24/06/11 14:18, Ramana Radhakrishnan wrote: >>> On 24/06/11 01:40, Janis Johnson wrote: >>>> Test gcc.target/arm/pr42093.c, added by Ramana, requires support for >>>> arm_thumb2 but fails for those targets. The patch for which it was >>>> added modified support for thumb1. Should the test instead require >>>> arm_thumb1_ok, as in this patch? >>> >>> No this is for a Thumb2 defect so the test is valid for Thumb2 - we >>> shouldn't be generating a tbb / tbh with signed offsets and that's what >>> was happening there. >>> >>> This test I think ends up being fragile because the generation of tbb / >>> tbh depends on how the blocks have been laid out . It would be >>> interesting to try and get a test that works reliably in T2 . >>> >>> cheers >>> Ramana >>> >>>> >>>> Janis >>> >>> >>> >> Perhaps -fno-reorder-blocks could be used to make it less fragile. >> >> R. >> > > It passes for all thumb2 targets with that option. > > Janis > > > Ok, so consider a patch to use that option pre-approved. R.
Index: gcc.target/arm/pr42093.c =================================================================== --- gcc.target/arm/pr42093.c (revision 175313) +++ gcc.target/arm/pr42093.c (working copy) @@ -1,5 +1,5 @@ /* { dg-options "-mthumb -O2" } */ -/* { dg-require-effective-target arm_thumb2_ok } */ +/* { dg-require-effective-target arm_thumb1_ok } */ /* { dg-final { scan-assembler-not "tbb" } } */ /* { dg-final { scan-assembler-not "tbh" } } */