-save-temps still produces different .s and .o

[Per Bothner]

Alexandre Oliva wrote:

> It turns out that -fworking-directory was totally disabled with a
> patch that Per Bothner installed on Oct 1.  I'd noticed make bootstrap
> with distcc stopped working, but only today have I been able to
> investigate why.

It's hard to duplicate the "old" behaviour, because the "old" behavior
is not in 3.3.  It appears there is no released compiler that supports
-fworking-directory, so we can consider alternative solutions.

> It turns out that we no longer see the main input filename early
> enough when compiling a file that was already preprocessed,

I remember looking at some of this code, but without a testcase
(and not really knowing what it was for) I can easily have broken it.

Unfortunately, the old mechanism of trying to get the "real" main
input filename by peeking at the first file of the preprocessed file
was a bit of a kludge, and puts nasty constraints on the order things
are initialized, which complicates re-organizing the code, as might
be needed for multi-minfile compiles and the compile server.

What I did in the compile server branch was get the "real" main
input filename by using the -dumpbase option.  We're already passing
this flag when compiling with -save-temps.

I suggest doing something similar for the working directory.
So instead of extending the cpp file format, and adding the
-fworking-directory option, I think it would be easier to
have a cc1 command-line option that just calls set_src_pwd.
This seems a much simpler solution and does not constrain
the initialization logic of the compiler.

For the option for the directory name, we can invent a new
one or overload the -dumpbase option (just like stabs overloads
N_SO).  I.e.:
   cc1 -dumpbase ORIG_DIR_NAME/ -dumpbase ORIG_FILE_NAME foo.i ...

> The only way I see to fix this problem is to arrange for all front
> ends to call the init code from within their parse code, after they
> find out the real main_input_filename.  I.e., lang_dependent_init(),
> init_final() and coverage_init() would no longer be called in toplev.c
> before lang_hooks.compile_file, but rather within their code.  Would
> such a change be acceptable?

No.  There are too many dependencies in the compiler and this would
make it worse.

> Meanwhile, here's the patch that restores at least identical debug
> info with and without -save-temps.  Per, does any of this conflict
> with your needs? 

It conflicts with the long-term needs of the compile-server, whenever
that would get merged in.  At which point we'd probably have to
implement my proposed solution.

I'm willing to implement my solution.  This would include removing
the implementation and documentation of -fworking-directory.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/