bug#6031: gcc 4.5 breaks optimized builds of emacs

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Elias Pipping]

Hi,

I'm on the current HEAD of the repo.or.cz mirror of emacs which is

  http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b

When I compile a minimal version of emacs like this:

  $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
--without-alsa --without-dbus; [..]

with gcc 4.5 and run it via

  $ ./src/emacs -Q -nw

I get a segfault. Dropping the -foptimize-sibling-calls (which is
implied by -O2) makes it work again. So does using an older version of
gcc (e.g. 4.4.3) or running emacs outside a terminal.


$ gdb ./src/emacs
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/pipping/emacs/src/emacs...done.
(gdb) run -Q -nw

< clears terminal >


Program received signal SIGSEGV, Segmentation fault.
0x0000000000406015 in fill_up_glyph_row_area_with_spaces
(row=0x111e320, area=2) at dispnew.c:2910
2910            *text++ = space_glyph;
(gdb) bt
#0  0x0000000000406015 in fill_up_glyph_row_area_with_spaces
(row=0x111e320, area=2) at dispnew.c:2910
#1  0x000000000040a6a8 in fill_up_glyph_row_with_spaces
(matrix=0xde7290, w=0xb4a630) at dispnew.c:2892
#2  build_frame_matrix_from_leaf_window (matrix=0xde7290, w=0xb4a630)
at dispnew.c:2790
#3  build_frame_matrix_from_window_tree (matrix=0xde7290, w=0xb4a630)
at dispnew.c:2718
#4  0x000000000040c51c in build_frame_matrix (f=0xb4a3b0, force_p=1,
inhibit_hairy_id_p=1) at dispnew.c:2698
#5  update_frame (f=0xb4a3b0, force_p=1, inhibit_hairy_id_p=1) at dispnew.c:3560
#6  0x0000000000426340 in echo_area_display (update_frame_p=1) at xdisp.c:9624
#7  0x0000000000426601 in message3_nolog (m=16043489, nbytes=65,
multibyte=0) at xdisp.c:8479
#8  0x00000000004267d0 in message3 (m=16043489, nbytes=65,
multibyte=0) at xdisp.c:8414
#9  0x00000000004d3bf7 in Fmessage (nargs=<value optimized out>,
args=<value optimized out>) at editfns.c:3408
#10 0x00000000004d976c in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd510) at eval.c:3054
#11 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#12 0x00000000004dbca2 in funcall_lambda (fun=8298757, nargs=0,
arg_vector=0x7fffffffd6d8) at eval.c:3260
#13 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd6d0) at eval.c:3119
#14 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#15 0x00000000004dbca2 in funcall_lambda (fun=8300205, nargs=1,
arg_vector=0x7fffffffd8c8) at eval.c:3260
#16 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd8c0) at eval.c:3119
#17 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#18 0x00000000004dbca2 in funcall_lambda (fun=8273333, nargs=0,
arg_vector=0x7fffffffdaa8) at eval.c:3260
#19 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffdaa0) at eval.c:3119
#20 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#21 0x00000000004dbca2 in funcall_lambda (fun=8268357, nargs=0,
arg_vector=0x7fffffffdbe0) at eval.c:3260
#22 0x00000000004dbd87 in apply_lambda (fun=8268357, args=<value
optimized out>, eval_flag=1) at eval.c:3184
#23 0x00000000004db750 in Feval (form=<value optimized out>) at eval.c:2410
#24 0x00000000004d8dc4 in internal_condition_case (bfun=0x474709
<top_level_2>, handlers=11756482, hfun=0x474faf <cmd_error>) at
eval.c:1512
#25 0x0000000000474bdb in top_level_1 () at keyboard.c:1373
#26 0x00000000004d8c94 in internal_catch (tag=11752306, func=0x474bb1
<top_level_1>, arg=11704658) at eval.c:1248
#27 0x000000000047513a in command_loop () at keyboard.c:1328
#28 0x00000000004751ee in recursive_edit_1 () at keyboard.c:950
#29 0x0000000000475338 in Frecursive_edit () at keyboard.c:1012
#30 0x0000000000472747 in main (argc=<value optimized out>,
argv=0x7fffffffe418) at emacs.c:1784
(gdb)


Kind Regards,

