On Wed, Jan 7, 2009 at 5:09 PM, DJ Delorie <d...@redhat.com> wrote: > >> As I repeatedly said having sizetype of a different precision than >> pointer types will cause all sorts of problems ;) > > And as I've rebutted repeatedly, I can't change the chip. > >> The middle-end generally assumes it can cast between sizetype and >> pointers arbitrarily. > > Bad assumption. It will get worse with the upcoming named address > branch work.
Yeah well. It can only get fixed if we get rid of the restriction of using sizetype for POINTER_PLUS_EXPR. Which is some work. >> In the above case, what type is tmp_9, what type is tmp_16? > > The 107t dump file doesn't say, but the .128r.expand file looks like this: It should. Actually they should be the same type (the variable name is tmp). So, tmp_9 = tmp_16 + 2; D.1229_1 = (unsigned int) tmp_9; tmp_13 = (short unsigned int *) D.1229_1; if (bufend_6(D) > tmp_13) there is probably some place that inserts a useless conversion sequence (well, not useless in your case ;)) from tmp to unsigned int to short unsigned int *. I guess tmp is not short unsigned int * but some other pointer type, right? But bufend is short unsigned int *? Can you open a bugzilla for this? It should be not too difficult to track down the piece of IVOPTs that creates that conversion sequence ... Richard.
