Bug 112222
| Summary: | [libc] 32-bit libc incorrectly converts some FP numbers | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Peter Jeremy <PeterJeremy> |
| Component: | amd64 | Assignee: | freebsd-amd64 (Nobody) <amd64> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 6.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
On 2007-Apr-29 09:54:41 +1000, Peter Jeremy <peterjeremy@optushome.com.au> wrote: > Further testing has localised the problem to dtoa(), though it is > not yet clear whether the problem is in the source code, the > compiler or the 32-bit cross-build part of buildworld. I've narrowed the problem down to the -msse2 that is in the version of Makefile.inc1 that I have. I notice that this flag was removed in Makefile.inc1 v1.499.2.18. Some manual experimenting with the CFLAGS implied by that Makefile suggests that the problem goes away with the newer Makefile.inc1. I will upgrade world and retry. -- Peter Jeremy I tried to replicate this on my amd64 system running 7-PRERELEASE and gcc 4.2.1 but got the expected result. Is this PR still an issue? -- Bruce Cran Is this a duplicate of kern/102424? -- Bruce Cran if this issue has indeed been fixed by gcc commit r117331 (http://gcc.gnu.org/viewcvs?view=revision&revision=117331) the only branch it still applies to is stable/6. since it is very unlikely that a committer will backport these changes to gcc 3.4.6 the pr should be closed. -- Alexander Best State Changed From-To: open->closed This had been resolved in all branches (head/8/7) and can no longer be reproduced. |
During testing of some 32-bit code on amd64, nonsense was printed for some floating point conversions, eg ':e+22' instead of 1e+23 or ':e-07' instead of 1e-06. Further testing has localised the problem to dtoa(), though it is not yet clear whether the problem is in the source code, the compiler or the 32-bit cross-build part of buildworld. The problem only appears to affect numbers with a decimal fractional part of 1 and decimal exponents of -307, -298, -283, -280, -278, -277, -275, -274, -272, -271, -269, -268, -260, -258, -145, -96, -94, -93, -88, -85, -82, -81, -80, -77, -76, -75, -74, -72, -71, -69, -67, -66, -65, -64, -49, -40, -39, -36, -34, -29, -28, -24, -23, -20, -19, -16, -14, -12, -11, -7, -6, +23, +24, +28, +29, +31, +35, +36, +38, +40, +41, +42, +43, +46, +47, +48, +51, +52, +53, +55, +57, +59, +62, +65, +66, +67, +68, +72, +73, +74, +77, +78, +79, +80, +82, +85, +86, +87, +88, +89, +90, +94, +95, +96, +97, +98, +100, +103, +104, +108, +110, +113, +114, +115, +116, +117, +121, +122, +129, +130, +132, +133, +136, +137, +138, +139, +140, +141, +142, +143, +144, +145, +148, +149, +151, +152, +153, +154, +155, +172, +174, +178, +182, +190, +191, +192, +193, +198, +201, +205, +206, +207, +209, +216, +218, +221, +222, +223, +227, +230, +243, +244, +246, +252, +262, +263, +267, +268, +271, +273, +275, +277, +278, +283, +285, +288, +289, +290, +292, +294, +297, +299, +300, +301, +302, +303, +306. Linking against libc/gdtoa_dtoa.o compiled in an i386 environment does not show the problem. Fix: Unknown. How-To-Repeat: echo 'main(){printf("%g %g %g\\n", 1e-24, 1e-7, 1e100);}' > x.c cc -m32 x.c ./a.out