* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
@ 2013-01-10 17:46 Gilles Pion
2013-01-11 6:26 ` Glenn Morris
2013-01-11 8:03 ` Paul Eggert
0 siblings, 2 replies; 13+ messages in thread
From: Gilles Pion @ 2013-01-10 17:46 UTC (permalink / raw
To: 13408
[-- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-10 17:46 bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2 Gilles Pion
@ 2013-01-11 6:26 ` Glenn Morris
2013-01-11 8:24 ` Eli Zaretskii
2013-01-11 8:03 ` Paul Eggert
1 sibling, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2013-01-11 6:26 UTC (permalink / raw
To: Gilles Pion; +Cc: 13408
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-10 17:46 bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2 Gilles Pion
2013-01-11 6:26 ` Glenn Morris
@ 2013-01-11 8:03 ` Paul Eggert
2013-01-11 9:15 ` Eli Zaretskii
1 sibling, 1 reply; 13+ messages in thread
From: Paul Eggert @ 2013-01-11 8:03 UTC (permalink / raw
To: 13408-done
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-11 6:26 ` Glenn Morris
@ 2013-01-11 8:24 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-01-11 8:24 UTC (permalink / raw
To: Glenn Morris; +Cc: gpion, 13408
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-11 8:03 ` Paul Eggert
@ 2013-01-11 9:15 ` Eli Zaretskii
2013-01-11 19:11 ` Paul Eggert
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-01-11 9:15 UTC (permalink / raw
To: Paul Eggert; +Cc: gpion, 13408
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-11 9:15 ` Eli Zaretskii
@ 2013-01-11 19:11 ` Paul Eggert
2013-01-11 19:51 ` 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
0 siblings, 1 reply; 13+ messages in thread
From: Paul Eggert @ 2013-01-11 19:11 UTC (permalink / raw
To: Eli Zaretskii; +Cc: gpion, 13408
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* conservative stack scanning (was: Re: bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2)
2013-01-11 19:11 ` Paul Eggert
@ 2013-01-11 19:51 ` Stefan Monnier
2013-01-12 1:51 ` conservative stack scanning Paul Eggert
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2013-01-11 19:51 UTC (permalink / raw
To: Paul Eggert; +Cc: gpion, Eli Zaretskii, emacs-devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conservative stack scanning
2013-01-11 19:51 ` 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
@ 2013-01-12 1:51 ` Paul Eggert
2013-01-12 2:15 ` Broken !GC_MARK_STACK [Re: conservative stack scanning] Dmitry Antipov
2013-01-12 4:23 ` conservative stack scanning Stefan Monnier
0 siblings, 2 replies; 13+ messages in thread
From: Paul Eggert @ 2013-01-12 1:51 UTC (permalink / raw
To: Stefan Monnier; +Cc: gpion, Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Broken !GC_MARK_STACK [Re: conservative stack scanning]
2013-01-12 1:51 ` conservative stack scanning Paul Eggert
@ 2013-01-12 2:15 ` Dmitry Antipov
2013-01-12 6:19 ` Paul Eggert
2013-01-12 4:23 ` conservative stack scanning Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: Dmitry Antipov @ 2013-01-12 2:15 UTC (permalink / raw
To: Paul Eggert; +Cc: gpion, Eli Zaretskii, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conservative stack scanning
2013-01-12 1:51 ` conservative stack scanning Paul Eggert
2013-01-12 2:15 ` Broken !GC_MARK_STACK [Re: conservative stack scanning] Dmitry Antipov
@ 2013-01-12 4:23 ` Stefan Monnier
2013-01-12 5:22 ` Paul Eggert
1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2013-01-12 4:23 UTC (permalink / raw
To: Paul Eggert; +Cc: gpion, Eli Zaretskii, emacs-devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: conservative stack scanning
2013-01-12 4:23 ` conservative stack scanning Stefan Monnier
@ 2013-01-12 5:22 ` Paul Eggert
0 siblings, 0 replies; 13+ messages in thread
From: Paul Eggert @ 2013-01-12 5:22 UTC (permalink / raw
To: Stefan Monnier; +Cc: gpion, Eli Zaretskii, emacs-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Broken !GC_MARK_STACK [Re: conservative stack scanning]
2013-01-12 2:15 ` Broken !GC_MARK_STACK [Re: conservative stack scanning] Dmitry Antipov
@ 2013-01-12 6:19 ` Paul Eggert
2013-01-14 9:59 ` Dmitry Antipov
0 siblings, 1 reply; 13+ messages in thread
From: Paul Eggert @ 2013-01-12 6:19 UTC (permalink / raw
To: Dmitry Antipov; +Cc: gpion, Eli Zaretskii, Stefan Monnier, emacs-devel
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Broken !GC_MARK_STACK [Re: conservative stack scanning]
2013-01-12 6:19 ` Paul Eggert
@ 2013-01-14 9:59 ` Dmitry Antipov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Antipov @ 2013-01-14 9:59 UTC (permalink / raw
To: Paul Eggert; +Cc: gpion, Eli Zaretskii, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-01-14 9:59 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-10 17:46 bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2 Gilles Pion
2013-01-11 6:26 ` Glenn Morris
2013-01-11 8:24 ` Eli Zaretskii
2013-01-11 8:03 ` Paul Eggert
2013-01-11 9:15 ` Eli Zaretskii
2013-01-11 19:11 ` Paul Eggert
2013-01-11 19:51 ` 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
2013-01-12 1:51 ` conservative stack scanning Paul Eggert
2013-01-12 2:15 ` Broken !GC_MARK_STACK [Re: conservative stack scanning] Dmitry Antipov
2013-01-12 6:19 ` Paul Eggert
2013-01-14 9:59 ` Dmitry Antipov
2013-01-12 4:23 ` conservative stack scanning Stefan Monnier
2013-01-12 5:22 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.