On September 25, 2015 6:52:37 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote: >On 09/22/2015 03:26 PM, David Malcolm wrote: >> This patch is essentially identical to v1 here: >> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00729.html >> The only change is in the ChangeLog, moving the libgo.exp >> ChangeLog entry into gcc/testsuite/ChangeLog, analogous to >> where Ian put it when introducing the file in r167407. >> >> OK for trunk? >> >> Blurb from v1 follows: >> >> This patch adds an easy way to write tests for expected multiline >> output. For example we can test carets and underlines for >> a particular diagnostic with: >> >> /* { dg-begin-multiline-output "" } >> typedef struct _GMutex GMutex; >> ^~~~~~~ >> { dg-end-multiline-output "" } */ >> >> It is used extensively by the rest of the patch kit. >> >> multiline.exp is used by prune.exp; hence we need to load it before >> prune.exp via *load_gcc_lib* for the testsuites of the various >> non-"gcc" support libraries (e.g. boehm-gc). >> >> gcc/testsuite/ChangeLog: >> * lib/multiline.exp: New file. >> * lib/prune.exp: Load multiline.exp. >> (prune_gcc_output): Call into multiline.exp to handle any >> multiline output directives. >> * lib/libgo.exp: Load multiline.exp before prune.exp, using >> load_gcc_lib. >> >> boehm-gc/ChangeLog: >> * testsuite/lib/boehm-gc.exp: Load multiline.exp before >> prune.exp, using load_gcc_lib. >> >> libatomic/ChangeLog: >> * testsuite/lib/libatomic.exp: Load multiline.exp before >> prune.exp, using load_gcc_lib. >> >> libgomp/ChangeLog: >> * testsuite/lib/libgomp.exp: Load multiline.exp before prune.exp, >> using load_gcc_lib. >> >> libitm/ChangeLog: >> * testsuite/lib/libitm.exp: Load multiline.exp before prune.exp, >> using load_gcc_lib. >> >> libvtv/ChangeLog: >> * testsuite/lib/libvtv.exp: Load multiline.exp before prune.exp, >> using load_gcc_lib. >This stalled due to the dejagnu version discussion, which itself has >stalled :( > >I think the only issue was the loading of prune.exp and until we've >jumped to the latest dejagnu, using load_gcc_lib is the approved way to > >deal with that problem. > >Soooo. > >Approved. Hopefully we'll be able to clean up the load_gcc_lib mess in > >the near future, but I don't see a good reason to continue to hold up >this patch.
Indeed, didn't mean to stall that one. It's just seeing folks scratching their head over solved non-problems is something I cannot easily overcome. Bad habit, I know. I fear I'll never learn it ;) Cheers, > >jeff
