Re: AC_LANG_BOOL_COMPILE_TRY(C) fails with OS vendor compilers

[Noah Misch]

On Fri, Jul 02, 2004 at 07:37:25AM -0700, Paul Eggert wrote:

> On the compilers in question, what value does 1/0 return?  Perhaps we
> can make use of that somehow.

On the Compaq CC, the program ``int main() { int c = 1/0; printf("%d\n", c); }''
prints ``0''.

> Another possibility: perhaps these troublesome compilers reject
> arithmetic overflow?  For example, do they reject the expression
> ((short int) 2147483647)?  We could evaluate this expression in
> addition to 1/0.  The reason I'm suggesting this is that the C
> standard requires a diagnostic for overflow, but not for division by
> zero (strange but true....).

That yields no diagnostic on the same compiler.  Alas.

> > 2) Test for the switch (including none) that makes the compiler
> > driver return a nonzero status when a division by zero exists in the
> > code.
> 
> I'd rather not head down that path: it's too much maintenance hassle.
> 
> How about this idea instead?
> 
> 1.  For native compiles, compile, link, and run a program that prints
> 1 or 0 depending on whether x is nonzero.  This avoids the problem.
> 
> 2.  For cross-compiles, use the current strategy, but evaluate both
> 1/!x and 1/!!x.  If both expressions compile, we have a troublesome
> compiler like HP's, so reject the compiler and abort the invocation of
> "configure".  In the error message, suggest to the user that they find
> an option to make the compiler work right, and give the known flags as
> examples.

Testing both 1/!x and 1/!!x is a great idea.  That should flush out most of the
cases in which the compiler does not cooperate with our trick of choice.

How about this?

2.1.  Test { int c[(x) ? 1 : -1];  }
2.2.  Test { int c[!(x) ? 1 : -1]; }
2.3.  If exactly one of 2.1 and 2.2 fails, use result of 2.1.  Else:
2.4.  Test { int c = 1/!!(x); }
2.5.  Test { int c = 1/!(x);  }
2.6.  If exactly one of 2.4 and 2.5 fails, use result of 2.4.  Otherwise,
AC_MSG_ERROR with suggested switched to place in CFLAGS.

This should cover all the cases we have observed, prevent a (minute) regression
in the next release, and report the cases it does not handle.

Another option, should this issue arise again, is to abuse the bit field size
expression:

struct foo { int bar : (x ? 8 : -8); };

This will probably have the exact same success and failure modes as the array
size trick, but I'd be interested to see if Sun CC is kinder to it.