headers
Iain Hibbert | 1 May 2011 14:37

Re: CVS commit: pcc/arch/amd64

On Wed, 2 Mar 2011, Anders Magnusson wrote:

> Module Name:	pcc
> Committed By:	ragge
> Date:		Wed Mar  2 17:37:31 UTC 2011
>
> Modified Files:
> 	pcc/arch/amd64: local.c
>
> Log Message:
> #ifdef notyet removal of unneccessary casts in branch tests, needs debugging.
> Fixes Jira#PCC-269 by Nicolas Joly.
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.42 -r1.43 pcc/arch/amd64/local.c

I think this introduced a compile-time error (from -Wall on gcc) in that
the toolarge() function is now unused, patch attached

iain

Index: arch/amd64/local.c
===================================================================
RCS file: /cvsroot/pcc/arch/amd64/local.c,v
retrieving revision 1.47
diff -u -p -r1.47 local.c
--- arch/amd64/local.c	14 Apr 2011 17:01:16 -0000	1.47
+++ arch/amd64/local.c	1 May 2011 12:30:10 -0000
 <at>  <at>  -33,6 +33,7  <at>  <at> 
 /*
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iain Hibbert | 7 May 2011 18:58

parallel build failures

Hi

I occasionally see parallel build failures with ccom, and looking a bit
closer at the output of "gmake -j4" I perhaps see why:

===> cc/ccom
gmake[2]: Entering directory `/tmp/pcc/cc/ccom'
gcc   -DGCC_COMPAT -DPCC_DEBUG -Dos_netbsd -Dmach_i386 -D_ISOC99_SOURCE -I. -I. -I../.. -I../../mip
-I../../arch/i386 -I../../os/netbsd  -g -O2  -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wshadow -Wsign-compare -DMKEXT -o mkext \
../../mip/mkext.c ../../arch/i386/table.c ../../mip/common.c
yacc  -d cgram.y
gcc   -DGCC_COMPAT -DPCC_DEBUG -Dos_netbsd -Dmach_i386 -D_ISOC99_SOURCE -I. -I. -I../.. -I../../mip
-I../../arch/i386 -I../../os/netbsd  -g -O2  -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wshadow -Wsign-compare -DMKEXT -o mkext \
../../mip/mkext.c ../../arch/i386/table.c ../../mip/common.c
mv y.tab.c cgram.c
mv y.tab.h cgram.h
flex  scan.l
mv lex.yy.c scan.c
./mkext
gcc  -DGCC_COMPAT -DPCC_DEBUG -Dos_netbsd -Dmach_i386 -D_ISOC99_SOURCE -I. -I. -I../.. -I../../mip
-I../../arch/i386 -I../../os/netbsd  -g -O2  -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wshadow -Wsign-compare -c -o external.o external.c
./mkext
gcc  -DGCC_COMPAT -DPCC_DEBUG -Dos_netbsd -Dmach_i386 -D_ISOC99_SOURCE -I. -I. -I../.. -I../../mip
-I../../arch/i386 -I../../os/netbsd  -g -O2  -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wshadow -Wsign-compare -c -o optim.o optim.c

it seems that mkext is being built and run twice, and sometimes there is a
(Continue reading)

Permalink | Reply | 10 comments |
headers
Thorsten Glaser | 7 May 2011 19:43
Picon
Gravatar

Re: parallel build failures

Iain Hibbert dixit:

>The patch below seems to fix it, by channeling the dependencies through
>the mkext binary itself, I don't know if there is a better way..

I think that’s the correct way to fix it.

Disclaimer: not tried, I don’t use parallel builds.

bye,
//mirabilos
--

-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
	-- me, wondering why it’s not Jerry Potter………
Permalink | Reply | 9 comments |
headers
Iain Hibbert | 7 May 2011 21:05

Re: parallel build failures

On Sat, 7 May 2011, Thorsten Glaser wrote:
> Iain Hibbert dixit:
> >The patch below seems to fix it, by channeling the dependencies through
> >the mkext binary itself, I don't know if there is a better way..
>
> I think that's the correct way to fix it.

I think the actual creation of external.[ch] is inherently ambiguous,
since the mkext program is not documented to spit them out in a particular
order. gmake doesn't have anything like .WAIT though so its probably the
best way forward

> Disclaimer: not tried, I don?t use parallel builds.

Mmmm... delicious SMP :)

% (gmake clean && /usr/bin/time gmake) >/dev/null
yacc: 4 shift/reduce conflicts.
       23.39 real        21.66 user         1.53 sys
% (gmake clean && /usr/bin/time gmake -j4) >/dev/null
yacc: 4 shift/reduce conflicts.
       10.45 real        14.61 user         1.02 sys
% (gmake clean && /usr/bin/time gmake) >/dev/null
yacc: 4 shift/reduce conflicts.
       23.49 real        21.73 user         1.51 sys
% (gmake clean && /usr/bin/time gmake -j4) >/dev/null
yacc: 4 shift/reduce conflicts.
        8.82 real        13.33 user         1.10 sys

dual core iain
(Continue reading)

Permalink | Reply | 8 comments |
headers
Thorsten Glaser | 7 May 2011 21:21
Picon
Gravatar

Re: parallel build failures

Iain Hibbert dixit:

>I think the actual creation of external.[ch] is inherently ambiguous,
>since the mkext program is not documented to spit them out in a particular
>order.

Hm. Why not just depend on one of them then?
(The other could depend on that one.)

>Mmmm... delicious SMP :)

hw.model=Intel(R) Pentium(R) M processor 1.40GHz ("GenuineIntel" 686-class)
hw.ncpu=1

>dual core iain

//“I can deal with Debian/m68k because I’m used to
  slowness from BSD” mirabilos

PS: The hard disc (IBM X40…) is worse, I’m saving for the CF
    adaptor and 2x64 GB CF-cards currently…
--

-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
	-- me, wondering why it’s not Jerry Potter………
Permalink | Reply | 7 comments |
headers
Iain Hibbert | 8 May 2011 10:13

Re: parallel build failures

On Sat, 7 May 2011, Thorsten Glaser wrote:

> Iain Hibbert dixit:
>
> >I think the actual creation of external.[ch] is inherently ambiguous,
> >since the mkext program is not documented to spit them out in a particular
> >order.
>
> Hm. Why not just depend on one of them then?
> (The other could depend on that one.)

since the two files are created concurrently I think it would leave an
opening for make to run ./mkext twice sometimes..

iain
Permalink | Reply | 6 comments |
headers
Thorsten Glaser | 8 May 2011 12:24
Picon
Gravatar

Re: parallel build failures

Iain Hibbert dixit:

>> Hm. Why not just depend on one of them then?
>> (The other could depend on that one.)
>
>since the two files are created concurrently I think it would leave an
>opening for make to run ./mkext twice sometimes..

I was thinking of something like this:

external.h: external.c
external.c: mkext
	./mkext

bye,
//mirabilos
--

-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.	-- Rob Pike in "Notes on Programming in C"
Permalink | Reply | 5 comments |
headers
Thorsten Glaser | 8 May 2011 21:01
Picon
Gravatar

Re: parallel build failures

Dixi quod…

>external.h: external.c
>external.c: mkext
>	./mkext

Nevermind, that can’t cover all cases either.
How _are_ things like that done normally, portably?
(Yacc comes to mind.)

external.c external.h: mkext
	./mkext

Does this work or run mkext twice?

bye,
//mirabilos
--

-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”	-- Tonnerre, psychoschlumpf and myself in #nosec
Permalink | Reply | 4 comments |
headers
Iain Hibbert | 8 May 2011 22:54

Re: parallel build failures

On Sun, 8 May 2011, Thorsten Glaser wrote:

> Dixi quod?
>
> >external.h: external.c
> >external.c: mkext
> >	./mkext
>
> Nevermind, that can?t cover all cases either.
> How _are_ things like that done normally, portably?
> (Yacc comes to mind.)

I think yacc rules generally ignore the .h file on the principle that it
is tied to the .c file, and we could do the same for external.h, just
listing external.c as a dependency for the object files..

> external.c external.h: mkext
> 	./mkext
>
> Does this work or run mkext twice?

at the time the decision is made, neither of the targets exist, so both
rules will be processed in parallel.. (ie run twice :)

been fiddling today, cleaned up Makefile.in attached

- drop DEF as unused
- use ${..} consistently for variables
- use CFLAGS consistently (sometimes _CFLAGS was used)
- use ${srcdir} where appropriate
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antoine Leca | 9 May 2011 10:18
Picon
Favicon

Re: parallel build failures

Thorsten Glaser wrote:
> How _are_ things like that done normally, portably?
> (Yacc comes to mind.)

I am interested by the answers at this question, but I won't hold my
breath. I stumbed on this subject while applying the BSD buildsystem to
a new project, and I found various answers among the field, including
variable answers for a given OS (like for example yacc to be special
cased with knobs like YHEADER; I know yacc is special anyway since the
-d option can be sometimes skipped.)

About portability, the AFAIK best standard this about, i.e. POSIX.2 and
its rationale, is very elliptic about yacc-dependent y.tab.h: it
mentions it as a reason to have ordered list of prerequisites, as in

foo: y.tab.o lex.o main.o
    $(CC) $(CFLAGS) -o $ <at>  t.tab.o lex.o main.o

along with the comment "[...] Although there may be better ways to
express this relationship [...]" I wonder which are the better ways they
are alluding to?

Antoine
Permalink | Reply | 2 comments |

Gmane