This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Binutils v gcc problems


Hi,
  I have two problems; both of which are fairly unrelated but which I
can't classify as binutils or gcc problems - hence the posting to both
lists.

My host machine is Linux/Alpha; default compiler being egcs-1.1.2 release
I'm trying to build a cross binutils/gcc set to m68k-linux and am hitting
problems at the point where gcc attempts to compile libgcc2.c using the
newly built cross compiler.

The binutils source is unmodified binutils-2.10.1.0.2, the gcc being
crossed is cvs as of today (which has built fine crossed to sparc and mips
- well at least to the point where it wants a C library.)

Points to remember: binutils is K&R C, Linux/Alpha has
sizeof(long)==sizeof(any pointer)=8, sizeof(int)=4

1) 'as' seg faults
  The first problem is that the cross assembler itself segfaults in 
gen_to_words called from line 2022 of tc-m68k.c .  gen_to_words is
declared and defined as:

int  
gen_to_words (words, precision, exponent_bits)   
     LITTLENUM_TYPE *words;
     int precision;
     long exponent_bits;  

and from gdb inside gen_to_words it looks like the value of 'precision' is
actually one byte of the 'words' pointer value.  The calling code in
tc-m68k.c is:

  gen_to_words (words, baseo, (long) outro);

where words is an array declared as

short int* words[6];

and baseo and outro are both register ints.  Now to me this looks like
some screwyness from the fact that it doesn't really know the size of the
first argument is not an int.

Note: 1) Adding a printf printing precision in gen_to_words stops it
segging. 2) Compiling with latest cvs stops it segging.

2) 'as' comp;ains of libgcc2.s:100: Error: cannot create floating-point
number

  Now at first I thought that this could be a result of using a newer
compiler to 'fix' problem 1. But given that line 100 is :

     fcmp.d #0r-1.08709117743770659141e-1257,%fp2

  I've got to ask is it actually a valid floating point number, and if not
what is the compiler doing outputting it.

------------------------------------------------------
I tried unsuccessfully to recreate (1) with a simple test program given
below.

Dave

#define TT_L1 short int

int main() {
  TT_L1 words[6];
  register int baseo=4,outro=5;

  /* Equivalent hopefully to line 2022 in tc-m68k.c */
  testfunc(words,baseo, (long) outro);
}

/* Equivalent hopefully to gen_to_words in atof-ieee.c */
int
testfunc (words, precision, exponent_bits)
  TT_L1 *words;
  int precision;
  long exponent_bits;
{
  printf("in testfunc words=%p\n",words);
  printf("in testfunc precision=%d\n", precision);
  printf("in testfunc exponent_bits=%ld\n",exponent_bits);

  return precision;
}

-- 
 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert      | Running GNU/Linux on       |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___________________________|___ http://www.treblig.org  |________/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]