Re: M32C vs PR tree-optimization/39233

2009-04-16 Thread DJ Delorie
> I'm not sure if this is the same problem, but didn't I suggest in > the past to fix this up during expansion? That is, if we end up > with a POINTER_PLUS_EXPR with different mode size pointer and offset > promote (or demote) the offset argument to pointer size properly? > > What happened to th

Re: M32C vs PR tree-optimization/39233

2009-04-16 Thread Richard Guenther
On Wed, 15 Apr 2009, DJ Delorie wrote: > > As of this fix (yes, I know it was some time ago - I've been busy), > the m32c-elf build fails building the target libiberty: > > ./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \ > -auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-string

Re: M32C vs PR tree-optimization/39233

2009-04-16 Thread Paolo Bonzini
> Note that the issue is with our representation of POINTER_PLUS_EXPR > which insists on using sizetype for the pointer offset argument > (where I don't remember if m32c uses a bigger or smaller mode for > sizetype than for pointers). Whenever the sizes of the modes for > pointers and sizetype do

Re: M32C vs PR tree-optimization/39233

2009-04-16 Thread Richard Guenther
On Wed, 15 Apr 2009, DJ Delorie wrote: > > yes; however, maybe it would be easier to wait till Richard finishes the > > work on not representing the overflow semantics in types (assuming that's > > going to happen say in a few weeks?), which should make the fix > > unnecessary, > > Another though

Re: M32C vs PR tree-optimization/39233

2009-04-15 Thread DJ Delorie
> yes; however, maybe it would be easier to wait till Richard finishes the > work on not representing the overflow semantics in types (assuming that's > going to happen say in a few weeks?), which should make the fix > unnecessary, Another thought - is this bug in the 4.4 branch? If so, a 4.4 fi

Re: M32C vs PR tree-optimization/39233

2009-04-15 Thread DJ Delorie
> yes; however, maybe it would be easier to wait till Richard finishes the > work on not representing the overflow semantics in types (assuming that's > going to happen say in a few weeks?), which should make the fix > unnecessary, Ah, ok. Can I ask for m32c to be on the test list for this work?

Re: M32C vs PR tree-optimization/39233

2009-04-15 Thread Zdenek Dvorak
Hi, > Can we somehow make this fix contingent on ports that have suitable > integral modes? yes; however, maybe it would be easier to wait till Richard finishes the work on not representing the overflow semantics in types (assuming that's going to happen say in a few weeks?), which should make th

M32C vs PR tree-optimization/39233

2009-04-15 Thread DJ Delorie
As of this fix (yes, I know it was some time ago - I've been busy), the m32c-elf build fails building the target libiberty: ./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \ -auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-strings -Wc++-compat \ -Wstrict-prototypes -pedantic -vers