@@ -1,3 +1,9 @@
+2015-02-05 Jeff Law <law@redhat.com>
+
+ PR target/43264
+ * config/h8300/h8300.c (get_shift_alg): Fix ASHIFTRT by
+ 24 to 28 bits for the H8/300.
+
2015-02-06 Alan Modra <amodra@gmail.com>
PR target/64876
@@ -4384,7 +4384,7 @@ get_shift_alg (enum shift_type shift_type, enum shift_mode shift_mode,
info->cc_inline = CC_SET_ZNV;
goto end;
case SHIFT_ASHIFTRT:
- info->special = "mov.b\t%z0,%w0\n\tbld\t#7,%w0\n\tsubx\t%x0,%x0\n\tsubx\t%x0,%x0\n\tsubx\t%x0,%x0";
+ info->special = "mov.b\t%z0,%w0\n\tbld\t#7,%w0\n\tsubx\t%x0,%x0\n\tsubx\t%y0,%y0\n\tsubx\t%z0,%z0";
info->shift1 = "shar.b\t%w0";
info->cc_inline = CC_SET_ZNV;
goto end;
This is actually a long standing regression (though it's not marked that way in the BZ database). Basically there was a change from encoding the funcvec and eighbit_data attributes in the symbol name to instead putting them in the function decl's flags. This was, IMHO, a good thing. Unfortunately the transition wasn't totally completed and with no tests in the suite, the author of the transition wasn't aware of the deficiencies. The PR complains about funcvec not working. But upon inspection I found a place where eightbit_data wasn't working and in building the tests I found a place where we should be accepting eightbit_data operands but weren't. Tested by building gcc, libgcc & newlib and running the testsuite for h8300-elf with no regressions. Installed on the trunk. jeff commit 6e5dc637c92a02eb1c0186125fa84c7c39bd8292 Author: Jeff Law <law@redhat.com> Date: Thu Feb 5 22:29:12 2015 -0700 PR target/43264 * config/h8300/h8300.c (get_shift_alg): Fix ASHIFTRT by 24 to 28 bits for the H8/300.