diff -ur sqlite-src.old/src/util.c sqlite-src-3071700/src/util.c
--- sqlite-src.old/src/util.c	2013-11-28 09:57:32.167493980 +0100
+++ sqlite-src-3071700/src/util.c	2013-11-28 09:59:01.877811972 +0100
@@ -511,7 +511,7 @@
     u = u*10 + c - '0';
   }
   if( u>LARGEST_INT64 ){
-    *pNum = SMALLEST_INT64;
+    *pNum = neg ? SMALLEST_INT64 : LARGEST_INT64;
   }else if( neg ){
     *pNum = -(i64)u;
   }else{
@@ -542,7 +542,6 @@
       /* zNum is exactly 9223372036854775808.  Fits if negative.  The
       ** special case 2 overflow if positive */
       assert( u-1==LARGEST_INT64 );
-      assert( (*pNum)==SMALLEST_INT64 );
       return neg ? 0 : 2;
     }
   }
diff -ur sqlite-src.old/src/vdbe.c sqlite-src-3071700/src/vdbe.c
--- sqlite-src.old/src/vdbe.c	2013-11-28 09:57:32.162493963 +0100
+++ sqlite-src-3071700/src/vdbe.c	2013-11-28 10:04:01.533814781 +0100
@@ -3465,7 +3465,9 @@
         ** point number. */
         assert( (pIn3->flags & MEM_Real)!=0 );
 
-        if( iKey==SMALLEST_INT64 && (pIn3->r<(double)iKey || pIn3->r>0) ){
+        if( (iKey==SMALLEST_INT64 && pIn3->r<(double)iKey)
+         || (iKey==LARGEST_INT64 && pIn3->r>(double)iKey)
+        ){
           /* The P3 value is too large in magnitude to be expressed as an
           ** integer. */
           res = 1;
diff -ur sqlite-src.old/src/vdbemem.c sqlite-src-3071700/src/vdbemem.c
--- sqlite-src.old/src/vdbemem.c	2013-11-28 09:57:32.162493963 +0100
+++ sqlite-src-3071700/src/vdbemem.c	2013-11-28 10:00:14.877065531 +0100
@@ -303,15 +303,8 @@
 
 /*
 ** Convert a 64-bit IEEE double into a 64-bit signed integer.
-** If the double is too large, return 0x8000000000000000.
-**
-** Most systems appear to do this simply by assigning
-** variables and without the extra range tests.  But
-** there are reports that windows throws an expection
-** if the floating point value is out of range. (See ticket #2880.)
-** Because we do not completely understand the problem, we will
-** take the conservative approach and always do range tests
-** before attempting the conversion.
+** If the double is out of range of a 64-bit signed integer then
+** return the closest available 64-bit signed integer.
 */
 static i64 doubleToInt64(double r){
 #ifdef SQLITE_OMIT_FLOATING_POINT
@@ -328,14 +321,10 @@
   static const i64 maxInt = LARGEST_INT64;
   static const i64 minInt = SMALLEST_INT64;
 
-  if( r<(double)minInt ){
-    return minInt;
-  }else if( r>(double)maxInt ){
-    /* minInt is correct here - not maxInt.  It turns out that assigning
-    ** a very large positive number to an integer results in a very large
-    ** negative integer.  This makes no sense, but it is what x86 hardware
-    ** does so for compatibility we will do the same in software. */
+  if( r<=(double)minInt ){
     return minInt;
+  }else if( r>=(double)maxInt ){
+    return maxInt;
   }else{
     return (i64)r;
   }
@@ -417,17 +406,11 @@
   **
   ** The second and third terms in the following conditional enforces
   ** the second condition under the assumption that addition overflow causes
-  ** values to wrap around.  On x86 hardware, the third term is always
-  ** true and could be omitted.  But we leave it in because other
-  ** architectures might behave differently.
+  ** values to wrap around.
   */
   if( pMem->r==(double)pMem->u.i
    && pMem->u.i>SMALLEST_INT64
-#if defined(__i486__) || defined(__x86_64__)
-   && ALWAYS(pMem->u.i<LARGEST_INT64)
-#else
    && pMem->u.i<LARGEST_INT64
-#endif
   ){
     pMem->flags |= MEM_Int;
   }
diff -ur sqlite-src.old/test/autoinc.test sqlite-src-3071700/test/autoinc.test
--- sqlite-src.old/test/autoinc.test	2013-11-28 09:57:32.145493901 +0100
+++ sqlite-src-3071700/test/autoinc.test	2013-11-28 10:00:25.973101898 +0100
@@ -216,7 +216,7 @@
 } {t1 1238}
 do_test autoinc-2.28 {
   execsql {
-    UPDATE sqlite_sequence SET seq='12345678901234567890'
+    UPDATE sqlite_sequence SET seq='-12345678901234567890'
       WHERE name='t1';
     INSERT INTO t1 VALUES(NULL,6);
     SELECT * FROM t1;
diff -ur sqlite-src.old/test/e_expr.test sqlite-src-3071700/test/e_expr.test
--- sqlite-src.old/test/e_expr.test	2013-11-28 09:57:32.130493848 +0100
+++ sqlite-src-3071700/test/e_expr.test	2013-11-28 10:00:32.053121919 +0100
@@ -1606,14 +1606,14 @@
 # an INTEGER then the result of the cast is the largest negative
 # integer: -9223372036854775808.
 #
-do_expr_test e_expr-31.2.1 { CAST(2e+50 AS INT) } integer -9223372036854775808
+do_expr_test e_expr-31.2.1 { CAST(2e+50 AS INT) } integer 9223372036854775807
 do_expr_test e_expr-31.2.2 { CAST(-2e+50 AS INT) } integer -9223372036854775808
 do_expr_test e_expr-31.2.3 { 
   CAST(-9223372036854775809.0 AS INT)
 } integer -9223372036854775808
 do_expr_test e_expr-31.2.4 { 
   CAST(9223372036854775809.0 AS INT)
-} integer -9223372036854775808
+} integer 9223372036854775807
 
 
 # EVIDENCE-OF: R-09295-61337 Casting a TEXT or BLOB value into NUMERIC