unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
       [not found] <E1WZTF5-00018M-TN@vcs.savannah.gnu.org>
@ 2014-04-14 13:10 ` Stefan Monnier
  2014-04-14 20:08   ` Paul Eggert
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2014-04-14 13:10 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

>   * src/alloc.c (TAGGABLE_NULL): New constant,
>   for porting to hosts with nontrivial DATA_SEG_BITS settings.
[...]
>   * src/lisp.h (lisp_h_XPNTR): Don't OR in bits that aren't masked out,
>   for consistency with how TAGGABLE_NULL is computed.

Can't these systems USE_LSB_TAG?


        Stefan



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
  2014-04-14 13:10 ` [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5 Stefan Monnier
@ 2014-04-14 20:08   ` Paul Eggert
  2014-04-14 20:26     ` Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Eggert @ 2014-04-14 20:08 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On 04/14/2014 06:10 AM, Stefan Monnier wrote:
> Can't these systems USE_LSB_TAG?
IRIX cc doesn't define USE_LSB_TAG because it doesn't support alignas 
(8) a.k.a. __attribute__ ((__aligned__ (8))).

How about this idea for the trunk: remove DATA_SEG_BITS from the source 
code.  On the troublesome platforms that remain we configure 
Lisp_Objects to be wider than pointers, which solves the DATA_SEG_BITS 
problem in a different way.  Something like the attached patch, say.


[-- Attachment #2: DATA_SEG_BITS.patch --]
[-- Type: text/x-patch, Size: 10162 bytes --]

=== modified file 'ChangeLog'
--- ChangeLog	2014-04-14 05:35:45 +0000
+++ ChangeLog	2014-04-14 20:01:11 +0000
@@ -1,5 +1,10 @@
 2014-04-14  Paul Eggert  <eggert@cs.ucla.edu>
 
+	Remove DATA_SEG_BITS.
+	On the now-rare platforms that don't support USE_LSB_TAG,
+	configure as if --with-wide-int were specified.
+	* configure.ac (DATA_SEG_BITS): Remove.  All uses removed.
+
 	* autogen.sh: Use autoreconf's -f option (Bug#17258).
 
 	Clean up configure-time library handling a bit.

=== modified file 'admin/CPP-DEFINES'
--- admin/CPP-DEFINES	2014-04-14 05:23:31 +0000
+++ admin/CPP-DEFINES	2014-04-14 19:48:43 +0000
@@ -86,7 +86,6 @@
 BROKEN_GET_CURRENT_DIR_NAME
 BROKEN_NON_BLOCKING_CONNECT
 BROKEN_PTY_READ_AFTER_EAGAIN
-DATA_SEG_BITS
 DEFAULT_SOUND_DEVICE
 DEVICE_SEP
 DIRECTORY_SEP

=== modified file 'configure.ac'
--- configure.ac	2014-04-14 05:23:31 +0000
+++ configure.ac	2014-04-14 19:48:43 +0000
@@ -4252,28 +4252,6 @@
 esac
 
 
-dnl Used in lisp.h, emacs.c, vm-limit.c
-dnl NEWS.18 describes this as "a number which contains
-dnl the high bits to be inclusive or'ed with pointers that are unpacked."
-AH_TEMPLATE(DATA_SEG_BITS, [Extra bits to be or'd in with any pointers
-stored in a Lisp_Object.])
-dnl if Emacs uses fewer than 32 bits for the value field of a LISP_OBJECT.
-
-case $opsys in
-  aix*)
-    dnl This works with 32-bit executables; Emacs doesn't support 64-bit.
-    AC_DEFINE(DATA_SEG_BITS, [0x20000000])
-    ;;
-  hpux*)
-    dnl The data segment on this machine always starts at address 0x40000000.
-    AC_DEFINE(DATA_SEG_BITS, [0x40000000])
-    ;;
-  irix6-5)
-    AC_DEFINE(DATA_SEG_BITS, [0x10000000])
-    ;;
-esac
-
-
 AH_TEMPLATE(TAB3, [Undocumented.])
 
 case $opsys in

=== modified file 'etc/emacs-buffer.gdb'
--- etc/emacs-buffer.gdb	2014-01-01 07:43:34 +0000
+++ etc/emacs-buffer.gdb	2014-04-14 19:48:43 +0000
@@ -79,7 +79,7 @@
 
 define ygetptr
   set $ptr = $arg0
-  set $ptr = ((CHECK_LISP_OBJECT_TYPE ? $ptr.i : $ptr) & VALMASK) | DATA_SEG_BITS
+  set $ptr = (CHECK_LISP_OBJECT_TYPE ? $ptr.i : $ptr) & VALMASK
 end
 
 define ybuffer-list

=== modified file 'src/.gdbinit'
--- src/.gdbinit	2014-01-29 18:17:20 +0000
+++ src/.gdbinit	2014-04-14 19:48:43 +0000
@@ -49,7 +49,7 @@
   else
     set $bugfix = $arg0
   end
-  set $ptr = ($bugfix & VALMASK) | DATA_SEG_BITS
+  set $ptr = $bugfix & VALMASK
 end
 
 define xgetint
@@ -1093,8 +1093,8 @@
 end
 
 define xcoding
-  set $tmp = (struct Lisp_Hash_Table *) ((Vcoding_system_hash_table & VALMASK) | DATA_SEG_BITS)
-  set $tmp = (struct Lisp_Vector *) (($tmp->key_and_value & VALMASK) | DATA_SEG_BITS)
+  set $tmp = (struct Lisp_Hash_Table *) (Vcoding_system_hash_table & VALMASK)
+  set $tmp = (struct Lisp_Vector *) ($tmp->key_and_value & VALMASK)
   set $name = $tmp->contents[$arg0 * 2]
   print $name
   pr
@@ -1106,8 +1106,8 @@
 end
 
 define xcharset
-  set $tmp = (struct Lisp_Hash_Table *) ((Vcharset_hash_table & VALMASK) | DATA_SEG_BITS)
-  set $tmp = (struct Lisp_Vector *) (($tmp->key_and_value & VALMASK) | DATA_SEG_BITS)
+  set $tmp = (struct Lisp_Hash_Table *) (Vcharset_hash_table & VALMASK)
+  set $tmp = (struct Lisp_Vector *) ($tmp->key_and_value & VALMASK)
   p $tmp->contents[charset_table[$arg0].hash_index * 2]
   pr
 end

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2014-04-12 19:24:17 +0000
+++ src/ChangeLog	2014-04-14 19:48:43 +0000
@@ -1,3 +1,16 @@
+2014-04-14  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Remove DATA_SEG_BITS.
+	* alloc.c (gdb_make_enums_visible): Update to match lisp.h.
+	* lisp.h (GCTYPEBITS): Move definition up, and switch to the
+	DEFINE_GDB_SYMBOL_START way to define it.
+	(NONPOINTER_BITS): New macro.
+	(EMACS_INT): Use it, to select a wider integer on troublesome
+	platforms that don't allow USE_LSB_TAG.
+	(USE_LSB_TAG): Simplify, based on above changes.
+	(gdb_DATA_SEG_BITS): Remove.  All uses removed.
+	* vm-limit.c (exceeds_lisp_ptr): Remove.  All uses removed.
+
 2014-04-12  Eli Zaretskii  <eliz@gnu.org>
 
 	* xdisp.c (move_it_by_lines): If a large portion of buffer text is

=== modified file 'src/alloc.c'
--- src/alloc.c	2014-04-08 12:39:40 +0000
+++ src/alloc.c	2014-04-14 19:48:43 +0000
@@ -7130,7 +7130,6 @@
   enum char_bits char_bits;
   enum CHECK_LISP_OBJECT_TYPE CHECK_LISP_OBJECT_TYPE;
   enum DEFAULT_HASH_SIZE DEFAULT_HASH_SIZE;
-  enum enum_USE_LSB_TAG enum_USE_LSB_TAG;
   enum FLOAT_TO_STRING_BUFSIZE FLOAT_TO_STRING_BUFSIZE;
   enum Lisp_Bits Lisp_Bits;
   enum Lisp_Compiled Lisp_Compiled;

=== modified file 'src/lisp.h'
--- src/lisp.h	2014-04-07 20:54:16 +0000
+++ src/lisp.h	2014-04-14 20:01:11 +0000
@@ -61,6 +61,24 @@
 /* Number of elements in an array.  */
 #define ARRAYELTS(arr) (sizeof (arr) / sizeof (arr)[0])
 
+/* Number of bits in a Lisp_Object tag.  This can be used in #if,
+   and for GDB's sake also as a regular symbol.  */
+DEFINE_GDB_SYMBOL_BEGIN (int, GCTYPEBITS)
+#define GCTYPEBITS 3
+DEFINE_GDB_SYMBOL_END (GCTYPEBITS)
+
+/* The number of bits needed in an EMACS_INT over and above the number
+   of bits in a pointer.  This is 0 on systems where:
+   1.  We can specify multiple-of-8 alignment on static variables.
+   2.  We know malloc returns a multiple of 8.  */
+#if (defined alignas \
+     && (defined GNU_MALLOC || defined DOUG_LEA_MALLOC || defined __GLIBC__ \
+	 || defined DARWIN_OS || defined __sun))
+# define NONPOINTER_BITS 0
+#else
+# define NONPOINTER_BITS GCTYPEBITS
+#endif
+
 /* EMACS_INT - signed integer wide enough to hold an Emacs value
    EMACS_INT_MAX - maximum value of EMACS_INT; can be used in #if
    pI - printf length modifier for EMACS_INT
@@ -68,16 +86,18 @@
 #ifndef EMACS_INT_MAX
 # if INTPTR_MAX <= 0
 #  error "INTPTR_MAX misconfigured"
-# elif INTPTR_MAX <= INT_MAX && !defined WIDE_EMACS_INT
+# elif INTPTR_MAX <= INT_MAX >> NONPOINTER_BITS && !defined WIDE_EMACS_INT
 typedef int EMACS_INT;
 typedef unsigned int EMACS_UINT;
 #  define EMACS_INT_MAX INT_MAX
 #  define pI ""
-# elif INTPTR_MAX <= LONG_MAX && !defined WIDE_EMACS_INT
+# elif INTPTR_MAX <= LONG_MAX >> NONPOINTER_BITS && !defined WIDE_EMACS_INT
 typedef long int EMACS_INT;
 typedef unsigned long EMACS_UINT;
 #  define EMACS_INT_MAX LONG_MAX
 #  define pI "l"
+/* Check versus LLONG_MAX, not LLONG_MAX >> NONPOINTER_BITS.
+   In theory this is not safe, but in practice it seems to be OK.  */
 # elif INTPTR_MAX <= LLONG_MAX
 typedef long long int EMACS_INT;
 typedef unsigned long long int EMACS_UINT;
@@ -218,12 +238,6 @@
 
 enum Lisp_Bits
   {
-    /* Number of bits in a Lisp_Object tag.  This can be used in #if,
-       and for GDB's sake also as a regular symbol.  */
-    GCTYPEBITS =
-#define GCTYPEBITS 3
-	GCTYPEBITS,
-
     /* 2**GCTYPEBITS.  This must be a macro that expands to a literal
        integer constant, for MSVC.  */
 #define GCALIGNMENT 8
@@ -247,32 +261,14 @@
    This can be used in #if, e.g., '#if VAL_MAX < UINTPTR_MAX' below.  */
 #define VAL_MAX (EMACS_INT_MAX >> (GCTYPEBITS - 1))
 
-/* Unless otherwise specified, use USE_LSB_TAG on systems where:  */
-#ifndef USE_LSB_TAG
-/* 1.  We know malloc returns a multiple of 8.  */
-# if (defined GNU_MALLOC || defined DOUG_LEA_MALLOC || defined __GLIBC__ \
-      || defined DARWIN_OS || defined __sun)
-/* 2.  We can specify multiple-of-8 alignment on static variables.  */
-#  ifdef alignas
-/* 3.  Pointers-as-ints exceed VAL_MAX.
+/* Whether the least-significant bits of an EMACS_INT contain the tag.
    On hosts where pointers-as-ints do not exceed VAL_MAX, USE_LSB_TAG is:
     a. unnecessary, because the top bits of an EMACS_INT are unused, and
     b. slower, because it typically requires extra masking.
-   So, default USE_LSB_TAG to true only on hosts where it might be useful.  */
-#   if VAL_MAX < UINTPTR_MAX
-#    define USE_LSB_TAG true
-#   endif
-#  endif
-# endif
-#endif
-#ifdef USE_LSB_TAG
-# undef USE_LSB_TAG
-enum enum_USE_LSB_TAG { USE_LSB_TAG = true };
-# define USE_LSB_TAG true
-#else
-enum enum_USE_LSB_TAG { USE_LSB_TAG = false };
-# define USE_LSB_TAG false
-#endif
+   So, USE_LSB_TAG is true only on hosts where it might be useful.  */
+DEFINE_GDB_SYMBOL_BEGIN (bool, USE_LSB_TAG)
+#define USE_LSB_TAG (EMACS_INT_MAX >> GCTYPEBITS < INTPTR_MAX)
+DEFINE_GDB_SYMBOL_END (USE_LSB_TAG)
 
 #ifndef alignas
 # define alignas(alignment) /* empty */
@@ -346,8 +342,7 @@
 #define lisp_h_XCONS(a) \
    (eassert (CONSP (a)), (struct Lisp_Cons *) XUNTAG (a, Lisp_Cons))
 #define lisp_h_XHASH(a) XUINT (a)
-#define lisp_h_XPNTR(a) \
-   ((void *) (intptr_t) ((XLI (a) & VALMASK) | DATA_SEG_BITS))
+#define lisp_h_XPNTR(a) ((void *) (intptr_t) (XLI (a) & VALMASK))
 #define lisp_h_XSYMBOL(a) \
    (eassert (SYMBOLP (a)), (struct Lisp_Symbol *) XUNTAG (a, Lisp_Symbol))
 #ifndef GC_CHECK_CONS_LIST
@@ -608,18 +603,8 @@
   PVEC_FONT /* Should be last because it's used for range checking.  */
 };
 
-/* DATA_SEG_BITS forces extra bits to be or'd in with any pointers
-   which were stored in a Lisp_Object.  */
-#ifndef DATA_SEG_BITS
-# define DATA_SEG_BITS 0
-#endif
-enum { gdb_DATA_SEG_BITS = DATA_SEG_BITS };
-#undef DATA_SEG_BITS
-
 enum More_Lisp_Bits
   {
-    DATA_SEG_BITS = gdb_DATA_SEG_BITS,
-
     /* For convenience, we also store the number of elements in these bits.
        Note that this size is not necessarily the memory-footprint size, but
        only the number of Lisp_Object fields (that need to be traced by GC).

=== modified file 'src/vm-limit.c'
--- src/vm-limit.c	2014-01-01 07:43:34 +0000
+++ src/vm-limit.c	2014-04-14 19:48:43 +0000
@@ -71,15 +71,6 @@
 /* Number of bytes of writable memory we can expect to be able to get.  */
 static size_t lim_data;
 \f
-/* Return true if PTR cannot be represented as an Emacs Lisp object.  */
-static bool
-exceeds_lisp_ptr (void *ptr)
-{
-  return (! USE_LSB_TAG
-	  && VAL_MAX < UINTPTR_MAX
-	  && ((uintptr_t) ptr & ~DATA_SEG_BITS) >> VALBITS != 0);
-}
-
 #ifdef HAVE_GETRLIMIT
 
 # ifndef RLIMIT_AS
@@ -222,9 +213,6 @@
       else if (warnlevel > warned_85 && data_size < five_percent * 18)
 	warnlevel = warned_85;
     }
-
-  if (exceeds_lisp_ptr (cp))
-    (*warn_function) ("Warning: memory in use exceeds lisp pointer size");
 }
 \f
 /* Enable memory usage warnings.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
  2014-04-14 20:08   ` Paul Eggert
