> I don't know if you noticed, but the C++ runtime library started using
> the builtins exclusively in 4.4.0, we exposed a small bug (fixed by
> Richard I think), where the compiler crashed for an integer type
> argument, but otherwise *nobody* complained so far.
Wow, now that's a pretty strong ar
On 09/09/2010 11:43 AM, FX wrote:
> Thus, my question is: Is there any risk in doing so?
>
I don't know if you noticed, but the C++ runtime library started using
the builtins exclusively in 4.4.0, we exposed a small bug (fixed by
Richard I think), where the compiler crashed for an integer type
a
I have a questions regarding GCC C99 built-ins: isfinite, isnan, isnormal,
isinf and signbit.
Currently, libgfortran (which is compiled with -std=c99) has a few configure
tests and target-specific hacks to provide reasonable versions of the macros
above: using the ones in headers if they are
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
> vol
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.
>
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
> 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'
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;
&g
> 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
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;
> }
T
> 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);
>
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 ()
>> >>
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
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
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)
>> ;
>> ret
> > 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
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 fo
> 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
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
20 matches
Mail list logo
