(j3.2006) Fw: a question on MERGE and expression evaluation

Jim Xia jimxia
Thu Nov 18 20:44:30 EST 2010


I'm more than happy to take it that we don't need to evaluate full 
expression of 1/a in the merge.  But I'm afraid there will be users 
picking 12.5.3 as an evidence that standard mandate the evaluation, 
whereas almost everywhere else the standard says otherwise.  The second 
sentence in 12.5.3 does seem conflict with other text, and should be 
fixed.

Cheers,

Jim Xia

XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM

http://www.ibm.com/software/awdtools/fortran/xlfortran



From:
Keith Bierman <khbkhb at gmail.com>
To:
fortran standards email list for J3 <j3 at j3-fortran.org>
Cc:
j3-bounces at j3-fortran.org, longb at cray.com
Date:
11/18/2010 05:53 PM
Subject:
Re: (j3.2006) Fw: a question on MERGE and expression evaluation





On Thu, Nov 18, 2010 at 2:44 PM, Jim Xia <jimxia at ca.ibm.com> wrote:


I'm not convinced that all these answers are correct.  The quoted text in 
previous replied are from clause 7 (on expression), and what they say is 
"you can omit expression evaluation if you're sure what the expression 
must be evaluated to".  That's about operations evaluation like "expr1 
.op. expr2" where you know the evaluation is true by evaluating expr1. 
 This is not what's happening here: "Merge(1/a, 0.0, a > 0)" is a function 
reference, right?  And 12.5.3 seems to say 1.0/a should be evaluated at 
the function call. 




What do we say about this mandate? 

Obviously those of you actively working on the Standard should decide. My 
input for what it's worth is that the cited answers are what the outcome 
should be. MERGE is intrinsic, not a customer written function. "magic" 
aka optimization should be encouraged to the greatest extent possible in 
the Fortran tradition.

If someone really wants to enforce execution, they should write it 
themselves, or wrap it in a user function (really good optimizers might 
see through such artifices; but we never put in precise optimization 
barrier instructions ;>).
 

Keith Bierman
khbkhb at gmail.com
kbiermank AIM
303 997 2749
_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20101118/5afd5eb8/attachment.htm>



More information about the J3 mailing list