From: "Marshall, Simon" <simon.marshall@misys.com>
Cc: "'emacs-pretesters@gnu.org'" <emacs-pretesters@gnu.org>,
"'emacs-devel@gnu.org'" <emacs-devel@gnu.org>,
"'ebotcazou@gcc.gnu.org'" <ebotcazou@gcc.gnu.org>,
"'ishikawa@yk.rim.or.jp'" <ishikawa@yk.rim.or.jp>
Subject: RE: Anyone built Emacs with gcc-3.3?
Date: Mon, 14 Jul 2003 12:19:12 +0100 [thread overview]
Message-ID: <FC3DA3DC8D4AD311AB910020352A8FDC10755484@eagle.midas-kapiti.com> (raw)
Paul, thanks. I can confirm that Emacs builds OK for me on s8 with
gcc-3.3 with the below Emacs patches plus your unexelf.c patch. (Eric's
patch was not relevant for me anyway as I don't build with Xaw.)
I do get a gripe though:
alloc.c:398: warning: initialization makes pointer from integer without
a cast
due to this change:
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};
Casting 1 with (Lisp_Object *) keeps gcc happy; so does removing the
initialisation. I'll leave someone else to work out the correct way to
deal with this.
Thanks to everyone for sorting this out. Simon.
-----Original Message-----
From: Marshall, Simon
Sent: 11 July 2003 11:38
To: 'Paul Eggert'
Cc: 'ebotcazou@gcc.gnu.org'; 'ishikawa@yk.rim.or.jp'
Subject: RE: Anyone built Emacs with gcc-3.3?
Paul, many thanks. FYI, I put your email on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386, seeing as they have
also looked at it with objdump. Your input may help them and vice
versa.
I hope this can be fixed for 3.3.1, rather than the target 3.3.2.
Simon.
-----Original Message-----
From: Paul Eggert [mailto:eggert@twinsun.com]
Sent: 11 July 2003 10:55
To: rms@gnu.org
Cc: simon.marshall@misys.com; emacs-devel@gnu.org;
emacs-pretesters@gnu.org
Subject: Re: Anyone built Emacs with gcc-3.3?
> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 05 Jul 2003 18:25:56 -0400
>
> The way to debug this is to treat it as an Emacs bug. When you
> find the bug, it will actually be a miscompiled function (if this
> is GCC's fault). Then you can send a useful GCC bug report.
I looked into this a bit, and there seem to be at least two problems.
One is an Emacs portability problem; the rest I don't know yet.
Emacs assumes that a top-level declaration like "int pure[1000] = {0};"
puts "pure" into the data area. However, this assumption is no longer
true with GCC 3.3 on Solaris 8, which notices that "pure" has an
initializer that is all zeros, and puts "pure" into BSS instead.
This is a valid optimization, so I guess Emacs should deal with it.
I checked for all static variables that Emacs 21.3 defines to be zero
in Solaris 8, and which become readonly after dumping with GCC 3.2.3
but not with GCC 3.3, and I came up with the following patch to fix
this portability problem. This fixes part of the bug, but not all;
Emacs still dumps core. I'll see if I can investigate this further if
I find more time but that won't be before this weekend.
2003-07-11 Paul Eggert <eggert@twinsun.com>
GCC 3.3 no longer puts "int foo = 0;" into data; it optimizes
this case and puts it into BSS instead, at least on Solaris 8.
* src/alloc.c (pure, staticvec, staticidx):
Initialize to nonzero, so that it's data.
* src/emacs.c (bss_end): Likewise.
(main): Use bss_end==1 to mean it's unset.
The following changes don't fix any bugs, but they remove
initializations to zero that do not need to be in pure space.
I am including them in this patch (if only to document them).
* src/emacs.c (gdb_data_seg_bits): Do not initialize to zero
explicitly, since it's OK for this to be in BSS.
* src/xfns.c (cursor_bits): Likewise.
* src/xterm.c (Xt_default_resources): Likewise.
diff -pru emacs-21.3/src/alloc.c emacs-21.3-fix/src/alloc.c
--- emacs-21.3/src/alloc.c 2003-01-17 05:45:13.000000000 -0800
+++ emacs-21.3-fix/src/alloc.c 2003-07-11 02:02:37.215626000 -0700
@@ -188,7 +188,7 @@ Lisp_Object Vpurify_flag;
/* Force it into data space! */
-EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {0,};
+EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {1,};
#define PUREBEG (char *) pure
#else /* not HAVE_SHM */
@@ -395,11 +395,11 @@ struct gcpro *gcprolist;
/* Addresses of staticpro'd variables. */
#define NSTATICS 1024
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};
/* Index of next unused slot in staticvec. */
-int staticidx = 0;
+int staticidx = 1;
static POINTER_TYPE *pure_alloc P_ ((size_t, int));
diff -pru emacs-21.3/src/emacs.c emacs-21.3-fix/src/emacs.c
--- emacs-21.3/src/emacs.c 2002-08-29 12:27:07.000000000 -0700
+++ emacs-21.3-fix/src/emacs.c 2003-07-11 01:39:19.348060000 -0700
@@ -86,7 +86,7 @@ EMACS_INT gdb_emacs_intbits = sizeof (EM
#ifdef DATA_SEG_BITS
EMACS_INT gdb_data_seg_bits = DATA_SEG_BITS;
#else
-EMACS_INT gdb_data_seg_bits = 0;
+EMACS_INT gdb_data_seg_bits /* = 0 */;
#endif
EMACS_INT PVEC_FLAG = PSEUDOVECTOR_FLAG;
@@ -188,10 +188,10 @@ extern Lisp_Object Vwindow_system;
extern Lisp_Object Vauto_save_list_file_name;
#ifdef USG_SHARED_LIBRARIES
-/* If nonzero, this is the place to put the end of the writable segment
+/* If not 1, this is the place to put the end of the writable segment
at startup. */
-unsigned int bss_end = 0;
+unsigned int bss_end = 1;
#endif
/* Nonzero means running Emacs without interactive terminal. */
@@ -856,7 +856,7 @@ main (argc, argv, envp)
stack_bottom = &stack_bottom_variable;
#ifdef USG_SHARED_LIBRARIES
- if (bss_end)
+ if (bss_end != 1)
brk ((void *)bss_end);
#endif
diff -pru emacs-21.3/src/xfns.c emacs-21.3-fix/src/xfns.c
--- emacs-21.3/src/xfns.c 2002-12-06 09:05:35.000000000 -0800
+++ emacs-21.3-fix/src/xfns.c 2003-07-11 01:26:46.669033000 -0700
@@ -3954,13 +3954,7 @@ x_icon (f, parms)
background, border and mouse colors; also create the
mouse cursor and the gray border tile. */
-static char cursor_bits[] =
- {
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
- };
+static char cursor_bits[32];
static void
x_make_gc (f)
diff -pru emacs-21.3/src/xterm.c emacs-21.3-fix/src/xterm.c
--- emacs-21.3/src/xterm.c 2002-10-15 07:21:45.000000000 -0700
+++ emacs-21.3-fix/src/xterm.c 2003-07-11 01:25:07.789266000 -0700
@@ -284,7 +284,7 @@ struct frame *pending_autoraise_frame;
#ifdef USE_X_TOOLKIT
/* The application context for Xt use. */
XtAppContext Xt_app_con;
-static String Xt_default_resources[] = {0};
+static String Xt_default_resources[1];
#endif /* USE_X_TOOLKIT */
/* Nominal cursor position -- where to draw output.
next reply other threads:[~2003-07-14 11:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-14 11:19 Marshall, Simon [this message]
[not found] ` <3F12B8E7.2C387FE7@yk.rim.or.jp>
2003-07-14 14:41 ` Anyone built Emacs with gcc-3.3? Eric Botcazou
2003-07-14 17:47 ` Paul Eggert
2003-07-14 19:40 ` Eric Botcazou
-- strict thread matches above, loose matches on Subject: below --
2003-07-08 15:18 Marshall, Simon
2003-07-09 15:49 ` Richard Stallman
2003-07-11 9:57 ` Paul Eggert
2003-07-07 8:26 Marshall, Simon
2003-07-08 14:28 ` Richard Stallman
2003-07-08 14:39 ` Jason Rumney
2003-07-09 5:34 ` Dhruva Krishnamurthy
2003-07-09 7:36 ` Pascal Obry
2003-07-09 7:59 ` Jason Rumney
2003-07-04 12:36 Nelson H. F. Beebe
2003-07-04 8:33 Marshall, Simon
2003-07-04 8:41 ` Dhruva Krishnamurthy
2003-07-04 16:17 ` puneet
2003-07-08 22:41 ` Dave Love
2003-07-09 12:31 ` Puneet Goel
2003-07-15 22:31 ` Dave Love
2003-07-05 22:25 ` Richard Stallman
2003-07-11 9:55 ` Paul Eggert
2003-07-11 22:52 ` Paul Eggert
2003-07-13 14:56 ` Simon Leinen
2003-07-14 5:52 ` Paul Eggert
2003-07-12 5:32 ` Richard Stallman
2003-07-08 22:30 ` Dave Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FC3DA3DC8D4AD311AB910020352A8FDC10755484@eagle.midas-kapiti.com \
--to=simon.marshall@misys.com \
--cc=ebotcazou@gcc.gnu.org \
--cc=emacs-devel@gnu.org \
--cc=emacs-pretesters@gnu.org \
--cc=ishikawa@yk.rim.or.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).