[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: |
Paul Eggert |
Subject: |
Re: AC_LANG_BOOL_COMPILE_TRY(C) fails with OS vendor compilers |
Date: |
Mon, 05 Jul 2004 15:34:13 -0700 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Noah Misch <address@hidden> writes:
> 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.
Yes, that sounds like a good strategy for cross-compiles. For native
compiles, we could bypass all this and simply run a program.
> 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.
It behaves the same as the array size trick, which shouldn't be too
surprising.
- Re: AC_LANG_BOOL_COMPILE_TRY(C) fails with OS vendor compilers, (continued)