@ 2014-04-14 20:26     ` Stefan Monnier
  2014-04-15  2:00       ` Paul Eggert
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2014-04-14 20:26 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

> How about this idea for the trunk: remove DATA_SEG_BITS from the source
> code.  On the troublesome platforms that remain we configure Lisp_Objects to
> be wider than pointers, which solves the DATA_SEG_BITS problem
> in a different way.  Something like the attached patch, say.

Using wide-int on those machines sounds rather undesirable, since AFAIK
they're all relatively old machines, so they're less likely to benefit
from wide-int.


        Stefan



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
  2014-04-14 20:26     ` Stefan Monnier
@ 2014-04-15  2:00       ` Paul Eggert
  2014-04-15 17:02         ` Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Eggert @ 2014-04-15  2:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On 04/14/2014 01:26 PM, Stefan Monnier wrote:
> Using wide-int on those machines sounds rather undesirable, since AFAIK
> they're all relatively old machines, so they're less likely to benefit
> from wide-int.

IRIX machines are indeed old and SGI dropped support for IRIX in 
December, so if IRIX is the main issue I suggest following suit and 
removing support from the Emacs trunk.

AIX and HP-UX are still alive though, and they run on newer machines 
(e.g., POWER7+, Itanium Poulson) where wide-int should work reasonably 
well.  Emacs runs on AIX (see Bug#14258) and on HP-UX (see Bug#16717) 
and I doubt whether users on those platforms nowadays will much care 
whether wide-int is used.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
  2014-04-15  2:00       ` Paul Eggert
