bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2

bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2

[Gilles Pion]

[-- Attachment #1.1: Type: text/plain, Size: 3286 bytes --]

*1st compilation error:*

sysdep.c: In function 'init_signals':
sysdep.c:1940:34: error: 'deliver_danger_signal' undeclared (first use in
this function)
sysdep.c:1940:34: note: each undeclared identifier is reported only once
for each function it appears in
gmake[1]: *** [sysdep.o] Error 1
gmake[1]: Leaving directory
`/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src'
gmake: *** [src] Error 2

Have bee able to fix by adding declaration of "deliver_danger_signal"
in  sysdep.c:

  void deliver_danger_signal (int sig);

*2nd compilation error:*
(did not found a easy way to fix)

/fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -c  -Demacs  -I.
-I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src -I../lib
-I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src/../lib
    -MMD -MF deps/eval.d -MP     -O2 -I/opt/freeware/include eval.c
eval.c: In function 'mark_backtrace':
eval.c:3380:20: error: invalid type argument of unary '*' (have
'Lisp_Object')
gmake[1]: *** [eval.o] Error 1
gmake[1]: Leaving directory
`/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src'
gmake: *** [src] Error 2
*
*
Context:

$ /fdj/opt/gcc-4.7/bin/gcc --version
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


  Where should the build process find the source code?
 /sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92
  What compiler should emacs be built with?
/fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -O2 -I/opt/freeware/include
  Should Emacs use the GNU version of malloc?             yes
  Should Emacs use a relocating allocator for buffers?    yes
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          LUCID
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  no
  Does Emacs use -ltiff?                                  no
  Does Emacs use a gif library?                           no
  Does Emacs use -lpng?                                   no
  Does Emacs use -lrsvg-2?                                no
  Does Emacs use imagemagick?                             no
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  no
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               no
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                no
  Does Emacs use -lxml2?                                  no
  Does Emacs use -lfreetype?                              no
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   no
  Does Emacs use toolkit scroll bars?                     no


-- 
Gilles PION

[-- Attachment #1.2: Type: text/html, Size: 6541 bytes --]

[-- Attachment #2: config.txt --]
[-- Type: text/plain, Size: 1226 bytes --]

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by emacs configure 24.2.92, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --prefix=/fdj/opt/emacs-24.2.92 --exec-prefix=/fdj/opt/emacs-24.2.92 --sysconfdir=/etc/fdj/opt/emacs --localstatedir=/var/fdj/opt/emacs --without-kerberos --without-pop --with-x-toolkit=lucid --without-sound --without-kerberos --without-kerberos5 --with-jpeg=no --with-png=no --with-gif=no --with-tiff=no --with-xpm --without-toolkit-scroll-bars --enable-locallisppath=/fdj/share/emacs/site-lisp --without-makeinfo

## --------- ##
## Platform. ##
## --------- ##

hostname = ax210
uname -m = 00CD11A44C00
uname -r = 3
uname -s = AIX
uname -v = 5

/usr/bin/uname -p = powerpc
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = 5.3.0.0
/bin/universe          = unknown

PATH: /usr/vac/bin
PATH: /usr/vacpp/bin
PATH: /usr/local/bin
PATH: /bin
PATH: /usr/bin
PATH: /usr/ccs/bin
PATH: /opt/freeware/bin

bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2

[Glenn Morris]

Gilles Pion wrote:

> sysdep.c: In function 'init_signals':
> sysdep.c:1940:34: error: 'deliver_danger_signal' undeclared (first use in
> this function)
[...]
> Have bee able to fix by adding declaration of "deliver_danger_signal"
> in  sysdep.c:
>
>   void deliver_danger_signal (int sig);

Or maybe just move handle_danger_signal and deliver_danger_signal
entirely from emacs.c to sysdep.c? That's the only file that uses them,
and eg handle_fatal_signal/deliver_fatal_signal are already there.

> /fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -c  -Demacs  -I.
> -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src -I../lib
> -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src/../lib
>     -MMD -MF deps/eval.d -MP     -O2 -I/opt/freeware/include eval.c
> eval.c: In function 'mark_backtrace':
> eval.c:3380:20: error: invalid type argument of unary '*' (have
> 'Lisp_Object')

Does anyone see what the problem is here?

bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 11 Jan 2013 01:26:15 -0500
> Cc: 13408@debbugs.gnu.org
> 
> > /fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -c  -Demacs  -I.
> > -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src -I../lib
> > -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src/../lib
> >     -MMD -MF deps/eval.d -MP     -O2 -I/opt/freeware/include eval.c
> > eval.c: In function 'mark_backtrace':
> > eval.c:3380:20: error: invalid type argument of unary '*' (have
> > 'Lisp_Object')
> 
> Does anyone see what the problem is here?

This is the code in question, with line 3380 the last one:

  void
  mark_backtrace (void)
  {
    register struct backtrace *backlist;
    ptrdiff_t i;

    for (backlist = backtrace_list; backlist; backlist = backlist->next)
      {
	mark_object (*backlist->function);

Shouldn't it be

	mark_object (backlist->function);

instead?

bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2

[Paul Eggert]

Glenn's suggestion for moving handle_danger_signal and deliver_danger_signal
seems good, so I installed a patch to do that, as emacs-24 bzr 111170.

The other problem is due to a stray '*'.  This was fixed a while ago
in the trunk, so I backported that to emacs-24 as bzr 111171.

I'll be optimistic and close the bug as fixed; if I'm wrong I'll
reopen it.

Here are the URLs for these two fixes.

http://bzr.savannah.gnu.org/lh/emacs/emacs-24/revision/111170

http://bzr.savannah.gnu.org/lh/emacs/emacs-24/revision/111171

bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2

[Eli Zaretskii]

> Date: Fri, 11 Jan 2013 00:03:39 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> The other problem is due to a stray '*'.  This was fixed a while ago
> in the trunk, so I backported that to emacs-24 as bzr 111171.

Do you happen to know what did GCC make out that, before the change?
Did it just ignore the dereference?

bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2

[Paul Eggert]

On 01/11/2013 01:15 AM, Eli Zaretskii wrote:
>> Date: Fri, 11 Jan 2013 00:03:39 -0800
>> > From: Paul Eggert <eggert@cs.ucla.edu>
>> > 
>> > The other problem is due to a stray '*'.  This was fixed a while ago
>> > in the trunk, so I backported that to emacs-24 as bzr 111171.
> Do you happen to know what did GCC make out that, before the change?
> Did it just ignore the dereference?

No, GCC consistently refused to compile it.  It's just that
this code is rarely compiled -- it's normally ifdeffed out,
so GCC doesn't see the problem.  I suppose that on AIX the
code is not ifdeffed out, so that's why the bug was reported
for AIX.

In older Emacs versions, the types were different and the
"*" was OK; it became a stray "*" only fairly recently.

conservative stack scanning (was: Re: bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2)

[Stefan Monnier]

> No, GCC consistently refused to compile it.  It's just that
> this code is rarely compiled -- it's normally ifdeffed out,
> so GCC doesn't see the problem.  I suppose that on AIX the
> code is not ifdeffed out, so that's why the bug was reported
> for AIX.

Ah, that's where the AIX-dependence comes from!
Shouldn't we just enable conservative stack scanning for
all architectures?  AFAIK, the only systems where we don't use it are
systems where we don't know whether we can use it, rather than systems
where we know we can't use it.


        Stefan

Re: conservative stack scanning

[Paul Eggert]

On 01/11/2013 11:51 AM, Stefan Monnier wrote:
> Shouldn't we just enable conservative stack scanning for
> all architectures?

Yes, we should give it a try.  If it doesn't work we can revert.
If it does work, we can simplify Emacs and this will help prevent
future bugs like Bug#13408.

Here's a proposed patch.

=== modified file 'ChangeLog'
--- ChangeLog	2013-01-11 23:28:04 +0000
+++ ChangeLog	2013-01-12 01:49:51 +0000
@@ -1,3 +1,10 @@
+2013-01-12  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Enable conservative stack scanning for all architectures.
+	Suggested by Stefan Monnier in
+	<http://lists.gnu.org/archive/html/emacs-devel/2013-01/msg00183.html>.
+	* configure.ac (GC_MARK_STACK): Remove.
+
 2013-01-11  Paul Eggert  <eggert@cs.ucla.edu>
 
 	* lib/getopt_.h: Remove trailing CRs that crept in.

=== modified file 'configure.ac'
--- configure.ac	2013-01-10 03:43:02 +0000
+++ configure.ac	2013-01-12 01:49:51 +0000
@@ -3777,22 +3777,13 @@
 esac
 
 
-dnl These won't be used automatically yet.  We also need to know, at least,
+dnl This won't be used automatically yet.  We also need to know, at least,
 dnl that the stack is continuous.
 AH_TEMPLATE(GC_SETJMP_WORKS, [Define if setjmp is known to save all
   registers relevant for conservative garbage collection in the jmp_buf.])
 
-AH_TEMPLATE(GC_MARK_STACK, [Define to GC_USE_GCPROS_AS_BEFORE if
-  conservative garbage collection is not known to work.])
-
 
 case $opsys in
-  aix4-2 | hpux* | unixware)
-    dnl Conservative garbage collection has not been tested, so for now
-    dnl play it safe and stick with the old-fashioned way of marking.
-    AC_DEFINE(GC_MARK_STACK, [GC_USE_GCPROS_AS_BEFORE])
-    ;;
-
   dnl Not all the architectures are tested, but there are Debian packages
   dnl for SCM and/or Guile on them, so the technique must work.  See also
   dnl comments in alloc.c concerning setjmp and gcc.
@@ -3807,8 +3798,7 @@
 #else
 # error "setjmp not known to work on this arch"
 #endif
-    ]], [[]])], AC_DEFINE(GC_SETJMP_WORKS, 1),
-      AC_DEFINE(GC_MARK_STACK, [GC_USE_GCPROS_AS_BEFORE]) )
+    ]], [[]])], AC_DEFINE(GC_SETJMP_WORKS, 1))
     ;;
 esac
 

