[Top] [All Lists]

Re: CVS linux

To: "Maciej W. Rozycki" <>
Subject: Re: CVS linux
From: Richard Sandiford <>
Date: Fri, 08 Jul 2005 16:39:38 +0100
Cc: Ralf Baechle DL5RB <>, Thiemo Seufer <>,
In-reply-to: <> (Maciej W. Rozycki's message of "Fri, 8 Jul 2005 16:05:05 +0100 (BST)")
Mail-followup-to: "Maciej W. Rozycki" <>,Ralf Baechle DL5RB <>, Thiemo Seufer <>,,
Original-recipient: rfc822;
References: <> <> <20050707121235.GV1645@hattusa.textio> <> <20050707122226.GW1645@hattusa.textio> <> <> <87zmsx4do1.fsf@talisman.home> <>
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
"Maciej W. Rozycki" <> 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  <>
>       * 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.



<Prev in Thread] Current Thread [Next in Thread>