"Maciej W. Rozycki" <firstname.lastname@example.org> writes:
> On Fri, 8 Jul 2005, Richard Sandiford wrote:
>> Right. I've always thought of them as the canonical options for gcc
>> as well. I think the only reason internal compilers like cc1 have
>> -mel and -meb is because gcc's target options system has traditionally
>> required every target option to begin with "-m". (That's no longer
>> a restriction in 4.1 FWIW.)
> I'm not sure relaxing this restriction is actually a good idea -- there
> may be tools external to GCC that make this assumption for additional
> handling of options passed to GCC.
Oh, I agree that targets shouldn't gratuitously add non -m options.
All I meant was that, if a target does decide to support compatibility
options like -EB or -EL (or -BE or -LE), the new intrastructure allows
you to do it directly, rather than introduce internal forwarding options
like -meb or -mel. Forwarding options can cause the sort of confusion
we've seen here.
If we have a clean slate, and no compatibility worries, I agree that
it's better to use -m options across the board.
> FWIW, I prepared the following patch for GCC 3.4.x the other day -- would
> you care to verify whether it's still needed for 4.x? It may be worth
> applying to 3.4, too -- I think the branch hasn't got closed yet, has it?
A quick look at the code suggests that it is still needed for 4.x, yes.
> 2005-07-08 Maciej W. Rozycki <email@example.com>
> * config/mips/linux.h (CC1_SPEC): Override defaults from
Looks reasonable, but I think you should just set SUBTARGET_CC1_SPEC
to the normal linux.h definition of CC1_SPEC. There shouldn't be
any need to redefine CC1_SPEC itself (with all the mips.h duplication
that that implies). It'll be easier to keep things in sync that way.
> Unfortunately it won't let us remove the newly introduced hackery from
> Linux as (unlike you) we need to support versions back to 2.95.x.