On Thu, Mar 3, 2011 at 5:27 AM, Mark Mentovai <m...@moxienet.com> wrote: > Felix Fietkau wrote: >> Actually, it emits -16384 in both the working and non-working case, >> I think what makes the difference of working vs non-working is this: >> >> Broken: (0xffffc000 is in v0) >> - e8: 00021a02 srl v1,v0,0x8 >> - ec: 00021200 sll v0,v0,0x8 >> >> Working: (0xffffc000 is in v1) >> + e8: 7c623a00 ext v0,v1,0x8,0x8 >> + ec: 00031a00 sll v1,v1,0x8 >> >> using ext instead of srl prevents the extra bits from spilling over. > > Sure. I was looking at the assembly emitted by the other compilers I tested. > None of those even ever use -16384 (0xffffc000). They all simply OR in 0xc000 > (as an immediate value). > > I’m in touch with Linaro about this bug, so maybe we’ll get some traction > without having to commit my workaround patch.
Yip, Richard is having a look into this. Officially we don't support MIPS, but compiler bugs are so rare it's worth looking into each one. -- Michael _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
