> 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
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
> 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
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
> 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
> 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?
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
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