On 04/11/06 11:39, Otto Moerbeek wrote:
On Thu, 6 Apr 2006, chefren wrote:
On 04/05/06 02:07, Andrew Pinski wrote:
Actually I bet ntohs16 is violating C aliasing rules.
Interesting, how do you figure that?
The following diff (backported from gcc PR
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10692>) seems to fix the
problem. I hardly know i386 assembly, so please check if the produced
code is correct.
Cool! We patched & compiled gcc and inspected the new assembly output,
it indeed fixes the bug.
The bug is an over-enthusiastic optimization in gcc, which removes a
"store temporary value to stack" without full justification.
How did you manage to find that Bugzilla PR based on this problem
description? It does not seem trivial!
If I see things correctly, this fix is not in either 3.3.5 or 3.3.6.
Debian -stable backported it into their 3.3.5 gcc.
Yes.
The Bugzilla PR indicates that someone applies the fix to gcc 3.4 and
beyond, the "Debian GCC maintainers" suggest applying it to gcc 3.3,
but the story ends there.
The fix was never applied to the gcc 3.3 branch.
(See line 6936 in
http://gcc.gnu.org/viewcvs/branches/gcc-3_3-branch/gcc/reload1.c?view=markup
)
----
We notice that the upcoming OpenBSD 3.9 still uses gcc 3.3.5.
Is the gcc 3.3 branch still a supported product for the gcc people,
and this a fix that "slipped through the cracks" in their usual
maintenance process?
Or does OpenBSD 3.9 use a "slightly long-in-the-tooth" gcc? In that
case, how is the process of back porting all bug fixes made to gcc 3.4
and onward arranged for OpenBSD?
Now the funny thing is that according to the PR, this is a mk68k
specific bug, although the fix is not in target specific code.
Yes, the originator hit it with mk68k, we hit it with i686, but we see
nothing obvious about the bug that makes clear that it can't be hit
with i386 for example.
Thanks for enlightening us.
+++chefren