Elias Pipping

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Dan Nicolaescu]

Elias Pipping <pipping.elias@googlemail.com> writes:

> Hi,
>
> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>
>   http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>
> When I compile a minimal version of emacs like this:
>
>   $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
> --without-alsa --without-dbus; [..]
>
> with gcc 4.5 and run it via
>
>   $ ./src/emacs -Q -nw
>
> I get a segfault. Dropping the -foptimize-sibling-calls (which is
> implied by -O2) makes it work again. So does using an older version of
> gcc (e.g. 4.4.3) or running emacs outside a terminal.

Can you please uncomment this line in emacs/src/s/intel386.h
/* #define NO_ARG_ARRAY */

recompile everything and see if you get the problem after that.

>
>
> $ gdb ./src/emacs
> GNU gdb (GDB) 7.1
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/pipping/emacs/src/emacs...done.
> (gdb) run -Q -nw
>
> < clears terminal >
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
> (row=0x111e320, area=2) at dispnew.c:2910
> 2910            *text++ = space_glyph;
> (gdb) bt
> #0  0x0000000000406015 in fill_up_glyph_row_area_with_spaces
> (row=0x111e320, area=2) at dispnew.c:2910
> #1  0x000000000040a6a8 in fill_up_glyph_row_with_spaces
> (matrix=0xde7290, w=0xb4a630) at dispnew.c:2892
> #2  build_frame_matrix_from_leaf_window (matrix=0xde7290, w=0xb4a630)
> at dispnew.c:2790
> #3  build_frame_matrix_from_window_tree (matrix=0xde7290, w=0xb4a630)
> at dispnew.c:2718
> #4  0x000000000040c51c in build_frame_matrix (f=0xb4a3b0, force_p=1,
> inhibit_hairy_id_p=1) at dispnew.c:2698
> #5  update_frame (f=0xb4a3b0, force_p=1, inhibit_hairy_id_p=1) at dispnew.c:3560
> #6  0x0000000000426340 in echo_area_display (update_frame_p=1) at xdisp.c:9624
> #7  0x0000000000426601 in message3_nolog (m=16043489, nbytes=65,
> multibyte=0) at xdisp.c:8479
> #8  0x00000000004267d0 in message3 (m=16043489, nbytes=65,
> multibyte=0) at xdisp.c:8414
> #9  0x00000000004d3bf7 in Fmessage (nargs=<value optimized out>,
> args=<value optimized out>) at editfns.c:3408
> #10 0x00000000004d976c in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffd510) at eval.c:3054
> #11 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #12 0x00000000004dbca2 in funcall_lambda (fun=8298757, nargs=0,
> arg_vector=0x7fffffffd6d8) at eval.c:3260
> #13 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffd6d0) at eval.c:3119
> #14 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #15 0x00000000004dbca2 in funcall_lambda (fun=8300205, nargs=1,
> arg_vector=0x7fffffffd8c8) at eval.c:3260
> #16 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffd8c0) at eval.c:3119
> #17 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #18 0x00000000004dbca2 in funcall_lambda (fun=8273333, nargs=0,
> arg_vector=0x7fffffffdaa8) at eval.c:3260
> #19 0x00000000004d9949 in Ffuncall (nargs=<value optimized out>,
> args=0x7fffffffdaa0) at eval.c:3119
> #20 0x000000000050bde9 in Fbyte_code (bytestr=<value optimized out>,
> vector=<value optimized out>, maxdepth=<value optimized out>) at
> bytecode.c:680
> #21 0x00000000004dbca2 in funcall_lambda (fun=8268357, nargs=0,
> arg_vector=0x7fffffffdbe0) at eval.c:3260
> #22 0x00000000004dbd87 in apply_lambda (fun=8268357, args=<value
> optimized out>, eval_flag=1) at eval.c:3184
> #23 0x00000000004db750 in Feval (form=<value optimized out>) at eval.c:2410
> #24 0x00000000004d8dc4 in internal_condition_case (bfun=0x474709
> <top_level_2>, handlers=11756482, hfun=0x474faf <cmd_error>) at
> eval.c:1512
> #25 0x0000000000474bdb in top_level_1 () at keyboard.c:1373
> #26 0x00000000004d8c94 in internal_catch (tag=11752306, func=0x474bb1
> <top_level_1>, arg=11704658) at eval.c:1248
> #27 0x000000000047513a in command_loop () at keyboard.c:1328
> #28 0x00000000004751ee in recursive_edit_1 () at keyboard.c:950
> #29 0x0000000000475338 in Frecursive_edit () at keyboard.c:1012
> #30 0x0000000000472747 in main (argc=<value optimized out>,
> argv=0x7fffffffe418) at emacs.c:1784
> (gdb)
>
>
> Kind Regards,
>
> Elias Pipping

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Elias Pipping]

