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 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:
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
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 a ton of
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
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 tries
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 type (which
(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 expansion
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
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,
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,
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.
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
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
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.
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:
integer_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 be
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
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.
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:
integer_type 0xb7f52c30 public unsigned SI
size integer_cst 0xb7ee7540 type integer_type
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
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
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 =
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 r1,r3,a0
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
