2011/10/12 Michael Matz <m...@suse.de>: > Hi, > > On Wed, 12 Oct 2011, Kai Tietz wrote: > >> > And I think it could use some overview of the transformation done like in >> > the initial patch, ala: >> > >> > "Transform ((A && B) && C) into (A && (B & C))." >> > >> > and >> > >> > "Or (A && B) into (A & B)." for this part: >> > >> > + /* Needed for sequence points to handle trappings, and side-effects. >> > */ >> > + else if (simple_operand_p_2 (arg0)) >> > + return fold_build2_loc (loc, ncode, type, arg0, arg1); >> >> Well to use here binary form of operation seems to me misleading. > > Hmm? What do you mean? Both operations are binary. ANDIF is '&&', AND > is '&'. In fold-const.c comments we usually use the C notations of the > operations.
See TRUTH_AND_EXPR is in C-notation && and TRUTH_ANDIF_EXPR is also &&. The transcription to binary & is done in gimplifier. Btw I just noticed that by this patch a latent bug in gimplifier about boolification for TRUTH_NOT_EXPR/TRUTH_AND/OR... is present. On Fortran there are different boolean-kinds types with different precision. This makes them incompatible to eachother in gimple (as useless_type_conversion_p returns for them false). For gimplier needs to ensure that operands for those TRUTH_... expression met a compatible type of final expression type. I will sent a patch for this as soon I completed regression-testing for it. >> It is right that the non-IF AND/OR has finally the same behavior as the >> binary form in gimple. Nevertheless it isn't the same on AST level. But >> sure I can Add comments for operations like (A OR/AND-IF B) OR/AND-IF C >> -> (A OR/AND-IF (B OR/AND C and A OR/AND-IF C -> (A OR/AND C) > > Too much noise, leave out the || variant, and just say once "Same for ||." > > > Ciao, > Michael. Cheers, Kai