On Sun, Apr 25, 2010 at 5:07 AM, Dan Nicolaescu <dann@gnu.org> wrote:
> Elias Pipping <pipping.elias@googlemail.com> writes:
>
>> Hi,
>>
>> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>>
>>   http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>>
>> When I compile a minimal version of emacs like this:
>>
>>   $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
>> --without-alsa --without-dbus; [..]
>>
>> with gcc 4.5 and run it via
>>
>>   $ ./src/emacs -Q -nw
>>
>> I get a segfault. Dropping the -foptimize-sibling-calls (which is
>> implied by -O2) makes it work again. So does using an older version of
>> gcc (e.g. 4.4.3) or running emacs outside a terminal.
>
> Can you please uncomment this line in emacs/src/s/intel386.h
> /* #define NO_ARG_ARRAY */
>
> recompile everything and see if you get the problem after that.

Hi!

no -- assuming you meant src/m/intel386.h and thus

--- src/m/intel386.h~   2010-04-24 15:24:25.000000000 +0200
+++ src/m/intel386.h    2010-04-25 13:07:01.555119059 +0200
@@ -42,7 +42,7 @@
 /* Define NO_ARG_ARRAY if you cannot take the address of the first of a
  * group of arguments and treat it as an array of the arguments.  */

-/* #define NO_ARG_ARRAY */
+#define NO_ARG_ARRAY

 #ifdef USG
 #define TEXT_START 0

that doesn't appear to help.


Kind regards,

Elias Pipping

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Eli Zaretskii]

> From: Elias Pipping <pipping.elias@googlemail.com>
> Date: Sun, 25 Apr 2010 01:44:14 +0200
> Cc: 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
> (row=0x111e320, area=2) at dispnew.c:2910
> 2910            *text++ = space_glyph;

Please show the values of the following variables in frame 0:

  (gdb) p text
  (gdb) p end
  (gdb) p row->used[area]

Thanks.

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Elias Pipping]

On Sun, Apr 25, 2010 at 3:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Elias Pipping <pipping.elias@googlemail.com>
>> Date: Sun, 25 Apr 2010 01:44:14 +0200
>> Cc:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000406015 in fill_up_glyph_row_area_with_spaces
>> (row=0x111e320, area=2) at dispnew.c:2910
>> 2910            *text++ = space_glyph;
>
> Please show the values of the following variables in frame 0:
>
>  (gdb) p text
>  (gdb) p end
>  (gdb) p row->used[area]
>
> Thanks.

(gdb) p text
$1 = (struct glyph *) 0x1163000
(gdb) p end
$2 = (struct glyph *) 0x7ffff73525fa
(gdb) p *end
$3 = {charpos = -19543819183790871, object = 4904358129765974015,
pixel_width = -30270, ascent = -29241,
  descent = 327, voffset = -28477, type = 0, multibyte_p = 0,
left_box_line_p = 0, right_box_line_p = 1,
  overlaps_vertically_p = 0, padding_p = 0, glyph_not_available_p = 1,
avoid_cursor_p = 0, resolved_level = 8,
  bidi_type = 2, face_id = 37008, font_type = 1, slice = {x = 37008, y
= 37008, width = 37008, height = 65464}, u = {
    ch = 1224736767, cmp = {automatic = 1, id = 8388607, from = 8, to
= 4}, img_id = 1224736767, stretch = {
      height = 65535, ascent = 18687}, val = 1224736767}}
(gdb) p row->used[area]
$4 = 0
(gdb)

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Eli Zaretskii]

> From: Elias Pipping <pipping.elias@googlemail.com>
> Date: Sun, 25 Apr 2010 16:56:20 +0200
> Cc: 6031@debbugs.gnu.org
> 
> (gdb) p text
> $1 = (struct glyph *) 0x1163000
> (gdb) p end
> $2 = (struct glyph *) 0x7ffff73525fa

