Hi Christophe, > On 29 Jan 2019, at 09:58, Christophe Lyon <christophe.l...@linaro.org> wrote: > > On Sat, 26 Jan 2019 at 17:43, Iain Sandoe <idsan...@googlemail.com> wrote: >> >> Hi Christophe, >> >>> On 23 Jan 2019, at 13:16, Christophe Lyon <christophe.l...@linaro.org> >>> wrote: >> >>> dg-extract-results currently moves lines like >>> WARNING: program timed out >>> at the end of each .exp section when it generates .sum files. >>> >>> This is because it sorts its output based on the 2nd field, which is >>> normally the testname as in: >>> FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto >>> -fno-use-linker-plugin -flto-partition=none execution test >>> >>> As you can notice 'program' comes after >>> gcc.c-torture/execute/20020129-1.c alphabetically, and generally after >>> most (all?) GCC testnames. >>> >>> This is a bit of a pain when trying to handle transient test failures >>> because you can no longer match such a WARNING line to its FAIL >>> counterpart. >>> >>> The attached patch changes this behavior by replacing the line >>> WARNING: program timed out >>> with >>> WARNING: gcc.c-torture/execute/20020129-1.c -O2 -flto >>> -fno-use-linker-plugin -flto-partition=none execution test program >>> timed out >>> >>> The effect is that this line will now appear immediately above the >>> FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto >>> -fno-use-linker-plugin -flto-partition=none execution test >>> so that it's easier to match them. >>> >>> >>> I'm not sure how much people depend on the .sum format, I also >>> considered emitting >>> WARNING: program timed out gcc.c-torture/execute/20020129-1.c -O2 >>> -flto -fno-use-linker-plugin -flto-partition=none execution test >>> >>> I also restricted the patch to handling only 'program timed out' >>> cases, to avoid breaking other things. >>> >>> I considered fixing this in Dejagnu, but it seemed more complicated, >>> and would delay adoption in GCC anyway. >>> >>> What do people think about this? >> >> It seems a good idea (for those of us with targets prone to timeout issues). >> I’m going to give it a try on Darwin. >> > > Thanks for taking a look and confirming I'm not the only one having to face > random timeouts :-)
My worst-cases are a couple of PCH-related that are still unanalysed.. but those are not the only ones. + when I use VMs to cover some of the earlier versions of the system, they are much more prone to occasional timeouts. > Did it work for you? So far it’s looking nice… (anything that makes the dg output more stable is Good in my book) … I am not sure (not checked thoroughly) but I think I saw one case in libgomp testing where it didn’t pick up the timeout, will poke some more at that if i see it again. thanks for the patch! Iain
