[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

["ramana at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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