On Fri, Nov 14, 2008 at 10:23 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> > Now I'm getting a ton of errors (like, around 5000) that look like this:
>>
>> Just remove that assert for testing.
>
> Looks good without the assert, 21 new passes and only 1 new failure:
>
> PASS-FAIL: gcc.c-torture/ex
> > Now I'm getting a ton of errors (like, around 5000) that look like this:
>
> Just remove that assert for testing.
Looks good without the assert, 21 new passes and only 1 new failure:
PASS-FAIL: gcc.c-torture/execute/loop-ivopts-1.c execution, -O3
-fomit-frame-pointer -funroll-loops
On Thu, Nov 13, 2008 at 5:25 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> I don't think this is a suitable general solution. Can you instead try the
>> attached which again tries to simply make sure we sign-extend a sizetype
>> offset if that is smaller than the pointer mode.
>
> Now I'm getting
> I don't think this is a suitable general solution. Can you instead try the
> attached which again tries to simply make sure we sign-extend a sizetype
> offset if that is smaller than the pointer mode.
Now I'm getting a ton of errors (like, around 5000) that look like this:
[ gdb ] up
#1 0x08
On Wed, Nov 12, 2008 at 10:40 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Ping? Is this the right thing to do? I'd like to get this (and a few
> other m32c bugs) resolved before the next release.
I don't think this is a suitable general solution. Can you instead try the
attached which again t
Ping? Is this the right thing to do? I'd like to get this (and a few
other m32c bugs) resolved before the next release.
> This seems to work, with a suitable extendhipsi2 pattern for m32c:
>
> Index: expr.c
> ===
> --- expr.c(
