[Patches] [ python-Patches-466353 ] Py_HUGE_VAL on BeOS for Intel

[noreply@sourceforge.net]

Patches item #466353, was opened at 2001-09-29 04:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466353&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Py_HUGE_VAL on BeOS for Intel

Initial Comment:
*** Python-2.2a4/Include/pyport.h~	Thu Sep  6 07:36:55 2001
--- Python-2.2a4/Include/pyport.h	Sat Sep 29 19:50:51 2001
***************
*** 236,246 ****
--- 236,251 ----
   * defined to be the largest positive finite rather than 
infinity.  We need
   * the std-conforming infinity meaning (provided the 
platform has one!).
   */
+ #if defined(__BEOS__) && defined(__INTEL__)
+ /* On BeOS for Intel, INFINITY is defined as float. */
+ #define Py_HUGE_VAL HUGE_VAL
+ #else
  #ifdef INFINITY
  #define Py_HUGE_VAL INFINITY
  #else
  #define Py_HUGE_VAL HUGE_VAL
  #endif
+ #endif /* defined(__BEOS__) && defined(__INTEL__) */
  
  /* Py_OVERFLOWED(X)
   * Return 1 iff a libm function overflowed.  Set errno to 
0 before calling

On BeOS for Intel, INFINITY is defined as float, and
HUGE_VAL is defined as double.  This patch is mandatory;
with the original pyport.h, "gcc -O" emits internal errors
in compilation of Objects/floatobject.c and
Objects/longobject.c.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-10-01 12:51

Message:
Logged In: YES 
user_id=31435

Thanks for the followup!  That's one messy expansion for 
INFINITY.  I checked in the explicit cast to double, for 
2.2b1:

Include/pyport.h; new revision: 2.37

But you should still report the internal compiler errors to 
your compiler supplier.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-09-30 07:45

Message:
Logged In: NO 

>Question:  What (exactly) do INFINITY and HUGE_VAL expand 
>to on this platform?  (As above, that INFINITY is "a float" 
>doesn't explain anything.)

#define	__HUGE_VAL_bytes	{ 0, 0, 0, 0, 0, 0, 0xf0, 0x7f }
#define __huge_val_t	union { unsigned char __c[8]; double __d; 
}
#define HUGE_VAL	(((__huge_val_t) { __c: __HUGE_VAL_bytes 
}).__d)

#define __HUGE_VALF_bytes	{ 0, 0, 0x80, 0x7f }
#define __huge_valf_t	union { unsigned char __c[4]; float __f; }
#define HUGE_VALF	(((__huge_valf_t) { __c: __HUGE_VALF_bytes 
}).__f)

#define INFINITY	HUGE_VALF

>Another question:  do the compiler errors go away if the 
>original Python is replaced by
>
>#define Py_HUGE_VAL ((double)INFINITY)
>
>? 

Yes, they do.  Thank you!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-29 09:46

Message:
Logged In: YES 
user_id=31435

Python doesn't use Py_HUGE_VAL for anything except floating-
point equality testing against a double, and unary minus 
(Python doesn't pick apart the bits, or do anything else 
potentially platform-dependent with it), so a float 
infinity should be fine (the compiler should simply promote 
it to double in the places Python uses it, same as any 
other float used in a double context).

Have you reported this as a gcc bug ("internal errors" are 
compiler bugs)?  One problem with your #ifdef is that it 
will live forever, even after the gcc bug is fixed.  
Another problem is that I see no reason to believe that a 
compiler bug is unique to a specific operating system -- in 
which case the #ifdef doesn't really solve the problem.  
Therefore I'm extremely reluctant to accept this idea.

A general autoconf test setting a (say) 
CANT_USE_INFINITY_FOR_HUGEVAL symbol when the platform 
compiler demonstrably screws up would be a good solution.

Question:  What (exactly) do INFINITY and HUGE_VAL expand 
to on this platform?  (As above, that INFINITY is "a float" 
doesn't explain anything.)

Another question:  do the compiler errors go away if the 
original Python is replaced by

#define Py_HUGE_VAL ((double)INFINITY)

?  That is, if an explicit cast is enough to fix this, 
that's by far the simplest approach.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466353&group_id=5470