Hmm... `end' looks entirely bogus to me...  It should have been much
smalle.  Can you set a watchpoint at the address of row->glyphs[3],
and see who puts there a non-null value?  Here's how to do that:

   In the crashed session:
   (gdb) p &row->glyphs[3]
   $1 = (struct glyph **) 0x12345678

   Start a new session:
   gdb ./emacs
   (gdb) start -Q -nw
   (gdb) watch *(struct glyph **) 0x12345678
   (gdb) continue

0x12345678 is of course just an example, you will actually see some
other value.

You should see one change of the value here (line 673 in dispnew.c):

      matrix->rows = (struct glyph_row *) xrealloc (matrix->rows, size);
      bzero (matrix->rows + matrix->rows_allocated,
	     new_rows * sizeof *matrix->rows);

The value should change to a NULL pointer.  You should then see
another change in the loop which starts on line 697 in dispnew.c:

      for (i = 0; i < dim.height; ++i)

The value should change from a NULL pointer to something non-null.

There should be some more similar changes.  Please see which one of
them puts the bogus value 0x7ffff73525fa or some such there.

Thanks.

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Elias Pipping]

On Sun, Apr 25, 2010 at 6:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Elias Pipping <pipping.elias@googlemail.com>
>> Date: Sun, 25 Apr 2010 16:56:20 +0200
>> Cc: 6031@debbugs.gnu.org
>>
>> (gdb) p text
>> $1 = (struct glyph *) 0x1163000
>> (gdb) p end
>> $2 = (struct glyph *) 0x7ffff73525fa
>
> Hmm... `end' looks entirely bogus to me...  It should have been much
> smalle.  Can you set a watchpoint at the address of row->glyphs[3],
> and see who puts there a non-null value?  Here's how to do that:
>
>   In the crashed session:
>   (gdb) p &row->glyphs[3]
>   $1 = (struct glyph **) 0x12345678
>
>   Start a new session:
>   gdb ./emacs
>   (gdb) start -Q -nw
>   (gdb) watch *(struct glyph **) 0x12345678
>   (gdb) continue
>
> 0x12345678 is of course just an example, you will actually see some
> other value.

(after quite a couple of changes to it):

Hardware watchpoint 2: *(struct glyph **) 0x1126868

Old value = (struct glyph *) 0xa35312d39353838
New value = (struct glyph *) 0x0
0x00007ffff7639f58 in memset () from /lib/libc.so.6
(gdb)

after that, before the watchpoint is hit again, the segfault occurs.

> You should see one change of the value here (line 673 in dispnew.c):
>
>      matrix->rows = (struct glyph_row *) xrealloc (matrix->rows, size);
>      bzero (matrix->rows + matrix->rows_allocated,
>             new_rows * sizeof *matrix->rows);
>
> The value should change to a NULL pointer.  You should then see
> another change in the loop which starts on line 697 in dispnew.c:
>
>      for (i = 0; i < dim.height; ++i)
>
> The value should change from a NULL pointer to something non-null.
>
> There should be some more similar changes.  Please see which one of
> them puts the bogus value 0x7ffff73525fa or some such there.
>
> Thanks.

Kind regards,

Elias

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Chong Yidong]

Elias Pipping <pipping.elias@googlemail.com> writes:

> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>
>   http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>
> When I compile a minimal version of emacs like this:
>
>   $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
> --without-alsa --without-dbus; [..]
>
> with gcc 4.5 and run it via
>
>   $ ./src/emacs -Q -nw
>
> I get a segfault. Dropping the -foptimize-sibling-calls (which is
> implied by -O2) makes it work again. So does using an older version of
> gcc (e.g. 4.4.3) or running emacs outside a terminal.

Could you do me a favor, and check whether the problem also exists for
the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?

Thanks.

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Elias Pipping]

