On Thu, Nov 17, 2016 at 01:56:03PM -0700, Jeff Law wrote:
> On 11/17/2016 11:24 AM, Jakub Jelinek wrote:
> >On Thu, Nov 17, 2016 at 11:14:26AM -0700, Martin Sebor wrote:
> >>--- a/gcc/fortran/interface.c
> >>+++ b/gcc/fortran/interface.c
> >>@@ -2821,7 +2821,8 @@ compare_actual_formal (gfc_actual_arglist **ap,
> >>gfc_formal_arglist *formal,
> >> for (f = formal; f; f = f->next)
> >> n++;
> >>
> >>- new_arg = XALLOCAVEC (gfc_actual_arglist *, n);
> >>+ /* Take care not to call alloca with a zero argument. */
> >>+ new_arg = XALLOCAVEC (gfc_actual_arglist *, n + !n);
> >>
> >> for (i = 0; i < n; i++)
> >> new_arg[i] = NULL;
> >
> >Ugh, that is just too ugly. I don't see anything wrong on alloca (0),
> >and we don't rely on those pointers being distinct from other pointers.
> On systems where alloca was implemented on top of malloc, alloca (0) would
> cause collection of alloca'd objects that had gone out of scope.
Ouch. Do we support any such systems as hosts? If yes, can't we just
define XALLOCAVEC etc. to alloca (len + 1) or alloca (len ? len : 1)
on those systems and leave the sane hosts as is?
Jakub
