3:23 p.m.
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.
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. 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." 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.
why is everyone so keen on union type? the vc++ debugger is broken anyway when handling
unions, as are many other debuggers. (it chokes and does not let you call debug_print() on
a union.) furthermore, you can't type a raw union into a debugger expression, unlike
an int. there is no guarantee that a compiler will correctly optimize a 4-byte union into
a register. if you want the compiler to convert your 4-byte union into an int, just use
an int for god's sake!
and if it does turn out we're relying on undefined behavior, then my question goes
doubly, why do we want the union? there is *NO* undefined behavior with ints.
------- Original Message -------
On
Sat, 21 Dec 2002 17:08:30 +0300 Dmitry Bely?wrote:
"Ben Wing" <wing(a)666.com> writes:
> yes, i definitely have discovered compiler problems in the past. there's
> another message in which i wrote about this yesterday, i think.
Hmm, I have not found anything concrete.
> when
> expressions got too complicated, gcc failed to do structure assignments
> completely in parallel.
You told that VC++ also suffers from this "union bug". Can I see a piece
of code that reproduces it for VC++ 6.0 sp5? (or at least can you tell me
where it crashes in XEmacs)
> the bugs only occur usually when you turn on
> error-checking and mule, because these options greatly increase the
> complexity of the expressions. OCaml may simply not have any code with the
> expression complexity that we have.
Maybe. But I would rather believe into the code with undefined behaviour
(you know, C is a sort of mine field :-)), than in VC++ union bug (until I
see an example :-))
- Dmitry Bely
10:58 p.m.
New subject: union type is evil, redux
"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
6:54 a.m.
New subject: union type is evil, redux
>>>> "Dmitry" == Dmitry Bely
<dbely(a)mail.ru> writes:
Dmitry> Compiler bugs should be proven. The presence of crash is
Dmitry> obviously not enough.
Everything should be proven. There should be no crashes. Good luck.
The question is, is it worth proving some particular thing? If you
ask me, the compiler (and library) authors should be more interested
in getting code that works under the broadest possible set of
circumstances rather than defending whatever tricky thing they
currently do, relying on the ability to excuse silly behavior with
"the standard doesn't guarantee sane behavior in this case."
While I strongly dislike faking a union with casts, I sympathize with
Ben having recently had a similar experience with malloc. I don't
think that having a standard is meaningful unless (a) it's obvious by
Patent Office standards or (b) the people who are excusing surprising
behavior with "the standard says it's OK" are willing to explain how to
go about writing compliant code. Neither (a) nor (b) is satisfied in
the "union builds crash when they shouldn't" case.
Basically what it comes down to is the compiler writers are saying "we
don't support union type when you use it to make obscure things clear,
only when you use it to make trivial things verbose." Why bother?
Ben's reaction, though a little violent, is perfectly plausible: OK,
we'll deprecate union type since in practice we can't rely on
reasonable behavior.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:28 p.m.
New subject: union type is evil, redux
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Dmitry> Compiler bugs should be proven. The presence of crash
is
Dmitry> obviously not enough.
Everything should be proven. There should be no crashes. Good luck.
Thanks for the best wishes :-) "Compiler bug" is too strong and relatively
unlikely claim (like "my program crashes because cosmic rays causes
mailfunction in my computer" :-)), so some proof is really needed.
The question is, is it worth proving some particular thing? If you
ask me, the compiler (and library) authors should be more interested
in getting code that works under the broadest possible set of
circumstances rather than defending whatever tricky thing they
currently do, relying on the ability to excuse silly behavior with
"the standard doesn't guarantee sane behavior in this case."
You can propose something else? There is ANSI C standard, that leaves some
things undefined (e.g. for perfomance or portability reasons), so "silly"
is just your emotions. Just an example:
int multiply( int x, int y ){ return x * y; }
/*
*...
*/
int a = 2;
int b = multiply( a++, a);
/* can you predict b value here? */
Would you blame C compilers for that?
Good or bad is the current ANSI C standard, its the only ground we have. If
somebody does not follow the strict standard specs (no matter how logical
or obvious his/her intentions was), it's his/her bug, not the compiler
problem.
While I strongly dislike faking a union with casts, I sympathize
with
Ben having recently had a similar experience with malloc. I don't
think that having a standard is meaningful unless (a) it's obvious by
Patent Office standards or (b) the people who are excusing surprising
behavior with "the standard says it's OK" are willing to explain how to
go about writing compliant code. Neither (a) nor (b) is satisfied in
the "union builds crash when they shouldn't" case.
Which code piece is problematic in the union case? If it's already
discussed in the pass, can you give me the reference? I am asking this over
and over again but does not see any response yet. This talk should be
specific otherwise it's quite useless.
Basically what it comes down to is the compiler writers are saying
"we
don't support union type when you use it to make obscure things clear,
only when you use it to make trivial things verbose." Why bother?
Again, it's just words. Can you show any problematic code?
Ben's reaction, though a little violent, is perfectly plausible:
OK,
we'll deprecate union type since in practice we can't rely on
reasonable behavior.
Please don't misunderstand me, I am not going to teach anybody how to
program. But "fixing" the bugs by avoiding some language constructs
(without any guarantee that the bug won't reveal itself in other place)
does not seem to be very appealing to me...
- Dmitry Bely
P.S. Sorry if my message seems to be offensive for anybody. My intention
was just the technical discussion and nothing else.
4:07 a.m.
New subject: union type is evil, redux
>>>> "Dmitry" == Dmitry Bely
<dbely(a)mail.ru> writes:
Dmitry> Thanks for the best wishes :-) "Compiler bug" is too
Dmitry> strong and relatively unlikely claim
OK, so let's stop talking about compiler "bugs" and talk about
compiler _behavior_. Compiler _behavior_ _has_ been proven by Ben in
the past, and the compiler writers refused to change it. I don't
think it's unreasonable, when combined with the circumstantial
evidence of "crash goes away with --use-union-type=no", to presume
that unions still don't work as XEmacs code expects them to.
The question then is "Will the compiler change its behavior, or must
XEmacs change its code? If the latter, should we try to conform to
the standard, or should we deprecate the troublesome construct since
we already have a working alternative?" From Ben's point of view, the
answer is obvious.
Dmitry> If somebody does not follow the strict standard specs (no
Dmitry> matter how logical or obvious his/her intentions was),
Dmitry> it's his/her bug, not the compiler problem.
It _is_ a compiler problem (in a different sense), because a feature
that the vendor has gone to some effort to support (a) cannot be used
and (b) decreases user confidence in the reliability of the compiler
for the user's purpose.
If the GCC developers want to say "we have good reason for doing it
this way, and therefore it's unlikely to change", I can't object to
that. But it's reasonable then to deprecate use of --use-union-type
in XEmacs, which is all that's in question here.
Dmitry> Again, it's just words.
Yes, but it's the _vendor_'s words. Ben says he demonstrated the
behavior, they admitted it, and they refused to change it.
Dmitry> But "fixing" the bugs by avoiding some language constructs
Dmitry> (without any guarantee that the bug won't reveal itself in
Dmitry> other place) does not seem to be very appealing to me...
It's not appealing to me or Mike Sperber, either. But there's never a
guarantee that you've actually fixed a bug. So the question is "is it
worth trying harder to be more sure?" Ben, who has already worked
hard on the problem (or a similar one), says "No!"
Look, what Ben is saying AFAICT is that where currently we do
Lisp_Object foo (Lisp_Object);
Lisp_Object bar (Lisp_object x) { Lisp_Object y; y = foo(x); return y; }
etc all over the place, it works correctly. That is, with typedef int
Lisp_Object; it fails _intermittently_ with the union type. In order
to make the union type work, probably we'd have to do something like
#define a LISP_ASSIGN macro in order to enforce explicit temporaries
and replace all object assignments with macro calls
Lisp_object bar (Lisp_Object x)
{
Lisp_Object y;
LISP_ASSIGN(y,x);
return y;
}
This is _not_ a win. And replacing just the "dangerous ones" is GCPRO
all over again.
Dmitry> Sorry if my message seems to be offensive for anybody.
I don't consider it offensive, and I doubt Ben does. But I think you
are leaving too little responsibility to the compiler writers. It is
not a purely technical problem. It is also a matter of user
confidence. Theirs to lose....
And remember, where standards don't dictate semantics, it's often[1]
because it's unclear what semantics are appropriate. If users can
make a case that certain semantics are useful and consistent with the
standard, I think that compiler writers, as well as the users, can
(indirectly) benefit from using those semantics.
Footnotes:
[1] Of course, not always. The order of evaluation of arguments is
an immediate counterexample; that ambiguity is dictated by efficiency.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:04 a.m.
New subject: union type is evil, redux
On Tue, 24 Dec 2002 13:07:21 +0900, "Stephen J. Turnbull" said:
Yes, but it's the _vendor_'s words. Ben says he demonstrated
the
behavior, they admitted it, and they refused to change it.
And given that they apparently cited chapter-and-verse to justify their
refusal, I have to consider the GCC people totally in the right on this one.
This leaves us with two basic options:
1) Somebody wraps their brain around the problem code in XEmacs (which may
be quite evil, as you note:
Lisp_object bar (Lisp_Object x)
{
Lisp_Object y;
LISP_ASSIGN(y,x);
return y;
}
This is _not_ a win. And replacing just the "dangerous
ones" is GCPRO
all over again.
Amen. ;) Note that I've pondered this for a bit, and haven't convinced
myself that a sufficiently aggressive compiler may not *still* present us
with great screwage - remember that if the compiler can screw us by reordering
code, it can screw us by reordering the explicit temporaries unless you
flag them as 'volatile' (otherwise it can screw up by optimizing them into
total non-existence). However, 'volatile' has some performance issues that
we'd *NOT* want having inside a LISP_ASSIGN macro....
I don't consider it offensive, and I doubt Ben does. But I think
you
are leaving too little responsibility to the compiler writers. It is
not a purely technical problem. It is also a matter of user
confidence. Theirs to lose....
To be honest, my confidence is more shaken by the out-and-out compiler ICE's
that I've managed to get. There's a routine in XFree86 called
'mipmap2.c'
which will crap the compiler out totally if compiled with '-O3 -march=pentium4
-mfpmath=sse' (though weirdly enough, using -Os rather than -O3 works).
That bug started somewhere back whenever they added fpmath support,
and is still in 3.2.1.
And quite frankly, I'd much rather know the gcc people are devoting their
limited resources to fixing out-and-out *bugs* than trying to "fix" something
with unspecified semantics..
There's always option 2: Heave it over the side. ;)
/Valdis
7:37 a.m.
New subject: union type is evil, redux
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> And given that they apparently cited chapter-and-verse to
Valdis> justify their refusal, I have to consider the GCC people
Valdis> totally in the right on this one.
"Totally" is a bit extreme. Sometimes the standard is broken. And if
they wanted to, the standard permits treating whatever it is they do
as an optional optimization, just as they do "ANSI aliasing" and
"frame pointers" and such, and guaranteeing sanity as a GCC extension
if that option is not set.
Valdis> remember that if the compiler can screw us by reordering
Valdis> code, it can screw us by reordering the explicit
Valdis> temporaries unless you flag them as 'volatile' (otherwise
Valdis> it can screw up by optimizing them into total
Valdis> non-existence).
Since when? AFAIK, explicit temporaries guarantee order of evaluation
for a given expression. Has that changed in the C-late-90s standards?
From what Ben said, it sounds like this is more an "interleaving
separate evaluations" problem (ie, on opposite sides of the = sign).
Valdis> And quite frankly, I'd much rather know the gcc people are
Valdis> devoting their limited resources to fixing out-and-out
Valdis> *bugs* than trying to "fix" something with unspecified
Valdis> semantics.
Oh, I mostly agree.
Valdis> There's always option 2: Heave it over the side. ;)
Well, except for you, all the "I'm with the GCC team" posters also
(implicitly or explicitly) object to dropping union type. Ben was
just frothing about the GCC team, it had no semantic content AFAICT
(ie, he has no intent of following up with a GCC bug report). He just
wants union type deprecated.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:54 a.m.
New subject: union type is evil, redux
I've compiled successfully with union type for many years, with
multiple C and C++ compilers, without any problems. It was a standard
part of my acceptance tests before doing a release of XEmacs.
Martin
5:48 a.m.
New subject: union type is evil, redux
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> I've compiled successfully with union type for many years,
mb> with multiple C and C++ compilers, without any problems. It
mb> was a standard part of my acceptance tests before doing a
mb> release of XEmacs.
Build is one thing---I've caught a fair number of silly typos with
union type, just as I'm sure you did. I always build with union type,
and I have yet to see a build problem with union type that wasn't
either (a) a silly typo or (b) also reflected in the integer type
build.
Run is another thing. Ben claims he sees intermittent (== not during
build, presumably) crashes when building with union type, not when
building without. I can't verify that integer type doesn't crash, as
I normally run the union type build. But I do get "stack stomped"
kinds of crashes very intermittently, especially when heavily using
Gnus.
You're a VM user, right? It seems like the only thing that reliably
gets XEmacs in trouble is Gnus. :-/
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:57 a.m.
New subject: union type is evil, redux
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Run is another thing. Ben claims he sees intermittent (== not during
SJT> build, presumably) crashes when building with union type, not when
SJT> building without. I can't verify that integer type doesn't crash, as
SJT> I normally run the union type build. But I do get "stack stomped"
SJT> kinds of crashes very intermittently, especially when heavily using
SJT> Gnus.
I didn't use union-type for my own personal production use, only for
development testing. But that did include automated `make check'.
SJT> You're a VM user, right? It seems like the only thing that reliably
SJT> gets XEmacs in trouble is Gnus. :-/
We don't have any automated GUI tests.
8:19 a.m.
New subject: union type is evil, redux
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> We don't have any automated GUI tests.
Actually, we do now. I make sure that we can at least put up an X
frame without crashing before rolling the release. :-)
More seriously, I will say I have really come to appreciate
test-harness.el.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:30 p.m.
New subject: union type is evil, redux
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Look, what Ben is saying AFAICT is that where currently we do
Wow! We have finally started the technical discussion! :-)
Lisp_Object foo (Lisp_Object);
Lisp_Object bar (Lisp_object x) { Lisp_Object y; y = foo(x); return y; }
etc all over the place, it works correctly. That is, with typedef int
Lisp_Object; it fails _intermittently_ with the union type. In order
to make the union type work, probably we'd have to do something like
#define a LISP_ASSIGN macro in order to enforce explicit temporaries
and replace all object assignments with macro calls
Lisp_object bar (Lisp_Object x)
{
Lisp_Object y;
LISP_ASSIGN(y,x);
return y;
}
This is _not_ a win. And replacing just the "dangerous ones" is GCPRO
all over again.
Well, looking into the C99 I don't see why the union assignment could be a
problem. Can you or Ben cite the gcc developers reply, explaining why it is
dangerous and not conforming to the C standard?
- Dmitry Bely
3:02 a.m.
New subject: union type is evil, redux
>>>> "Dmitry" == Dmitry Bely
<dbely(a)mail.ru> writes:
Dmitry> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Look, what Ben is saying AFAICT is that where currently we do
Dmitry> Wow! We have finally started the technical discussion! :-)
No, it's been technical all along. It's just that you didn't do the
construction I just did for you. I don't know any more about the
specific details than you do; Ben's messages have all been public.
Dmitry> Well, looking into the C99 I don't see why the union
Dmitry> assignment could be a problem. Can you or Ben cite the gcc
Dmitry> developers reply, explaining why it is dangerous and not
Dmitry> conforming to the C standard?
Ah, we agree then. The standard _seems_ to allow our usage, but it
doesn't, and nobody (except a language lawyer trying to cover the
vendor's ass) can explain why. I say, this is bogus.
As for citing the gcc developers, since Ben mentioned "19.13" this
would be about 1995.
Even if he could find the old message, what it comes down to is a lot
of probably useless work for Ben, no matter how you slice it. This is
not a profitable way for him to spend his time, at least in his
assessment. Ben has a long history of diving into these things once
others present evidence and narrow the field of problematic code. I
think it's reasonable to presume that his reluctance is a matter of
expert judgement, not mere laziness or arrogance, at this point.
That's why I asked for a backtrace/bug report, so that _other_ people
(not limited to you; me and Mike for sure, presumably Glynn Clements
and Valdis Kletnieks, maybe even Martin) can do the work they're
requesting to support --use-union-type, and also recognize the
"--use-union-type syndrome" when they see the symptoms.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
9:02 p.m.
New subject: union type is evil, redux
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Dmitry> Well, looking into the C99 I don't see why the
union
Dmitry> assignment could be a problem. Can you or Ben cite the gcc
Dmitry> developers reply, explaining why it is dangerous and not
Dmitry> conforming to the C standard?
Ah, we agree then. The standard _seems_ to allow our usage, but it
doesn't, and nobody (except a language lawyer trying to cover the
vendor's ass) can explain why. I say, this is bogus.
Are you absolutely sure that the bug is caused by improper union assignment
implementation by compiler vendors, not something else?
As for citing the gcc developers, since Ben mentioned
"19.13" this
would be about 1995.
Even if he could find the old message, what it comes down to is a lot
of probably useless work for Ben, no matter how you slice it. This is
not a profitable way for him to spend his time, at least in his
assessment. Ben has a long history of diving into these things once
others present evidence and narrow the field of problematic code. I
think it's reasonable to presume that his reluctance is a matter of
expert judgement, not mere laziness or arrogance, at this point.
That's why I asked for a backtrace/bug report, so that _other_ people
(not limited to you; me and Mike for sure, presumably Glynn Clements
and Valdis Kletnieks, maybe even Martin) can do the work they're
requesting to support --use-union-type, and also recognize the
"--use-union-type syndrome" when they see the symptoms.
Agree completely. The problem is that we only have Ben's conclusion
(theoretically he can be mistaken, right?) and cannot verify it ourselves
until more info is supplied.
- Dmitry Bely
10:09 p.m.
New subject: union type is evil, redux
On Fri, 27 Dec 2002 00:02:28 +0300, Dmitry Bely said:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Dmitry> Well, looking into the C99 I don't see why the union
> Dmitry> assignment could be a problem. Can you or Ben cite the gcc
> Dmitry> developers reply, explaining why it is dangerous and not
> Dmitry> conforming to the C standard?
>
> Ah, we agree then. The standard _seems_ to allow our usage, but it
> doesn't, and nobody (except a language lawyer trying to cover the
> vendor's ass) can explain why. I say, this is bogus.
Are you absolutely sure that the bug is caused by improper union assignment
implementation by compiler vendors, not something else?
At the risk of being pedantic, the question *should* be "are you absolutely
sure that the bug is caused by a union assignment implementation that
doesn't match our expectations?". I'm at least provisionally assuming that
we're in one of those fuzzy areas where both the gcc compiler and xemacs
code are technically in compliance...
Agree completely. The problem is that we only have Ben's
conclusion
(theoretically he can be mistaken, right?) and cannot verify it ourselves
until more info is supplied.
Amen to that. Of course, language lawyers have been around at least since
before Tom Duff created the Duff Device, so we're following in a time-honored
tradition. On the other hand, over the years, I've been at both ends of
the war - I've tripped over real compiler/optimizer bugs in multiple vendor's
language suites, and I've had optimizers reveal subtle user-program bugs.
I wonder if simply re-arranging the order of the fields in the union would
suffice to work around the bug (as he ducks for cover ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
3:37 a.m.
New subject: union type is evil, redux
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> I wonder if simply re-arranging the order of the fields in
Valdis> the union would suffice to work around the bug (as he
Valdis> ducks for cover ;)
You've got the sources, and it won't even cost you $6 million to
rebuild.
;-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:15 a.m.
New subject: union type is evil, redux
Ben Wing wrote:
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.
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. 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."
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.
This all smells like a type punning bug; does it go away if you
disable optimisation?
--
Glynn Clements <glynn.clements(a)virgin.net>
7789
days inactive
7794
days old
16 comments
6 participants
participants (6)
-
Ben Wing -
Dmitry Bely -
Glynn Clements -
Martin Buchholz -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks