jkmcnk / sx-gcc Goto Github PK

building testcase gcc.c-torture/execute/builtins/pr22237.c with

gcc -o pr22237 pr22237.c pr22237-lib.c lib/main.c -Os

corrupts code: code doe not behave as expected, execution abort()s

Yet another missing symbol.

We don't have full 64bit division implemented. There is currently an insn
defined for "divdi3" in sx.md, but it is actually a 56 bit division
floating point mantissa width). Not sure, though, why __divdi3 from the
libgcc2 is expected? One option is to remove the "divdi3" insn definition,
that might force libgcc2 to build the __divdi3 itself. Another option is to
expand the divdi3 insn and make it truly 64 bit. In that case we need to
find out how to get rid of the need for __divdi3.

To run one of the testcases with this bug:

env RUNTESTFLAGS="--target_board=v00 execute.exp=20000402-1.c" make check

Regards,
Erich

This is again one failure which I see on ia64, but not on x86_64, with svn
r126 of sx-binutils:

Please use labels and text to provide additional information.
{{{
hwwnec11@a1:~/sx-gcc/TEST> ~/sx-gcc/INST/sx8-nec-superux/bin/gcc -O0 -w
../sx-gcc/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c -c
-save-temps
memcpy-chk.s: Assembler messages:
memcpy-chk.s:6069: Error: attempt to .org/.space backwards? (-96)
memcpy-chk.s:6085: Internal error!
Assertion failure in size_seg at ../../sx-binutils/gas/write.c line 569.
Please report this bug.
}}}

Assembler source is included:

Test case dg.exp=pr19402-2.c fails with a crash when compiling.

Shortend testcase :
void abort(void);

long double powil(long double x, int n)
{
  return __builtin_powil(x, n);
}

int main()
{
  if (powil(1.0, -5) != 1.0)
    abort();
  return 0;
}

Where __builtin_powil(x, n); is the problem.
I suspect the problem is calling __builtin_powil with long double. 


The failure is :
*** glibc detected ***
/home/fred/dev/projects/sx/sx/libexec/gcc/sx8-nec-superux/4.2.2/cc1:
free(): invalid next size (fast): 0x0000000000d94a40 ***

SX COFF archive (static lib) format differs significantly from the standard
COFF.

most notable differences are:
- no extended filenames,
- 64 chars max for filenames,
- 64-bit offsets in the index (map) archive entry.

need to fix this in libbfd.

testcase gcc.c-torture/execute/builtins/pr22237

when built with

gcc -o pr22237 pr22237.c pr22237-lib.c lib/main.c -O3 -funroll-loops

segfaults

The source code below is an extract from the
"gcc.c-torture/execute/conversion.c" which currently fails with sx-gcc:

{{{

float
s2f(s)
     int s;
{
  return s;
}

int
fnear (float x, float y)
{
  float t = x - y;

  return t == 0 || x / t > 1000000.0;
}

main()
{
  if (!fnear (s2f(0x7fffffff), (float)(int)0x7fffffff)) 
    abort();


  exit(0);
}

}}}

The main cause for the test failure is the usage of the "flt@" SX
instruction in the "s2f" function.
According to the "3.4 Format Conversion" section of the SX-8 "SX-8 CPU
Functional Description Manual", the "flt@" function doesn't work on
integers that are outside the [-2^24, +2^23] interval.

If we wish the "gcc.c-torture/execute/conversion.c" test to succeede, we
will probably have to replace the "flt@" command with an assembler routine.

Whenever movdi (case 2b) is appearing in the RTL dump, the results will be
bogus. An example is attached. The problem is the general immediate case
for long long type variables.

