[egcs 1.1] Fix gcc.c handling of %O vis-a-vis temp files

[Craig Burley]

>  In message < 199807261855.OAA08052@melange.gnu.org >you write:
>  > This fixes, possibly among other things, `g77 -v' so it finishes.
>  > (The problem was that each %g%O was being given an entirely new
>  > temp file name.)
>This is the desired behavior now.  Each time you compile a file you 
>use a new set of temporary files.

There's not quite enough detail in what you wrote for me to be *sure*
what you're saying, but I believe the canonical interpretation would be
incorrect for the current sources.  You might use a new *set* for
the entire compile, but you still use a *single* file for the output
from the preprocessor and the input to the compiler; for the output
of the compiler and the input to the assembler; and for the output
of the assembler and the input to the linker.  Right?  If not, pretty
much nothing would work -- right?  If so, and if, as I believe, the
*suffix* is the key for determining whether a previously generated
name is used, then `%O' is, as documented, just another suffix, right?
So it, too, should represent a *single* file each time `%g%O' is
specified, right?

Originally, given `gcc foo.c', you got *one* temp filename "base" (sans
extension) for the preprocessed file, the assembler file, and the object
file.  Extensions were just "tacked on" to the `%g' or similar
specification.

Currently, you get one temp filename *per extension*.  That is, you
get one temp filename for the preprocessed file; a different one for
the assembler file; and yet a different one for the object file.

The bug I'm fixing is that the handling of `%g%O' is broken.  It is
*supposed* to be exactly as if the proper target-specific suffix
(normally `.o') is present, as in `%g.o'.  But, unlike when `.o' is
explicitly used, do_spec_1 currently generates a *new* filename per
*occurrence* of `%g%O' in the specs it is processing.

This is not how the behavior is documented.  Note I can't see any
docs (offhand) for the new temp-per-suffix-instead-of-per-invocation
changes, so maybe gcc.c sources are no longer the right place to find
docs, but I don't think there *needs* to be a writeup for that.  However,
if you just read what is *written* about %O, you see *no* mention of the
fact that a brand-new temp filename is generated each time it is
mentioned when paired with %g, and if you read the entry for %g, it's
quite clear that each and every `%g%O' would yield *exactly one* temp
filename for all such uses in an invocation, just as would be the
case for `%g.o' or `%g.s'.  (The docs don't make it clear whether
`%g.o' would use a different base name than `%g.s', IIRC, but it
shouldn't matter, as they're clearly two different files anyway.)

Further, the code as it exists (before my patch) is a bit buggy in
this and one other respect.  First, it doesn't have *any* comment
saying "we purposely ensure that we never match %O in our list of
suffixes, by searching for %O but entering it as .o or whatever",
which is a style bug, not to mention a coding kludge (since omitting
the search for each new %O would be a better approach, rather than
searching for something you *know* won't be found).  Second, it tries,
but fails, to properly support `%g%Ox', for example, which my patch
corrects by calling abort() in such a case rather than failing in
more mysterious ways.

So my claim is that the reason for the first bug is that the failure
to find %O (in effect) in the list of suffixes is *itself* a bug.
(The second is a bug regardless.)

Note that normal gcc and other `specs' entries don't really represent
linking of the object file using the "direct" approach -- essentially,
an exceptional mechanism is used to get the desired behavior, one that
I don't think g77 can use for `g77 -v', and perhaps one other front ends
can't always use.  (I believe I tried using this mechanism way back when
I was trying to get `g77 -v' to work for 0.5.23, and couldn't; certainly
gcc's exceptional handling of the linking phase isn't set up to *run* the
executable after linking it, so the gcc approach doesn't work, while
the approach g77 uses currently works fine, modulo newly introduced
bugs like this.)

It seems to me that most specs files actually use `%u%O', not `%g%O',
for the pertinent stuff.  So fixing `%g%O' won't hurt anything, but will
make `g77 -v' work again.

The upshot is that, while most specs files *happen* to use `%g%O' only
once, if at all, the bug I'm fixing is that it won't work whenever it is
used more than once, as g77 does for `g77 -v'.

>Is there some reason we can not fix g77 to DTRT?

g77 is already doing the right thing, based on the docs.  I doubt any
specs are suddenly requiring `%g%O' to return a new temp filename
each time it is used.  If I'm wrong, *they* should be changed to use
`%u%O' and `%U%O' as appropriate -- not g77.  But my investigation
suggests they're *already* using these, where appropriate.

However, we could "fix" g77 so `g77 -v' no longer uses `%g%O', but
uses `%g.o' instead, which would have the same effect on most systems,
and perhaps not break even on systems that *normally* use some other
suffix (but still work with `.o').  That seems like a backwards step
to me, but if it's what I have to do to make `g77 -v' work for
egcs 1.1, I'll do it.

In short, this is a very-recently-introduced bug, my fix takes complete
care of it, and any code that (erroneously) depends on the previous
behavior is broken *and* is trivially fixed by changing a single
character in one or two places in the appropriate specs entries.  But
I doubt any code besides g77 uses `%g%O' anyway -- neither gcc.c nor
cp/lang-specs.h contain this string, for example.

        tq vm, (burley)

P.S. Why do I feel I'm having to defend the workability of `g77 -v'
every couple of weeks?  Couldn't we just decide "it works, it's
useful, g77 users and developers have been depending on it for a
couple of years, so anything that breaks will be *assumed* to be
broken until proven otherwise"?

More to the point, before asking whether we should fix *g77* to DTRT,
shouldn't the person asking the question first determine just what
they think is *broken* in it?  I've *already* done the most full
investigation I think I could of why I thought `%g%O' is broken, along
with providing a patch and explanation -- why the leap to the conclusion
that I'm entirely wrong, and it must be my code that's wrong, without any
explanation of *what* is wrong in it?  (Perhaps I erroneously assumed
that simply examining the code changes would back up my documentation
as far as their validity; but I believe, even without looking at the
code changes, it's clear enough that I'm fixing a bug, at least to
anyone looking at the relevant specs entries and the docs for spec
entries like %g and %O.)