Re: [PATCH] Fix driver/39293

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
>> I think that adding a new -save-temps-o option, with the behavior
>> suggested above, is probably the best option, perhaps in parallel with
>> adding a deprecation warning for -save-temps.
> 
> The logic is reasonably compelling, but I really hate the idea of adding
> yet another weird option.  I think I would be happier with breaking
> existing scripts.

I almost said the same thing, but I think we really need to get serious
about compatibility issues.  Every time users upgrade to a new compiler
version, way too much stuff breaks, and lots of little things add up to
a lot of pain.  That makes using other compilers more attractive to users.

I find statements like "I looked through Fedora and nothing there
breaks" to be relatively weak evidence.  Sure, that's a ton of code, but
most of it is code that has already been engineered for portability,
across architectures, across operating systems, and even across
compilers (including lots of variants of GCC).  That codebase looks very
different from some of the codebases that other users of GCC have.

> Maybe we should ask: does anybody know of any scripts which would break,
> and how difficult they would be to fix?

I have seen scripts which grab data from .s files generated with
-save-temps.  Those aren't public; they're part of crufty build processes.

There are some possible weird compromises.  For example, create the
temporary files in the new locations, but create symlinks from the old
locations to the new ones.  That's mostly backwards-compatible, but
still avoids the weird bugs from parallel compilation.  Or use the old
algorithm, but open files with O_EXCL.  But, both of those have some
run-time costs.

Or a configure-time option to GCC controlling how -save-temps works, and
then we get to argue about the default.  Or an environment variable
controlling how -save-temps works, and then we get to argue about the
default again.  This is actually a case where an environment variable
might not be a crazy idea; it's less invasive to user build processes
than a command-line option.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713