bug#10164: 24.0.91; Instant crash enabling linum-mode

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Cc: Tim Crews <tim.crews@code-affinity.com>,  10164@debbugs.gnu.org
>> Date: Wed, 30 Nov 2011 07:52:40 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Tue, 29 Nov 2011 19:05:20 -0700
>> >> From: Tim Crews <tim.crews@code-affinity.com>
>> >> 
>> >>     Start Emacs with runemacs -Q --no-init-file
>> >>     C-x C-f foo.txt
>> >>     M-x linum-mode
>> >>     (Emacs doesn't crash yet)
>> >>     Type anything.  Emacs instantly crashes.
>> >
>> > Arrgh!  This is GCC 4.6.x "as-is" code reordering in action.  Emacs
>> > crashes here:
>> >
>> >          xassert (!row->enabled_p
>> >                   || row->mode_line_p
>> >                   || verify_row_hash (row));
>> >
>> > Evidently, it calls verify_row_hash before it tests row->mode_line_p.
>> 
>> Are you sure?
>
> How else can I explain this display from GDB:

Compiler bug?


>   (gdb) prow
>   y=0 x=0 pwid=673 a+d=12+4=16 phys=12+4=16 vis=16
>   used=(LMargin=0,Text=84,RMargin=0) Hash=263825844
>   start=0 end=0 ENA MODEL
>
> ?  MODEL says that this row has its mode_line_p flag set.
>
> Just to be sure, I ran the recipe again under GDB, setting a
> breakpoint inside verify_row_hash thusly:
>
>   (gdb) break verify_row_hash if row->mode_line_p != 0
>
> and sure enough, it breaks as soon as I turn on linum-mode, with ROW
> that shows the glyphs in the mode line.
>
>> Without interprocedural analysis the compiler cannot know
>> that `verify_row_hash' does not alter row->enabled_p, so it cannot
>> change the evaluation order.
>
> I don't know.  Maybe GCC does perform such an analysis.  Or maybe it

It can't by default, `row_hash' is in a different file, so it's not
available when compiling dispnew.c.

> decides that the result of this comparison in verify_row_hash:
>
>   row->hash == row_hash (row)
>
> will not change even if row_hash does modify its argument ROW.  Or
> maybe it's a bug in GCC.