Re: [22.1.90]: Point before start of properties

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> So, adding -O (or -O2) to gcc-4.2.3 triggers the problem, and 
>> switching to gcc-4.1.2 triggers it as well?

> Yes.  Btw, I didn't mention before that gcc gives me lots of warnings of
> the form "dispnew.c:3061: warning: incompatible implicit declaration of
> built-in function 'alloca'".  (That is the reason why I tried undefing
> GNU_MALLOC and HAVE_ALLOCA, though IIRC I could not get rid of the
> warnings and made no difference to the problem of calling error at
> intervals.c:794.)  Could this be relevant?

Any warning outside of intervals.c seem unlikely to be a good source of
the problem.  Do you ever get any kind of warning when compiling
intervals.c?

Also you said that the problem could be triggered with gcc-4.1.2 even
without optimization, is that really true?  If so, can you try again
with gcc-4.1.2 and no optimizations, to get better debug info?

Another thing: do you know if your compilation uses USE_LSB_TAG or not?
Is it a 64bit or 32bit memory model?
Have you tried to compile it with -DUSE_LISP_UNION_TYPE just to see if
it hides the problem (or give some compilation warning at least)?

> I can understand not being able to see i0 in intervals_equal, but I
> don't understand not being able to see prev and newi in the caller.  I
> tried to reproduce this with CFLAGS="-g -DENABLE_CHECKING=1
> -DSYSTEM_PURESIZE_EXTRA=1300000", ie, no optimisation, but could not
> reproduce the abort (or call of error).

The fact that you don't get the assertion failure when compiling without
optimizations indicates that this assertion failure is unlikely to
be a fluke, tho the "CHECK (!INT_LISPLIKE (i)" thingy is fishy.

The fields of the i1 interval don't seem to be valid (0x8 can't be
a left pointer, the right point seems to be misaligned (maybe it's
actually a string and the up_obj bit should be set), total_length and
position could only make sense in a buffer of at least 5-6MB).
Then again, we have no idea if we're really looking at i1 and
its contents.

> Do you think these ENABLE_CHECKING aborts are genuine?

Maybe.

> Could there be a problem with the definition of NULL_INTERVAL_P (I see
> its definition has changed)?

The INT_LISPLIKE thingy is fishy.  I suspect that it may misfire (the
"struct interval" may have size 28, so intervals pointers may not all be
aligned on multiples of 8, which implies that an interval pointer may
have the same tag bits as a buffer).

> So, ENABLE_CHECKING not withstanding, it appears to be a problem with
> the optimisation of intervals.c itself.
> Any other thoughts?

Not really.  If you can reproduce it without optimizations, then you may
be able to track it down more precisely and figure out if it's
a compiler bug or an Emacs bug.


        Stefan