isinf

isinf

[Hiroshi Fujishima]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Hi,

Why does the compilation of b.c fail, while that of a.c succeeds with
gcc-4.0.0 or later?  Compilaton with gcc-3.4.4 both failed.

% gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: ../gcc/configure --disable-nls --with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: posix
gcc version 4.0.2 20050707 (prerelease)
% gcc a.c
% gcc b.c
Undefined			first referenced
 symbol  			    in file
isinf                               /tmp/ccSOxuGb.o
ld: fatal: Symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status


[-- Attachment #2: a.c --]
[-- Type: application/octet-stream, Size: 63 bytes --]

int
main (void)
{
  double f = 0.0;
  isinf (f);
  return 0;
}

[-- Attachment #3: b.c --]
[-- Type: application/octet-stream, Size: 238 bytes --]

#include <stdio.h>

int
main (void)
{
  double f = 0.0;
  if (!isinf (f))
    {
      printf ("not isinf(oo) ... ");
      return 1;
    }
  if (!isinf (-f))
    {
      printf ("not isinf(-oo) ... ");
      return 1;
    }
  return 0;
}

[-- Attachment #4: Type: text/plain, Size: 23 bytes --]


-- 
Hiroshi Fujishima

Re: isinf

[Eric Botcazou]

> 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 eliminated at -O1.

-- 
Eric Botcazou

Re: isinf

[Hiroshi Fujishima]

Eric Botcazou <ebotcazou@libertysurf.fr> 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 
> a little questionable though.  The gap is eliminated at -O1.

Thank you for explication.  Is it gcc's expected behavior?

The configure script which is included in rrdtool[1] checks whether
the system has isinf() as below.

#include <math.h>
int
main ()
{
float f = 0.0; isinf(f)
  ;
  return 0;
}

If above compilation is success, the configure script defines
HAVE_ISINF macro.  The prior version to gcc-4.0.0 above compilation
fails, so below isinf macro is defined. But gcc-4.0.0 or later it
succeeds, so below isinf macro is not defind though the system doesn't
have isinf().

/* Solaris */
#if (! defined(HAVE_ISINF) && defined(HAVE_FPCLASS))
#  define HAVE_ISINF 1
#  define isinf(a) (fpclass(a) == FP_NINF || fpclass(a) == FP_PINF)
#endif

Is this gcc's problem?  Or should I contact rrdtool's developer?

Regards.

[1] <URL:http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/>

-- 
Hiroshi Fujishima

Re: isinf

[Eric Botcazou]

> > 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 to eliminate calls to pure functions whose return value is not 
used, as they have no "external" effects.  GCC 3.x doesn't do it at -O0, 
whereas 4.x does.

> The configure script which is included in rrdtool[1] checks whether
> the system has isinf() as below.
>
> #include <math.h>
> int
> main ()
> {
> float f = 0.0; isinf(f)
>   ;
>   return 0;
> }

The test is clearly fragile.  Assigning the return value of isinf to a 
variable should be sufficient for 4.0.x at -O0.

-- 
Eric Botcazou

Re: isinf

[Hiroshi Fujishima]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

>> The configure script which is included in rrdtool[1] checks whether
>> the system has isinf() as below.
>>
>> #include <math.h>
>> int
>> main ()
>> {
>> float f = 0.0; isinf(f)
>>   ;
>>   return 0;
>> }
>
> The test is clearly fragile.  Assigning the return value of isinf to a 
> variable should be sufficient for 4.0.x at -O0.

Yes, I contact rrdtool maintainer.  Thank you.

-- 
Hiroshi Fujishima

Re: isinf

[Joe Buck]

On Thu, Jul 14, 2005 at 08:16:07AM +0900, Hiroshi Fujishima wrote:
> Eric Botcazou <ebotcazou@libertysurf.fr> writes:
> 
> >> The configure script which is included in rrdtool[1] checks whether
> >> the system has isinf() as below.
> >>
> >> #include <math.h>
> >> int
> >> main ()
> >> {
> >> float f = 0.0; isinf(f)
> >>   ;
> >>   return 0;
> >> }
> >
> > The test is clearly fragile.  Assigning the return value of isinf to a 
> > variable should be sufficient for 4.0.x at -O0.
> 
> Yes, I contact rrdtool maintainer.  Thank you.

Best to make it a global variable, to guard against dead code elimination.

Re: isinf

[Dale Johannesen]

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 <ebotcazou@libertysurf.fr> writes:
>>
>>>> The configure script which is included in rrdtool[1] checks whether
>>>> the system has isinf() as below.
>>>>
>>>> #include <math.h>
>>>> int
>>>> main ()
>>>> {
>>>> float f = 0.0; isinf(f)
>>>>   ;
>>>>   return 0;
>>>> }
>>>
>>> The test is clearly fragile.  Assigning the return value of isinf to 
>>> a
>>> variable should be sufficient for 4.0.x at -O0.
>>
>> Yes, I contact rrdtool maintainer.  Thank you.
>
> Best to make it a global variable, to guard against dead code 
> elimination.

Volatile would be even better.  It's valid to eliminate stores into 
globals
if you can determine the value isn't used thereafter, which we can here,
at least theoretically.

Re: isinf

[Hiroshi Fujishima]

Joe Buck <Joe.Buck@synopsys.COM> writes:

>> >> The configure script which is included in rrdtool[1] checks whether
>> >> the system has isinf() as below.
>> >>
>> >> #include <math.h>
>> >> int
>> >> main ()
>> >> {
>> >> float f = 0.0; isinf(f)
>> >>   ;
>> >>   return 0;
>> >> }
>> >
>> > The test is clearly fragile.  Assigning the return value of isinf to a 
>> > variable should be sufficient for 4.0.x at -O0.
>
> Best to make it a global variable, to guard against dead code elimination.

Oops, the configure script compiling with -O2 optimization.  The
compilation of the following code still suceesss.

#include <math.h>

int a;

int
main ()
{
  float f = 0.0;
  a = isinf (f);
  return 0;
}

Do I misunderstand?  Since I am the newbie of C, I consulted this page:
http://www.phim.unibe.ch/comp_doc/c_manual/C/SYNTAX/glo_int_vars.html

-- 
Hiroshi Fujishima

Re: isinf

[Eric Botcazou]

> 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 <math.h>
>
> int a;
>
> int
> main ()
> {
>   float f = 0.0;
>   a = isinf (f);
>   return 0;
> }

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;
}

or additionally compile with -fno-builtin.

-- 
Eric Botcazou

Re: isinf

[Michael Veksler]

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 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 compiler may deduce that isinf((double)argc) always
returns false, without ever calling the function.

>
> or additionally compile with -fno-builtin.

That may help.

Re: isinf

[Eric Botcazou]

> 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 compiler may deduce that isinf((double)argc) always
> returns false, without ever calling the function.

You're too clever. :-)

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;
}

-- 
Eric Botcazou

Re: isinf

[Michael Veksler]

Eric Botcazou <ebotcazou@libertysurf.fr> 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 when sizeof(u.i)<sizeof(u.d) ?
Not all of u.d will be initialized by u.i = argc, accessing the
uninitialized bits of u.d may trigger undefined behavior.

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 isinf.

  Michael

Re: isinf

[Andreas Schwab]

Michael Veksler <VEKSLER@il.ibm.com> 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 isinf.

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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: isinf

[Eric Botcazou]

> 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

Re: isinf

[Hiroshi Fujishima]

Andreas Schwab <schwab@suse.de> 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 not have finite but does have isfinite as a macro so we need
dnl actual code to check if this works
AC_CHECK_FUNCS(fpclassify, ,
  [AC_MSG_CHECKING(for fpclassify with <math.h>)
    AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>]], [[float f = 0.0; fpclassify(f)]])],[AC_MSG_RESULT(yes)
      AC_DEFINE(HAVE_FPCLASSIFY)],[AC_MSG_RESULT(no)])])
