------- Comment #17 from ramana at gcc dot gnu dot org 2010-04-15 18:39 ------- Created an attachment (id=20389) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20389&action=view) Testcase for the problem.
Can this bug be reprioritized ? Deep inside _gfortrani_set_integer, there's an incorrect sibling call to memcpy where it shouldn't be doing so. 64: e28d1010 add r1, sp, #16 68: e3a02004 mov r2, #4 6c: e521c008 str ip, [r1, #-8]! 70: e28dd014 add sp, sp, #20 74: e49de004 pop {lr} ; (ldr lr, [sp], #4) 78: eafffffe b 0 <memcpy> 78: R_ARM_PLT32 memcpy There's no reason why this should be being marked as a valid tail call here. >From the tailcall dumps. set_integer (void * dest, GFC_INTEGER_8 value, int length) { GFC_INTEGER_1 tmp; GFC_INTEGER_2 tmp; GFC_INTEGER_4 tmp; GFC_INTEGER_8 tmp; GFC_INTEGER_1 tmp.30; GFC_INTEGER_2 tmp.29; GFC_INTEGER_4 tmp.28; size_t length.27; <bb 2>: switch (length_1(D)) <default: <L4>, case 1: <L3>, case 2: <L2>, case 4: <L1>, case 8: <L0>> <L0>: tmp = value_2(D); memcpy (dest_4(D), &tmp, 8); [tail call] goto <bb 8>; <L1>: tmp.28_5 = (GFC_INTEGER_4) value_2(D); tmp = tmp.28_5; memcpy (dest_4(D), &tmp, 4); [tail call] goto <bb 8>; <L2>: tmp.29_7 = (GFC_INTEGER_2) value_2(D); tmp = tmp.29_7; memcpy (dest_4(D), &tmp, 2); [tail call] goto <bb 8>; <L3>: tmp.30_9 = (GFC_INTEGER_1) value_2(D); tmp = tmp.30_9; memcpy (dest_4(D), &tmp, 1); [tail call] goto <bb 8>; <L4>: internal_error (0B, &"Bad integer kind"[0]); <bb 8>: return; } Attached is a testcase for this . Reproducible by building a cross-compiler to arm-eabi . ../trunk/configure --with-cpu=cortex-a8 --target=arm-none-eabi --enable-languages=c And command line options for the testcase are just -O2. You can reproduce this problem with r149170 and the fix up patch applied as well. cheers Ramana -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572