On Tue, 29 Jan 2019 at 11:12, Iain Sandoe <idsan...@googlemail.com> wrote: > > 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.
If you still have the logs, you can run the script manually. > > thanks for the patch! > Iain >
