This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: MIPS: Workaround the "daddi" and "daddiu" errata
On Tue, 15 Jun 2004, Richard Sandiford wrote:
> Oh well. I think one thing we do agree on is that there's no point
> having a half fix. If you're going to treat FSF gcc as "crippled",
> and instead maintain your original patch as the preferred or official
> version[*], then there's probably not much point applying the new patch.
Well, this "crippled" patch works around the case we are sure it will
bite. Without the change the toolchain is essentially useless for the
affected hardware (in the 64-bit mode, that is -- I've already been hit by
the erratum with my detection code at Linux startup: an older version
used a value in the affected range as an argument to an asm constraint and
as a result the code used to fail to detect the presence of the erratum
when the workaround wasn't activated). This minimal change does a
reasonable job and it may even suffice to an ordinary user (i.e. not a
system developer), so I think it may still be good to have it in as an aid
to users. Otherwise I wouldn't have bothered creating it. But I think we
need to be fair and document the shortcomings then.
The rest are corner cases, no doubt, but they are important for me, as I
appreciate even faulty code giving corresponding results. It's a major
PITA to have to account for processor errata when chasing bugs, so I need
to maintain these patches at least as long as I am going to use my R4k
systems (in their 64-bit mode, of course -- I offload purely 32-bit stuff
to my R3k system).
Note that the corresponding gas change, which I consider needed for
inline asms and ordinary assembly, will require an update to this GCC
patch as gas will attempt to "fix" "daddiu" instructions GCC considers
"safe" -- for that I plan to use the ".set daddi" and ".set nodaddi"
directives I've already implemented. The idea is to keep ".set daddi"
active throughout all generated code and activate ".set nodaddi" for
inline assembly bits. Before I start coding, does it sound reasonable?
> I certainly can't hope to maintain it myself since I don't have any
> affected h/w.
Somehow I doubt you actually have access to all the MIPS hardware
variations GCC supports, anyway. ;-) But I understand your lack of
incentive to look after code that involves more than about a single line
that you can drop in and forget and moreover which is only to handle some
old and broken hardware that you don't even have.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +