This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: -save-temps still produces different .s and .o
Alexandre Oliva wrote:
Who would tell it? distcc and ccache know nothing about the compiler,
Obviously they know enough about the compiler and its options to
run the preprocessor and compiler proper separately. So it understands
the format of gcc options.
they just run whatever the user told them to, so it can't add command
line flags that some compilers might not support.
That can be handled by the configure script checking if
the new option is recognized.
An alternative is to use environment variables instead of flags.
Again, who would figure out the full source file name to pass to the
compiler?
The distcc client.
Except it would require these tools to adapt to specific features of
specific compilers, something they shouldn't have to do, since the
additional overhead would partially obviate the speed up that these
tools are meant to offer.
Not if it's done at configure time.
where you'd run:
gcc -flags source.c -c -o source.o
you run instead:
gcc -flags source.c -E > /tmp/tmpXXX.i
(cd /tmp && gcc -flags tmpXXX.i -c -o tmpXXX.o)
mv /tmp/tmpXXX.o source.o
if this doesn't produce the same object file as the single
translation, then it's useless for ccache and distcc, especially for
distcc.
I'm proposing:
DIR=`pwd`
gcc -flags source.c -E > /tmp/tmpXXX.i
(cd /tmp && gcc -fsource-name source.c -fworking-directory $DIR
-flags tmpXXX.i -c -o tmpXXX.o)
mv /tmp/tmpXXX.o source.o
This does not seem unreasonable, if it can simplify the compiler.
You seem to be willing to give up correct information in favor of
generating a single object file out of multiple sources.
No, I don't think so. Besides it's not just me and the compile
server. There is also the "intermodule" work, which is important
for cross-module optimization.
I don't
think this is a reasonable trade off. If you are compiling multiple
translation units, the debug info you get should be functionally
equivalent to that you'd get by compiling and assembling multiple
translation units separately, then running ld -r to merge them into a
single object file.
Functionally equivalent. It doesn't have to be identical.
The "main_input_filename" appears in the object file, but it isn't
really needed for anything. The "compilation direction" is useful
for finding source file (for the 'list' command), but is obviously
not essential. (Not that I'm arguing for leaving it out, of course.)
If you think you should output the translation unit identifier for
only the first translation, I have failed to communicate what I have
in mind. IMO, it should be done for every main input file.
Yes, in principle. However, certain debug format make that
difficult if doing a multi-module compile. And the latter
is more important, as it enables cross-module optmizations,
and the translation unit identifier isn't really used for anything.
Because it can't be done. If we output the initial debug info before
knowing the name of the real source file, we're emitting incorrect
debug info.
It can be done by using the command line flags for the initial debug
info, as I'm suggesting.
* Possibly remove -dumpbase, since we can use main_input_filename
after stripping directories.
It's not the same. Consider:
gcc -fpreprocessed test.i -fsource-name /path/to/src/foo.c \
-fworking-directory /path/to/build -da -o bar.o
What should the dump file names look like? Current compiler generates
test.i.*. Your suggestion would change it to foo.c.*. Why is such a
change a good thing?
Because that matches the output when compiling directly from source,
which I thought is what you wanted. Because the exact names of the
dump files isn't very important, so it seems wasteful to have a
special flag for it.
--
--Per Bothner
per@bothner.com http://per.bothner.com/