AC_CHECK_FUNCS(finite, ,
  [AC_CHECK_FUNCS(isfinite, ,
    [AC_MSG_CHECKING(for isfinite with <math.h>)
    AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>]], [[float f = 0.0; isfinite(f)]])],[AC_MSG_RESULT(yes)
      AC_DEFINE(HAVE_ISFINITE)],[AC_MSG_RESULT(no)])])])
AC_CHECK_FUNCS(isinf, ,
  [AC_MSG_CHECKING(for isinf with <math.h>)
    AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>]], [[float f = 0.0; int x = isinf(f)]])],[AC_MSG_RESULT(yes)
      AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])])

-- 
Hiroshi Fujishima

Re: isinf

[Jakub Jelinek]

On Thu, Jul 14, 2005 at 06:27:06PM +0900, Hiroshi Fujishima wrote:
> Andreas Schwab <schwab@suse.de> 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 not have finite but does have isfinite as a macro so we need
> dnl actual code to check if this works
> AC_CHECK_FUNCS(fpclassify, ,
>   [AC_MSG_CHECKING(for fpclassify with <math.h>)
>     AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>]], [[float f = 0.0; fpclassify(f)]])],[AC_MSG_RESULT(yes)
>       AC_DEFINE(HAVE_FPCLASSIFY)],[AC_MSG_RESULT(no)])])
> AC_CHECK_FUNCS(finite, ,
>   [AC_CHECK_FUNCS(isfinite, ,
>     [AC_MSG_CHECKING(for isfinite with <math.h>)
>     AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>]], [[float f = 0.0; isfinite(f)]])],[AC_MSG_RESULT(yes)
>       AC_DEFINE(HAVE_ISFINITE)],[AC_MSG_RESULT(no)])])])
> AC_CHECK_FUNCS(isinf, ,
>   [AC_MSG_CHECKING(for isinf with <math.h>)
>     AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>]], [[float f = 0.0; int x = isinf(f)]])],[AC_MSG_RESULT(yes)
>       AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])])

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 <math.h>)
     AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>
volatile int x; volatile float f;]], [[x = isinf(f)]])],[AC_MSG_RESULT(yes)
       AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])])
should be reasonably safe for now.

	Jakub

Re: isinf

[Andreas Schwab]

Jakub Jelinek <jakub@redhat.com> 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 <math.h>)
>      AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <math.h>
> volatile int x; volatile float f;]], [[x = isinf(f)]])],[AC_MSG_RESULT(yes)
>        AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])])
> should be reasonably safe for now.

Perhaps it should just check whether the macro isinf exists (but still use
AC_CHECK_FUNCS(isinf) for pre-C99 hosts).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."