This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix driver/39293
On Tue, Mar 03, 2009 at 11:00:49AM -0800, Mark Mitchell wrote:
> 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.
In fact that's how I stumbled over the problem. I have my own private script
for building spec and I was looking at the asm.
> 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.
Not all systems have symlinks.
> 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.
Unless the variable happens to clash with some other variable. Hmmm, I have
about 175 environment variables set right now.
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com