Jakub Jelinek <[EMAIL PROTECTED]> writes:
> Guess that's because AC_HAVE_FUNCS(isinf) is wrong.
> isinf/isfinite/fpclassify are all documented as macros in ISO C99.
> So
>[AC_MSG_CHECKING(for isinf with )
> AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include
> volatile int x; volatile float f;]],
On Thu, Jul 14, 2005 at 06:27:06PM +0900, Hiroshi Fujishima wrote:
> Andreas Schwab <[EMAIL PROTECTED]> writes:
>
> > Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure
> > script, although whether it is autoconf generated is not clear so far.
>
> Though I don't know the why
Andreas Schwab <[EMAIL PROTECTED]> writes:
> Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure
> script, although whether it is autoconf generated is not clear so far.
Though I don't know the why, rrdtool-1.2.10/configure.ac has the
following macro.
dnl HP-UX 11.00 does no
> Why not just use AC_HAVE_FUNCS(isinf)? IIUC this is part of a configure
> script, although whether it is autoconf generated is not clear so far.
Real men write their configure checks by hand, although whether the rrdtool
maintainer is a male is not clear so far. ;-)
--
Eric Botcazou
Michael Veksler <[EMAIL PROTECTED]> writes:
> Maybe there is a simpler way? For example:
>
> volatile int a;
> volatile double b;
> int main ()
> {
>a = isinf (b);
>return 0;
> }
>
> This way the compiler must not assume anything about 'b',
> making it impossible to optimizes the call to i
Eric Botcazou <[EMAIL PROTECTED]> wrote on 14/07/2005 10:05:50:
[...]
> union U {
> int i;
> double d;
> };
>
> volatile int a;
>
> int
> main (int argc, char *argv[])
> {
> union U u;
> u.i = argc;
> a = isinf (u.d);
> return 0;
> }
>
Doesn't the code display undefined behavior wh
> This may work today, but and still break in the future. This
> will not work (possibly) years from now when gcc will start
> doing VRP on math functions like isinf.
>
> MIN_INT <= argc <= MAX_INT falls well into representable
> values of double (assuming 32 bit int or less). This means
> that the
Eric Botcazou wrote on 14/07/2005 08:59:53:
> The compiler knows the answer of isinf (0) so it again optimizes away the
> call. Try something like:
>
> int a;
>
> int
> main (int argc, char *argv[])
> {
> a = isinf ((double) argc);
> return 0;
> }
This may work today, but and still br
> Oops, the configure script compiling with -O2 optimization.
Clearly not the best option for this kind of tests.
> The compilation of the following code still suceesss.
>
> #include
>
> int a;
>
> int
> main ()
> {
> float f = 0.0;
> a = isinf (f);
> return 0;
> }
The compiler knows the
Joe Buck <[EMAIL PROTECTED]> writes:
>> >> The configure script which is included in rrdtool[1] checks whether
>> >> the system has isinf() as below.
>> >>
>> >> #include
>> >> int
>> >> main ()
>> >> {
>> >> float f = 0.0; isinf(f)
>> >> ;
>> >> return 0;
>> >> }
>> >
>> > The test is clearl
On Jul 13, 2005, at 4:29 PM, Joe Buck wrote:
On Thu, Jul 14, 2005 at 08:16:07AM +0900, Hiroshi Fujishima wrote:
Eric Botcazou <[EMAIL PROTECTED]> writes:
The configure script which is included in rrdtool[1] checks whether
the system has isinf() as below.
#include
int
main ()
{
float f = 0.0;
On Thu, Jul 14, 2005 at 08:16:07AM +0900, Hiroshi Fujishima wrote:
> Eric Botcazou <[EMAIL PROTECTED]> writes:
>
> >> The configure script which is included in rrdtool[1] checks whether
> >> the system has isinf() as below.
> >>
> >> #include
> >> int
> >> main ()
> >> {
> >> float f = 0.0; isinf
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> The configure script which is included in rrdtool[1] checks whether
>> the system has isinf() as below.
>>
>> #include
>> int
>> main ()
>> {
>> float f = 0.0; isinf(f)
>> ;
>> return 0;
>> }
>
> The test is clearly fragile. Assigning the return v
> > Because the call to isinf is optimized away even at -O0 in the latter
> > case (isinf being a pure function), but not in the former. That could be
> > deemed a little questionable though. The gap is eliminated at -O1.
>
> Thank you for explication. Is it gcc's expected behavior?
It is valid
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Why does the compilation of b.c fail, while that of a.c succeeds with
>> gcc-4.0.0 or later?
>
> Because the call to isinf is optimized away even at -O0 in the latter case
> (isinf being a pure function), but not in the former. That could be deemed
>
> Why does the compilation of b.c fail, while that of a.c succeeds with
> gcc-4.0.0 or later?
Because the call to isinf is optimized away even at -O0 in the latter case
(isinf being a pure function), but not in the former. That could be deemed
a little questionable though. The gap is eliminate
16 matches
Mail list logo
