Almost succesfull build on AIX

Thomas Vogels <tov@infiniti.ece.cmu.edu> writes:

"Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

Here's the problem:

1/0

[1]INF

is.finite(1/0)

[1] TRUE

Much to my surprise, a 'printf ("%g", 1/.0)' prints INF in a C
program.  Should this not result in a floating point exception?

Not according to IEEE specs (but integer divide by zero is generally
unmaskable). The interesting thing is that is.finite returns TRUE on
the result, and the printing also suggests that the infinite value is
not recognised internally (if it were, it would get printed as

1/0

[1] Inf
)

It would be nice to see the actual bit pattern of 1/.0. Could one of
you do something like

	x = 1/.0;
	printf("%0x,%0x\n", ((int *) &x)[0], ((int *) &x)[1]);

or whatever other obfuscation works on AIX...

O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Thomas Vogels writes:

"Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

Here's the problem:

1/0

[1]INF

is.finite(1/0)

[1] TRUE

Ah ... but FRITZ wrote that ...

Much to my surprise, a 'printf ("%g", 1/.0)' prints INF in a C
program.  Should this not result in a floating point exception?

R was built using the flags included below, gcc version is 2.7.2. Does
anybody with experience on AIX know what's going on (the all uppercase
INF looks somewhat suspicious).

Because it's a return value, not the R string "Inf".  Wild guess,
lemme think about it.

Kurt> If I may add.  Building for me only works with LDCMD and SHLIBLD as
Kurt> 
Kurt> f77
Kurt> or
Kurt> cc with `-lc -lm' added to DLLFLAGS and SHLIBLDFLAGS

Yes, there is still something wrong with the DLLFLAGS.  (Which also
shows up when you try to link local libraries (like a private copy of
the readline lib).)   I've played a little more with the way R.exp is
generated.  Let me try it on 64.2 and 65.

Please, NOT with 0.64.2.  All my configure/make changes are in 0.65!

Kurt> It did not work with
Kurt> ld (gives an exec format error in the main binary)

My experience is that if I compile the main function with gcc then I
have to link with gcc, otherwise it can't find .__main.  Which leads
to:

Kurt> gcc (cannot find libgcc.a???)

Yep and hmm.  Arne found that you can say "gcc
--print-libgcc-file-name" and then gcc actually does that.  You can
add the result of the command on the link line.  (If however gcc never
finds libgcc.a then you're in deep trouble.  Check wether you can find
gcc's spec file.)

The specs file is fine.  My question is, is that a known gcc problem on
AIX or is that due to the rather outdated version of gcc we have?  If it
is a general problem, I can easily add to DLLFLAGS.

Kurt> I am not sure up to what extend this is a problem with AIX in general or
Kurt> the specific system Fritz and I have access to, which in particular has
Kurt> gcc built 3 years ago for AIX 3.something.

Probably something with AIX in general.

BTW, do you not get compiler errors about blkcnt not being defined
when you compile with gcc?  So far, I had to patch most programs
because there is a bug with the standard include files.

No.

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

PD> Thomas Vogels <tov@infiniti.ece.cmu.edu> writes:
    >> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

      > >> Here's the problem:
      > >>> 1/0
      > >> [1]INF
      > >>> is.finite(1/0)
      > >> [1] TRUE

    >> Much to my surprise, a 'printf ("%g", 1/.0)' prints INF in a C
    >> program.  Should this not result in a floating point exception?

    PD> Not according to IEEE specs (but integer divide by zero is
    PD> generally unmaskable). The interesting thing is that is.finite
    PD> returns TRUE on the result, and the printing also suggests that the
    PD> infinite value is not recognised internally (if it were, it would
    PD> get printed as
    >> 1/0
    PD> [1] Inf )

    PD> It would be nice to see the actual bit pattern of 1/.0. Could one
    PD> of you do something like

    PD>    x = 1/.0; printf("%0x,%0x\n", ((int *) &x)[0], ((int *) &x)[1]);

    PD> or whatever other obfuscation works on AIX...

I've done more than Peter requested;
namely, the "finite" probing has always been a big problem on AIX,
and I rediscovered my old testing code -- which I enhanced with Peter's HEX
dump proposal:
  [everything in  ftp://stat.ethz.ch/U/maechler/R/AIX-finite-tst.tar.gz !]

    #include <stdio.h>
    #include <math.h>

    #ifdef AIX
    # include <fp.h>
    #endif

    main() {
      double x,x2,x3;
      printf("finite(1.0)= %d (=1, hopefully)\n", finite(1.0));
      x=1./0.; x2= (-1.)/0.;  x3 = 0./0.;
      printf("Inf := 1/0 = %f;\t -Inf := -1/0 = %f;\t NaN:= 0/0 = %f\n",x, x2, x3);
      printf("finite(x), f.(x2), f.(x3): %d %d %d  (should all be 0)\n",
	     finite(x),finite(x2),finite(x3));
      printf("Now the `bits':\n");
      printf(" Inf : %0x,%0x\n", ((int *) &x )[0], ((int *) &x )[1]);
      printf("-Inf : %0x,%0x\n", ((int *) &x2)[0], ((int *) &x2)[1]);
      printf(" NaN : %0x,%0x\n", ((int *) &x3)[0], ((int *) &x3)[1]);

    #ifdef AIX
      printf("FINITE(x), f.(x2), f.(x3): %d %d %d  (should all be 0)\n",
	     FINITE(x),FINITE(x2),FINITE(x3));
    #endif
    }

