https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #47 from Alexander Cherepanov <ch3root at openwall dot com> --- On 2015-11-16 14:00, rguenther at suse dot de wrote: >> --- Comment #43 from Jeehoon Kang <jeehoon.kang at sf dot snu.ac.kr> --- >> - Performance degradation due to "casted pointers as escaped" is >> insignificant. > > I think this is not true. For example with MatLab (might be sth else, > if I don't remember correctly) you are required to pass pointers to > arrays in two halves in double(!) values (I believe the only function > argument type they support). GCC happily makes points-to analysis work > through those. But this is invalid C. First, it breaks strict aliasing rules. Second, the representations of these doubles are free to change at any time given their values are kept intact (e.g. change one NaN to another). That is, unrelated improvements in other optimizations in gcc will break all of this in the future, right? > I also don't think doing the above would solve the cases of equality > compares of pointes themselves. (hopefully undefined) Hm, undefining comparisons between a pointer pointing past the end of an object and a pointer to another object could be a way forward. You propose to undefine it for any objects (similar to "<") or only when they are not parts (including recursively) of the same aggregate? In any case this will fix some theoretical problems, e.g. transitivity of == as described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502#c17 . OTOH, again in any case, it will not solve all problems. For instance, if you want to track bounds of arrays in runtime you still can get equal pointers with different additional info -- pointers to an object and a subobject. Granted, this is kinda hypothetical (IIUC UBSAN works a bit different right now). > I added the current handling of pointers vs. integers for a > missed-optimization bug that said a hand-written memcpy loop > didn't properly transfer points-to info (properly as in > optimially for optimization). GCC can now do that ;) Nice! Does gcc properly transfer effective type info too, over a hand-written memcpy loop? Just curious. On 2015-11-16 15:51, rguenther at suse dot de wrote: >> Thank you for giving me the information. I don't know the GCC internals, so I >> would like to ask how much it would cost to introduce the syntax for pointer >> subtractions. I hope it is not that huge, but I really don't have any idea. > > It would be quite some (mechanical) work but otherwise not too difficult. > There is the choice whether to embed the division implicitely here or > not. If you choose to fix it please fix pr45779 on the way (see pr67999 for a context).
