http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48880
--- Comment #3 from Witold Baryluk <baryluk at smp dot if.uj.edu.pl> 2011-05-05 09:55:25 UTC --- In my case it only happens if I have two independent calls with different arguments. I do not understand some aspects, but removing some semingly unrelated things or adding some dummy variable write, make bug disapear. It shouldn't matter, but maybe VRP information is somehow cached for each block, and this caching do not takes into accout some additional informations? It looks very similar to PR46639 - in original test case I even had program with structure somehow similar to one from PR46639 (assigning a pointer function to the static global variable), but after minimizing it further I removed it and failure still occurs. As of figuring out that at <bb 4> a n_2(D) is in range [1, 3] isn't hard. It can be done both in forward as well a backward manner. (but of course VRP works by propgating forward, but does it consider separetly all data paths?) I know it isn't bug, but is regression and gcc isn't doing properly VRP or inlineing somewhere probably. I reported it only because kernel failed to compile :) And AFAIK linux kernel uses extensively static checks for things like memset, memcpy, copy_from_user, etc., to make sure all calls call them with legth/count/size not bigger than actual buffer size to which they are writing or reading. I of course can compile linux kernel by unseting proper CONFIG_* in kernel configuration. It is also quite important as it could remove significant amount of dead code after partial inlineing.
