This is the mail archive of the
mailing list for the GCC project.
Re: -save-temps still produces different .s and .o
Alexandre Oliva wrote:
> Yup. -E and -c. That's about all they have to know. Portable
Does Posix (or other standard) specify -E? Does it specify that
that compiling foo.i should be treated as a preprocessed C file?
The interface of cpp output file is an internal (though traditional)
interface. If distcc/cachecc wants to make use of an internal
interface, it is not totally unreasonable to ask them to use
special (optional) flags.
These command line options are not portable, so ccache and distcc, or
any other compiler wrapper, won't use it.
That's not necessarily our problem.
The compilation directory is absolutely essential for GDB to locate
source files without user intervention.
Not really. dbx and raw stabs didn't have it. It's helpful,
that's all. You don't need it if, for example, debugging in the
build directory, or if you use directory commands.
The main input filename is
absolutely essential for GDB's `info var' or `info func' to list the
actual source filename when you use ccache or distcc or -save-temps in
a compilation; currently, all you get is some random .i filename.
Hm. Looks like you're right (judging form some experiments on
c-parse.y). Should this be viewed as a bug in gdb - why isn't it using
the actual (momentary) source filename?
But 'info var' and 'info func' are relatively obscure commands
(I never use them). Most gdb commands and display uses the momentary
filename, so the main filename is unimportant.
And of course using the -finput-filename and -finput-dirname options
avoids the problem. It also can be used to fix c-parse.c and similar
files, which is a bonus of my proposal.
Command line flags like these are useless. The programs you'd like to
have changed to pass them won't do that, and shouldn't do that. GCC
has been able to figure out the main input filename forever, and now
it doesn't; this is a major regression.
I agree it's a regression; though it doesn't affect debugging
much if at all, so it's not an important regression. The question is
whether the minor regression (fixable by using a command line option)
is worth increased simplicity/flexibility of gcc internals.
I'm interested in other opinions on this matter.
GCC has been able to figure
out the preprocessing source directory from Aug 5 to Oct 1 last year,
now it doesn't; this is a minor regression. Introducing regressions
is not moving forward.
Internal simplification and reducing internal dependencies is
moving forward, especially if it makes possible architectural
changes that can improve optimization and/or compilation speed.
Assume that a tool actually took the trouble of supporting remote
compilation using gcc with dumping. It took the trouble to figure out
how GCC names the files, and proceeds accordingly. Now you change the
names from under it, and the tool is broken.
You're arguing hypotheticals. I doubt such a tool exists, and if it
does I don't see why I should care. The dump files are for debugging
Gcc; we're free to change their format, and well as their names.
Besides if they pass the new flags as suggested, things would work