Re: 3.0 branch: wrong CFLAGS for gen*

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Robert Lipe <robertlipe@usa.net>
 > 
 > > >  > The two occurrences of it in genattr.c are consecutive at line
 > > >
 > > > I don't see a call to free anywhere, so I think this xmalloc gets
 > > > leaked.  That's the flipside of this anti-alloca sentiment.  It
 > > > doesn't look like a big deal here, but it's sloppy.
 > >
 > > I suggest apply the mainline treatment to the branch. genattr is not
 > > a program that will run forever; a little memory leakage there is
 > > nothing compared with not being able to build the thing.  (But, yes,
 > > we should figure out how to free the memory some day...)
 > >
 > > The obvious patch is preapproved for the branch.
 > 
 > Sorry to be dense, but which obvious patch, the one that reverted the
 > Makefiles or this one:
 > 
 > 
 > Index: genattr.c
 > ===================================================================
 > RCS file: /cvs/gcc/egcs/gcc/genattr.c,v
 > retrieving revision 1.38
 > diff -u -p -r1.38 genattr.c
 > --- genattr.c   2000/11/10 16:01:14     1.38
 > +++ genattr.c   2001/10/05 14:24:53
 > @@ -279,11 +279,9 @@ from the machine description file `md'.
 >  
 >           if (unit == 0)
 >             {
 > -             int len = strlen (name) + 1;
 >               unit = (struct function_unit *)
 > -               alloca (sizeof (struct function_unit));
 > -             unit->name = (char *) alloca (len);
 > -             memcpy (unit->name, name, len);
 > +               xmalloc (sizeof (struct function_unit));
 > +             unit->name = xstrdup (name);
 >               unit->multiplicity = multiplicity;
 >               unit->simultaneity = simultaneity;
 >               unit->ready_cost.min = unit->ready_cost.max = ready_cost;
 > 
 > 
 > Bootstrap in progress now.   Depressingly, I suppose I can't regression
 > test it since my stinking target hasn't bootstrapped for weeks...
 > 
 > 
 > Someone (Kaveh?) recently said that everyone knows that genFOO can't use
 > alloca.   If I understood that correctly,  a "grep 'alloca (' gen*.c"
 > disagrees. 
 > RJL

Okay, I believe I misspoke because I was confused between the trunk
and the branch.  Let me try to resummarize the alloca situation for
both places.

For the 3.0 branch, alloca.c is symlinked from the libiberty directory
and built in the gcc build dir.  If host!=build, then two copies are
created, one for each.  These object files are linked via $LIBS and
$HOST_LIBS in the Makefile.  So one is free to use alloca in the
gen*.c programs, even in the "build" programs and if the stage1
compiler doesn't have a builtin alloca, then the C alloca will be used
instead.

On the trunk, the situation is different.  The alloca machinery was
removed IIRC by one of Zack's cleanups.  You either get it from
libiberty or a compiler builtin.  Since there is no "build" libiberty,
you can't use alloca in "build" programs any more.  Part of the
cleanup was to remove all uses of alloca in "build" programs.

Anyway, since we're talking about the 3.0 branch, Robert you should be
able to link genattr and get alloca from alloca.o.  I looked at the
link command for genattr in the Makefile and it does get $HOST_LIBS.
So I am at a loss to explain why your link failed.  Certainly if that
is failing, then you shouldn't be able to link any other gen* programs
either.  So I'm very curious what is going on here.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions