[971215]: Another patch for delta88 - [Was: Re: Big improvement on m[68]8k-motorola-sysv{,3} systems ]

[Manfred Hollstein]

On Tue, 16 December 1997, 23:55:15, law@cygnus.com wrote:

 > 
 >   In message < 9712081108.AA16457@lts.sel.alcatel.de >you write:
 > 
 >   > Wed Dec  3 16:51:47 1997  Manfred Hollstein  <manfred@s-direktnet.de>
 >   > 
 >   > 	* g++.old-deja/g++.law/profile1.C (XFAIL): Expect it to fail on
 >   > 	m68k-motorola-sysv and m88k-motorola-sysv3.
 >   > 
 >   > 	* gcc.c-torture/execute/920501-8.c (sprintf): Don't declare prototype
 >   > 	on SunOS.
 >   > 	
 >   > 	* gcc.c-torture/execute/loop-2e.cexp: New file to indicate expected
 >   > 	compile failures on m68k-motorola-sysv and m88k-motorola-sysv3.
 >   > 	* gcc.c-torture/execute/loop-2f.cexp: Likewise.
 > Installed.  Note I had already fixed 920501-8.c.
I saw this too late :-(

 >   > 
 >   > 	* fixincludes (size_t): Add support for Motorola's stdlib.h
 >   > 	which fails to provide a definition for size_t.
 >   > 	(fabs/hypot): Provide a prototype for fabs on m88k-motorola-sysv3.
 >   > 	(str{len,spn,cspn} return value): Handle different layout on sysV88.
 >   > 	(hypot): Provide a fake for hypot which is broken on m88k-motorola-sysv
 > Also installed.  However, in the future, please don't provide two completely
 > separate patches in the same message.  It's easier if they are separate
 > messages.
Thanks a lot, this was really causing me a lot of headache. But, from what I
see in the latest snapshot you installed an old version of my patch.
In my e-mail you replied to, I wrote:

 It's a followup   to my previous  bug
 report `[971031]: Fix for broken  hypot funct. on m88k-motorola-sysv3'
 I posted on Nov 5th and replaces that patch completely.

But you added the patch against 971031.

Here's a patch for the patch:

Wed Dec 17 11:44:53 1997  Manfred Hollstein  <manfred@s-direktnet.de>

	* fixincludes (size_t): Add support for Motorola's stdlib.h
	which fails to provide a definition for size_t.
	(fabs/hypot): Provide a prototype for fabs on m88k-motorola-sysv3.

diff -c -p egcs-971215.orig/gcc/fixincludes egcs-971215/gcc/fixincludes
*** egcs-971215.orig/gcc/fixincludes	Wed Dec 17 11:33:48 1997
--- egcs-971215/gcc/fixincludes	Tue Dec 16 14:45:34 1997
*************** for file in sys/types.h stdlib.h sys/std
*** 366,371 ****
--- 366,378 ----
    if [ -r ${LIB}/$file ]; then
      echo Fixing size_t, ptrdiff_t and wchar_t in $file
      sed \
+       -e '/^[ 	]*\*[ 	]*typedef unsigned int size_t;/N'	\
+       -e 's/^\([ 	]*\*[ 	]*typedef unsigned int size_t;\n[ 	]*\*\/\)/\1\
+ #ifndef __SIZE_TYPE__\
+ #define __SIZE_TYPE__ long unsigned int\
+ #endif\
+ typedef __SIZE_TYPE__ size_t;\
+ /'	\
        -e '/typedef[ 	][ 	]*[a-z_][ 	a-z_]*[ 	]size_t/i\
  #ifndef __SIZE_TYPE__\
  #define __SIZE_TYPE__ long unsigned int\
*************** done
*** 2300,2305 ****
--- 2307,2314 ----
  # libm.a on m88k-motorola-sysv3 contains a stupid optimization for function
  # hypot(), which returns the second argument without even looking at its value
  # if the other is 0.0
+ # Another drawback is that fix-header doesn't fix fabs' prototype, and I have
+ #  no idea why.
  file=math.h
  if [ $target_canonical = m88k-motorola-sysv3 ]; then
    if [ -r $file ] && [ ! -r ${LIB}/$file ]; then
*************** if [ $target_canonical = m88k-motorola-s
*** 2309,2316 ****
    fi
  
    if [ -r ${LIB}/$file ]; then
!     echo Fixing $file, hypot definition
!     sed -e '/^extern double hypot();$/a\
  \/* Workaround a stupid Motorola optimization if one\
     of x or y is 0.0 and the other is negative!  *\/\
  #ifdef __STDC__\
--- 2318,2327 ----
    fi
  
    if [ -r ${LIB}/$file ]; then
!     echo Fixing $file, fabs/hypot definition
!     sed \
!       -e 's/extern double floor(), ceil(), fmod(), fabs();/extern double floor(), ceil(), fmod(), fabs _PARAMS((double));/' \
!       -e '/^extern double hypot();$/a\
  \/* Workaround a stupid Motorola optimization if one\
     of x or y is 0.0 and the other is negative!  *\/\
  #ifdef __STDC__\

 > 
 > I'm a little worried about the size_t change, but I guess if it causes
 > problems we'll find out soon enough.
 > 
 > jeff

Manfred