ping*2: [RFA:] testsuite infrastructure for options implied by dg-final methods

[Hans-Peter Nilsson]

> From: Mike Stump <mikestump@comcast.net>
> Date: Fri, 4 Nov 2011 17:53:05 +0100

> On Nov 4, 2011, at 6:47 AM, Hans-Peter Nilsson <hans-peter.nilsson@axis.com> wrote:
> > Ping again, CC:ing testsuite maintainers.
> 
> With the number of qualified individuals commenting in the
> thread, I was going to stay out of it.  If all the breakages
> and review point others had are resolved, Ok.

I know people responded to my patch message when reporting
problems after Honza's LTO_TORTURE_OPTIONS change but as I
mentioned, those breakages were unrelated to my patch, and
AFAICT mostly for load_lib ordering problems and for not setting
GCC_UNDER_TEST properly in Honza's original change for use in
other testsuites.  I should have guessed and I'll remember to
scream loudly next time I'm implicated that way. :)

I looked and it seemed that Richi's problems was unresolved,
running
 make check-gfortran RUNTESTFLAGS="dg.exp=logical_dot_product.f90"
supposedly in the obj/gcc subdir - use check-fortran from the
obj/ toplevel. But I can't repeat it neither with nor without my
patch.  Richi?

>  I kinda don't
> like the brittle upvars.

That's just the way it has to be done to inspect the necessary
dejagnu state and how other lib/*.exp infrastructure parts are
doing it, some for exactly the same "upvar" (lto and scanasm).
If this use breaks, they break too.

I thought about it, but found no other way.  Maybe as a future
dejagnu improvements introducing stable hooks in dejagnu would
be one way to do it.  (For dejagnu folks convenience, thread at
<http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01917.html>)

>  If someone has a substantially less
> brittle method that does not use upvar and is reasonably
> concise and readable...

I'll wait a few days.

brgds, H-P