Fix the int8 and int2 cases of (minimum possible integer) % (-1).

The correct answer for this (or any other case with arg2 = -1) is zero,
but some machines throw a floating-point exception instead of behaving
sanely.  Commit f9ac414c dealt with this
in int4mod, but overlooked the fact that it also happens in int8mod
(at least on my Linux x86_64 machine).  Protect int2mod as well; it's
not clear whether any machines fail there (mine does not) but since the
test is so cheap it seems better safe than sorry.  While at it, simplify
the original guard in int4mod: we need only check for arg2 == -1, we
don't need to check arg1 explicitly.

Xi Wang, with some editing by me.

src/backend/utils/adt/int.c

@@ -1095,8 +1095,12 @@ int4mod(PG_FUNCTION_ARGS)
 		PG_RETURN_NULL();
 	}
 
-	/* SELECT ((-2147483648)::int4) % (-1); causes a floating point exception */
-	if (arg1 == INT_MIN && arg2 == -1)
+	/*
+	 * Some machines throw a floating-point exception for INT_MIN % -1, which
+	 * is a bit silly since the correct answer is perfectly well-defined,
+	 * namely zero.
+	 */
+	if (arg2 == -1)
 		PG_RETURN_INT32(0);
 
 	/* No overflow is possible */
@@ -1119,6 +1123,15 @@ int2mod(PG_FUNCTION_ARGS)
 		PG_RETURN_NULL();
 	}
 
+	/*
+	 * Some machines throw a floating-point exception for INT_MIN % -1, which
+	 * is a bit silly since the correct answer is perfectly well-defined,
+	 * namely zero.  (It's not clear this ever happens when dealing with
+	 * int16, but we might as well have the test for safety.)
+	 */
+	if (arg2 == -1)
+		PG_RETURN_INT16(0);
+
 	/* No overflow is possible */
 
 	PG_RETURN_INT16(arg1 % arg2);

src/backend/utils/adt/int8.c

@@ -649,6 +649,14 @@ int8mod(PG_FUNCTION_ARGS)
 		PG_RETURN_NULL();
 	}
 
+	/*
+	 * Some machines throw a floating-point exception for INT64_MIN % -1,
+	 * which is a bit silly since the correct answer is perfectly
+	 * well-defined, namely zero.
+	 */
+	if (arg2 == -1)
+		PG_RETURN_INT64(0);
+
 	/* No overflow is possible */
 
 	PG_RETURN_INT64(arg1 % arg2);