https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 2 Jun 2016, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372 > > --- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- > On Wed, 1 Jun 2016, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372 > > > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |jakub at gcc dot gnu.org > > > > --- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Isn't > > this generally a problem of the whole folder, not just cp_fold? I mean, > > if you have say MEM[&MEM[p, CST1], CST2] and the outer MEM_REF has e.g. > > TREE_THIS_VOLATILE, TREE_THIS_NOTRAP, TREE_SIDE_EFFECTS, TREE_READONLY, > > TREE_CONSTANT set on it, and you call fold on it, then I don't see what > > would preserve those bits (not sure if all of them are applicable). I > > True, but that's a bug of that specific folder then. Actually it's not a bug of those but of the callers (given fold_binary doesn't get to see that flag). > > see just > > switch (TREE_CODE_LENGTH (code)) > > { > > case 1: > > op0 = TREE_OPERAND (t, 0); > > tem = fold_unary_loc (loc, code, type, op0); > > return tem ? tem : expr; > > case 2: > > op0 = TREE_OPERAND (t, 0); > > op1 = TREE_OPERAND (t, 1); > > tem = fold_binary_loc (loc, code, type, op0, op1); > > return tem ? tem : expr; > > case 3: > > op0 = TREE_OPERAND (t, 0); > > op1 = TREE_OPERAND (t, 1); > > op2 = TREE_OPERAND (t, 2); > > tem = fold_ternary_loc (loc, code, type, op0, op1, op2); > > return tem ? tem : expr; > > without really trying to preserve anything. This would need to do the fixup in case of tcc_reference codes. Fortunately fold () calls are rare.
