"Maciej W. Rozycki" <macro@xxxxxxxxxxxxxx> 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 <macro@xxxxxxxx> > > * config/mips/linux.h (CC1_SPEC): Override defaults from > config/linux.h. 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. Understood. Richard
