| Message ID | 53E484B2.10309@arm.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Aug 8, 2014 at 4:05 PM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote: > > On 07/08/14 10:43, Bin Cheng wrote: >> >> Hi, >> Case pr61772.c scans specific string in assembly file, and it is run for >> many different option combinations. When it's tested against different >> lto >> option combinations on targets like ARM, the generated pr61772.s may only >> contain lto object content, rather than assembly codes. The scanning >> check >> is failed in these cases. >> I think disabling lto won't weaken the test since what it tests has >> nothing >> to do with lto. This patch fixes these failures by disabling lto. >> >> Is it OK? > > > Hi Bin, > > Do you think it would be better to just add -ffat-lto-objects instead? That > way the output would contain the assembly as well. Example patch attached. > > We might want check that LTO doesn't optimise the assembly away? Not actually. It's a compilation time test and IMHO if-conversion optimization here has nothing to do with lto. Another reason here is we can't just add a single lto option without support full lto testing. Consider scenario testing on a target without lto? Please correct if I was wrong. Thanks, bin > > Kyrill > > >> Thanks, >> bin >> >> gcc/testsuite/ChangeLog >> 2014-08-07 Bin Cheng <bin.cheng@arm.com> >> >> * gcc.dg/torture/pr61772.c: Skip lto running.
On 08/08/14 09:24, Bin.Cheng wrote: > On Fri, Aug 8, 2014 at 4:05 PM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote: >> On 07/08/14 10:43, Bin Cheng wrote: >>> Hi, >>> Case pr61772.c scans specific string in assembly file, and it is run for >>> many different option combinations. When it's tested against different >>> lto >>> option combinations on targets like ARM, the generated pr61772.s may only >>> contain lto object content, rather than assembly codes. The scanning >>> check >>> is failed in these cases. >>> I think disabling lto won't weaken the test since what it tests has >>> nothing >>> to do with lto. This patch fixes these failures by disabling lto. >>> >>> Is it OK? >> >> Hi Bin, >> >> Do you think it would be better to just add -ffat-lto-objects instead? That >> way the output would contain the assembly as well. Example patch attached. >> >> We might want check that LTO doesn't optimise the assembly away? > Not actually. It's a compilation time test and IMHO if-conversion > optimization here has nothing to do with lto. Another reason here is > we can't just add a single lto option without support full lto > testing. Consider scenario testing on a target without lto? Please > correct if I was wrong. Ok, skipping it is fine by me then. Kyrill > Thanks, > bin >> Kyrill >> >> >>> Thanks, >>> bin >>> >>> gcc/testsuite/ChangeLog >>> 2014-08-07 Bin Cheng <bin.cheng@arm.com> >>> >>> * gcc.dg/torture/pr61772.c: Skip lto running.
diff --git a/gcc/testsuite/gcc.dg/torture/pr61772.c b/gcc/testsuite/gcc.dg/torture/pr61772.c index da4c93e..aa60c14 100644 --- a/gcc/testsuite/gcc.dg/torture/pr61772.c +++ b/gcc/testsuite/gcc.dg/torture/pr61772.c @@ -1,4 +1,5 @@ /* { dg-do compile } */ +/* { dg-options "-ffat-lto-objects" } */ /* { dg-final { scan-assembler-times "XXX" 2 } } */ static inline __attribute__((always_inline)) int dec_and_test (int *i)