Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 May 2003 16:30:12 -0400
From:      Mikhail Teterin <mi+mx@aldan.algebra.com>
To:        David Schultz <das@FreeBSD.ORG>
Cc:        freebsd-bugs@FreeBSD.ORG
Subject:   Re: bin/43299: march=pentium4 miscompiles msun/src/e_pow.c
Message-ID:  <200305131630.12451.mi%2Bmx@aldan.algebra.com>
In-Reply-To: <20030513180417.GA4917@HAL9000.homeunix.com>
References:  <200305131610.h4DGA8vx007871@freefall.freebsd.org> <20030513180417.GA4917@HAL9000.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Boundary-00=_UXVw+Srlan1UKc3
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Tuesday 13 May 2003 02:04 pm, David Schultz wrote:
 
= >  As can be seen above, using pentium3 produces the correct result, while
= >  pentium4 produces the incorrect 0. We can, pretty much, rule out a kernel
= >  problem in handling MMX/SSE. Which is it -- our __ieee754_pow or the gcc?
= 
= gcc is using SSE instructions in the Pentium 4 case:

Are these SSE, which pentium3 also has, or the SSE2?
 
= [...]
= -       fxch    %st(1)
= -       fstpl   -56(%ebp)
= -       movl    -56(%ebp), %ecx
= -       movl    %ecx, -56(%ebp)
= -       movl    %edi, -52(%ebp)
= -       fldl    -56(%ebp)
= +       movd    %edi, %xmm0
= +       movsd   %xmm0, -64(%ebp)
= +       fldl    -64(%ebp)
= [...]
= 
= It's possible that gcc screwed something up wrt alignment or has
= some sort of bug in the generation of SSE instructions.

It seems like the problem is inside the SET_HIGH_WORD(ax, ix) macro
on line e_pow.c:214, which expands into
into

	do {
		ieee_double_shape_type sh_u;

		sh_u.value = (ax);
		sh_u.parts.msw = (ix);
		(ax) = sh_u.value;
	} while (0);

for whatever reason, if compiled for pentium4 with -O1, the line

	sh_u.value = (ax)

is SKIPPED -- according to the debugger. ax ends up filled with junk,
which screws everything up afterwards... I'm attaching the simple test
file (the skipped line is 34 in it). If compiled for p3 or for p4 with
-O0, the result is 0.5. When compiled for p4 with -O1, the result
is junk. The junk is persistent -- I'm getting ``5.29463e-315'' on
both FreeBSD (gcc version 3.2.2 20030205) and Linux (gcc version 3.2
20020903).

But I don't know assembly-code. Could you look at it? Thanks!

	-mi


--Boundary-00=_UXVw+Srlan1UKc3--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305131630.12451.mi%2Bmx>