🚀 go-pugleaf

>>>>> On 24 May 1993 12:06:44 EST,
>>>>> In message <C7JJJ8.Lp4@plato.ds.boeing.com>,
>>>>> dano@dogfish.boeing.com (Dan Olson) wrote:

Dan> I'm installing gcc 2.4.0 on a sun 3 using 4.1.1 (of course).  Now
Dan> long doubles (96 bits) != doubles (64 bits), and the sun scanf
Dan> doesn't seem to be able to read long doubles.  So, enquire fails
Dan> (unhappily).

I was going to submit a bug report about this shortly.

The problem I observed (on an HP9000s425 under HPUX 8.0) was that the
system supplied scanf routine expects a long double to be 128 bits.
Thus using one of the routines in the scanf family to scan in a long
double results in an overwriting of the longword above the (gcc
allocated) 96 bit long double.  When compiling enquire, this results
in the trashing of the saved frame pointer for the calling function.

Dan> What do you all do?  Redefine long double size back to 64 bits?

This is the workaround I have used.

It doesn't *really* solve the problem, though, since a similar problem
will arise if you define a long double in your gcc compiled code and
use the system supplied scanf routines with a "%L[feg]" format.

I suppose long double should be defined as 128 bits on the
m68k-hp-hpux target.  I don't know if gcc can do arithmetic on such a
large floating point type.

It is possible that HPUX only uses the first 96 bits of this 128 (the
Motorola 68881 extended floating point format is 96 bits).  In this
case, it might be possible to get gcc to allocate 128 bits, but only
use 96.