Re: RFC: Bug in specs processing

[Mark Mitchell <mark at codesourcery dot com>]

Andrew Pinski wrote:

> >  gcc -c -ohw.o hw.c

> This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11810 .
> There was a patch posted here:

Thanks for the information.  In looking at this further, I think I've 
found a simple way to solve the problem.

In particular, we already have a macro SWITCHES_NEED_SPACES.  This macro 
applies when gcc is parsing the command-line options, before we start 
any specs processing.  If SWITCHES_NEED_SPACES contains the letter "o", 
then we will split "-ofoo.o" into "-o foo.o", and from that point 
forward everything just works.

The SWITCHES_NEED_SPACES macro is presently defined to a non-empty 
string only for Alpha OSF and MIPS IRIX; in both cases it contains only 
the letter "o".

So, I propose we just make the default definition of the macro contain 
the letter "o" instead of being the empty string.  The only case this 
will break is if there are assemblers/linkers out there that *require* 
the "-ofoo.o" form.  We know the GNU assembler and linker are happy with 
either form.  Does anyone actually know of a tool that requires the 
other form?  If there is such a tool, we could have a specs spelling 
that says "substitute the option and the argument, collapsing them into 
a single argument" so that a spec for such a tool could still exist.

In other words, my proposed solution is to make the canonical spelling 
inside gcc be the two-argument "-o foo.o" spelling, and -- if necessary 
-- to collapse the spelling for the output.  If there really are tools 
that require "-ofoo.o" this will improve the user experience, since 
presently saying "-o foo.o" will not work on such platforms.  (Because 
that's true, I doubt there exist such tools; lots of Makefiles would die 
there.)

Thoughts?

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