Re: why open output file if -fsyntax-only

[Nix <nix at esperi dot demon dot co dot uk>]

On 13 Mar 2001, Per Bothner yowled:
> On October 14 1999 I changed toplev.c so the assembler output file
> was not opened if -fsyntax-only.

I'll respond, as this was my (work|fault). (Jeff was a lot of help,
too, as you say.)

> On August 21 Jeff undid this change, and I don't understand why.  There is
> a comment:
> 
>   /* Open assembler code output file.  Do this even if -fsyntax-only is on,
>      because then the driver will have provided the name of a temporary
>      file or bit bucket for us.  */
> 
> -but I'm afraid that doesn't clarify the situation.  Why do we want to
> open a file we shouldn't be writing to?  It just wastes time - and
> hides bugs.  (I consider writing when flag_syntax_only is true to be
> a bug.)

The problem is that in varasm.c (and other places), there are *many*
places where we write to files when -fsyntax-only is on, and they're
buried deep in the guts of the compiler; places that, IMHO, should not
have to consider `is -fsyntax-only provided' or even `are we writing
output', but which should just write output with the assurance that it
gets thrown away if it isn't needed. Repeated checks of whether the
output file is NULL obfuscate parts of the compiler that are already too
obfuscated, and introduce a class of bugs that otherwise would not
exist.

> My agenda is not actually when the user specifies -fsyntax-only,
> bt when gcj does so.  When gcj compiles .java files to .class files,
> it passes -fsyntax-only to jc1 to suppress generating an output file.
> I really don't want to open an output file needlessly.  Not only do
> we waste time opening the file, we then waste time removing it.

Look at the change done in gcc.c at the same time; the system throws the
data straight at /dev/null if /dev/null is supported; a temporary file
is used only if we don't have a bit bucket on the host. So there's no
tempfile creation or removal as long as HOST_BIT_BUCKET is defined and
writable. (All that stuff is handled by the compiler driver.)

> We do have the option of using standard output as the output file: '-o -'.
> But then I need to be certain that the compiler is not going to be
> spewing random junk to the output file.  I would feel more comfortable
> that such problems will be caught quickly if we just don't open the output.

In practice, they *aren't* caught quickly :( I guess nobody uses
-fsyntax-only much, because until I wrote that patch last year there
were three-line C programs that were throwing things at an output file
with -fsyntax-only (such as c-torture/compile/921126-1.c on an
i586-pc-linux-gnu host) and crashing as a result. There are *dozens* of
places which need armouring against -fsyntax-only, and I think that such
armouring is tantamount to obfuscation.

I'm suffering from a nasty cold at the moment so I fear I'm not being
very coherent here. I went into rather more detail in the thread rooted
at <http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01517.html>; the
precise things being done in the patch changed a bit over the course of
the thread (which continues in
<http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00346.html> and
<http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00210.html>), but the
rationale remained the same.

-- 
`I wish the garbage collection service for my apartment was half as aggressive
 as the one in GNU ld.' --- Phil Edwards