lwb@pensoft.uucp (Lance Bledsoe) (05/04/91)
We are starting a couple of projects on AIX/RS6000, and we need a Fortran compiler that works well. Any leads on this would be GREATLY appreciated!!! Thanks in advance. -- Lance Bledsoe Off: (512) 343-1111 Pencom Software, Inc. Fax (512) 343-9650 8716 Loop 360 N. Suite 300 UUCP: cs.utexas.edu!pensoft!lwb Austin, Texas 78759 UUNET: uunet!uudell!pensoft!lwb
jackv@turnkey.tcc.com (Jack F. Vogel) (05/05/91)
In article <1991May3.211427.19026@pensoft.uucp> lwb@pensoft.uucp (Lance Bledsoe) writes: >We are starting a couple of projects on AIX/RS6000, and we need >a Fortran compiler that works well. Huhhh? Is there something wrong with VS Fortran from IBM?? Or were you just not aware of its existence? I don't know about the 6000 version, but on the 370 its hot, providing vector facility utilization and all. Contact your SE. Disclaimer: Opinions are my own, not necessarily my employer's. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
jkorpela@vipunen.hut.fi (Jukka Korpela) (05/08/91)
Uh? For RS/6000, the IBM product is XL FORTRAN, not VS FORTRAN. Anybody here worked with XL FORTRAN? I'd like to share some experiences. I'm struggling, among other things, with the problem of detecting the occurrence of floating-point errors. (I've abandoned the hope of ever really trapping them...)
prener@watson.ibm.com (Dan Prener) (05/08/91)
In article <1991May3.211427.19026@pensoft.uucp>, lwb@pensoft.uucp (Lance Bledsoe) writes: |> We are starting a couple of projects on AIX/RS6000, and we need |> a Fortran compiler that works well. |> |> Any leads on this would be GREATLY appreciated!!! |> |> Thanks in advance. |> |> |> -- |> Lance Bledsoe Off: (512) 343-1111 |> Pencom Software, Inc. Fax (512) 343-9650 |> 8716 Loop 360 N. Suite 300 UUCP: cs.utexas.edu!pensoft!lwb |> Austin, Texas 78759 UUNET: uunet!uudell!pensoft!lwb Are you looking for something other than IBM's XL FORTRAN? -- Dan Prener (prener @ watson.ibm.com)
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (05/09/91)
In article <JKORPELA.91May8015509@vipunen.hut.fi> jkorpela@vipunen.hut.fi (Jukka Korpela) writes: >I'm struggling, among other things, with the problem of detecting the >occurrence of floating-point errors. (I've abandoned the hope of ever really >trapping them...) I'd like to find the answer to this also. I asked on comp.unix.aix and got no replies. The corresponding situation for SunOS looks like this: integer n, ieee_handler, sigfpe_abort n = ieee_handler( 'set', 'common', SIGFPE_ABORT ) On the RS/6000, it seems that FORTRAN doesn't have anything special, but that the fp_enable stuff could be used to get the processor to signal on things like divide by zero instead of merrily going on. Amazing that the Fortran manual has no mention of this nor an example. Hmph. Anyone?
jkorpela@vipunen.hut.fi (Jukka Korpela) (05/10/91)
This is a brief summary of what I've found so far (thnx to all who sent me mail 'bout the problems) about arithmetics on RS/6000: - the default handling of almost all arithmetic errors (I guess integer divide by zero is the only exception - it generates core dump...) is to ignore them; but floating point errors do behave in the IEEE way, and a numeric variable who's value is infinity or NaN is printed out as "INF" or "NaNQ" or something like that - peculiarly, if you want to test within a program whether the value of X is NaN, X.NE.X seems to be the (undocumented) way; there are probably ways of detecting infinities as well - using the (documented, but poorly documented) routines FPGETS and FPSETS you can detect if floating-point errors have occurred - but you probably can't really trap them; even in C, you can't use the standardized tools; I tried to trap SIGFPE and the result is that a) 1.0/0.0 doesn't generate a trap, it simply produces INF, b) if I call fp_enable_all, 1.0/0.0 still doesn't generate a trap, but it produces 1.0 !!! - errors in math routines (well, actually, more or less invalid args to them, like SQRT(-1.0) or EXP(1E30)) do not necessarily (usually?) set FPE flags on (understandable), so you can't use FPGETS to see if they; you CAN use matherr, but it's designed to be C callable, so you need a simple interface routine I'm not happy with the situation, but at least I can tell our users how they can (and should!) insert a small piece of code to make their program report floating-point errors ***somehow***.
orville@weyrich.UUCP (Orville R. Weyrich) (05/10/91)
In article <1991May9.015512.27264@murdoch.acc.Virginia.EDU> gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes: >In article <JKORPELA.91May8015509@vipunen.hut.fi> jkorpela@vipunen.hut.fi (Jukka Korpela) writes: > >>I'm struggling, among other things, with the problem of detecting the >>occurrence of floating-point errors. (I've abandoned the hope of ever really >>trapping them...) > >On the RS/6000, it seems that FORTRAN doesn't have anything special, >but that the fp_enable stuff could be used to get the processor to >signal on things like divide by zero instead of merrily going on. >Amazing that the Fortran manual has no mention of this nor an example. >Hmph. Of course the FORTRAN *LANGUAGE* does not contain a definition of how FP errors are to be handled. The language is designed to be compatible with all sorts of obsolete antique hardware, and the hardware folks would never agree to make FORTRAN adhere to something like the IEEE floating point standard (sarcasm here). If they did, the next thing the software folks would try to do would be to make adherence to ASCII standard (more sarcasm). The only language that I am aware of that has any sort of floating-point error handling built into thae standard is Ada, and even that does not support the IEEE floating-point very well. On the other hand, the FORTRAN standard is permissive, and if a vendor WANTED to embrace industry standards by providing IEEE floating point support, they could do so without violating the FORTRAN standard. Who did you say made your RS/6000? On a more positive note, I seem to recall that the IBM-370 FORTRAN manuals were divided into separate books for the language users and for those poor folks that had to do system level program integration. The (nonstandard) IBM library routines for controlling the handling of run-time errors were I think documented in the PROGRAMMER'S REFERENCE, not the LANGUAGE REFERENCE. In any event, the facility was provided to either ignore FP errors, to invoke an error handler, or to abort. If you chose to ignore FP errors, you could poll the run-time system to determine how many times such an error had occurred since the last time you asked. One would hope that in the absence of adherence to the international FP standard, the RS/6000 would at least attempt to maintain compatibility with IBM-370 FORTRAN. I don't know. My advice would be to get an industry-standard i486 machine to code on, and use a Borland language that you can buy the run-time code for so that you can be sure that the FP errors are handled the way you want them to be. (I don't know about the currernt Borland products, but the version 3.0 of Pascal did not quite get the error handling right. Since this is comp.lang.fortran rather than Pascal, e-mail me for details). -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
dik@cwi.nl (Dik T. Winter) (05/11/91)
In article <JKORPELA.91May10100448@vipunen.hut.fi> jkorpela@vipunen.hut.fi (Jukka Korpela) writes: > - peculiarly, if you want to test within a program whether the value > of X is NaN, X.NE.X seems to be the (undocumented) way; there are > probably ways of detecting infinities as well This is perfectly documented in the IEEE standard on floating point arithmetic! To test for infinities try: (X-X).NE.(X-X) (if X is an infinity, X-X is a NaN.) another way: (1.0/X).EQ.0.0 > - using the (documented, but poorly documented) routines FPGETS and > FPSETS you can detect if floating-point errors have occurred They probably extract the sticky IEEE flags. > - but you probably can't really trap them; even in C, you can't use > the standardized tools; I tried to trap SIGFPE and the result is > that a) 1.0/0.0 doesn't generate a trap, it simply produces INF, > b) if I call fp_enable_all, 1.0/0.0 still doesn't generate a trap, > but it produces 1.0 !!! That is definitely a bug. But you really do not want to trap them in the RS6000. According to my literature it is possible at the hardware level, but it implies that all F-P operations will be serialized, which costs you a lot of performance. > - errors in math routines (well, actually, more or less invalid args to > them, like SQRT(-1.0) or EXP(1E30)) do not necessarily (usually?) set > FPE flags on (understandable), so you can't use FPGETS to see if they; > you CAN use matherr, but it's designed to be C callable, so you need > a simple interface routine SQRT must set the sticky bits according to IEEE. IEEE does not talk about EXP, but a honest implementation would also correctly set the bits. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl