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.

jeff


Reply via email to