[PATCH] Fix mips-tfile issues on Tru64

[Roger Sayle]

On Wed, 5 Feb 2003, Richard Henderson wrote:
> On Wed, Feb 05, 2003 at 12:17:29AM -0700, Roger Sayle wrote:
> > I have a suspicion that although the requirement for a whitespace
> > terminator is documented in the comments in the source code...
>
> I have a suspicion that it's documented nowhere, and was not
> in fact intended at all.  Certainly I consider it a bug.

I don't suppose you have a suggestion for how this can be fixed?
The semantics of arg_going as described above its declaration:

/* Nonzero if an arg has been started and not yet terminated
   (with space, tab or newline).  */
static int arg_going;

And the only checks of this value in do_spec_1 are after seeing
either '\n':

      case '\n':
        /* End of line: finish any pending argument,
           then run the pending command if one has been started.  */
        if (arg_going)
	  ...

or '|':

      case '|':
        /* End any pending argument.  */
        if (arg_going)
	  ...

or ' ' or '\t':

      case '\t':
      case ' ':
        /* Space or tab ends an argument if one is pending.  */
        if (arg_going)
	  ...


The arg_going argument is also processed at the end of the string if
processing_spec_function is true.  Given that arg_going is doing
exactly "what's described on the label", I wasn't sure whether it
was osf.h that was at fault.


Using all my expertise of GCC's RTL optimization passes and constant
folding transformations, I suspect that a plausible fix may be to change
the '{' case in do_spec_1 at line 5130 of gcc.c, such that on returning
from "handle_braces" its performs the same arg_going processing as the
%W{...} case does after calling handle_braces, on line 4797 of the same
file.

Does that seem like it should be the intended behaviour?  If so, I'll
prepare a patch and test it.  Sorry for asking for my hand to be held,
but I have great difficulty trying to understand what the author of
GCC's specs system was intending to do.

Roger
--