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
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)
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.
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
> > 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
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
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)
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
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
RSS Feed3 | |
|---|---|
21 | |
26 | |
16 | |
5 | |
14 | |
6 | |
36 | |
12 | |
6 | |
47 | |
17 | |
9 | |
15 | |
4 | |
21 | |
5 | |
27 | |
49 | |
50 | |
49 | |
14 | |
25 | |
30 | |
17 | |
16 | |
37 | |
47 | |
1 | |
2 | |
7 | |
14 | |
47 | |
14 | |
60 | |
120 | |
51 | |
28 | |
155 | |
29 | |
5 | |
18 | |
16 | |
6 | |
9 | |
45 | |
11 | |
74 | |
21 | |
23 | |
22 | |
23 | |
64 | |
33 | |
132 | |
34 | |
26 | |
67 | |
48 | |
14 | |
63 | |
21 | |
7 | |
29 | |
32 | |
44 | |
48 | |
45 | |
39 | |
13 | |
18 | |
43 | |
29 | |
19 | |
18 | |
56 | |
16 | |
42 | |
32 | |
39 | |
62 | |
78 | |
17 | |
21 | |
52 | |
30 | |
54 | |
8 | |
15 | |
32 | |
20 | |
79 | |
47 | |
19 | |
40 | |
90 | |
48 | |
22 | |
50 | |
26 | |
5 | |
55 | |
23 | |
48 | |
85 | |
30 | |
57 | |
69 | |
53 | |
83 | |
129 | |
82 | |
127 | |
94 | |
135 | |
65 | |
73 | |
30 | |
62 | |
107 | |
32 | |
78 | |
52 | |
43 | |
82 | |
65 | |
50 | |
30 | |
65 | |
50 | |
55 |
