Re: gcc.c-torture/unsorted/pass.c: what is it supposed to test?

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Fri, 27 Feb 2004, Diego Novillo wrote:

> which at first sight doesn't strike me as particularly valid nor
> useful.  What is it supposed to test?  Compiler endurance against
> invalid code?

Probably.  The effective purpose of lots of c-torture tests is that they
once exercised a bug in historically fragile areas of the compiler, and
may do so again.  Invalid calls to unprototyped functions (wrong number of
arguments, or arguments of incompatible types except for the
signed/unsigned and pointer variations permitted in 6.5.2.2#6) could quite
reasonably receive a warning and be compiled into a trap.  Such a warning
is requested in bug 14030 (at least), and I don't think the listing in
trouble.texi, "Certain Changes We Don't Want to Make", is good enough
reason for not making such a warning when the incompatibility may
interfere with subsequent optimisation and code generation.  (Besides,
with unit-at-a-time and intermodule compilation, there is much more scope
for detecting these problems even if the definition of the function
doesn't come before its use and in the same file.)

> What is happening here is that the aliasing code is not marking 'w' nor
> 'q' as call-clobbered because their addresses are casted to int, and so
> no valid pointer holds their address.  So, we mark the call to foo as a
> tail call and then fail later in the back end with:

Casting a pointer to intptr_t (which may be int) *is* a valid way of
passing it to other functions.  So is printing it to a file with printf
%p, casting to intptr_t and printing it to a file as an integer, or
looking at the bits of the pointer and scattering them about memory.

-- 
Joseph S. Myers
jsm@polyomino.org.uk