relative line numbers and dg-line directive

Hi,

I.

dg-error et al accept line numbers:
...
# dg-error regexp comment [{ target/xfail selector } [{.|0|linenum}]] 

#       indicate an error message <regexp> is expected on this line 

#       (the test fails if it doesn't occur) 

#       linenum=0 for general tool messages (eg: -V arg missing). 

#       "." means the current line. 

...

When testing for a single message on the same line, we don't need to 
specify a line number:
...
ind a; /* { dg-error "unknown type name ind" "" } */
...

But when testing for two messages on the same line, we need a line 
number in the second test:
...
ind a[]; /* { dg-error "unknown type name ind" "" } */
/* { dg-warning "assumed to have one element" "" { target *-*-* } 1 } */
...


II.

Using absolute line numbers is fragile though. When modifying the 
testcase (f.i., by adding a dg-require-effective-target line at the 
start) the line number needs to be updated.

In the gcc testsuite, relative line numbers (with .-1 meaning the 
previous line and .+1 meaning the next line) have been added as a means 
to work around that. So, the previous example can be rewritten as:
...
ind a[]; /* { dg-error "unknown type name ind" "" } */
/* { dg-warning "assumed to have one element" "" { target *-*-* } .-1 } */
...


III.

However, when relative line numbers become too large, it becomes less 
clear what line it refers to, and when adding a line inbetween the 
directive using the relative line number and the line it refers to, the 
relative line number still needs to be updated.

In the gcc testsuite, we've also added the directive dg-line  with 
argument varname, that saves the line number of the directive in a 
variable varname, which can be used as line number in dg directives:
...
extern void some_func (int *); /* { dg-line some_func_decl } */

<SNIP many lines>

   some_func (&j); /* { dg-warning "discards .volatile. " } */
/* { dg-message "but argument is of type" "" { target *-*-* } 
some_func_decl } */
...



IV.

Is there any interest in having either or both of these concepts added 
to dejagnu's dg.exp?

Thanks,
- Tom