Kumba <kumba@xxxxxxxxxx> writes: > Kumba wrote: >> The attached patch adds a workaround to have gcc emit branch likely >> instructions (beqzl) in atomic operations for R10000 CPUs. This is >> because revisions of this CPU before 3.0 misbehave, while revisions 2.6 >> and earlier will deadlock. This issue has been noted on SGI IP28 >> (Indigo2 Impact R10000) systems and SGI IP27 Origin systems. >> >> After creating a patch to glibc based off of Debian Bug #462112 >> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462112), it was >> suggested by David Daney that a similar patch be created for GCC. >> >> Feedback would be welcome on any suggestions for improving this patch >> (please CC, as I'm not subscribed to the ML). >> >> Thanks! > > Oops, typo in my first patch. Stray parenthesis around the macro > check. Fixed patch is included. > > I'm wondering whether this should be limited to _MIPS_ARCH_R10000, > though. Maybe _MIPS_ARCH_MIPS4 instead, because the R10000 is at > minimum, a MIPS-IV CPU, and there might be cases where a userland > compiled with -march=mips4 could get used instead of one optimized for > -march=r10000? > > Or would MIPS-II be better, which is when the branch likely > instruction was added? As Maciej said, this should really be controlled by an -mfix-r10000 command-line option, not by the _MIPS_ARCH_* macro. (In this context, _MIPS_ARCH_* is a property of the compiler that you're using to build gcc itself.) There are two ways we could handle this: - Make -mfix-r10000 require -mbranch-likely. (It mustn't _imply_ -mbranch-likely. It should simply check that -mbranch-likely is already in effect.) - Make -mfix-r10000 insert nops when -mbranch-likely is not in effect. Richard
