Martin Husemann | 1 Dec 08:54 2005
Picon

alloca in libc

Stupid question - shouldn't we use the gcc builtin alloca()?
Some archs seem to have alloca implementations in libc, others don't.

I ask because the recent constifications to execl*.c made them use alloca
on sparc64, and sparc64 has no libc alloca implementation.

So the other part of the question - why is gcc not using the builtin when
complinig libc?

Martin

Juergen Hannken-Illjes | 1 Dec 09:04 2005
Picon
Picon

Re: alloca in libc

On Thu, Dec 01, 2005 at 08:54:21AM +0100, Martin Husemann wrote:
> Stupid question - shouldn't we use the gcc builtin alloca()?
> Some archs seem to have alloca implementations in libc, others don't.
> 
> I ask because the recent constifications to execl*.c made them use alloca
> on sparc64, and sparc64 has no libc alloca implementation.

dito for at least sparc and evbppc

> So the other part of the question - why is gcc not using the builtin when
> complinig libc?
> 
> Martin

--

-- 
Juergen Hannken-Illjes - hannken <at> eis.cs.tu-bs.de - TU Braunschweig (Germany)

Martin Husemann | 1 Dec 16:13 2005
Picon

Re: alloca in libc

On Thu, Dec 01, 2005 at 08:54:20AM +0100, Martin Husemann wrote:
> So the other part of the question - why is gcc not using the builtin when
> complinig libc?

Ok, I found it: we now use -std=c99

Martin

matthew green | 1 Dec 18:37 2005
Picon

re: alloca in libc


   On Thu, Dec 01, 2005 at 08:54:20AM +0100, Martin Husemann wrote:
   > So the other part of the question - why is gcc not using the builtin when
   > complinig libc?

   Ok, I found it: we now use -std=c99

why do we do that?  i don't see how it is correct espcially since we
don't try to program to a strictly C99 environment.  is alloca()
part of C99?  maybe this option correctly turns off the builtin?

i had also noticed this problem on macppc with something compiled
with -ansi.

Jason Thorpe | 1 Dec 21:52 2005

Re: alloca in libc


On Dec 1, 2005, at 9:37 AM, matthew green wrote:

>
>    On Thu, Dec 01, 2005 at 08:54:20AM +0100, Martin Husemann wrote:
>> So the other part of the question - why is gcc not using the  
>> builtin when
>> complinig libc?
>
>    Ok, I found it: we now use -std=c99

If you used -std=gnu99 alloca() should still be available.

Furthermore, we could provide our own <alloca.h> header file that  
simply:

#define	alloca(x)	__builtin_alloca(x)

That would work with any -std=... option.

-- thorpej

Anders Hjalmarsson | 1 Dec 22:14 2005
X-Face
Picon

Re: alloca in libc


> 
> If you used -std=gnu99 alloca() should still be available.
> 
> Furthermore, we could provide our own <alloca.h> header file that  
> simply:
> 
> #define	alloca(x)	__builtin_alloca(x)
> 
> That would work with any -std=... option.
> 
> -- thorpej

Do we really need a new header, can't we simply put that define in
stdlib.h (where it is currently declared)?
After all, if the protype is visible after including <stdlib.h>,
surely one would expect the function to be provided in some way without
including extra headers.

-hjalmar

David Young | 2 Dec 09:50 2005
Picon

please test: makefs -t cd9660 code-sharing patch

Please test
<http://che.ojctech.com/~dyoung/public/makefs-code-sharing-patch>, which
stops makefs duplicating the kernel's cd9660 code.  I am especially
interested in test results on non-NetBSD build hosts.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933

Jeff Rizzo | 3 Dec 08:30 2005
Picon

Re: please test: makefs -t cd9660 code-sharing patch

David Young wrote:

>Please test
><http://che.ojctech.com/~dyoung/public/makefs-code-sharing-patch>, which
>stops makefs duplicating the kernel's cd9660 code.  I am especially
>interested in test results on non-NetBSD build hosts.
>
>Dave
>
>  
>

I don't have time to delve into it tonight to see if I messed something
up, but on my Powerbook running MacOS 10.4.3:

host113:riz  ~/netbsd/src> ./build.sh -U -M ~/netbsd/buildobj -T
~/netbsd/tools  -u -m i386 release

<SNIP>

nbmake: don't know how to make
/Users/riz/netbsd/src/tools/makefs/../../usr.sbin/makefs/cd9660/iso.h. Stop

nbmake: stopped in /Users/riz/netbsd/src/tools/makefs

*** Failed target:  dependall
*** Failed command: cd /Users/riz/netbsd/src/tools/makefs;
/Users/riz/netbsd/tools/bin/nbmake realall

(Continue reading)

David Young | 3 Dec 08:46 2005
Picon

Re: please test: makefs -t cd9660 code-sharing patch

On Fri, Dec 02, 2005 at 11:30:12PM -0800, Jeff Rizzo wrote:
> David Young wrote:
> 
> >Please test
> ><http://che.ojctech.com/~dyoung/public/makefs-code-sharing-patch>, which
> >stops makefs duplicating the kernel's cd9660 code.  I am especially
> >interested in test results on non-NetBSD build hosts.
> >
> >Dave
> >
> >  
> >
> 
> I don't have time to delve into it tonight to see if I messed something
> up, but on my Powerbook running MacOS 10.4.3:
> 
> host113:riz  ~/netbsd/src> ./build.sh -U -M ~/netbsd/buildobj -T
> ~/netbsd/tools  -u -m i386 release

I have a hunch you need to run ~/netbsd/tools/bin/nbmake-i386 distclean
in tools/makefs/.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933

Jeff Rizzo | 3 Dec 17:35 2005
Picon

Re: please test: makefs -t cd9660 code-sharing patch

David Young wrote:

>
>I have a hunch you need to run ~/netbsd/tools/bin/nbmake-i386 distclean
>in tools/makefs/.
>
>  
>

Correct!  After cleaning out all the various directories and doing a
full build overnight, it worked on MacOS 10.4.3.

Thanks,
+j


Gmane