[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_LANG_BOOL_COMPILE_TRY(C) fails with OS vendor compilers
From: |
Noah Misch |
Subject: |
Re: AC_LANG_BOOL_COMPILE_TRY(C) fails with OS vendor compilers |
Date: |
Mon, 5 Jul 2004 02:32:49 -0700 |
User-agent: |
Mutt/1.5.6i |
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.