* bug#6031: gcc 4.5 breaks optimized builds of emacs @ 2010-04-24 23:44 Elias Pipping 2010-04-25 3:07 ` Dan Nicolaescu ` (4 more replies) 0 siblings, 5 replies; 15+ messages in thread From: Elias Pipping @ 2010-04-24 23:44 UTC (permalink / raw To: 6031 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping @ 2010-04-25 3:07 ` Dan Nicolaescu 2010-04-25 11:12 ` Elias Pipping 2010-04-25 13:33 ` Eli Zaretskii ` (3 subsequent siblings) 4 siblings, 1 reply; 15+ messages in thread From: Dan Nicolaescu @ 2010-04-25 3:07 UTC (permalink / raw To: Elias Pipping; +Cc: 6031 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-25 3:07 ` Dan Nicolaescu @ 2010-04-25 11:12 ` Elias Pipping 0 siblings, 0 replies; 15+ messages in thread From: Elias Pipping @ 2010-04-25 11:12 UTC (permalink / raw To: Dan Nicolaescu; +Cc: 6031 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping 2010-04-25 3:07 ` Dan Nicolaescu @ 2010-04-25 13:33 ` Eli Zaretskii 2010-04-25 14:56 ` Elias Pipping 2010-04-25 18:32 ` Chong Yidong ` (2 subsequent siblings) 4 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2010-04-25 13:33 UTC (permalink / raw To: Elias Pipping; +Cc: 6031 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-25 13:33 ` Eli Zaretskii @ 2010-04-25 14:56 ` Elias Pipping 2010-04-25 16:15 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Elias Pipping @ 2010-04-25 14:56 UTC (permalink / raw To: Eli Zaretskii; +Cc: 6031 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) ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-25 14:56 ` Elias Pipping @ 2010-04-25 16:15 ` Eli Zaretskii 2010-04-26 22:41 ` Elias Pipping 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2010-04-25 16:15 UTC (permalink / raw To: Elias Pipping; +Cc: 6031 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-25 16:15 ` Eli Zaretskii @ 2010-04-26 22:41 ` Elias Pipping 0 siblings, 0 replies; 15+ messages in thread From: Elias Pipping @ 2010-04-26 22:41 UTC (permalink / raw To: Eli Zaretskii; +Cc: 6031 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping 2010-04-25 3:07 ` Dan Nicolaescu 2010-04-25 13:33 ` Eli Zaretskii @ 2010-04-25 18:32 ` Chong Yidong 2010-04-26 15:40 ` Elias Pipping 2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller 2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller 4 siblings, 1 reply; 15+ messages in thread From: Chong Yidong @ 2010-04-25 18:32 UTC (permalink / raw To: Elias Pipping; +Cc: 6031 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-25 18:32 ` Chong Yidong @ 2010-04-26 15:40 ` Elias Pipping 2010-04-26 17:40 ` Eli Zaretskii 2010-04-26 22:12 ` Elias Pipping 0 siblings, 2 replies; 15+ messages in thread From: Elias Pipping @ 2010-04-26 15:40 UTC (permalink / raw To: Chong Yidong; +Cc: 6031 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-26 15:40 ` Elias Pipping @ 2010-04-26 17:40 ` Eli Zaretskii 2010-04-26 22:12 ` Elias Pipping 1 sibling, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2010-04-26 17:40 UTC (permalink / raw To: Elias Pipping; +Cc: 6031, cyd > 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-26 15:40 ` Elias Pipping 2010-04-26 17:40 ` Eli Zaretskii @ 2010-04-26 22:12 ` Elias Pipping 1 sibling, 0 replies; 15+ messages in thread From: Elias Pipping @ 2010-04-26 22:12 UTC (permalink / raw To: Chong Yidong; +Cc: 6031 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls 2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping ` (2 preceding siblings ...) 2010-04-25 18:32 ` Chong Yidong @ 2010-04-26 20:17 ` Ulrich Mueller 2010-04-26 21:09 ` Dan Nicolaescu 2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller 4 siblings, 1 reply; 15+ messages in thread From: Ulrich Mueller @ 2010-04-26 20:17 UTC (permalink / raw To: 6031 I just want to point out that we observe a very similar issue in <http://bugs.gentoo.org/317187>, for the 23.1 release. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls 2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller @ 2010-04-26 21:09 ` Dan Nicolaescu 0 siblings, 0 replies; 15+ messages in thread From: Dan Nicolaescu @ 2010-04-26 21:09 UTC (permalink / raw To: Ulrich Mueller; +Cc: 6031 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping ` (3 preceding siblings ...) 2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller @ 2010-04-27 11:26 ` Ulrich Mueller 2010-04-27 15:37 ` Chong Yidong 4 siblings, 1 reply; 15+ messages in thread From: Ulrich Mueller @ 2010-04-27 11:26 UTC (permalink / raw To: 6031 Looks like this is a GCC bug: http://gcc.gnu.org/PR43904 http://gcc.gnu.org/PR43572 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6031: gcc 4.5 breaks optimized builds of emacs 2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller @ 2010-04-27 15:37 ` Chong Yidong 0 siblings, 0 replies; 15+ messages in thread From: Chong Yidong @ 2010-04-27 15:37 UTC (permalink / raw To: Ulrich Mueller; +Cc: 6031 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-04-27 15:37 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-24 23:44 bug#6031: gcc 4.5 breaks optimized builds of emacs Elias Pipping 2010-04-25 3:07 ` Dan Nicolaescu 2010-04-25 11:12 ` Elias Pipping 2010-04-25 13:33 ` Eli Zaretskii 2010-04-25 14:56 ` Elias Pipping 2010-04-25 16:15 ` Eli Zaretskii 2010-04-26 22:41 ` Elias Pipping 2010-04-25 18:32 ` Chong Yidong 2010-04-26 15:40 ` Elias Pipping 2010-04-26 17:40 ` Eli Zaretskii 2010-04-26 22:12 ` Elias Pipping 2010-04-26 20:17 ` bug#6031: Emacs 23.1 breaks with gcc 4.5 and -foptimize-sibling-calls Ulrich Mueller 2010-04-26 21:09 ` Dan Nicolaescu 2010-04-27 11:26 ` bug#6031: gcc 4.5 breaks optimized builds of emacs Ulrich Mueller 2010-04-27 15:37 ` Chong Yidong
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.