* lisp.h:

* w32heap.c:
* emacs.c:
* alloc.c: Replace all references of NO_UNION_TYPE with
USE_LISP_UNION_TYPE.

* m/xtensa.h (NO_UNION_TYPE):
* m/vax.h (NO_UNION_TYPE):
* m/template.h (NO_UNION_TYPE):
* m/sparc.h (NO_UNION_TYPE):
* m/mips.h (NO_UNION_TYPE):
* m/macppc.h (NO_UNION_TYPE):
* m/m68k.h (NO_UNION_TYPE):
* m/iris4d.h (NO_UNION_TYPE):
* m/intel386.h (NO_UNION_TYPE):
* m/ibms390x.h (NO_UNION_TYPE):
* m/ibms390.h (NO_UNION_TYPE):
* m/ibmrs6000.h (NO_UNION_TYPE):
* m/ia64.h (NO_UNION_TYPE):
* m/hp800.h (NO_UNION_TYPE):
* m/arm.h (NO_UNION_TYPE):
* m/amdx86-64.h (NO_UNION_TYPE):
* m/alpha.h (NO_UNION_TYPE): Remove definition, all platform were
defining it the same.

1 files changed, 4 insertions, 4 deletions

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index ec96b19f2bc..207ea334701 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -3757,8 +3757,8 @@ If the code is incorrect, your compiler has this problem.
 In the XCONS, etc., macros in lisp.h you must replace (a).u.val with
 ((a).u.val + coercedummy) where coercedummy is declared as int.
 
-This problem will not happen if the m-...h file for your type
-of machine defines NO_UNION_TYPE.  That is the recommended setting now.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
 
 *** C compilers lose on returning unions.
 
@@ -3766,8 +3766,8 @@ I hear that some C compilers cannot handle returning a union type.
 Most of the functions in GNU Emacs return type Lisp_Object, which is
 defined as a union on some rare architectures.
 
-This problem will not happen if the m-...h file for your type
-of machine defines NO_UNION_TYPE.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
 
 
 This file is part of GNU Emacs.