On Fri, May 25, 2007 at 11:00:51PM +0100, Al Viro wrote: > > But that means a fsckload of extra nodes allocated on pretty much any > > program - use of arrays is not rare and indices tend to be int, so we > > hit an extra allocated node on each such place. > > Argh... Question: how much do we care if we see BINOP[+] with 64bit > type as result and 32bit type in one of the arguments? That's what > we get when we have > char *p; > int i; > > p + i > > with -m64. IOW, how much does it violate the assumptions outside of > frontend? We do not allocate any new nodes if sizeof(*p) is 1... Actually, turns out that at least on the kernel builds a straightforward variant (IMPLIED_CAST when width of i is smaller than bits_in_pointer, whatever sizeof(*p) might be) isn't visibly smaller... It would need more profiling, but there's a chance that nothing trickier would be needed. BTW, _Bool is seriously mishandled - for one thing, some places treat it as one-bit unsigned integer (i.e. (_Bool)2 becomes 0 with a warning, while it should yield 1). For another, sizeof(_Bool) becomes 0, with all obvious breakage. And finally, assignment of pointer to _Bool generates a warning and cast.1 in linearizer. Correct behaviour is (a) no warning whatsoever and (b) replacement with b = (p != NULL). The same thing applies in passing arguments and in return statement, of course... Oh, and type of comparison result is int, not _Bool... It rarely matters, but sometimes it does - e.g. sizeof(0 == 0) should evaluate to sizeof(int), not sizeof(_Bool) (which basically casts the damn thing in stone - changing the type of == result on valid C90 arguments would break existing programs). I agree that use of bool_ctype in evaluate_compare() is very natural, but we should at least take care interaction with sizeof ;-/ - To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
