* bug#10749: 24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf @ 2012-02-06 23:40 Peter Dyballa 2012-02-09 9:39 ` Peter Dyballa ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Peter Dyballa @ 2012-02-06 23:40 UTC (permalink / raw To: 10749 Hello! The error is this: Loading cus-start (source)... Loading international/mule (source)... Loading international/mule-conf (source)... Wrong type argument: listp, "DEAD" make[2]: *** [bootstrap-emacs] Error 1 It happens when I try to build the NS and the X11 variants. On Mac OS X 10.6.8 all goes well... (with another compiler version and intel hardware) I made distclean, bootstrap, and of course I configured between the makes. Every time it ends with the same messages. -- Greetings Pete Specifications are for the weak and timid! ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: 24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf 2012-02-06 23:40 bug#10749: 24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf Peter Dyballa @ 2012-02-09 9:39 ` Peter Dyballa 2012-02-09 21:50 ` Peter Dyballa 2012-02-15 7:24 ` bug#10749: 24.0.93 fails to build with 'Invalid function: "DEAD"' Paul Eggert [not found] ` <handler.10749.B.132860743020881.ack@debbugs.gnu.org> 2 siblings, 1 reply; 15+ messages in thread From: Peter Dyballa @ 2012-02-09 9:39 UTC (permalink / raw To: 10749 Hello! This seems to be a compiler issue. On Mac OS X 10.5.8, Leopard, I could reproduce the same with GCC 4.2. When I reduced optimisation from -fast (Apple convenience setting) to -O0 and -O1 all went fine. I'm going to increase the level of optimisation and see the result. Maybe there is some interference between the wide ints introduced, the merely 32-bit PPC architecture (PowerPC 7447A, "G4") and the -fast option which was introduced for the "G5", the IBM PowerPC 970, complete 64-bit architecture. -- Greetings Pete They're putting dimes in the hole in my head to see the change in me. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: 24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf 2012-02-09 9:39 ` Peter Dyballa @ 2012-02-09 21:50 ` Peter Dyballa 2012-02-09 23:45 ` Peter Dyballa 0 siblings, 1 reply; 15+ messages in thread From: Peter Dyballa @ 2012-02-09 21:50 UTC (permalink / raw To: 10749 This really looks like a compiler issue. Using -O[0-4s] all goes fine, but using -fast leads to errors. My last try was with: time nice +11 env LANG=C PATH=/sw/bin:$PATH ./configure --without- sound --without-dbus --without-pop --without-gconf --without-gpm -- without-gsettings --without-selinux --without-gif --without-jpeg -- without-png --without-rsvg --without-tiff --without-xpm --with-ns -- disable-ns-self-contained --x-libraries=/usr/X11/lib --x-includes=/usr/ X11/include --enable-locallisppath=/Library/Application\ Support/Emacs/ calendar24:/Library/Application\ Support/Emacs CFLAGS="-g -H -pipe - fPIC -fno-common -fast -pthread -mfused-madd -mmultiple -ftree- vectorize -mpowerpc-gfxopt -maltivec -faltivec -mabi=altivec - mcpu=7450 -mtune=G4" LDFLAGS="-Wl,-dead_strip_dylibs -Wl,-bind_at_load -Wl,-t" CPP=cpp-4.2 CC=gcc-4.2 CXX=g++-4.2 PKG_CONFIG_PATH=/sw/lib/ xft2/lib/pkgconfig:/sw/share/pkgconfig:/sw/lib/pkgconfig:/usr/X11/lib/ pkgconfig:/usr/X11/share/pkgconfig:/usr/lib/pkgconfig No wide-ints set up, even using the official "-mtune=G4" to overcome the G5 optimisation. It leads to: Loading window (source)... Loading .../emacs-24.0.93/lisp/files.el (source)... Recursive load: ".../emacs-24.0.93/lisp/emacs-lisp/cl-macs.el", ".../ emacs-24.0.93/lisp/emacs-lisp/cl-macs.el", ".../emacs-24.0.93/lisp/ emacs-lisp/cl-macs.el", ".../emacs-24.0.93/lisp/emacs-lisp/cl- macs.el", ".../emacs-24.0.93/lisp/emacs-lisp/cl-macs.el", ".../ emacs-24.0.93/lisp/files.el", ".../emacs-24.0.93/lisp/loadup.el" make[2]: *** [bootstrap-emacs] Error 1 I'll see whether an X11 variant works better. -- Greetings Pete ~ o ~_\\_/\ ~ O O ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: 24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf 2012-02-09 21:50 ` Peter Dyballa @ 2012-02-09 23:45 ` Peter Dyballa 0 siblings, 0 replies; 15+ messages in thread From: Peter Dyballa @ 2012-02-09 23:45 UTC (permalink / raw To: 10749 It is the -fast option. When I use it the X11 variant cannot be built. -- Greetings Pete Never be led astray onto the path of virtue ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-06 23:40 bug#10749: 24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf Peter Dyballa 2012-02-09 9:39 ` Peter Dyballa @ 2012-02-15 7:24 ` Paul Eggert 2012-02-15 7:39 ` Dan Horák [not found] ` <handler.10749.B.132860743020881.ack@debbugs.gnu.org> 2 siblings, 1 reply; 15+ messages in thread From: Paul Eggert @ 2012-02-15 7:24 UTC (permalink / raw To: Dan Horák; +Cc: 10780, 10749 I can't reproduce the problem on my bigendian 32-bit host (Solaris 10, 32-bit sparc, Sun C 5.12 2011/11/16), so the problem can't be just the 32-bit bigendianness. The symptoms are those of a failure during conservative garbage collection, and my suspicion is that the conservative marking isn't picking up some register that's hiding in a setjmp buffer or whatnot. Suppose you do a "make clean" and then "make CPPFLAGS=-DGC_LISP_OBJECT_ALIGNMENT=2" and/or "make CPPFLAGS=-DGC_LISP_OBJECT_ALIGNMENT=1". Does that work around the problem? Likewise, suppose you do a "make clean" and then rebuild with compiler optimization disabled. Does that work around the problem? I'll CC: this to bug 10749, since GC_LISP_OBJECT_ALIGNMENT=1 may work around its problems too. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-15 7:24 ` bug#10749: 24.0.93 fails to build with 'Invalid function: "DEAD"' Paul Eggert @ 2012-02-15 7:39 ` Dan Horák 2012-02-15 8:14 ` Paul Eggert 2012-02-15 9:15 ` Paul Eggert 0 siblings, 2 replies; 15+ messages in thread From: Dan Horák @ 2012-02-15 7:39 UTC (permalink / raw To: Paul Eggert; +Cc: 10780, 10749 Paul Eggert píše v Út 14. 02. 2012 v 23:24 -0800: > I can't reproduce the problem on my bigendian 32-bit host > (Solaris 10, 32-bit sparc, Sun C 5.12 2011/11/16), > so the problem can't be just the 32-bit bigendianness. > > The symptoms are those of a failure during conservative > garbage collection, and my suspicion is that the > conservative marking isn't picking up some register that's > hiding in a setjmp buffer or whatnot. > > Suppose you do a "make clean" and then > "make CPPFLAGS=-DGC_LISP_OBJECT_ALIGNMENT=2" and/or > "make CPPFLAGS=-DGC_LISP_OBJECT_ALIGNMENT=1". > Does that work around the problem? > > Likewise, suppose you do a "make clean" > and then rebuild with compiler optimization disabled. > Does that work around the problem? > > I'll CC: this to bug 10749, since GC_LISP_OBJECT_ALIGNMENT=1 > may work around its problems too. I have to do some more testing but now it seems that using --with-wide-int option for configure provokes the "Invalid function" behaviour. When the option is not given, the build is successful, when given, then I see a segfault in the non-bootstrap build. Dan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-15 7:39 ` Dan Horák @ 2012-02-15 8:14 ` Paul Eggert 2012-02-15 9:55 ` bug#10749: bug#10780: " Andreas Schwab 2012-02-15 9:15 ` Paul Eggert 1 sibling, 1 reply; 15+ messages in thread From: Paul Eggert @ 2012-02-15 8:14 UTC (permalink / raw To: Dan Horák; +Cc: 10780, 10749 On 02/14/2012 11:39 PM, Dan Horák wrote: > I have to do some more testing but now it seems that using > --with-wide-int option for configure provokes the "Invalid function" > behaviour. In that case the bug is probably distinct from Bug#10749, as 10749 occurs without wide ints. I'll drop 10749 from the CC: list before replying further. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: bug#10780: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-15 8:14 ` Paul Eggert @ 2012-02-15 9:55 ` Andreas Schwab 0 siblings, 0 replies; 15+ messages in thread From: Andreas Schwab @ 2012-02-15 9:55 UTC (permalink / raw To: Paul Eggert; +Cc: Dan Horák, 10780, 10749 I see a similar crash when building with wide ints on ppc-linux, where a string contains a null data pointer. Something is definitely broken with wide ints and gc marking. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10780: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-15 7:39 ` Dan Horák 2012-02-15 8:14 ` Paul Eggert @ 2012-02-15 9:15 ` Paul Eggert 2012-02-15 10:09 ` Andreas Schwab 2012-02-15 16:38 ` bug#10780: " Dan Horák 1 sibling, 2 replies; 15+ messages in thread From: Paul Eggert @ 2012-02-15 9:15 UTC (permalink / raw To: Dan Horák; +Cc: 10780 On 02/14/2012 11:39 PM, Dan Horák wrote: > I have to do some more testing but now it seems that using > --with-wide-int option for configure provokes the "Invalid function" > behaviour. Thanks for looking into it. I configured --with-wide-int on my bigendian 32-bit host and could not reproduce the problem. My host is a Solaris 10 sparc (32-bit). I tried with both Sun C 5.12 SunOS_sparc 2011/11/16 (cc -xO4) and with GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath) (gcc -O2). Since you built --with-wide-int, can you please also try compiling from scratch, with "make CPPFLAGS=-DGC_LISP_OBJECT_ALIGNMENT=4"? It could be that your compilers claim to be aligning 64-bit integers on 8-byte boundaries, but are occasionally actually aligning them on 4-byte boundaries. This messes up conservative garbage collection big-time and would explain your symptoms. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10780: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-15 9:15 ` Paul Eggert @ 2012-02-15 10:09 ` Andreas Schwab 2012-02-20 23:14 ` Paul Eggert 2012-02-15 16:38 ` bug#10780: " Dan Horák 1 sibling, 1 reply; 15+ messages in thread From: Andreas Schwab @ 2012-02-15 10:09 UTC (permalink / raw To: Paul Eggert; +Cc: Dan Horák, 10780 Paul Eggert <eggert@cs.ucla.edu> writes: > It could be that your compilers claim to be aligning 64-bit > integers on 8-byte boundaries, but are occasionally actually > aligning them on 4-byte boundaries. This messes up conservative > garbage collection big-time and would explain your symptoms. What about local variables in registers? They are split between two registers, but mark_stack does not handle that. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10780: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-15 10:09 ` Andreas Schwab @ 2012-02-20 23:14 ` Paul Eggert 2012-02-21 9:32 ` Dan Horák 0 siblings, 1 reply; 15+ messages in thread From: Paul Eggert @ 2012-02-20 23:14 UTC (permalink / raw To: Dan Horák; +Cc: 10780, Andreas Schwab On 02/15/2012 02:09 AM, Andreas Schwab wrote: > What about local variables in registers? They are split between two > registers, but mark_stack does not handle that. True. Teerrroooo. Thanks for diagnosing that. I pushed the following fix into the trunk. It's needed regardless of this particular bug. Dan, can you please check whether it indeed fixes the bug for you? Thanks. Fix crash due to non-contiguous EMACS_INT (Bug#10780). * lisp.h (VALBITS): Move definition up, so that USE_LSB_TAG can use it. (USE_LSB_TAG): Do not define if UINTPTR_MAX >> VALBITS == 0. It's useless in that case, and it can cause problems on hosts that allocate halves of EMACS_INT values separately. Reported by Dan Horák. Diagnosed by Andreas Schwab in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10780#30>. * mem-limits.h (EXCEEDS_LISP_PTR): Define to 0 on hosts where UINTPTR_MAX >> VALBITS == 0. This is required by the above change; it avoids undefined behavior on hosts where shifting right by more than the word width has undefined behavior. === modified file 'src/lisp.h' --- src/lisp.h 2012-01-19 07:21:25 +0000 +++ src/lisp.h 2012-02-20 16:27:49 +0000 @@ -168,6 +168,10 @@ #define GCTYPEBITS 3 #endif +#ifndef VALBITS +#define VALBITS (BITS_PER_EMACS_INT - GCTYPEBITS) +#endif + #ifndef NO_DECL_ALIGN # ifndef DECL_ALIGN # if HAVE_ATTRIBUTE_ALIGNED @@ -191,7 +195,15 @@ || defined DARWIN_OS || defined __sun) /* We also need to be able to specify mult-of-8 alignment on static vars. */ # if defined DECL_ALIGN -# define USE_LSB_TAG +/* mark_maybe_object assumes that EMACS_INT values are contiguous, + but this is not true on some hosts where EMACS_INT is wider than a pointer, + as they may allocate the halves of an EMACS_INT separately. + On these hosts USE_LSB_TAG is not needed because the top bits of an + EMACS_INT are unused, so define USE_LSB_TAG only on hosts where it + might be useful. */ +# if UINTPTR_MAX >> VALBITS != 0 +# define USE_LSB_TAG +# endif # endif #endif @@ -309,11 +321,6 @@ Lisp_Fwd_Kboard_Obj, /* Fwd to a Lisp_Object field of kboards. */ }; -/* These values are overridden by the m- file on some machines. */ -#ifndef VALBITS -#define VALBITS (BITS_PER_EMACS_INT - GCTYPEBITS) -#endif - #ifdef USE_LISP_UNION_TYPE #ifndef WORDS_BIGENDIAN === modified file 'src/mem-limits.h' --- src/mem-limits.h 2012-01-19 07:21:25 +0000 +++ src/mem-limits.h 2012-02-20 22:53:46 +0000 @@ -34,7 +34,7 @@ #endif extern char *start_of_data (void); -#if defined USE_LSB_TAG +#if defined USE_LSB_TAG || UINTPTR_MAX >> VALBITS == 0 #define EXCEEDS_LISP_PTR(ptr) 0 #elif defined DATA_SEG_BITS #define EXCEEDS_LISP_PTR(ptr) \ ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10780: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-20 23:14 ` Paul Eggert @ 2012-02-21 9:32 ` Dan Horák 2012-02-21 23:37 ` bug#10749: " Paul Eggert 0 siblings, 1 reply; 15+ messages in thread From: Dan Horák @ 2012-02-21 9:32 UTC (permalink / raw To: Paul Eggert; +Cc: 10780, Andreas Schwab Paul Eggert píše v Po 20. 02. 2012 v 15:14 -0800: > On 02/15/2012 02:09 AM, Andreas Schwab wrote: > > > What about local variables in registers? They are split between two > > registers, but mark_stack does not handle that. > > True. Teerrroooo. Thanks for diagnosing that. > > I pushed the following fix into the trunk. It's needed > regardless of this particular bug. Dan, can you please > check whether it indeed fixes the bug for you? Thanks. yes, this change fixed the issue for me. Thanks to all involved. > > Fix crash due to non-contiguous EMACS_INT (Bug#10780). > * lisp.h (VALBITS): Move definition up, so that USE_LSB_TAG can use it. > (USE_LSB_TAG): Do not define if UINTPTR_MAX >> VALBITS == 0. > It's useless in that case, and it can cause problems on hosts > that allocate halves of EMACS_INT values separately. > Reported by Dan Horák. Diagnosed by Andreas Schwab in > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10780#30>. > * mem-limits.h (EXCEEDS_LISP_PTR): Define to 0 on hosts where > UINTPTR_MAX >> VALBITS == 0. This is required by the above change; > it avoids undefined behavior on hosts where shifting right by more > than the word width has undefined behavior. > === modified file 'src/lisp.h' > --- src/lisp.h 2012-01-19 07:21:25 +0000 > +++ src/lisp.h 2012-02-20 16:27:49 +0000 > @@ -168,6 +168,10 @@ > #define GCTYPEBITS 3 > #endif > > +#ifndef VALBITS > +#define VALBITS (BITS_PER_EMACS_INT - GCTYPEBITS) > +#endif > + > #ifndef NO_DECL_ALIGN > # ifndef DECL_ALIGN > # if HAVE_ATTRIBUTE_ALIGNED > @@ -191,7 +195,15 @@ > || defined DARWIN_OS || defined __sun) > /* We also need to be able to specify mult-of-8 alignment on static vars. */ > # if defined DECL_ALIGN > -# define USE_LSB_TAG > +/* mark_maybe_object assumes that EMACS_INT values are contiguous, > + but this is not true on some hosts where EMACS_INT is wider than a pointer, > + as they may allocate the halves of an EMACS_INT separately. > + On these hosts USE_LSB_TAG is not needed because the top bits of an > + EMACS_INT are unused, so define USE_LSB_TAG only on hosts where it > + might be useful. */ > +# if UINTPTR_MAX >> VALBITS != 0 > +# define USE_LSB_TAG > +# endif > # endif > #endif > > @@ -309,11 +321,6 @@ > Lisp_Fwd_Kboard_Obj, /* Fwd to a Lisp_Object field of kboards. */ > }; > > -/* These values are overridden by the m- file on some machines. */ > -#ifndef VALBITS > -#define VALBITS (BITS_PER_EMACS_INT - GCTYPEBITS) > -#endif > - > #ifdef USE_LISP_UNION_TYPE > > #ifndef WORDS_BIGENDIAN > > === modified file 'src/mem-limits.h' > --- src/mem-limits.h 2012-01-19 07:21:25 +0000 > +++ src/mem-limits.h 2012-02-20 22:53:46 +0000 > @@ -34,7 +34,7 @@ > #endif > > extern char *start_of_data (void); > -#if defined USE_LSB_TAG > +#if defined USE_LSB_TAG || UINTPTR_MAX >> VALBITS == 0 > #define EXCEEDS_LISP_PTR(ptr) 0 > #elif defined DATA_SEG_BITS > #define EXCEEDS_LISP_PTR(ptr) \ > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10749: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-21 9:32 ` Dan Horák @ 2012-02-21 23:37 ` Paul Eggert 0 siblings, 0 replies; 15+ messages in thread From: Paul Eggert @ 2012-02-21 23:37 UTC (permalink / raw To: Dan Horák; +Cc: 10780-done, 10749 On 02/21/2012 01:32 AM, Dan Horák wrote: > this change fixed the issue for me. Great! Thanks for checking. I'm marking 10780 as "done". I'm leaving 10749 open, as it occurs without wide ints <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10749#11> and is almost surely a different bug. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#10780: 24.0.93 fails to build with 'Invalid function: "DEAD"' 2012-02-15 9:15 ` Paul Eggert 2012-02-15 10:09 ` Andreas Schwab @ 2012-02-15 16:38 ` Dan Horák 1 sibling, 0 replies; 15+ messages in thread From: Dan Horák @ 2012-02-15 16:38 UTC (permalink / raw To: Paul Eggert; +Cc: 10780 Paul Eggert píše v St 15. 02. 2012 v 01:15 -0800: > On 02/14/2012 11:39 PM, Dan Horák wrote: > > I have to do some more testing but now it seems that using > > --with-wide-int option for configure provokes the "Invalid function" > > behaviour. > > Thanks for looking into it. I configured --with-wide-int on > my bigendian 32-bit host and could not reproduce the problem. > My host is a Solaris 10 sparc (32-bit). I tried with both > Sun C 5.12 SunOS_sparc 2011/11/16 (cc -xO4) and with > GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath) (gcc -O2). > > Since you built --with-wide-int, can you please also try > compiling from scratch, with > "make CPPFLAGS=-DGC_LISP_OBJECT_ALIGNMENT=4"? > It could be that your compilers claim to be aligning 64-bit > integers on 8-byte boundaries, but are occasionally actually > aligning them on 4-byte boundaries. This messes up conservative > garbage collection big-time and would explain your symptoms. The builds (on s390, haven't tried ppc yet) were successful with GC_LISP_OBJECT_ALIGNMENT set to 1, 2 and 4. Only when it's not set, the build fails with the "Invalid function" error message. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <handler.10749.B.132860743020881.ack@debbugs.gnu.org>]
* bug#10749: Acknowledgement (24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf) [not found] ` <handler.10749.B.132860743020881.ack@debbugs.gnu.org> @ 2012-04-16 20:24 ` Peter Dyballa 0 siblings, 0 replies; 15+ messages in thread From: Peter Dyballa @ 2012-04-16 20:24 UTC (permalink / raw To: 10749 This bug report was somehow resolved. -- Greetings Pete In a world without walls and fences, who needs gates and windows? ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-04-16 20:24 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-06 23:40 bug#10749: 24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf Peter Dyballa 2012-02-09 9:39 ` Peter Dyballa 2012-02-09 21:50 ` Peter Dyballa 2012-02-09 23:45 ` Peter Dyballa 2012-02-15 7:24 ` bug#10749: 24.0.93 fails to build with 'Invalid function: "DEAD"' Paul Eggert 2012-02-15 7:39 ` Dan Horák 2012-02-15 8:14 ` Paul Eggert 2012-02-15 9:55 ` bug#10749: bug#10780: " Andreas Schwab 2012-02-15 9:15 ` Paul Eggert 2012-02-15 10:09 ` Andreas Schwab 2012-02-20 23:14 ` Paul Eggert 2012-02-21 9:32 ` Dan Horák 2012-02-21 23:37 ` bug#10749: " Paul Eggert 2012-02-15 16:38 ` bug#10780: " Dan Horák [not found] ` <handler.10749.B.132860743020881.ack@debbugs.gnu.org> 2012-04-16 20:24 ` bug#10749: Acknowledgement (24.0.93; does not compile on Mac OS X 10.4.11/PPC in international/mule-conf) Peter Dyballa
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.