Steve Youngs <steve(a)sxemacs.org&gt; writes: > Sorry, haven't checked 21.5, but I'd imagine this is needed there > too. > > 21.4 patch: > ChangeLog files diff command: cvs -q diff -U 0 > Files affected: src/ChangeLog > Source files diff command: cvs -q diff -uN > Files affected: src/emacs.c > > Index: src/ChangeLog > =================================================================== > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v > retrieving revision 1.290.2.83 > diff -u -U0 -r1.290.2.83 ChangeLog > --- src/ChangeLog 11 Jan 2005 02:02:11 -0000 1.290.2.83 > +++ src/ChangeLog 12 Jan 2005 01:11:36 -0000 > ＠＠ -0,0 +1,7 ＠＠ > +2005-01-12 Steve Youngs <steve(a)sxemacs.org&gt; > + > + From Evgeny Zajcev <lg(a)sxemacs.org&gt;: > + > + * emacs.c (debug_can_access_memory): Fix problem of "clever" > + compilers being over-zealous in their optimising. > + > Index: src/emacs.c > =================================================================== > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/emacs.c,v > retrieving revision 1.97.2.8 > diff -u -u -r1.97.2.8 emacs.c > --- src/emacs.c 13 Jun 2004 20:19:39 -0000 1.97.2.8 > +++ src/emacs.c 12 Jan 2005 01:10:26 -0000 > ＠＠ -535,15 +535,13 ＠＠ > old_sigsegv = > (SIGTYPE (*) (int)) signal (SIGSEGV, debug_memory_error); > > - if (len > 1) > - /* If we can, try to avoid problems with super-optimizing compilers > - that might decide that memcmp (ptr, ptr, len) can be optimized > - away since its result is always 1. */ > - memcmp (ptr, (char *) ptr + 1, len - 1); > - else > - memcmp (ptr, ptr, len); > - } > - else > + /* Examine memory pool at PTR */ > + while (len-- > 0) { > + char a = ((char*)ptr)[len]; > + if (a == '1') > + /* pass */; > + } > + } else > retval = 0; > signal (SIGBUS, old_sigbus); > signal (SIGSEGV, old_sigsegv); > Do you have a test case?

Steve Youngs <steve(a)sxemacs.org&gt; writes: > Sorry, haven't checked 21.5, but I'd imagine this is needed there > too. > > 21.4 patch: > ChangeLog files diff command: cvs -q diff -U 0 > Files affected: src/ChangeLog > Source files diff command: cvs -q diff -uN > Files affected: src/emacs.c > > Index: src/ChangeLog > =================================================================== > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v > retrieving revision 1.290.2.83 > diff -u -U0 -r1.290.2.83 ChangeLog > --- src/ChangeLog 11 Jan 2005 02:02:11 -0000 1.290.2.83 > +++ src/ChangeLog 12 Jan 2005 01:11:36 -0000 > ＠＠ -0,0 +1,7 ＠＠ > +2005-01-12 Steve Youngs <steve(a)sxemacs.org&gt; > + > + From Evgeny Zajcev <lg(a)sxemacs.org&gt;: > + > + * emacs.c (debug_can_access_memory): Fix problem of "clever" > + compilers being over-zealous in their optimising. > + > Index: src/emacs.c > =================================================================== > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/emacs.c,v > retrieving revision 1.97.2.8 > diff -u -u -r1.97.2.8 emacs.c > --- src/emacs.c 13 Jun 2004 20:19:39 -0000 1.97.2.8 > +++ src/emacs.c 12 Jan 2005 01:10:26 -0000 > ＠＠ -535,15 +535,13 ＠＠ > old_sigsegv = > (SIGTYPE (*) (int)) signal (SIGSEGV, debug_memory_error); > > - if (len > 1) > - /* If we can, try to avoid problems with super-optimizing compilers > - that might decide that memcmp (ptr, ptr, len) can be optimized > - away since its result is always 1. */ > - memcmp (ptr, (char *) ptr + 1, len - 1); > - else > - memcmp (ptr, ptr, len); > - } > - else > + /* Examine memory pool at PTR */ > + while (len-- > 0) { > + char a = ((char*)ptr)[len]; > + if (a == '1') > + /* pass */; > + } > + } else > retval = 0; > signal (SIGBUS, old_sigbus); > signal (SIGSEGV, old_sigsegv); This patch should look like this (to work with gcc295 and gcc342): Index: src/ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v retrieving revision 1.290.2.83 diff -u -U0 -r1.290.2.83 ChangeLog --- src/ChangeLog 11 Jan 2005 02:02:11 -0000 1.290.2.83 +++ src/ChangeLog 12 Jan 2005 01:11:36 -0000 ＠＠ -0,0 +1,7 ＠＠ +2005-01-12 Steve Youngs <steve(a)sxemacs.org&gt; + + From Evgeny Zajcev <lg(a)sxemacs.org&gt;: + + * emacs.c (debug_can_access_memory): Fix problem of "clever" + compilers being over-zealous in their optimising. + Index: src/emacs.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.97.2.8 diff -u -u -r1.97.2.8 emacs.c --- src/emacs.c 13 Jun 2004 20:19:39 -0000 1.97.2.8 +++ src/emacs.c 12 Jan 2005 01:10:26 -0000 ＠＠ -535,15 +535,13 ＠＠ old_sigsegv = (SIGTYPE (*) (int)) signal (SIGSEGV, debug_memory_error); - if (len > 1) - /* If we can, try to avoid problems with super-optimizing compilers - that might decide that memcmp (ptr, ptr, len) can be optimized - away since its result is always 1. */ - memcmp (ptr, (char *) ptr + 1, len - 1); - else - memcmp (ptr, ptr, len); - } - else + /* Examine memory pool at PTR */ + while (len-- > 0) { + char a = ((char*)ptr)[len]; + if (a == '1') + ((char*)ptr)[len] = a; + } + } else retval = 0; signal (SIGBUS, old_sigbus); signal (SIGSEGV, old_sigsegv); -- lg

Vin Shelton <acs(a)xemacs.org&gt; wrote: > Thank you, but I agree with Daryl Okahata's assessment if gcc-3.4.2 > with certain aggressive optimizations requires code like this, that's > a bug in the compiler and we should advise users not to use that > compiler with a particular set of options (perhaps on a particular > platform). I have not verified this, but the OP commented that the compiler is buggy even without any optimization flags (even though the subject line implies otherwise). If so, then perhaps configure.in should be modified to disallow building with that compiler.