Description of problem: 29.855121321 - 5.92034325 should not be NULL, but it is under 3.5.9-2 compiled with gcc 4.3.2. gcc 4.3.2 miscompiles SQLite with optimization above -O1. It's *not* the -ffast-math problem; it's something else. The problem does not appear unless function inlining is enabled. However, the latest SQLite, 3.6.6.2, compiles and runs just fine.
3.6.6.2 is already in rawhide. Did you mean to file this for F10?
Yes. :-)
This is really serious -- can we increase the priority on this and have an update for f10? Seriously, the sqlite that comes with f10 can hardly do *any* floating point arithmetic properly -- try this: select 1.0/3.0; and it comes out null! I was using sqlite to figure grades and I've been trying to figure out all morning why everything suddenly went wrong when I ran queries that work fine under f8 under f10. I rebuilt and installed the 3.6.6.2-4 package from the development tree and I'll give it a try -- seems to be working so far. This really can't wait until f11 comes out!
I'd like to second the requests. Today I've stumbled over the division problem, too. Using floating point arithmetics in select statements seems to have some issues. I've played a little bit with various optimization options and as Daniel mentioned in the bug report, the problems are caused by this optimization option: "-finline-small-functions". The attached patch turns off this specific optimization and sqlite will be able to do floating point arithmetics again. I'm not an compiler expert so I can't say anything about the real performance loss, but I would expect it is not significant. It would be great if a fix like this could find its way into F10. Thank you very much in advance.
Created attachment 328915 [details] patch to turn off -finline-small-functions
Hmm, this appears to be somewhat arch-specific: [pmatilai@localhost ~]$ rpm -q sqlite sqlite-3.5.9-2.fc10.x86_64 [pmatilai@localhost ~]$ sqlite3 SQLite version 3.5.9 Enter ".help" for instructions sqlite> select 1.0/3.0; 0.333333333333333 sqlite> select 29.855121321 - 5.92034325; 23.934778071 sqlite> Are you folks using ix86 (or something else)? Just trying to figure what would be the best fix here. FWIW the reason I'm somewhat against updating F10 to sqlite 3.6 is that it has some incompatible changes. The incompatibilities are limited to obscure corner cases but still...
(In reply to comment #6) > [pmatilai@localhost ~]$ rpm -q sqlite > sqlite-3.5.9-2.fc10.x86_64 > sqlite> select 1.0/3.0; > 0.333333333333333 > Are you folks using ix86 (or something else)? Just trying to figure what would > be the best fix here. I've seen the problem on X86 (32): sqlite-3.5.9-2.fc10.i386 ... SQLite version 3.5.9 Enter ".help" for instructions sqlite> select 1.0/3.0; sqlite> > FWIW the reason I'm somewhat against updating F10 to sqlite 3.6 is that it has > some incompatible changes. The incompatibilities are limited to obscure corner > cases but still... I fully understand the concerns and I agree that an update to 3.6.x would be too risky in a stable release (and so should be better done in rawhide). What do you think about my suggestion just to turn off the problematic optimization (without any other changes, see my attached patch). The only drawback I could imagine would be performance related - but if the package would stay 2 weeks or so in updates-testing, it should be most likely safe enough. What do you think?
If the problem is a buggy compiler optimization then I'd certainly be happy with a recompiled package of 3.5.9. Correct calculation certainly trumps speed. And someone who knows what's going on under the hood ought to file a bug for gcc. So many other programs use sqlite under the hood these days --- I'm a little surprised this bug hasn't caused more things to fail.
Created attachment 329276 [details] Upstream fix After some more digging, this appears to be the same as this Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488864, and the upstream fix is here: http://www.sqlite.org/cvstrac/chngview?cn=5396 "Improved NaN testing for highly optimized GCC on x86" seems to make sense as I can't reproduce this (I only have x86_64 boxes here). Can you test if the attached patch fixes the issue?
sqlite-3.5.9-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/sqlite-3.5.9-3.fc10
Heh, bodhi was faster than me... Anyway the issue was reproducable on x86_64 too by building a 32bit version, and the above patch indeed fixed it. Until it hits the testing repo the build can be found in koji here: http://koji.fedoraproject.org/koji/buildinfo?buildID=79083
(In reply to comment #11) > Heh, bodhi was faster than me... Anyway the issue was reproducable on x86_64 > too by building a 32bit version, and the above patch indeed fixed it. Until it > hits the testing repo the build can be found in koji here: > http://koji.fedoraproject.org/koji/buildinfo?buildID=79083 I've tested sqlite-3.5.9-3.fc10.i386.rpm which includes this fix and I'd like to confirm that the new package with the upstream patch solves the problem. Thanks!
sqlite-3.5.9-3.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update sqlite'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0820
*** Bug 452591 has been marked as a duplicate of this bug. ***
sqlite-3.5.9-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.