"Ben Wing" <wing(a)666.com> writes:
the crashes tend to occur in random places. they vary from one build
to
the next. often in pdump. vc++ does crash somewhere in pdump, in
differing places from build to build. compiling sans union type makes the
problem disappear.
It does only mean that there is a bug somethere in the code (not
neccesarily directly related to the union type, because it can be
combination of several factors). No reason yet to claim that the compiler
itself is buggy.
once i tracked the problem down and it was that gcc did not do
structure
assignments completely in parallel in all situations. with sufficiently
complicated expressions of the form x = f(x), where x is a structure, it
would sometimes think that it had correctly computed one of the fields, and
assign it a value, when in fact the old value was still needed elsewhere in
the expression.
Almost 100% it's programmer's error, relying on the unspecified order of
subexpressions evaluation, if I correctly understand you.
i wrote to the gcc developers and they got very defensive
and quoted a section of the ansi standard, saying "well, we agree your
expected behavior is reasonable but *technically* it's not required by the
ansi standard."
Probably I would agree with them (again, can you show any example?)
this only happened with mule and error-checking, because
the expression was much more complicated that way. by rewriting it using
temporaries, the problem went away.
debugging problems with pdump is extremely difficult so i'd rather not do
it when it's almost certainly a compiler problem.
In fact this sentense is just equivalent to "It's hard to find and fix the
bug in the XEmacs, probably living in the code using union type". Maybe. But it
definitely does not mean that
--use-union-type has a tendency to trigger compiler bugs, especially
in
combination with other features that increase the complexity of expressions
Compiler bugs should be proven. The presence of crash is obviously not enough.
- Dmitry Bely