On Sun, Apr 25, 2010 at 8:32 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Elias Pipping <pipping.elias@googlemail.com> writes:
>
>> I'm on the current HEAD of the repo.or.cz mirror of emacs which is
>>
>>   http://repo.or.cz/w/emacs.git/commit/910daaa95ca0708ad7022667e214bba4b8eb3d6b
>>
>> When I compile a minimal version of emacs like this:
>>
>>   $ ./configure CFLAGS="-O1 -foptimize-sibling-calls" --without-x
>> --without-alsa --without-dbus; [..]
>>
>> with gcc 4.5 and run it via
>>
>>   $ ./src/emacs -Q -nw
>>
>> I get a segfault. Dropping the -foptimize-sibling-calls (which is
>> implied by -O2) makes it work again. So does using an older version of
>> gcc (e.g. 4.4.3) or running emacs outside a terminal.
>
> Could you do me a favor, and check whether the problem also exists for
> the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?

It does not. Judging by the bisecting I did, the problem was introduced in

  http://repo.or.cz/w/emacs.git/commit/5a98a2a69b1a15173ce4bfa53307608a7150b407


Kind regards,

Elias

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Eli Zaretskii]

> From: Elias Pipping <pipping.elias@googlemail.com>
> Date: Mon, 26 Apr 2010 17:40:40 +0200
> Cc: 6031@debbugs.gnu.org
> 
> > Could you do me a favor, and check whether the problem also exists for
> > the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?
> 
> It does not. Judging by the bisecting I did, the problem was introduced in
> 
>   http://repo.or.cz/w/emacs.git/commit/5a98a2a69b1a15173ce4bfa53307608a7150b407

How to map this to Bazaar revnos or rev-ids?

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Elias Pipping]

On Mon, Apr 26, 2010 at 5:40 PM, Elias Pipping
<pipping.elias@googlemail.com> wrote:
> On Sun, Apr 25, 2010 at 8:32 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>> Could you do me a favor, and check whether the problem also exists for
>> the latest emacs-23 pretest at ftp://alpha.gnu.org/gnu/emacs/pretest/ ?
>
> It does not. Judging by the bisecting I did, the problem was introduced in
>
>  http://repo.or.cz/w/emacs.git/commit/5a98a2a69b1a15173ce4bfa53307608a7150b407
>
>
> Kind regards,
>
> Elias

A slightly different version of this problem does appear in 23.1.96,
though. A segfault when running in a terminal. This one doesn't occur
right after the start, though. To trigger it, press C-x C-f and press
<tab> four times. Here's what happens then:

Program received signal SIGSEGV, Segmentation fault.
build_frame_matrix_from_leaf_window (matrix=0xca5e30, w=0xa93f90) at
dispnew.c:2824
2824                  SET_CHAR_GLYPH_FROM_GLYPH (*border, right_border_glyph);
(gdb) bt
#0  build_frame_matrix_from_leaf_window (matrix=0xca5e30, w=0xa93f90)
at dispnew.c:2824
#1  build_frame_matrix_from_window_tree (matrix=0xca5e30, w=0xa93f90)
at dispnew.c:2720
#2  0x0000000000409601 in build_frame_matrix_from_window_tree
(matrix=0xca5e30, w=0xf0a800) at dispnew.c:2716
#3  0x000000000040c24d in build_frame_matrix (f=0xa93d10, force_p=0,
inhibit_hairy_id_p=0) at dispnew.c:2700
#4  update_frame (f=0xa93d10, force_p=0, inhibit_hairy_id_p=0) at dispnew.c:3951
#5  0x0000000000423c82 in redisplay_internal
(preserve_echo_area=<value optimized out>) at xdisp.c:11826
#6  0x00000000004769d5 in read_char (commandflag=1, nmaps=2,
maps=0x7fffffffcdf0, prev_event=10938770,
used_mouse_menu=0x7fffffffce74, end_time=0x0) at keyboard.c:2727
#7  0x00000000004790ed in read_key_sequence (keybuf=0x7fffffffcfa0,
bufsize=30, prompt=10938770, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1)
    at keyboard.c:9512