sxcc is solving this by storing the constant into the local pool and just
loading it. This is slower than putting it together from two or three
instructions which are anyway in the I-cache. The current approach in the
sx.md file is wrong, anyway (lea won't load an immediate).

Follow-on bug to #34.

After having fixed the missing cache-flush, added correct trampoline code
and fixed the computation of $s4 in case of trampoline jumps, following
cases still fail:

execute.exp=nestfunc-5.c fails
execute.exp=nestfunc-6.c fails
dg.exp=trampoline-1.c    fails

At least the first two ones can be attributed to the fact that the static
chain is restoring $s1, $s2 but not $s4 in case of a nonlocal goto (which
is something I wouldn't ever dare to use when coding in C).

Will close #34 and instead follow the fixing in this new bug.

Erich

must implement support for aliasing and weak symbols.

the following test cases from gcc.c-torture testsuite are involved:
- 981001-2.c
- 20011119-1.c
- 20040323-1.c

Testcase execute.exp=20000402-1.c
calls umoddi3 recursively and that is why it is hanging on the SX.

But, umoddi3 as it is defined in libgcc2 is not recursive!

#ifdef L_umoddi3
UDWtype
__umoddi3 (UDWtype u, UDWtype v)
{
  UDWtype w;

  (void) __udivmoddi4 (u, v, &w);

  return w;
}
#endif

dbx output (stack where) from executable 20000402-1.x0.13424
1000 __umoddi3(0x0, 0x8000) at 0x400003098
1001 __umoddi3(0x0, 0x8000) at 0x400003098
1002 __umoddi3(0x0, 0x8000) at 0x400003098
1003 __umoddi3(0x0, 0x8000) at 0x400003098
1004 __umoddi3(0x0, 0x8000) at 0x400003098
1005 __umoddi3(0x0, 0x8000) at 0x400003098

cpp says that __USER_LABEL_PREFIX__ is #defined to an empty string.

however testcase gcc.c-torture/compile/20011119-1.c seems to insert an
asterisk (*) in its place, resulting in a corrupt assembly source.

strange ...

build with -g, which in turn links against libg.a. chaos ensues when trying
to run the executable (illegal instruction trap, core dump).

the reason is the following:

jaka@wall:~/dev/sx/test/gcc/simple$ nm simple.dbg | grep main
0000000000000240 ? .CD.main
0000000400000b18 T _main
0000000000000258 ? main

i.e. the address of main is bizarre, and type of the main symbol is
strange. wtf does the linker do here?

obvious ... ;)

attempting to build sx8-nec-superux cross gcc on ia32 with optimization (!=
-O0), results in buggy cross compiler (fp_I_operand() called from
print_operand() corrupts stack)

right now, line no. entries are parsed and internally stored correctly.
however:

1. nm does not print symbol line numbers correctly,
2. objdump does not print line number info.

probably a problem with coff_find_[nearest_]line().

For example in function prologues we don't see "ldl=", instead we see only
"ldl".

Looking at the failures of gcc "make check" shows one simple class...

20010510-1.s: Assembler messages:
20010510-1.s:1: Warning: Unimplemented pseudo-op used.

In the attached file is an example.

What steps will reproduce the problem?
1. strip-new <path-to-the-object-file-to-strip>
2. examine the stripped object file with HEX editor. You will see that the
bytes 8-11 are all null.


I looks like the "coff_write_object_contents" contains the
"internal_f.f_timdat = 0;" line (somewhere around line 3767) which always
sets timestamp to 0. Between that and the actual printout to the file,
there is no function that would set the timestamp.

We should probably check with the "binutils" people what is the reason for
this...

gcc fails to compile the following test (assembler attached):


{{{
int foo (int a)
{
  static const short ar[] = { &&l1 - &&l1, &&l2 - &&l1 };
  void *p = &&l1 + ar[a];
  goto *p;
 l1:
  return 1;
 l2:
  return 2;
}
}}}

The assembler returns the error message
labels-3.s:5: Error: Unknown constant size (only 4 or 8 bytes allowed).

which is originating in the line:
        short   .L1-(.L2)

I'll try to find out whether and why gcc makes a "short" difference result
for the label, anyway sxas is compiling the code without complaint. So it
would be interesting to know whether gas has some limitation on the
constant values which is specific to the SX port, or whether this is just
builtin into gas.

Regards,
Erich

when cross-compiling for sx8-nec-superux, using optimizations (!= -O0)
cause gcc to crash.

The current implementation of BFD doesn't recognize .ELNI sections in COFF
SX files. Whenever we perform "objectcopy" command the "s_flags" field of
.ELNI section header turns from "0x2000" (i.e. the STYP_ELNI flag) to
"0x0020" (i.e. the STYP_TEXT flag).

FAIL: gcc.dg/pch/system-1.c  -O0  (test for excess errors)
Excess errors:
/home/fred/tmp/sx/src/sx-gcc/gcc/testsuite/gcc.dg/pch/system-1.c:1: error:
system-1.h: No such file or directory
/home/fred/tmp/sx/src/sx-gcc/gcc/testsuite/gcc.dg/pch/system-1.c:1: error:
one or more PCH files were found, but they were invalid
/home/fred/tmp/sx/src/sx-gcc/gcc/testsuite/gcc.dg/pch/system-1.c:1: error:
use -Winvalid-pch for more information
/home/fred/tmp/sx/src/sx-gcc/gcc/testsuite/gcc.dg/pch/system-1.c:5:
warning: incompatible implicit declaration of built-in function 'exit'

Running automated tests for GCC (make check), sxld fails to link for
example the testcase memcpy-chk.c (group: builtins) with the strange message

{{{
sxld: GROUP containing section .data is too big
sxld: can't allocate output section *group*, of size 8b14b2800000000
sxld: can't allocate output section *0group*, of size f74eb4d800005630
sxld fatal: internal error: audit_groups, findsanode failure
collect2: ld returned 13 exit status
}}}

I wonder whether this is due to some strange code generated by gcc or gas?

building with -O0 produces corrupt code (segfault). building with -Ox, x !=
0 produces running code.

this affects the following testcases from gcc.c-torture/execute/builtins/:

strlen-2.c
20000205-1.c

When compiling the code below:

{{

int i0[0];

int main (void)
{
  i0[0] = 1;
  return 0;
}

}}

we get a linker error:

  /tmp/cc4mojUS.o:fake:(.text+0x8): undefined reference to `i0'
  collect2: ld returned 1 exit status

If we set the length of the "i0" array to 1 (i.e. "int i0[1]"), the code
compiles fine.

Looks like the sx-gcc is unable to handle the arrays of size 0, although
this seems to be a regular C construct (the x86 gcc compiler compiles the
code above without any warnings).

I only encounter this on the Asama (ia64), some compielr tests fail with
the message:

{{{
/tmp/ccpmsiau.s: Assembler messages:
/tmp/ccpmsiau.s:67: Internal error!
Assertion failure in size_seg at ../../sx-binutils/gas/write.c line 569.
Please report this bug.
}}}

The assembler source producing this is attached. It does not seem to happen
on x86_64!

Regards,
Erich

SX does not really used fully ieee compliant quad floats.

implement support for SX-style quad floats (requries patching generic
fp-bit.c and real.[ch], see mips port for an example).

Several missing symbols with regard to timode

FAIL: gcc.dg/torture/fp-int-convert-timode.c  -O0  (test for excess errors)
Excess errors:
/tmp/ccwItxTo.o:fake:(.text+0x18): undefined reference to `__floattisf'
/tmp/ccwItxTo.o:fake:(.text+0x28): undefined reference to `__fixsfti'
/tmp/ccwItxTo.o:fake:(.text+0x3b8): undefined reference to `__floatuntisf'
/tmp/ccwItxTo.o:fake:(.text+0x3c8): undefined reference to `__fixunssfti'
/tmp/ccwItxTo.o:fake:(.text+0x5b8): undefined reference to `__floattidf'
/tmp/ccwItxTo.o:fake:(.text+0x5c8): undefined reference to `__fixdfti'
/tmp/ccwItxTo.o:fake:(.text+0x928): undefined reference to `__floatuntidf'
/tmp/ccwItxTo.o:fake:(.text+0x938): undefined reference to `__fixunsdfti'
/tmp/ccwItxTo.o:fake:(.text+0xb28): undefined reference to `__floattitf'
/tmp/ccwItxTo.o:fake:(.text+0xb38): undefined reference to `__fixtfti'
/tmp/ccwItxTo.o:fake:(.text+0xf28): undefined reference to `__floatuntitf'
/tmp/ccwItxTo.o:fake:(.text+0xf38): undefined reference to `__fixunstfti'

debug building doesn't work due to misinterpretation of -g:

jaka@wall:~/dev/sx/test/gcc/simple$ gcc -g -o simple.dbg simple.c 
/home/jaka/dev/sx/inst/lib/gcc/sx8-nec-superux/4.2.2/../../../../sx8-nec-superux
/bin/ld:
cannot find -lg
collect2: ld returned 1 exit status

1. Build binutils for sx, superux
2. Get a binary for SX
3. objdump -t binary

The symbols from the COFF-SX file have all the value 000000.

Under SuperUX the utility "dump" shows that this is wrong.

Before they get out of sight: memcpy-chk, memmove-chk, memcpy-2 and other
similar tests fail badly. There are three types of failures:

 * abort : check code, possibly goes wrong path
 * illegal instruction: jumping to wrong location?
 * memory fault

The failures vary with the compiler options.

The three classes of bugs need to be checked in dbx to see what happens,
and possibly separate bugs need to be opened.

Erich

This is not a bug, rather an observation.

I noticed that sx-gcc translates floating point types (float, double) into
a series of "long" pseudo-instructions instead of "float", "double"
pseudo-instructions.

To be a little more concrete, in the example below:

{{{
int
main (void)
{
  double f1 = 1.999;
  double f2 = 2.999;
  printf("f1 = %f\n", f1);
  printf("f2 = %f\n", f2);
  return 0;
}
}}}

the "f1" variable is translated into: 
  long 1073740775
  long 1821066134
instead of:
  double 1.999.

Similarly, the "f2" variable is translated into:
  long 1074265587
  long -1236950581
instead of:
  double 2.999.

Of course, all the programs work fine even with the series of longs in
place of float/double, so this is mostly an aesthetical "issue".

__ucmpti2 - documented in ./doc/gccint.info
gcc.c-torture/execute/20020413-1.c
gcc.c-torture/execute/20030914-1.c
gcc.c-torture/execute/930622-2.c
gcc.c-torture/execute/960215-1.c
gcc.c-torture/execute/960513-1.c
gcc.c-torture/execute/conversion.c
gcc.c-torture/execute/regstack-1.c
gcc.c-torture/execute/stdarg-2.c
gcc.c-torture/execute/ieee/20010226-1.c
gcc.c-torture/execute/ieee/inf-1.c

i0
gcc.c-torture/execute/20030811-1.c

_Qp_dtoq
gcc.c-torture/execute/ieee/20011123-1.c
gcc.c-torture/execute/ieee/pr29302-1.c

__unordsf2 - ./gcc/config/soft-fp/unordsf2.c
gcc.c-torture/execute/ieee/compare-fp-1.c
gcc.c-torture/execute/ieee/compare-fp-3.c
gcc.c-torture/execute/ieee/compare-fp-4.c
gcc.c-torture/execute/ieee/fp-cmp-4f.c
gcc.c-torture/execute/ieee/fp-cmp-8f.c

__unorddf2 - ./gcc/config/soft-fp/unorddf2.c
gcc.c-torture/execute/ieee/fp-cmp-4.c
gcc.c-torture/execute/ieee/fp-cmp-5.c
gcc.c-torture/execute/ieee/fp-cmp-8.c

General COFF and SX COFF files differ in the number of derived entries per
single type entry (this is a "n_type" field in symbol table entries).

Whereas general COFF files contain only 1 derived type, SX COFF files can
contain 12 derived types in a single "n_type" field. As a consequence, the
"ISPTR", "ISFCN", "ISARY" macros don't work as they should, since they can
only check the first derived type. We will have to modify them to check all
the other derived types too.

Problem occurs whith th test "complex-1".

Is probably an includes/library issue, but that's just a guess. Assigning
to Fred, as discussed in today's meeting.

Erich

The assembly of the line

    be> 0,48(,$s33)

results in the disassembled code

    7d100908:   19 04 00 a1      : a1000419 00000030    be  0,0x30(,
$s33)

instead of 

    7d100908:   19 34 00 a1      : a1003419 00000030    be> 0,0x30(,
$s33)

I.e. the "branch taken" hint is not implemented by the assembler.

While one level trampolines work ok, the two level example trampoline-1.c
doesn't.

gcc.c-torture/execute/20000822-1.c
fails to build with "undefined reference to `__gcc_flush_cache'"

consider these two source files:

-- func.c --
#include <stdio.h>

int extern_func(int a)
{
    printf("Hello, I have been compiled with GCC and I say: %d\n", a);

    return a + 42;
}
--

-- func-main.c --
#include <stdlib.h>
#include <stdio.h>

extern int extern_func(int);

int local_func(int r)
{
    printf("Local func says: %d\n", r);

    return 42;
}

int main(int argc, char **argv)
{
    int r = extern_func(42);
    int v = local_func(r);
    printf("Main says: %d\n", v);
}
--

when compiled with gcc, linked with native SX ld and run on v00, they
produce the following, obviously wrong output:

Hello, I have been compiled with GCC and I say: 2048
Local func says: 2560
Main says: 3072

if sources are compiled with native SX cc, I get the correct output:

Hello, I have been compiled with GCC and I say: 42
Local func says: 84
Main says: 42

The instruction
    ldl=    $s35,12(,$s3)
is converted by GAS into
    7d100968:   13 23 00 81      : 81002313 00000124    stl 
$s35,0x124(0,$s1)

    7d10096c:   00 00 01 24 

instead of
    7d100960:   03 a3 00 83      : 8300a303 0000000c    ldl 
$s35,0xc(0,$s3)

    7d100964:   00 00 00 0c 

The disassembler doesn't seem to handle the suffix right, either.

we need to parse the auxilliary symbol entries correctly (various other
functionality depends on this: symbol type resolution, proper lineno
integration etc.).

at least support:
- x_sym
- x_file
- x_scn
parts of the aux union.

While debugging for nestfun-3.c and other similar cases, I wasn't able to
convince dbx that some functions were really there. I remember one case
where it wasn't possible to do "stop in main". Possibly some of the stabs
are missing or are not translated properly.

addr2line tends to spit out the proper line the first time an address is
entered, then 0 for further entries of the same address ... not always
though ... ;)