=== modified file 'src/lisp.h'
--- src/lisp.h	2013-01-11 13:25:10 +0000
+++ src/lisp.h	2013-01-12 01:49:51 +0000
@@ -2217,7 +2217,14 @@
    2    Mark the stack, and check that everything GCPRO'd is
 	marked.
    3	Mark using GCPRO's, mark stack last, and count how many
-	dead objects are kept alive.  */
+	dead objects are kept alive.
+
+   Formerly, method 0 was used.  Currently, method 1 is used unless
+   specified by hand when building, e.g.,
+   "make CPPFLAGS='-DGC_MARK_STACK=GC_USE_GCPROS_AS_BEFORE'".
+   Methods 2 and 3 are present mainly to debug the transition from 0 to 1.
+   At some point we should simplify Emacs by removing support
+   for all methods other than method 1.  */
 
 
 #define GC_USE_GCPROS_AS_BEFORE		0

Broken !GC_MARK_STACK [Re: conservative stack scanning]

[Dmitry Antipov]

On 01/12/2013 05:51 AM, Paul Eggert wrote:

> On 01/11/2013 11:51 AM, Stefan Monnier wrote:
>> Shouldn't we just enable conservative stack scanning for
>> all architectures?
>
> Yes, we should give it a try.  If it doesn't work we can revert.
> If it does work, we can simplify Emacs and this will help prevent
> future bugs like Bug#13408.

