RE: [PATCH, function-specific-branch, committed] Cast alloca/xmalloc results to appropriate type.

["Meissner, Michael" <michael dot meissner at amd dot com>]

> -----Original Message-----
> From: Kaveh R. GHAZI [mailto:ghazi@caip.rutgers.edu]
> Sent: Wednesday, June 25, 2008 3:05 PM
> To: Meissner, Michael
> Cc: Richard Guenther; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, function-specific-branch, committed] Cast
> alloca/xmalloc results to appropriate type.
> 
> On Wed, 25 Jun 2008, Michael Meissner wrote:
> 
> > On Wed, Jun 25, 2008 at 05:08:32PM +0200, Richard Guenther wrote:
> > > On Wed, Jun 25, 2008 at 5:06 PM, Michael Meissner
> > > <michael.meissner@amd.com> wrote:
> > > > I noticed when moving the function specific patches to the
current
> trunk that
> > > > we now turn on the warnings about needing a cast from void *
when
> GCC converts
> > > > to C++, so this patch fixes some warnings in the code I wrote.
> > >
> > > You should use the allocator macros from libiberty instead.
> >
> > In two places, I could use ASTRDUP (assuming I can rely on
STRING_CST
> nodes
> > always having a null byte after the string), but in other places
> libiberity
> > alloca/xmalloc wrappers do not do what I need to do.
> >
> > For instance in c-common.c, I am converting from the string passed
to
> > attribute((optimize)) and optionally adding a '-', '-O', or '-f'
prefix
> before
> > the string, based on what is passed.  Then I need to allocate the
argv
> pointer
> > array, and there is no appropriate alloca macro.
> >
> > In i386.c, I am building a complete string of all of the arguments,
and
> the
> > xmalloc wrapper only takes a single type, not a length.  The concat
> functions
> > only work on arguments passed in, and not on an array of arguments
that
> are
> > being concatenated together.
> 
> 
> I recently added to the available macros in libiberty.h:
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01470.html
> 
> I believe all the alloca cases in your patch could be handled using
> XALLOCAVEC(char, ...) or maybe "const char *" for the string vector.


Cool, I'm just merging up to 137119 right now.  I saw that there
libiberity changes, but I hadn't looked at them yet.

--
Michael Meissner
AMD, MS 83-29
90 Central Street
Boxborough, MA 01719