As said, the attached code becomes trivial with -O1. The problem seems to
be that the if-then-else is replaced by a plain jump insn. The
corresponding edge of the block is deleted (erroneously), because it isn't
recognized as conditional jump (well, it isn't any more). So the bb can be
removed.

This doesn't happen in the same way with SF/DF conditional jumps.

Erich

Again a possible issue with mismatch between includes/libc (or maybe simply
things done differently in the SuperUX libc). Occurs when testing for
example "fputs", "fprintf" and others. Test was with our includes (i.e. the
fake includes taken from Linux).

Erich

If you compile the source code below with the sx-gcc compiler and execute
it, the function aborts:

{{

extern void abort (void);

int main()
{

  float a = 1.0;
  if (a + a == a) {
    abort ();
  }

  return 0;
}

}}

I have checked the assembler code that is generated from the source code 
above and it looks like the problem lies in the "bnef" instruction
(see the block below):

    fad@    $s36,$s35,$s35
    ldu $s35,272(,$s1)
    fcp@    $s35,$s36,$s35
    bnef@   $s35,.L4
    be> 0,.L2
.L4:
    lds $s35,.LC2   #movdi case3
    lea $s36,0
    sts $s36,-280(,$s2)
    lea $s34,-280(,$s2)
    or  $s33,0,$s35
    bsic    $s32,($s33)
.L2:
    or  $s35,0,(0)1
    or  $s123,0,$s35

We van see that the body of the "if" clause (i.e. the block which starts
with label ".L4") is executed if "a + a != a", which is the exact opposite
of the condition we specified in the "if" statement.

The same problem also occurs if we are using other comparison operators
(e.g. !=, >=, ...):

{{

int main()
{
  float a = 1.0;
  if (a != a) {
    abort ();
  }
}

}}

gcc.c-torture/execute/pr31448.c
tests setting 2 24 int bitfields, doing comparisons with constants. 

-O0 works, fails with -O1 and -O2.
-O3 works but optimizes away the call to the subroutine.
Still f looks the same for both -O2 and -O3. 

Generated -O0 -- -O3 assembler files and compared differences. 
Still need to do runs to see where the application crashes. 
Tests could not be done due to lack of internet connection. 

implement assembly output for arbitrary named sections.

this involves at least gcc.c-torture/compile/pr23237.c testcase.

SX-specific command line options for ld should be implemented; including
but not limited to:
- stack size
- machine type (sx4 - 8)
- float type (selects appropriate default lib dir)
- small/large page mem layout

optionally (and later):
- 32G/512G large page layout selection on >SX4
- 32/64-bit int (only applicable with float2 type)
- 32/64-bit size_t (selects appropriate default lib dir)

perhaps holger can shed some light on how important are these options and
how often they are used ...