From: Sven Joachim <svenjoac@gmx.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Paul Eggert <eggert@cs.ucla.edu>, 8623@debbugs.gnu.org
Subject: bug#8623: 23.3.50; (woman "git-remote") crashes
Date: Fri, 06 May 2011 14:36:04 +0200 [thread overview]
Message-ID: <87hb98huq3.fsf@turtle.gmx.de> (raw)
In-Reply-To: <87pqnwhzmr.fsf@turtle.gmx.de> (Sven Joachim's message of "Fri, 06 May 2011 12:50:04 +0200")
On 2011-05-06 12:50 +0200, Sven Joachim wrote:
> On 2011-05-06 12:15 +0200, Eli Zaretskii wrote:
>
>>> From: Sven Joachim <svenjoac@gmx.de>
>>> Cc: 8623@debbugs.gnu.org
>>> Date: Thu, 05 May 2011 23:12:18 +0200
>>>
>>> $ gcc --version | head -n1
>>> gcc (Debian 4.6.0-6) 4.6.1 20110428 (prerelease)
>>>
>>> > Also, can you build Emacs without optimizations, and try reproducing
>>> > in the unoptimized binary?
>>>
>>> Alas, the unoptimized binary does not crash.
>>
>> Darn! Debugging optimized code is pretty much hopeless with current
>> versions of GCC.
>>
>> Paul, could you please take a look at this? Could this be due to the
>> same problems with GCC 4.6 optimizations you recently fixed on the
>> trunk? If so, we may need similar changes on the release branch.
>
> I suspect so, because…
>
>> Sven, could you also try with the trunk build?
>
> The trunk is fine. I'm already bisecting the problem, but have to leave
> in 1.5 hours and will then be unavailable until Sunday. If I find out
> the commit which fixed the bug, I'll let you know.
The following commit (merged into the trunk as revision 104021)
contained the fix:
,----
| revno: 103939.1.42
| committer: Paul Eggert <eggert@cs.ucla.edu>
| branch nick: atest
| timestamp: Mon 2011-04-25 00:14:46 -0700
| message:
| lisp.h: Fix a problem with aliasing and vector headers.
|
| GCC 4.6.0 optimizes based on type-based alias analysis. For
| example, if b is of type struct buffer * and v of type struct
| Lisp_Vector *, then gcc -O2 was incorrectly assuming that &b->size
| != &v->size, and therefore "v->size = 1; b->size = 2; return
| v->size;" must therefore return 1. This assumption is incorrect
| for Emacs, since it type-puns struct Lisp_Vector * with many other
| types. To fix this problem, this patch adds a new type struct
| vector_header that documents the constraints on layout of vectors
| and pseudovectors, and helps optimizing compilers not get fooled
| by Emacs's type punning. It also adds the macros XSETTYPED_PVECTYPE
| XSETTYPED_PSEUDOVECTOR, TYPED_PSEUDOVECTORP, for similar reasons.
| * lisp.h (XVECTOR_SIZE): New convenience macro. All previous uses of
| XVECTOR (foo)->size replaced to use this macro, to avoid the hassle
| of writing XVECTOR (foo)->header.size.
| (XVECTOR_HEADER_SIZE): New macro, for use in XSETPSEUDOVECTOR.
| (XSETTYPED_PVECTYPE): New macro, specifying the name of the size
| member.
| (XSETPVECTYPE): Rewrite in terms of new macro.
| (XSETPVECTYPESIZE): New macro, specifying both type and size.
| This is a bit clearer, and further avoids the possibility of
| undesirable aliasing.
| (XSETTYPED_PSEUDOVECTOR): New macro, specifying the size.
| (XSETPSEUDOVECTOR): Rewrite in terms of XSETTYPED_PSEUDOVECTOR
| and XVECTOR_HEADER_SIZE.
| (XSETSUBR): Rewrite in terms of XSETTYPED_PSEUDOVECTOR and XSIZE,
| since Lisp_Subr is a special case (no "next" field).
| (ASIZE): Rewrite in terms of XVECTOR_SIZE.
| (struct vector_header): New type.
| (TYPED_PSEUDOVECTORP): New macro, also specifying the C type of the
| object, to help avoid aliasing.
| (PSEUDOVECTORP): Rewrite in terms of TYPED_PSEUDOVECTORP.
| (SUBRP): Likewise, since Lisp_Subr is a special case.
| * lisp.h (struct Lisp_Vector, struct Lisp_Char_Table):
| (struct Lisp_Sub_Char_Table, struct Lisp_Bool_Vector):
| (struct Lisp_Hash_Table): Combine first two members into a single
| struct vector_header member. All uses of "size" and "next" members
| changed to be "header.size" and "header.next".
| * buffer.h (struct buffer): Likewise.
| * font.h (struct font_spec, struct font_entity, struct font): Likewise.
| * frame.h (struct frame): Likewise.
| * process.h (struct Lisp_Process): Likewise.
| * termhooks.h (struct terminal): Likewise.
| * window.c (struct save_window_data, struct saved_window): Likewise.
| * window.h (struct window): Likewise.
| * alloc.c (allocate_buffer, Fmake_bool_vector, allocate_pseudovector):
| Use XSETPVECTYPESIZE, not XSETPVECTYPE, to avoid aliasing problems.
| * buffer.c (init_buffer_once): Likewise.
| * lread.c (defsubr): Use XSETTYPED_PVECTYPE, since Lisp_Subr is a
| special case.
| * process.c (Fformat_network_address): Use local var for size,
| for brevity.
|
`----
This commit touches 39 files. How to backport it to the emacs-23 branch
is left as an exercise for the reader.
Bye,
Sven
next prev parent reply other threads:[~2011-05-06 12:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 20:09 bug#8623: 23.3.50; (woman "git-remote") crashes Sven Joachim
2011-05-05 20:44 ` Eli Zaretskii
2011-05-05 21:12 ` Sven Joachim
2011-05-06 10:15 ` Eli Zaretskii
2011-05-06 10:50 ` Sven Joachim
2011-05-06 12:36 ` Sven Joachim [this message]
2011-05-06 14:39 ` Stefan Monnier
2011-05-06 14:47 ` Paul Eggert
2011-05-08 11:50 ` Sven Joachim
2011-05-08 16:34 ` Paul Eggert
2011-05-08 17:42 ` Sven Joachim
2011-05-08 18:22 ` Paul Eggert
2011-05-08 19:02 ` Eli Zaretskii
2011-05-09 10:10 ` Eli Zaretskii
2011-05-09 15:09 ` Sven Joachim
2011-05-09 15:28 ` Eli Zaretskii
2011-05-08 19:27 ` Eli Zaretskii
2011-05-09 10:13 ` Eli Zaretskii
2011-05-07 11:32 ` Richard Stallman
2011-05-06 14:37 ` Paul Eggert
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hb98huq3.fsf@turtle.gmx.de \
--to=svenjoac@gmx.de \
--cc=8623@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
/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 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.