"Bus error (core dumped)" failure when running "941014-2.c" test case

[GoogleCodeExporter]

When we execute the "gcc.c-torture/execute/941014-2.c" test case, it
crashes with the following error: "Bus error (core dumped)".

Original issue reported on code.google.com by nou...@gmail.com on 9 Dec 2008 at 2:39

[GoogleCodeExporter]

probably has to do with your code putting ugly addresses on the address bus when
accessing memory (odd address with 32 and 64 bit accesses seems the most likely
culprit). you're doing pointer arithmetic there, right? print every address you
compute before using it for memory access.

Original comment by jmoc...@gmail.com on 9 Dec 2008 at 3:17

[GoogleCodeExporter]

The test below is a simplified version of the "941014-2.c" test case. This test 
also
fails.

{{{

#include <stdlib.h>

typedef struct {
  unsigned short a;
  unsigned short b;
} foo_t;

volatile foo_t *
f ()
{
  volatile foo_t *foo_p = (volatile foo_t *)malloc (sizeof (foo_t));

  foo_p->b = 0x0100;

  return foo_p;
}

main ()
{
  volatile foo_t *foo_p;

  foo_p = f ();
  if (foo_p->b != 0x0100)
    abort ();
}

}}}

What is funny, is the fact that if we remove the "#include <stdlib.h>" include, 
both
tests work fine. 

With the simplified test above, the only instruction in the generated assembly 
code
that changes (besides the debug info) is the the "stl $s35,-276(,$s2)" 
instruction in
the "f" function (see the diff file attached. It was produced with the following
command "diff fails.s works.s").

Basically, when we compile the test with the "#include <stdlib.h>" sx-gcc 
generates
the following assembly code for the "malloc" call:

    or  $s35,8,(0)1
    stl $s35,-276(,$s2) <--------------?????
    lds $s35,.LC0   #movdi case3
    lea $s36,1
    sts $s36,-288(,$s2)
    lea $s34,-288(,$s2)
    or  $s33,0,$s35
    bsic    $s32,($s33)

I believe the "stl $s35,-276(,$s2)" instruction is faulty, since it only stores 
32
bits for the size of the allocated memory. By executing the program in the DBX
debugger, I noticed that the SX's "malloc" function expects this operand to be
64-bit. As a consequence, the memory size received is incorrect (too big) and 
the
malloc returns a "NULL" pointer. The "Bus error (core dumped)" is triggered 
because
we are trying to dereference this NULL pointer.

Original comment by nou...@gmail.com on 9 Dec 2008 at 4:47

Attachments:

• fails-works.diff

[GoogleCodeExporter]

trace the includes (probably a few levels deep;)) to the declaration of 
malloc() that
is used when you build. you will probably find out it takes a size_t parameter.

then, trace what size_t is typedefed to. you will probably find that this is an
unsigned 32-bit type. which is wrong. our target system (that is: the c runtime 
libs
we link against) expects 64-bit size_t.

probably, we just need to #define something to tell SX headers to use 64-bit 
size_t. 

CC-ing holger on this, perhaps he can provide us with an appropriate build-time
#define out of his sleeve? ;)

Original comment by jmoc...@gmail.com on 9 Dec 2008 at 5:13

• Added labels: gcc, sx-headers, sx-libc

[GoogleCodeExporter]

try building with -D_SIZE_T64=1

Original comment by jmoc...@gmail.com on 9 Dec 2008 at 6:04

[GoogleCodeExporter]

Yes, the -D_SIZE_T64=1 define indeed solves the issue.

Original comment by nou...@gmail.com on 10 Dec 2008 at 9:25

[GoogleCodeExporter]

Original comment by jmoc...@gmail.com on 10 Dec 2008 at 9:29

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Adding the "builtin_define ("_SIZE_T64");" to the "sx.h" header solves the 
problem.

Original comment by nou...@gmail.com on 10 Dec 2008 at 10:05

[GoogleCodeExporter]

Original comment by nou...@gmail.com on 10 Dec 2008 at 10:06

• Changed state: Fixed

[GoogleCodeExporter]

Oh yes, the r160 fixes this.

Original comment by nou...@gmail.com on 10 Dec 2008 at 10:12