On Wed, Nov 23, 2016 at 06:15:11PM -0700, Martin Sebor wrote:
> >Can't we just
> >gcc_assert (x != 0) before the problematical calls? That avoids
> >unnecessary over-allocation and gets us a clean ICE if we were to try
> >and call alloca with a problematical value.
>
> gcc_assert works only in some instances (e.g., in c-ada-spec.c:191)
> but not in others because some actually do make the alloca(0) call
> at runtime: at a minimum, lto.c:3285, reg-stack.c:2008, and
> tree-ssa-threadedge.c:344 assert during bootstrap.
>
> After reviewing a few more of the XALLOCAVEC calls in the affected
> files I suspect that those to alloca(0) pointed out by the warning
> may be just a subset that GCC happens to see thanks to constant
> propagation. If that's so then changing this subset to
> alloca(N + !N) or some such is probably not the right approach
> because it will miss all the other calls where GCC doesn't see that
> N is zero. I think the most robust solution is to do as Bernd
> suggests: change XALLOCAVEC as shown above. That will let us
> prevent any and all unsafe assumptions about the result of
> alloca(0) being either non-null or distinct. The other approach
> would be to change XALLOCAVEC to add 1 to the byte count. That
> would be in line with what XMALLOC does.
I still fail to see why you want to change anything at least for
hosts where you know XALLOCAVEC is __builtin_alloca.
Show me one place which assumes the result of alloca (0) in gcc sources is
distinct, or non-NULL. For 0 elements the pointer simply isn't used.
And whether for the malloc based alloca it GCs or not really doesn't matter
for us.
Jakub