@ 2014-04-15 17:02         ` Stefan Monnier
  2014-04-15 20:44           ` Paul Eggert
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2014-04-15 17:02 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

> AIX and HP-UX are still alive though, and they run on newer machines (e.g.,

But for those, we want to USE_LSB_TAG (or wide-int).


        Stefan



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
  2014-04-15 17:02         ` Stefan Monnier
@ 2014-04-15 20:44           ` Paul Eggert
  2014-04-15 21:33             ` Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Eggert @ 2014-04-15 20:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier wrote:
>> AIX and HP-UX are still alive though, and they run on newer machines (e.g.,
> But for those, we want to USE_LSB_TAG (or wide-int).

Right, and the DATA_SEG_BITS patch I proposed in 
<http://lists.gnu.org/archive/html/emacs-devel/2014-04/msg00190.html> 
should do just that.  The patch's effect on IRIX happens to be similar 
to its effect on AIX and HP-UX, but that shouldn't be an issue as IRIX 
doesn't matter these days so Emacs users shouldn't care what the patch 
does on IRIX.  If this or any other IRIX issue turns into a maintenance 
hassle we should simply drop support for IRIX -- I could propose that as 
a separate patch if you like.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
  2014-04-15 20:44           ` Paul Eggert
@ 2014-04-15 21:33             ` Stefan Monnier
  2014-04-15 22:46               ` Paul Eggert
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2014-04-15 21:33 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

>>> AIX and HP-UX are still alive though, and they run on newer machines (e.g.,
>> But for those, we want to USE_LSB_TAG (or wide-int).

> Right, and the DATA_SEG_BITS patch I proposed in
> <http://lists.gnu.org/archive/html/emacs-devel/2014-04/msg00190.html> should
> do just that.

Which pat of "just that"?  Does it make USE_LSB_TAG work under AIX and HP-UX?

Or does it fallback on wide-int when USE_LSB_TAG can't be used?
I think using wide-int silently is not a good idea.  So if USE_LSB_TAG
can't be used, I think it'd be better to fail (with a message
suggesting to report the problem and use wide-int in the mean time).


        Stefan



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5.
  2014-04-15 21:33             ` Stefan Monnier
@ 2014-04-15 22:46               ` Paul Eggert
  2014-04-16  1:09                 ` Systems that can't USE_LSB_TAG Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Eggert @ 2014-04-15 22:46 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Stefan Monnier wrote:

> Does it make USE_LSB_TAG work under AIX and HP-UX?
> Or does it fallback on wide-int when USE_LSB_TAG can't be used?

The latter.

> I think using wide-int silently is not a good idea.  So if USE_LSB_TAG
> can't be used, I think it'd be better to fail (with a message
> suggesting to report the problem and use wide-int in the mean time).

That's easy enough; revised patch attached.


[-- Attachment #2: DATA_SEG_BITS.patch --]
[-- Type: text/plain, Size: 10163 bytes --]

=== modified file 'ChangeLog'
--- ChangeLog	2014-04-14 05:35:45 +0000
+++ ChangeLog	2014-04-15 22:40:55 +0000
@@ -1,3 +1,8 @@
+2014-04-15  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Remove DATA_SEG_BITS.
+	* configure.ac (DATA_SEG_BITS): Remove.  All uses removed.
+
 2014-04-14  Paul Eggert  <eggert@cs.ucla.edu>
 
 	* autogen.sh: Use autoreconf's -f option (Bug#17258).

=== modified file 'admin/CPP-DEFINES'
--- admin/CPP-DEFINES	2014-04-14 05:23:31 +0000
+++ admin/CPP-DEFINES	2014-04-14 19:48:43 +0000
@@ -86,7 +86,6 @@
 BROKEN_GET_CURRENT_DIR_NAME
 BROKEN_NON_BLOCKING_CONNECT
 BROKEN_PTY_READ_AFTER_EAGAIN
-DATA_SEG_BITS
 DEFAULT_SOUND_DEVICE
 DEVICE_SEP
 DIRECTORY_SEP

=== modified file 'configure.ac'
--- configure.ac	2014-04-14 05:23:31 +0000
+++ configure.ac	2014-04-14 19:48:43 +0000
@@ -4252,28 +4252,6 @@
 esac
 
 
-dnl Used in lisp.h, emacs.c, vm-limit.c
-dnl NEWS.18 describes this as "a number which contains
-dnl the high bits to be inclusive or'ed with pointers that are unpacked."
-AH_TEMPLATE(DATA_SEG_BITS, [Extra bits to be or'd in with any pointers
-stored in a Lisp_Object.])
-dnl if Emacs uses fewer than 32 bits for the value field of a LISP_OBJECT.
-
-case $opsys in
-  aix*)
-    dnl This works with 32-bit executables; Emacs doesn't support 64-bit.
-    AC_DEFINE(DATA_SEG_BITS, [0x20000000])
-    ;;
-  hpux*)
-    dnl The data segment on this machine always starts at address 0x40000000.
-    AC_DEFINE(DATA_SEG_BITS, [0x40000000])
-    ;;
-  irix6-5)
-    AC_DEFINE(DATA_SEG_BITS, [0x10000000])
-    ;;
-esac
-
-
 AH_TEMPLATE(TAB3, [Undocumented.])
 
 case $opsys in

=== modified file 'etc/emacs-buffer.gdb'
--- etc/emacs-buffer.gdb	2014-01-01 07:43:34 +0000
+++ etc/emacs-buffer.gdb	2014-04-14 19:48:43 +0000
@@ -79,7 +79,7 @@
 
 define ygetptr
   set $ptr = $arg0
-  set $ptr = ((CHECK_LISP_OBJECT_TYPE ? $ptr.i : $ptr) & VALMASK) | DATA_SEG_BITS
+  set $ptr = (CHECK_LISP_OBJECT_TYPE ? $ptr.i : $ptr) & VALMASK
 end
 
 define ybuffer-list

=== modified file 'src/.gdbinit'
--- src/.gdbinit	2014-01-29 18:17:20 +0000
+++ src/.gdbinit	2014-04-14 19:48:43 +0000
@@ -49,7 +49,7 @@
   else
     set $bugfix = $arg0
   end
-  set $ptr = ($bugfix & VALMASK) | DATA_SEG_BITS
+  set $ptr = $bugfix & VALMASK
 end
 
 define xgetint
@@ -1093,8 +1093,8 @@
 end
 
 define xcoding
-  set $tmp = (struct Lisp_Hash_Table *) ((Vcoding_system_hash_table & VALMASK) | DATA_SEG_BITS)
-  set $tmp = (struct Lisp_Vector *) (($tmp->key_and_value & VALMASK) | DATA_SEG_BITS)
+  set $tmp = (struct Lisp_Hash_Table *) (Vcoding_system_hash_table & VALMASK)
+  set $tmp = (struct Lisp_Vector *) ($tmp->key_and_value & VALMASK)
   set $name = $tmp->contents[$arg0 * 2]
   print $name
   pr
@@ -1106,8 +1106,8 @@
 end
 
 define xcharset
-  set $tmp = (struct Lisp_Hash_Table *) ((Vcharset_hash_table & VALMASK) | DATA_SEG_BITS)
-  set $tmp = (struct Lisp_Vector *) (($tmp->key_and_value & VALMASK) | DATA_SEG_BITS)
+  set $tmp = (struct Lisp_Hash_Table *) (Vcharset_hash_table & VALMASK)
+  set $tmp = (struct Lisp_Vector *) ($tmp->key_and_value & VALMASK)
   p $tmp->contents[charset_table[$arg0].hash_index * 2]
   pr
 end

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2014-04-12 19:24:17 +0000
+++ src/ChangeLog	2014-04-15 22:39:53 +0000
@@ -1,3 +1,17 @@
+2014-04-15  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Remove DATA_SEG_BITS.
+	* alloc.c (gdb_make_enums_visible): Update to match lisp.h.
+	* lisp.h (GCTYPEBITS): Move definition up, and switch to the
+	DEFINE_GDB_SYMBOL_START way to define it.
+	(NONPOINTER_BITS): New macro.
+	(EMACS_INT): Use it.
+	[!USE_LSB_TAG && !WIDE_EMACS_INT]: Fail, and suggest reporting
+	the problem and/or configuring --with-wide-int.
+	(USE_LSB_TAG): Simplify, based on above changes.
+	(gdb_DATA_SEG_BITS): Remove.  All uses removed.
+	* vm-limit.c (exceeds_lisp_ptr): Remove.  All uses removed.
+
 2014-04-12  Eli Zaretskii  <eliz@gnu.org>
 
 	* xdisp.c (move_it_by_lines): If a large portion of buffer text is

=== modified file 'src/alloc.c'
--- src/alloc.c	2014-04-08 12:39:40 +0000
+++ src/alloc.c	2014-04-14 19:48:43 +0000
@@ -7130,7 +7130,6 @@
   enum char_bits char_bits;
   enum CHECK_LISP_OBJECT_TYPE CHECK_LISP_OBJECT_TYPE;
   enum DEFAULT_HASH_SIZE DEFAULT_HASH_SIZE;
-  enum enum_USE_LSB_TAG enum_USE_LSB_TAG;
   enum FLOAT_TO_STRING_BUFSIZE FLOAT_TO_STRING_BUFSIZE;
   enum Lisp_Bits Lisp_Bits;
   enum Lisp_Compiled Lisp_Compiled;

=== modified file 'src/lisp.h'
--- src/lisp.h	2014-04-07 20:54:16 +0000
+++ src/lisp.h	2014-04-15 22:44:12 +0000
@@ -61,6 +61,23 @@
 /* Number of elements in an array.  */
 #define ARRAYELTS(arr) (sizeof (arr) / sizeof (arr)[0])
 
+/* Number of bits in a Lisp_Object tag.  */
+DEFINE_GDB_SYMBOL_BEGIN (int, GCTYPEBITS)
+#define GCTYPEBITS 3
+DEFINE_GDB_SYMBOL_END (GCTYPEBITS)
+
+/* The number of bits needed in an EMACS_INT over and above the number
+   of bits in a pointer.  This is 0 on systems where:
+   1.  We can specify multiple-of-8 alignment on static variables.
+   2.  We know malloc returns a multiple of 8.  */
+#if (defined alignas \
+     && (defined GNU_MALLOC || defined DOUG_LEA_MALLOC || defined __GLIBC__ \
+	 || defined DARWIN_OS || defined __sun))
+# define NONPOINTER_BITS 0
+#else
+# define NONPOINTER_BITS GCTYPEBITS
+#endif
+
 /* EMACS_INT - signed integer wide enough to hold an Emacs value
    EMACS_INT_MAX - maximum value of EMACS_INT; can be used in #if
    pI - printf length modifier for EMACS_INT
@@ -68,16 +85,18 @@
 #ifndef EMACS_INT_MAX
 # if INTPTR_MAX <= 0
 #  error "INTPTR_MAX misconfigured"
-# elif INTPTR_MAX <= INT_MAX && !defined WIDE_EMACS_INT
+# elif INTPTR_MAX <= INT_MAX >> NONPOINTER_BITS && !defined WIDE_EMACS_INT
 typedef int EMACS_INT;
 typedef unsigned int EMACS_UINT;
 #  define EMACS_INT_MAX INT_MAX
 #  define pI ""
-# elif INTPTR_MAX <= LONG_MAX && !defined WIDE_EMACS_INT
+# elif INTPTR_MAX <= LONG_MAX >> NONPOINTER_BITS && !defined WIDE_EMACS_INT
 typedef long int EMACS_INT;
 typedef unsigned long EMACS_UINT;
 #  define EMACS_INT_MAX LONG_MAX
 #  define pI "l"
+/* Check versus LLONG_MAX, not LLONG_MAX >> NONPOINTER_BITS.
+   In theory this is not safe, but in practice it seems to be OK.  */
 # elif INTPTR_MAX <= LLONG_MAX
 typedef long long int EMACS_INT;
 typedef unsigned long long int EMACS_UINT;
@@ -218,12 +237,6 @@
 
 enum Lisp_Bits
   {
-    /* Number of bits in a Lisp_Object tag.  This can be used in #if,
-       and for GDB's sake also as a regular symbol.  */
-    GCTYPEBITS =
-#define GCTYPEBITS 3
-	GCTYPEBITS,
-
     /* 2**GCTYPEBITS.  This must be a macro that expands to a literal
        integer constant, for MSVC.  */
 #define GCALIGNMENT 8
@@ -247,31 +260,19 @@
    This can be used in #if, e.g., '#if VAL_MAX < UINTPTR_MAX' below.  */
 #define VAL_MAX (EMACS_INT_MAX >> (GCTYPEBITS - 1))
 
-/* Unless otherwise specified, use USE_LSB_TAG on systems where:  */
-#ifndef USE_LSB_TAG
-/* 1.  We know malloc returns a multiple of 8.  */
-# if (defined GNU_MALLOC || defined DOUG_LEA_MALLOC || defined __GLIBC__ \
-      || defined DARWIN_OS || defined __sun)
-/* 2.  We can specify multiple-of-8 alignment on static variables.  */
-#  ifdef alignas
-/* 3.  Pointers-as-ints exceed VAL_MAX.
+/* Whether the least-significant bits of an EMACS_INT contain the tag.
    On hosts where pointers-as-ints do not exceed VAL_MAX, USE_LSB_TAG is:
     a. unnecessary, because the top bits of an EMACS_INT are unused, and
     b. slower, because it typically requires extra masking.
-   So, default USE_LSB_TAG to true only on hosts where it might be useful.  */
-#   if VAL_MAX < UINTPTR_MAX
-#    define USE_LSB_TAG true
-#   endif
-#  endif
-# endif
-#endif
-#ifdef USE_LSB_TAG
-# undef USE_LSB_TAG
-enum enum_USE_LSB_TAG { USE_LSB_TAG = true };
-# define USE_LSB_TAG true
-#else
-enum enum_USE_LSB_TAG { USE_LSB_TAG = false };
-# define USE_LSB_TAG false
+   So, USE_LSB_TAG is true only on hosts where it might be useful.  */
+DEFINE_GDB_SYMBOL_BEGIN (bool, USE_LSB_TAG)
+#define USE_LSB_TAG (EMACS_INT_MAX >> GCTYPEBITS < INTPTR_MAX)
+DEFINE_GDB_SYMBOL_END (USE_LSB_TAG)
+
+#if !USE_LSB_TAG && !defined WIDE_EMACS_INT
+# error "USE_LSB_TAG not supported on this platform; please report this." \
+	"Try 'configure --with-wide-wint' to work around the problem."
+error !;
 #endif
 
 #ifndef alignas
@@ -346,8 +347,7 @@
 #define lisp_h_XCONS(a) \
    (eassert (CONSP (a)), (struct Lisp_Cons *) XUNTAG (a, Lisp_Cons))
 #define lisp_h_XHASH(a) XUINT (a)
-#define lisp_h_XPNTR(a) \
-   ((void *) (intptr_t) ((XLI (a) & VALMASK) | DATA_SEG_BITS))
+#define lisp_h_XPNTR(a) ((void *) (intptr_t) (XLI (a) & VALMASK))
 #define lisp_h_XSYMBOL(a) \
    (eassert (SYMBOLP (a)), (struct Lisp_Symbol *) XUNTAG (a, Lisp_Symbol))
 #ifndef GC_CHECK_CONS_LIST
@@ -608,18 +608,8 @@
   PVEC_FONT /* Should be last because it's used for range checking.  */
 };
 
-/* DATA_SEG_BITS forces extra bits to be or'd in with any pointers
-   which were stored in a Lisp_Object.  */
-#ifndef DATA_SEG_BITS
-# define DATA_SEG_BITS 0
-#endif
-enum { gdb_DATA_SEG_BITS = DATA_SEG_BITS };
-#undef DATA_SEG_BITS
-
 enum More_Lisp_Bits
   {
-    DATA_SEG_BITS = gdb_DATA_SEG_BITS,
-
     /* For convenience, we also store the number of elements in these bits.
        Note that this size is not necessarily the memory-footprint size, but
        only the number of Lisp_Object fields (that need to be traced by GC).

=== modified file 'src/vm-limit.c'
--- src/vm-limit.c	2014-01-01 07:43:34 +0000
+++ src/vm-limit.c	2014-04-14 19:48:43 +0000
@@ -71,15 +71,6 @@
 /* Number of bytes of writable memory we can expect to be able to get.  */
 static size_t lim_data;
 \f
-/* Return true if PTR cannot be represented as an Emacs Lisp object.  */
-static bool
-exceeds_lisp_ptr (void *ptr)
-{
-  return (! USE_LSB_TAG
-	  && VAL_MAX < UINTPTR_MAX
-	  && ((uintptr_t) ptr & ~DATA_SEG_BITS) >> VALBITS != 0);
-}
-
 #ifdef HAVE_GETRLIMIT
 
 # ifndef RLIMIT_AS
@@ -222,9 +213,6 @@
       else if (warnlevel > warned_85 && data_size < five_percent * 18)
 	warnlevel = warned_85;
     }
-
-  if (exceeds_lisp_ptr (cp))
-    (*warn_function) ("Warning: memory in use exceeds lisp pointer size");
 }
 \f
 /* Enable memory usage warnings.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Systems that can't USE_LSB_TAG
  2014-04-15 22:46               ` Paul Eggert
@ 2014-04-16  1:09                 ` Stefan Monnier
  2014-04-16  5:25                   ` Paul Eggert
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2014-04-16  1:09 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

>> Does it make USE_LSB_TAG work under AIX and HP-UX?
>> Or does it fallback on wide-int when USE_LSB_TAG can't be used?
> The latter.

Too bad, I think it's more important to make USE_LSB_TAG work.

>> I think using wide-int silently is not a good idea.  So if USE_LSB_TAG
>> can't be used, I think it'd be better to fail (with a message
>> suggesting to report the problem and use wide-int in the mean time).
> That's easy enough; revised patch attached.

Hmmm.. so with this patch we fail on all hosts where USE_LSB_TAG can't
be used, even those where DATA_SEG_BITS is not needed.

Which systems currently can't USE_LSB_TAG?


        Stefan



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Systems that can't USE_LSB_TAG
  2014-04-16  1:09                 ` Systems that can't USE_LSB_TAG Stefan Monnier
@ 2014-04-16  5:25                   ` Paul Eggert
  2014-04-16 13:03                     ` Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Eggert @ 2014-04-16  5:25 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier wrote:
> Hmmm.. so with this patch we fail on all hosts where USE_LSB_TAG can't
> be used, even those where DATA_SEG_BITS is not needed.

Yes, that's why I originally went for the wide-int fallback.

> Which systems currently can't USE_LSB_TAG?

Only IRIX as far as I know.  Specifically, the list includes:

1. Systems with pre-C11 compilers that are not in the following list: 
GCC, HP, IBM, Intel, Sun/Oracle, Microsoft, plus any mimics of these 
(such as clang).  Fundamentally we need the equivalent of GCC's 
attribute ((aligned (8))) and/or C11's _Alignas (8).

2. Systems where we must use the system malloc and it doesn't return a 
multiple of 8.

The only category (1) system I know of is IRIX cc, which SGI stopped 
supporting in December.  I don't know of any category (2) systems.

I don't know all the Emacs porting targets and quite possibly I've 
missed some.  Perhaps other unusual systems are in category (1); most 
likely we could port to them if we knew the right incantation to get an 
_Alignas equivalent on their compiler, and if not we could fall back on 
aligning the static C variables some other way.  We could port to 
category (2) systems (if any practical ones exist) by wrapping 
malloc/free/etc. and losing at most 8 bytes per allocation.  I hope we 
needn't use either hack, though.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Systems that can't USE_LSB_TAG
  2014-04-16  5:25                   ` Paul Eggert
@ 2014-04-16 13:03                     ` Stefan Monnier
  0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2014-04-16 13:03 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

>> Hmmm.. so with this patch we fail on all hosts where USE_LSB_TAG can't
>> be used, even those where DATA_SEG_BITS is not needed.
> Yes, that's why I originally went for the wide-int fallback.
>> Which systems currently can't USE_LSB_TAG?
> Only IRIX as far as I know.

In that case, it's fine.  That can be fixed by using another compiler
(tho IIUC, dumping fails with gcc currently, so "using another
compiler" might not be completely straightforward).

> 2. Systems where we must use the system malloc and it doesn't
> return a multiple of 8.

IIRC the Mac OS 9 build was like that, but we don't care about that
one now.  Don't know of any other.

So, yes, feel free to install your patch on trunk.


        Stefan



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-04-16 13:03 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <E1WZTF5-00018M-TN@vcs.savannah.gnu.org>
2014-04-14 13:10 ` [Emacs-diffs] emacs-24 r116961: Port to IRIX 6.5 Stefan Monnier
2014-04-14 20:08   ` Paul Eggert
2014-04-14 20:26     ` Stefan Monnier
2014-04-15  2:00       ` Paul Eggert
2014-04-15 17:02         ` Stefan Monnier
2014-04-15 20:44           ` Paul Eggert
2014-04-15 21:33             ` Stefan Monnier
2014-04-15 22:46               ` Paul Eggert
2014-04-16  1:09                 ` Systems that can't USE_LSB_TAG Stefan Monnier
2014-04-16  5:25                   ` Paul Eggert
2014-04-16 13:03                     ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).