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

[Eli Zaretskii]

> 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:

  (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
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.