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(
This seems to work, with a suitable extendhipsi2 pattern for m32c:
Index: expr.c
===
--- expr.c (revision 140759)
+++ expr.c (working copy)
@@ -8455,12 +8459,34 @@ expand_expr_real_1 (tree exp, rtx target
if (
> Ok, I just looked for POINTER_PLUS_EXPR and tried to make sure its
> offset is always sign-extended. Can you check where on the call
> path above we miss this special treatment?
It looks like it drops past them all and gets the generic treatment,
just before the MINUS_EXPR case.
On Thu, Oct 2, 2008 at 8:50 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Ok, here's where it's getting expanded:
>
> #12 0x081e2805 in convert_modes (mode=PSImode, oldmode=HImode, x=0xb7f63450,
> unsignedp=1)
>at ../../gcc/gcc/expr.c:859
> #13 0x0831f83a in expand_binop_directly (mode=945, bi
Ok, here's where it's getting expanded:
#12 0x081e2805 in convert_modes (mode=PSImode, oldmode=HImode, x=0xb7f63450,
unsignedp=1)
at ../../gcc/gcc/expr.c:859
#13 0x0831f83a in expand_binop_directly (mode=945, binoptab=0x8824de0,
op0=0xb7f63410,
op1=0xb7f63450, target=0xb7f63440, unsign
This is what I get with your patch and not mine:
neg.w r0 ; 7neghi2/1
mov.w r0,a0; 9
zero_extendhipsi2
add.l a0,r3r1 ; 15
add
> (what is the current sizetype mode?)
HImode
> There are no bitfield instructions. What I suggest is that you make
> sizetype 16bits (HImode), as if I remember correctly you are not
> concerned anyway about pointer offsets larger than what fits into
> signed 16bits. If you then use the expans
On Thu, Oct 2, 2008 at 12:43 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> I think this is the wrong place to fix this. If you would override
>> the sizetypes precision from your target, would that fix it? That
>> is, in stor-layout.c set_sizetype make the target allow adjusting
>> the passed ty
> Can you look in the CVS/SVN archives and see what the mn102 port did --
It used SImode for size_type but I think I tried that and it blew up
in useless_type_conversion_p. I can try again if you're interested in
the details.
DJ Delorie wrote:
I think this is the wrong place to fix this. If you would override
the sizetypes precision from your target, would that fix it? That
is, in stor-layout.c set_sizetype make the target allow adjusting
the passed type (which is supposed to be sizetype). If at all then
these type
> I think this is the wrong place to fix this. If you would override
> the sizetypes precision from your target, would that fix it? That
> is, in stor-layout.c set_sizetype make the target allow adjusting
> the passed type (which is supposed to be sizetype). If at all then
> these types should
On Wed, Oct 1, 2008 at 12:20 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> I've got a partial patch which works with older (4.3) gccs, but fails
> gimple's check for trunk (attached). My trivial test case...
>
> char *
> foo (char *a, int b)
> {
> return a-b;
> }
>
> ...fails thusly:
>
> siz
> Is this related to the loop termination bug I reported
> on the m32c?
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37665
Probably related, but I don't know if a patch to fix one will fix the
other.
Is this related to the loop termination bug I reported
on the m32c?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37665
The generated code is using the lower 16-bits of the
address for end of the array rather than the full 24-bit
address.
--joel
DJ Delorie wrote:
I've got a partial patch whi
I've got a partial patch which works with older (4.3) gccs, but fails
gimple's check for trunk (attached). My trivial test case...
char *
foo (char *a, int b)
{
return a-b;
}
...fails thusly:
constant 32>
unit size constant 4>
align 8 symtab 0 alias set -1 canonical type 0xb7f52c
> NEGATE_EXPR on an unsigned type is fully defined. It's what you
> should get when you say "unsigned int i, j; ...; i = - j;".
I didn't say it was undefined, I said it seemed wrong. Esp since the
example starts with a plain "int" value.
> I think the problem you are facing may be that POINTER
DJ Delorie <[EMAIL PROTECTED]> writes:
>> Does the following fix it?
>
> Nope, sorry. I was looking at this code in c-common.c, where the expr
> is first created, but I don't know what that ends up calling:
>
> /* Create the sum or difference. */
> if (resultcode == MINUS_EXPR)
> intop =
> Does the following fix it?
Nope, sorry. I was looking at this code in c-common.c, where the expr
is first created, but I don't know what that ends up calling:
/* Create the sum or difference. */
if (resultcode == MINUS_EXPR)
intop = fold_build1 (NEGATE_EXPR, sizetype, intop);
ret
On Sat, Sep 20, 2008 at 1:52 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> m32c-elf-gcc -mcpu=m32c (16 bit ints, 24 bit pointers) miscompiles
> this:
>
> int *foo (int *a, int b)
> {
> return a-b;
> }
>
> as this:
>
> _foo:
>enter #0 ; 30prologue_enter_24
>pushm
m32c-elf-gcc -mcpu=m32c (16 bit ints, 24 bit pointers) miscompiles
this:
int *foo (int *a, int b)
{
return a-b;
}
as this:
_foo:
enter #0 ; 30prologue_enter_24
pushm r1,r3,a0; 31pushm
; end of prologue ; 32prologue_end
25 matches
Mail list logo
