Work around what appears to be a GCC 32-bit optimization problem in the

computeHMS() routine of the date/time logic.

FossilOrigin-Name: aebdbcbebff1319dd00551c9fb9ad4b08859f10e87f097295d564ae1ba188c02

src/date.c

@@ -448,6 +448,32 @@ static void computeYMD(DateTime *p){
   p->validYMD = 1;
 }
 
+/* GCC (and sometimes Clang too) will sometimes be off by 1 millisecond
+** in computeHMS() on 32-bit platforms with optimization enabled.
+** I don't know if this is a compiler bug or a bug in the code.  It is hard
+** to debug because with optimization enabled, gdb skips around so much
+** you cannot see what is happening, and if you try adding debug printf()s
+** to the code, the problem goes away.
+**
+** For now, I will work around the problem by disabling optimizations in
+** the computeHMS() routine.
+**
+** Problem seen using gcc-5.4.0, gcc-9.4.0, clang-10.  Works ok on
+** MSVC, clang-3.4, and clang-6.0.
+**
+** Whatever the problem is, it causes some answers to be off by one
+** millisecond.  So we get results like "2021-03-05 03:04:05.599" instead
+** of the desired result of "2021-03-05 03:04:05.600".
+**
+** To reproduce the problem using TH3:
+**
+**    ./th3make debug.rc -O1 -m32 cfg/c1.cfg cov1/date8.test
+*/
+#if SQLITE_PTRSIZE==4 && GCC_VERSION>0
+#pragma GCC push_options
+#pragma GCC optimize ("O0")
+#endif
+
 /*
 ** Compute the Hour, Minute, and Seconds from the julian day number.
 */
@@ -467,6 +493,11 @@ static void computeHMS(DateTime *p){
   p->validHMS = 1;
 }
 
+/* Reactivate GCC optimization */
+#if SQLITE_PTRSIZE==4 && GCC_VERSION>0
+#pragma GCC pop_options
+#endif
+
 /*
 ** Compute both YMD and HMS
 */