AC_LANG_BOOL_COMPILE_TRY(C) fails with OS vendor compilers

[Noah Misch]

>From CVS HEAD lib/autoconf/c.m4:

> # AC_LANG_BOOL_COMPILE_TRY(C)(PROLOGUE, EXPRESSION)
> # -------------------------------------------------
> # The C standard does not require a diagnostic when we compute 1 / 0
> # at compile-time, but we don't know of any compiler that fails to
> # diagnose this.  Diagnostics are required for some other expressions
> # (e.g., ((EXPRESSION) ? 0 : (0, 0)), INT_MAX + !!(EXPRESSION)),
> # but they don't work as well in practice.
> m4_define([AC_LANG_BOOL_COMPILE_TRY(C)],
> [AC_LANG_PROGRAM([$1], [static int v = 1 / !!($2);
> v = 0;
> ])])

Though all compilers do seem to issue at least at warning for a guaranteed
division by zero, some (HP/UX 11.23 cc/aCC and Tru64 4.0 cc) do not return
non-zero on that account.  This makes tests that depend upon the above macro
unreliable with these compilers.

The side effects work out to be fairly harmless.  Affected Autoconf configure
script runs never define __CHAR_UNSIGNED__ and always define HAVE_LONG_DOUBLE.
When cross-compiling, every AC_CHECK_SIZEOF will return zero.  Since nearly all
cross compilation of GNU software uses gcc, the last issue may be more of a
theoretical eyesore than anything else.  Even the others will affect only a few
programs on few platforms with a few compilers.

That said, I'd like to fix it.  Would one of the following be appropriate?

1) Change the test such that it creates truly invalid C in the false case.  I
   don't know how to do this, but perhaps a reader does.  Ideas?

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.  Use that switch
   in compilations from AC_LANG_BOOL_TRY_COMPILE(C).  If ``configure'' finds no
   such switch, it will print a stern warning.  This switches I know of are as
   follows; when more than one switch works for a particular compiler, I list
   both.  If you can provide the flags for vendor compilers I have not listed
   (at least IBM, Sun, and SGI would be nice), please do so.
   
   **Compiler**                                               **Switch**
   Compaq C V6.5-207 (dtk) on Digital UNIX V4.0G (Rev. 1530)  -msg_fatal zerodiv
   Compaq C V6.5-207 (dtk) on Digital UNIX V4.0G (Rev. 1530)  -w3
   HP aC++/ANSI C B3910B A.05.56 [June 09 2004] [aCC6_beta]   +We
   HP aC++/ANSI C B3910B A.05.56 [June 09 2004] [aCC6_beta]   +We2039
   HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]                +We
   HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]                +We155
   icc 8.0 for ia64 Linux                                     none needed
   gcc 2.95.3                                                 none needed
   gcc 3.X                                                    none needed
   OpenVMS CC                                                 none available(?)

3) Don't bother.  The code uglification is not worth the small reduction in
   bugs.  Perhaps just document the limitation and print a warning upon use of
   an affected test with a non-gcc compiler.

4) I have better idea _______.

Thanks.