database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-12-24 14:17:58 +03:00
Code Activity

Exclude two recently added tests in where.test from valgrind runs. They fail due to the subtly different handling of real numbers under valgrind.

Browse Source 
FossilOrigin-Name: e842d2085b295ef1c927611f5d3b211fb6b513ca2676c074fe90331da81734eb
This commit is contained in:
dan
2021-11-23 11:34:43 +00:00
parent 70a05e9168
commit 619a5f5572
3 changed files with 24 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
test/where.test
View File

@@ -1576,14 +1576,22 @@ do_execsql_test where-26.8 {
# floating point values that are near 9223372036854775807 in the
# OP_SeekGE opcode (and similar).
#
reset_db
do_execsql_test where-27.1 {
CREATE TABLE t1(a INTEGER PRIMARY KEY);
INSERT INTO t1(a) VALUES(9223372036854775807);
SELECT 1 FROM t1 WHERE a>=(9223372036854775807+1);
} {}
do_execsql_test where-27.2 {
SELECT a>=9223372036854775807+1 FROM t1;
} {0}
# Valgrind documentation acknowledges that under valgrind, FP calculations
# may not be as accurate as on x86/amd64 hardware. This seems to be causing
# these tests to fail.
#
# https://valgrind.org/docs/manual/manual-core.html#manual-core.limits
#
if {[permutation]!="valgrind"} {
reset_db
do_execsql_test where-27.1 {
CREATE TABLE t1(a INTEGER PRIMARY KEY);
INSERT INTO t1(a) VALUES(9223372036854775807);
SELECT 1 FROM t1 WHERE a>=(9223372036854775807+1);
} {}
do_execsql_test where-27.2 {
SELECT a>=9223372036854775807+1 FROM t1;
} {0}
}
finish_test