[Top] [All Lists]

Re: [PATCH]: R10000 Needs LL/SC Workaround in Gcc

To: Richard Sandiford <>
Subject: Re: [PATCH]: R10000 Needs LL/SC Workaround in Gcc
From: "Maciej W. Rozycki" <>
Date: Tue, 11 Nov 2008 23:40:19 +0000 (GMT)
Cc: Kumba <>,, Linux MIPS List <>
In-reply-to: <87y6zphn5b.fsf@firetop.home>
Original-recipient: rfc822;
References: <> <> <87abcjibsl.fsf@firetop.home> <> <87tzargrn4.fsf@firetop.home> <> <87prleh2hc.fsf@firetop.home> <> <87myggilk2.fsf@firetop.home> <> <8763mypnhf.fsf@firetop.home> <> <87y6zphn5b.fsf@firetop.home>
User-agent: Alpine 1.10 (LFD 962 2008-03-14)
On Tue, 11 Nov 2008, Richard Sandiford wrote:

> (Which I suppose raises the question: should
>   -march=r10000 -mno-branch-likely
> be an error, or should it silently disable -mfix-r10000?  My vote is
> for "error".  You can always write -march=r10000 -mno-branch-likely
> -mno-fix-r10000 is that's really what you mean.
> The suggested change -- swapping these two blocks around -- should do that.)

 FWIW, my preference is for an error too.  The main reason being to warn 
the user about the incompatibility of these options.

 For the opposite case a scenario where in a building system they come 
from different places each can be imagined.  Or one could be buried 
somewhere down the Makefiles in a platform-specific section of an odd 
package.  In the end the user might not be fully aware they are doing 
something wrong and the result would be broken packages would fail 
randomly on the affected processors at the run time.

 Always prefer a build error to a run-time error if possible.


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