On Wed, Jul 11, 2012 at 12:11 PM, Steven Bosscher <stevenb....@gmail.com> wrote: > On Wed, Jul 11, 2012 at 12:06 PM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Wed, Jul 11, 2012 at 11:41 AM, Steven Bosscher <stevenb....@gmail.com> >> wrote: >>> Hello, >>> >>> One for under the "eat your own dog food" header. >>> >>> Bootstrapped and tested on powerpc64-unknown-linux-gnu. >>> cc1 is a few bytes smaller. I expect the benefits to be more >>> noticeable with an LTO-enabled bootstrap, but I haven't figured out >>> yet how to do that :-) >>> >>> OK for trunk? >> >> Hmm, we assume that the contents of the allocated memory is >> undefined (zero content is ok practically). So if there is no hidden >> init code anywhere in those functions the patch is ok. > > Yes, I was careful to watch out for that. This is why e.g. > ggc_alloc_string_stat isn't an ATTRIBUTE_MALLOC function. The only > thing I wasn't sure about, is whether the poisoning of memory with > ENABLE_GC_CHECKING counts as undefined.
Yes, I suppose so. The point is that there sould be no way to reproducibly create a valid pointer by combining data from that undefined content. Thus, char *mem = alloc (); int *ptr = mem[4] | (mem[7] + 3) << 8 | ...; should never yield a pointer to an actual integer object. if (mem[4] == 3) ptr = &i; else ptr = &j; is ok, thus only flow of actual data is what matters. "Zero filling is ok" may be overly optimistic for -fno-delete-nullpointer-checks targets where zero is a valid object address though ... Richard. > Ciao! > Steven
