 |
 |
On 11/28/2011 4:26 PM, Dan Nagle wrote: > Hi, > > On Nov 28, 2011, at 14:03 , Neil N. Carlson wrote: >> >> I'm not actually surprised that the argument expression >> was fully evaluated; that would be required if >> merge were a user-function. Do intrinsic functions >> have special rules in this regard? > > No. >> >> That got me to wondering why this bit of code doesn't >> cause any problems with the other compilers we use, >> which do trap on fp exceptions by default. Poking >> around with the nag compiler, I've found that it >> compiles the merge to a loop that only evaluates those >> elements of the array expression that are used, and >> so never tries to do a 1.0/0.0. I'd guess that the >> other compilers are doing the same thing. > > Yes. >> >> I actually prefer this behavior (in this case at least), >> but I'm suspicious that this may not be strictly kosher. > > It isn't. > > This has been discussed at length in J3/WG5 meetings. > The difficulty is that expression evaluation goes to the heart > of a compiler's optimizations. Thus, changes to the standard > in this area must be made carefully. > ifort, with default settings, doesn't vectorize MERGE where there is a possibility of overflow; the optional vectorization diagnostic being "protects exception." This may be overruled by directives such as !dir$ vector always in which case appropriate Inf or NaN results may be generated. In the case in question, the Inf results are masked out. Trapping would have to be requested if desired. I haven't seen an option for gfortran to vectorize such cases. -- Tim Prince