Problem with std_expand_builtin_va_start on targets where sizetype and ptr_type_node don't have the same mode

Zack Weinberg zackw@panix.com
Fri Jul 6 02:49:00 GMT 2007


On 05 Jul 2007 18:22:50 -0700, Ian Lance Taylor <iant@google.com> wrote:
> I think you would want something more like
>     rtx va_r = expand_expr (valist, NULL_RTX, VOIDmode, EXPAND_WRITE);
>     convert_move (va_r, nextarg, 0);
> but other than that I don't see why this would fail.  I think you
> should give it a try.

On m32c-elf, this gets me much farther; now it blows up compiling
libstdc++'s bitmap_allocator.cc, because for some reason reload wants
a MODE_PARTIAL_INT mode with 64 bits.  There is no such mode, so
get_smallest_mode_for_size aborts.  I am attaching the .lreg and .greg
dumps to this message (compressed).

> Of course you would need to test it on a
> backend which does not #define EXPAND_BUILTIN_VA_START; I think ARM is
> the only primary platform for which that is true.

Will try arm-elf simulator run overnight.  (I *think* there's an arm
simulator...?)

zw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitmap_allocator.cc.171r.lreg.gz
Type: application/x-gzip
Size: 96669 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20070706/7580b4ab/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitmap_allocator.cc.172r.greg.gz
Type: application/x-gzip
Size: 63540 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20070706/7580b4ab/attachment-0001.bin>


More information about the Gcc mailing list