------------
And I have this in my Makefile  [also available on Web, s.above]

    ## on AIX (percol)
    #CFLAGS = -D_XOPEN_SOURCE -DAIX
    # better for R (defines cosh(.)  AND fd_set(.) (sys/time.h):
    CFLAGS = -D_XOPEN_SOURCE_EXTENDED=1 -DAIX

My Conclusions: 

  - Only if I use these CFLAGS does  finite work properly.
  - The bit pattern are compiler-independent for +-Inf, but NOT for NaN :

Here is gcc [with above CFLAGS],  gcc version 2.7.2.3,  output:
----------------------------------
finite(1.0)= 1 (=1, hopefully)
Inf := 1/0 = INF;	 -Inf := -1/0 = -INF;	 NaN:= 0/0 = NaNQ
finite(x), f.(x2), f.(x3): 0 0 0  (should all be 0)
Now the `bits':
 Inf : 7ff00000,0
-Inf : fff00000,0
 NaN : 7fffffff,ffffffff
FINITE(x), f.(x2), f.(x3): 0 0 0  (should all be 0)
----------------------------------

xlc (the native AIX C compiler) gives the same BUT for the NaN bit pattern
where it has

 NaN : 7ff80000,0

------------------------

Martin Maechler <maechler@stat.math.ethz.ch>	http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum SOL G1;	Sonneggstr.33
ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086			<><
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

To add to my last E-mail  
where I said more-or-less

      ``we need  CFLAGS   -D_XOPEN_SOURCE_EXTENDED=1  

        for finite() and things to work ''

I now have put this into  config.site,
but then the compilation breaks when trying to compile 
src/unix/sock.c

it seems because of broken combination of header files 
   /usr/include/netinet/in_systm.h
   /usr/include/netinet/tcp.h
   /usr/include/netinet/ip.h

Maybe,  sock.c  {and further files?}
use other CFLAGS explicitly ?

Here the beginning of the long compilation error messages:

 gcc -I. -I../include -I../../src/include   -DHAVE_CONFIG_H  -g -O2 -D_XOPEN_SOURCE_EXTENDED=1 -c sock.c -o sock.o

 In file included from /usr/include/netinet/ip.h:75,
		  from /usr/include/netinet/tcp.h:72,
		  from sock.c:25:
 /usr/include/netinet/in_systm.h:79: parse error before `n_short'
 /usr/include/netinet/in_systm.h:79: warning: data definition has no type or storage class
 /usr/include/netinet/in_systm.h:80: parse error before `n_long'
 /usr/include/netinet/in_systm.h:80: warning: data definition has no type or storage class
 /usr/include/netinet/in_systm.h:82: parse error before `n_time'
 /usr/include/netinet/in_systm.h:82: warning: data definition has no type or storage class
 In file included from /usr/include/netinet/tcp.h:72,
		  from sock.c:25:
 /usr/include/netinet/ip.h:104: parse error before `u_long'
 /usr/include/netinet/ip.h:104: warning: no semicolon at end of struct or union
 /usr/include/netinet/ip.h:104: warning: no semicolon at end of struct or union
 /usr/include/netinet/ip.h:114: parse error before `ip_xhl'
 /usr/include/netinet/ip.h:114: warning: no semicolon at end of struct or union
 /usr/include/netinet/ip.h:119: warning: data definition has no type or storage class
 /usr/include/netinet/ip.h:120: parse error before `}'
 /usr/include/netinet/ip.h:120: warning: data definition has no type or storage class
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._