https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80153
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 23 Mar 2017, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80153 > > --- Comment #5 from amker at gcc dot gnu.org --- > Seems there is an issue that tree-affine lacks ability differentiating between > (unsgined)(pointer + offset) and (unsigned)pointer + (unsigned)offset. Yes, same for (unsigned)int + (unsigned)int and thus integer overflow. > The current behavior of tree_to_aff_combination always folds type conversion > into operands, generating exact the same affines for above two expressions: > > { > type = unsigned int > offset = 6 > elements = { > [0] = "oops!\n" * 1, > [1] = ivtmp.37_10 * 0xffffffffffffffffffffffffffffffffffffffffffffffff > } > } > > While converting affine back to tree, it takes the other way around, always > generating the latter expression: (unsgined)(pointer + offset). This causes > problem. > > IIUC, there are two possible fixes here. First one is as you mentioned, we > work conservatively and don't fold type conversion into operands (by not > stripping nop). I suspect this could causes serious code generation > regression. Yeah. > The second one is the opposite, we always fold type conversion into operands, > by keeping strip_nops. While converting affine back to tree, we generate > folded expression instead of trying to preserve pointer_plus expression as > now. > I prefer the second one, and understand there is concern since tree affine is > used in code generation we could lose pointer arithmetic semantic information > like the pointer_plus expression never overflows/wraps. I think it does that for integer arithmetic already (use unsigned for all computation) but I may be mistaken...
