Some tests in gcc.c-torture rely on undefined behaviour?

[Nicholas Nethercote]

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