Argh, current trunk is broken with !GC_MARK_STACK anyway:

1) I don't know why this isn't in the trunk:
    http://lists.gnu.org/archive/html/emacs-devel/2011-11/txtjY_VzSBijo.txt

2) My stuff from commit 111073 breaks !GC_MARK_STACK because Lisp_Objects
    referenced from Lisp_Misc_Save_Value are marked only if GC_MARK_STACK :-(.

Dmitry

Re: Broken !GC_MARK_STACK [Re: conservative stack scanning]

[Paul Eggert]

On 01/11/2013 06:15 PM, Dmitry Antipov wrote:

> Argh, current trunk is broken with !GC_MARK_STACK anyway:
> 
> 1) I don't know why this isn't in the trunk:
>    http://lists.gnu.org/archive/html/emacs-devel/2011-11/txtjY_VzSBijo.txt

I just now pushed that into the trunk, 
as bzr 111497.

> 2) My stuff from commit 111073 breaks !GC_MARK_STACK because Lisp_Objects
>    referenced from Lisp_Misc_Save_Value are marked only if GC_MARK_STACK :-(.

Is that something you can fix easily?

Re: Broken !GC_MARK_STACK [Re: conservative stack scanning]

[Dmitry Antipov]

On 01/12/2013 10:19 AM, Paul Eggert wrote:

> On 01/11/2013 06:15 PM, Dmitry Antipov wrote:
>
>> 1) I don't know why this isn't in the trunk:
>>     http://lists.gnu.org/archive/html/emacs-devel/2011-11/txtjY_VzSBijo.txt
>
> I just now pushed that into the trunk,
> as bzr 111497.

OK, thanks.

>
>> 2) My stuff from commit 111073 breaks !GC_MARK_STACK because Lisp_Objects
>>     referenced from Lisp_Misc_Save_Value are marked only if GC_MARK_STACK :-(.
>
> Is that something you can fix easily?

Hm... not so easy, but this is bzr 111518.

Dmitry

Re: conservative stack scanning

[Stefan Monnier]

> Yes, we should give it a try.  If it doesn't work we can revert.
> If it does work, we can simplify Emacs and this will help prevent
> future bugs like Bug#13408.
> Here's a proposed patch.

Looks OK.

> +   At some point we should simplify Emacs by removing support
> +   for all methods other than method 1.  */

There's no point including such speculation in there.


        Stefan

Re: conservative stack scanning

[Paul Eggert]

On 01/11/2013 08:23 PM, Stefan Monnier wrote:
> There's no point including such speculation in there.

OK, thanks, I removed the speculation and installed
that into the trunk as bzr 111496.