* isinf @ 2005-07-13 17:07 Hiroshi Fujishima 2005-07-13 19:08 ` isinf Eric Botcazou 0 siblings, 1 reply; 17+ messages in thread From: Hiroshi Fujishima @ 2005-07-13 17:07 UTC (permalink / raw) To: gcc [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 17:07 isinf Hiroshi Fujishima @ 2005-07-13 19:08 ` Eric Botcazou 2005-07-13 22:32 ` isinf Hiroshi Fujishima 0 siblings, 1 reply; 17+ messages in thread From: Eric Botcazou @ 2005-07-13 19:08 UTC (permalink / raw) To: Hiroshi Fujishima; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 19:08 ` isinf Eric Botcazou @ 2005-07-13 22:32 ` Hiroshi Fujishima 2005-07-13 22:59 ` isinf Eric Botcazou 0 siblings, 1 reply; 17+ messages in thread From: Hiroshi Fujishima @ 2005-07-13 22:32 UTC (permalink / raw) To: Eric Botcazou; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 22:32 ` isinf Hiroshi Fujishima @ 2005-07-13 22:59 ` Eric Botcazou 2005-07-13 23:17 ` isinf Hiroshi Fujishima 0 siblings, 1 reply; 17+ messages in thread From: Eric Botcazou @ 2005-07-13 22:59 UTC (permalink / raw) To: Hiroshi; +Cc: gcc > > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 22:59 ` isinf Eric Botcazou @ 2005-07-13 23:17 ` Hiroshi Fujishima 2005-07-13 23:29 ` isinf Joe Buck 0 siblings, 1 reply; 17+ messages in thread From: Hiroshi Fujishima @ 2005-07-13 23:17 UTC (permalink / raw) To: Eric Botcazou; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 23:17 ` isinf Hiroshi Fujishima @ 2005-07-13 23:29 ` Joe Buck 2005-07-13 23:39 ` isinf Dale Johannesen 2005-07-13 23:48 ` isinf Hiroshi Fujishima 0 siblings, 2 replies; 17+ messages in thread From: Joe Buck @ 2005-07-13 23:29 UTC (permalink / raw) To: Hiroshi Fujishima; +Cc: Eric Botcazou, gcc 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 23:29 ` isinf Joe Buck @ 2005-07-13 23:39 ` Dale Johannesen 2005-07-13 23:48 ` isinf Hiroshi Fujishima 1 sibling, 0 replies; 17+ messages in thread From: Dale Johannesen @ 2005-07-13 23:39 UTC (permalink / raw) To: Joe Buck; +Cc: gcc, Hiroshi Fujishima, Dale Johannesen, Eric Botcazou 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 23:29 ` isinf Joe Buck 2005-07-13 23:39 ` isinf Dale Johannesen @ 2005-07-13 23:48 ` Hiroshi Fujishima 2005-07-14 6:27 ` isinf Eric Botcazou 1 sibling, 1 reply; 17+ messages in thread From: Hiroshi Fujishima @ 2005-07-13 23:48 UTC (permalink / raw) To: Joe Buck; +Cc: Eric Botcazou, gcc 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-13 23:48 ` isinf Hiroshi Fujishima @ 2005-07-14 6:27 ` Eric Botcazou 2005-07-14 6:52 ` isinf Michael Veksler 0 siblings, 1 reply; 17+ messages in thread From: Eric Botcazou @ 2005-07-14 6:27 UTC (permalink / raw) To: Hiroshi Fujishima; +Cc: gcc, Joe Buck > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 6:27 ` isinf Eric Botcazou @ 2005-07-14 6:52 ` Michael Veksler 2005-07-14 7:33 ` isinf Eric Botcazou 0 siblings, 1 reply; 17+ messages in thread From: Michael Veksler @ 2005-07-14 6:52 UTC (permalink / raw) To: Eric Botcazou; +Cc: gcc, Hiroshi Fujishima, Joe Buck 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 6:52 ` isinf Michael Veksler @ 2005-07-14 7:33 ` Eric Botcazou 2005-07-14 7:56 ` isinf Michael Veksler 0 siblings, 1 reply; 17+ messages in thread From: Eric Botcazou @ 2005-07-14 7:33 UTC (permalink / raw) To: Michael Veksler; +Cc: gcc, Hiroshi Fujishima, Joe Buck > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 7:33 ` isinf Eric Botcazou @ 2005-07-14 7:56 ` Michael Veksler 2005-07-14 8:59 ` isinf Andreas Schwab 0 siblings, 1 reply; 17+ messages in thread From: Michael Veksler @ 2005-07-14 7:56 UTC (permalink / raw) To: Eric Botcazou; +Cc: gcc, Hiroshi Fujishima, Joe Buck 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 7:56 ` isinf Michael Veksler @ 2005-07-14 8:59 ` Andreas Schwab 2005-07-14 9:10 ` isinf Eric Botcazou 2005-07-14 9:27 ` isinf Hiroshi Fujishima 0 siblings, 2 replies; 17+ messages in thread From: Andreas Schwab @ 2005-07-14 8:59 UTC (permalink / raw) To: Michael Veksler; +Cc: Eric Botcazou, gcc, Hiroshi Fujishima, Joe Buck 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." ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 8:59 ` isinf Andreas Schwab @ 2005-07-14 9:10 ` Eric Botcazou 2005-07-14 9:27 ` isinf Hiroshi Fujishima 1 sibling, 0 replies; 17+ messages in thread From: Eric Botcazou @ 2005-07-14 9:10 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc, Michael Veksler, Hiroshi Fujishima, Joe Buck > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 8:59 ` isinf Andreas Schwab 2005-07-14 9:10 ` isinf Eric Botcazou @ 2005-07-14 9:27 ` Hiroshi Fujishima 2005-07-14 9:35 ` isinf Jakub Jelinek 1 sibling, 1 reply; 17+ messages in thread From: Hiroshi Fujishima @ 2005-07-14 9:27 UTC (permalink / raw) To: Andreas Schwab; +Cc: Michael Veksler, Eric Botcazou, gcc, Joe Buck 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 9:27 ` isinf Hiroshi Fujishima @ 2005-07-14 9:35 ` Jakub Jelinek 2005-07-14 9:47 ` isinf Andreas Schwab 0 siblings, 1 reply; 17+ messages in thread From: Jakub Jelinek @ 2005-07-14 9:35 UTC (permalink / raw) To: Hiroshi Fujishima Cc: Andreas Schwab, Michael Veksler, Eric Botcazou, gcc, Joe Buck 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: isinf 2005-07-14 9:35 ` isinf Jakub Jelinek @ 2005-07-14 9:47 ` Andreas Schwab 0 siblings, 0 replies; 17+ messages in thread From: Andreas Schwab @ 2005-07-14 9:47 UTC (permalink / raw) To: Jakub Jelinek Cc: Hiroshi Fujishima, Michael Veksler, Eric Botcazou, gcc, Joe Buck 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." ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2005-07-14 9:47 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-13 17:07 isinf Hiroshi Fujishima 2005-07-13 19:08 ` isinf Eric Botcazou 2005-07-13 22:32 ` isinf Hiroshi Fujishima 2005-07-13 22:59 ` isinf Eric Botcazou 2005-07-13 23:17 ` isinf Hiroshi Fujishima 2005-07-13 23:29 ` isinf Joe Buck 2005-07-13 23:39 ` isinf Dale Johannesen 2005-07-13 23:48 ` isinf Hiroshi Fujishima 2005-07-14 6:27 ` isinf Eric Botcazou 2005-07-14 6:52 ` isinf Michael Veksler 2005-07-14 7:33 ` isinf Eric Botcazou 2005-07-14 7:56 ` isinf Michael Veksler 2005-07-14 8:59 ` isinf Andreas Schwab 2005-07-14 9:10 ` isinf Eric Botcazou 2005-07-14 9:27 ` isinf Hiroshi Fujishima 2005-07-14 9:35 ` isinf Jakub Jelinek 2005-07-14 9:47 ` isinf Andreas Schwab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).