#8  0x000000000047aef1 in command_loop_1 () at keyboard.c:1643
#9  0x00000000004d41b4 in internal_condition_case (bfun=0x47ac15
<command_loop_1>, handlers=11006002, hfun=0x470aa2 <cmd_error>) at
eval.c:1490
#10 0x000000000046ff66 in command_loop_2 () at keyboard.c:1360
#11 0x00000000004d4084 in internal_catch (tag=11103042, func=0x46ff4c
<command_loop_2>, arg=10938770) at eval.c:1226
#12 0x0000000000470c02 in command_loop () at keyboard.c:1325
#13 0x0000000000470ce1 in recursive_edit_1 () at keyboard.c:954
#14 0x0000000000498809 in read_minibuf (map=10932022,
initial=13617857, prompt=<value optimized out>, backup_n=<value
optimized out>, expflag=0, histvar=<value optimized out>,
    histpos=0, defalt=15330225, allow_props=0, inherit_input_method=0)
at minibuf.c:740
#15 0x0000000000498c78 in Fcompleting_read (prompt=8075209,
collection=<value optimized out>, predicate=<value optimized out>,
require_match=11074946,
    initial_input=<value optimized out>, hist=11015314, def=15330225,
inherit_input_method=10938770) at minibuf.c:1824
#16 0x00000000004d4d25 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd4a8) at eval.c:3055
#17 0x000000000050736f in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#18 0x00000000004d6fbc in funcall_lambda (fun=8282029, nargs=4,
arg_vector=0x7fffffffd778) at eval.c:3211
#19 0x00000000004d4d43 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd770) at eval.c:3070
#20 0x000000000050736f in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#21 0x00000000004d6fbc in funcall_lambda (fun=8074637, nargs=2,
arg_vector=0x7fffffffd948) at eval.c:3211
#22 0x00000000004d4d43 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffd940) at eval.c:3070
#23 0x000000000050736f in Fbyte_code (bytestr=<value optimized out>,
vector=<value optimized out>, maxdepth=<value optimized out>) at
bytecode.c:680
#24 0x00000000004d6948 in Feval (form=<value optimized out>) at eval.c:2352
#25 0x00000000004d1e42 in Fcall_interactively (function=11460274,
record_flag=10938770, keys=10997285) at callint.c:365
#26 0x00000000004d4c42 in Ffuncall (nargs=<value optimized out>,
args=0x7fffffffdcd0) at eval.c:3030
#27 0x00000000004d4ee7 in call3 (fn=<value optimized out>, arg1=<value
optimized out>, arg2=<value optimized out>, arg3=<value optimized
out>) at eval.c:2850
#28 0x000000000047bc01 in command_loop_1 () at keyboard.c:1904
#29 0x00000000004d41b4 in internal_condition_case (bfun=0x47ac15
<command_loop_1>, handlers=11006002, hfun=0x470aa2 <cmd_error>) at
eval.c:1490
#30 0x000000000046ff66 in command_loop_2 () at keyboard.c:1360
#31 0x00000000004d4084 in internal_catch (tag=10998562, func=0x46ff4c
<command_loop_2>, arg=10938770) at eval.c:1226
#32 0x0000000000470c45 in command_loop () at keyboard.c:1339
#33 0x0000000000470ce1 in recursive_edit_1 () at keyboard.c:954
#34 0x0000000000470e2b in Frecursive_edit () at keyboard.c:1016
#35 0x000000000046db57 in main (argc=<value optimized out>,
argv=0x7fffffffe538) at emacs.c:1833
(gdb)

this is with the same CC and CFLAGS as mentioned before (changing
either appears to make the bug go away).


Kind regards,

Elias

bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls

[Ulrich Mueller]

I just want to point out that we observe a very similar issue in
<http://bugs.gentoo.org/317187>, for the 23.1 release.

bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls

[Dan Nicolaescu]

Ulrich Mueller <ulm@gentoo.org> writes:

> I just want to point out that we observe a very similar issue in
> <http://bugs.gentoo.org/317187>, for the 23.1 release.

Could you please try to find out where exactly the problem is?

You can do a binary search on the object files compiled with the
options that result in a working binary by linking them with the ones
that result in a non-working binary.
Maybe you can find a single file that gets miscompiled, and then 
find out what function in that file gets miscompiled.

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Ulrich Mueller]

Looks like this is a GCC bug:

http://gcc.gnu.org/PR43904
http://gcc.gnu.org/PR43572

bug#6031: gcc 4.5 breaks optimized builds of emacs

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> writes:

> Looks like this is a GCC bug:
>
> http://gcc.gnu.org/PR43904
> http://gcc.gnu.org/PR43572

Thanks.  I've added a PROBLEMS entry explaining this.