https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #11 from kargls at comcast dot net --- On 11/28/24 04:54, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805 > > --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> --- > Note with a patch like in comment#4 you'd get different answers for > complex * { a, -0.} and complex * { a, b } with b being -0., that > might be undesirable. The question is how the Frontend presents > us with a complex times real multiplication (I think GENERIC requires > two complex operands), and thus whether the desired optimization would > have to take place in the frontend to avoid the above consistency issue. > This is not processor-dependent behavior. gfortran implements real*complex in accordance with the words of the Fortran standard. 10.1.5.2.1 Interpretation of numeric intrinsic operations The two operands of numeric intrinsic binary operations may be of different numeric types or different kind type parameters. Except for a value of type real or complex raised to an integer power, if the operands have different types or kind type parameters, the effect is as if each operand that differs in type or kind type parameter from those of the result is converted to the type and kind type parameter of the result before the operation is performed. If 'r' is of type REAL and 'z' is of type COMPLEX, the Fortran standard is clear that the interpretation is <result is complex> = r * z = (r, 0.) * z The Fortran standard stops at this point and does not specify the actual underlying algorithm. The Fortran committee is leaning on 10.1.5.2.4 Evaluation of numeric intrinsic operations ... Once the interpretation of a numeric intrinsic operation is established, the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated. The claim is that 'r*z' is mathematically equivalent to 'r*x + I r*y', where 'x' and 'y' are the real and imaginary parts of 'z'. Somehow, J3 claims that +-inf are not part of the real numbers because IEEE-754 calls them special values. There is also the matter of two sets of implicit parentheses, J3 managed to ignore. Given Note 2 (F23, p 163), it is forbidden to transform 'X*(Y-Z)' into 'X*Y - X*Z'. Finally, note that it isn't a simply matter of adding an option. The point of the code in comment #7 is that someone will need to audit fortran/arith.cc to change gfortran's constant folding to not enforce 10.1.5.2.1 in the presence of this option. This audit may also then need to be extended to fortran/simplify.cc to determine how simplification may be affected by this option. Is is possible to do this audit? Sure. Someone will likely do it, ...., eventually. See ee cummings, 'anyone lived in a pretty how town'
