This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Some tests in gcc.c-torture rely on undefined behaviour?
- From: Nicholas Nethercote <njn at cs dot utexas dot edu>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 12 Jul 2005 09:41:22 -0500 (CDT)
- Subject: Some tests in gcc.c-torture rely on undefined behaviour?
Hi,
I've been looking at the gcc.c-torture tests, it seems some of them rely
on undefined behaviour. For example, 920612-1.c looks like this:
f(j)int j;{return++j>0;}
main(){if(f((~0U)>>1))abort();exit(0);}
AIUI, this passes the largest possible positive integer to f(), which then
increments it, causing signed overflow, the result of which is undefined.
The test passes if signed overflow wraps.
930529-1.c is similar -- again the maximum positive integer is
incremented.
20020508-2.c has the following code (abridged):
#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif
#define ROR(a,b) (((a) >> (b)) | ((a) << ((sizeof (a) * CHAR_BIT) - (b))))
#define INT_VALUE ((int)0x1234)
#define SHIFT1 4
int i = INT_VALUE;
int shift1 = SHIFT1;
if (ROR (i, shift1) != ROR (INT_VALUE, SHIFT1))
abort ();
Similarly, the left-shifting in ROR causes signed integer overflow (I
think) and so ROR relies on undefined behaviour. 20020508-3.c is similar.
My question is: what exactly is gcc.c-torture testing? It seems to be
testing more than just C standard compliance, but also certain
undefined-but-desired behaviours, such as wrap-on-signed-overflow (at
least in some cases). Is that right? If so, other C compilers could be
correct with respect to the C standard but not pass all the tests. I
couldn't find any kind of README or description about the tests that
covered this point, so I'd appreciate any explanations.
Thanks.
Nick