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 [EMAIL PROTECTED] (650) 331-3385 x713
