summaryrefslogtreecommitdiff
path: root/sources/gcc/3.4.1/400-mips-delay-slot.patch
diff options
context:
space:
mode:
authorManuel Novoa III <mjn3@codepoet.org>2004-09-03 00:49:43 +0000
committerManuel Novoa III <mjn3@codepoet.org>2004-09-03 00:49:43 +0000
commit3ad3d8a1d8c25bab9937e2d9e08ccdbb0b042543 (patch)
tree56c0b25562b460f75a4191b826be6690a8015db9 /sources/gcc/3.4.1/400-mips-delay-slot.patch
parente694138b173d963ab0348f652e3882db97e2d296 (diff)
Update to what I'm currently using. Lots of changes...
1) Allow selection of binutils/gcc/gdb/kernel headers to build, although some of the older tool patches probably need updating. 2) Rework gdb build so that remote debugging now works with gdbserver. 3) Misc. other package updates.3) Misc. other package updates.3) Misc. other package updates.
Diffstat (limited to 'sources/gcc/3.4.1/400-mips-delay-slot.patch')
-rw-r--r--sources/gcc/3.4.1/400-mips-delay-slot.patch46
1 files changed, 46 insertions, 0 deletions
diff --git a/sources/gcc/3.4.1/400-mips-delay-slot.patch b/sources/gcc/3.4.1/400-mips-delay-slot.patch
new file mode 100644
index 000000000..8111dba18
--- /dev/null
+++ b/sources/gcc/3.4.1/400-mips-delay-slot.patch
@@ -0,0 +1,46 @@
+http://www.linux-mips.org/archives/linux-mips/2004-09/msg00000.html
+
+Atsushi Nemoto <anemo@mba.ocn.ne.jp> writes:
+>/ Is this a get_user's problem or gcc's?/
+
+The latter. gcc is putting the empty asm:
+
+ __asm__ ("":"=r" (__gu_val));
+
+into the delay slot of the call.
+
+Part of the problem is that gcc estimates the length of an asm to be the
+number of instruction separators + 1. This means that it estimates the
+asm above to be one instruction long, which is perhaps a little silly
+for an empty string.
+
+But the real problem is that gcc should never trust this estimate anyway,
+since each "instruction" could obviously be a multi-instruction macro.
+gcc should certainly never put asms into delay slots.
+
+FWIW, I don't think the bug is specific to 3.3 or 3.4. It could
+probably trigger for other gcc versions too. It is highly dependent
+on scheduling though.
+
+The attached 3.4.x patch fixes the problem there, but if you want to work
+around it for old versions, just avoid using empty asms if you can,
+or make them volatile if you can't.
+
+Of course, the problem isn't confined to empty asms. If you have an asm
+with a single, multi-instruction macro, gcc might try putting that in a
+delay slot too. You should at least get an assembler warning in that case.
+
+Richard
+
+
+--- gcc-3.4.1/gcc/config/mips/mips.md-orig 2004-09-02 10:38:36.000000000 -0500
++++ gcc-3.4.1/gcc/config/mips/mips.md 2004-09-02 10:38:42.000000000 -0500
+@@ -251,7 +251,7 @@
+
+ ;; Can the instruction be put into a delay slot?
+ (define_attr "can_delay" "no,yes"
+- (if_then_else (and (eq_attr "type" "!branch,call,jump")
++ (if_then_else (and (eq_attr "type" "!branch,call,jump,multi")
+ (and (eq_attr "hazard" "none")
+ (eq_attr "single_insn" "yes")))
+ (const_string "yes")