[RFA]: simulator build failures with parallel make

[RFA]: simulator build failures with parallel make

[J.T. Conklin]

With gmake -j, the d10v, mn10200, mn10300 and v850 simulators can 
fail to build because the generated header simops.h is included by
simops.c, but is not listed as a dependency for that file.

There are similar failures with the ppc simulator.  I'll submit a
patch for it as soon as I get a few moments to address it.

        --jtc

(I have this change log entry in each of the four simulator directories)

2001-03-27  J.T. Conklin  <jtc@redback.com>

	* Makefile.in (simops.o): Add simops.h to dependency list.


Index: d10v/Makefile.in
===================================================================
RCS file: /cvs/src/src/sim/d10v/Makefile.in,v
retrieving revision 1.2
diff -c -r1.2 Makefile.in
*** Makefile.in	2000/02/22 08:52:21	1.2
--- Makefile.in	2001/03/27 20:07:40
***************
*** 48,53 ****
  	rm -f table.c simops.h gencode
  
  interp.o: interp.c table.c $(INCLUDE)
! simops.o: simops.c $(INCLUDE)
  endian.o: endian.c $(INCLUDE)
  table.o: table.c
--- 48,53 ----
  	rm -f table.c simops.h gencode
  
  interp.o: interp.c table.c $(INCLUDE)
! simops.o: simops.c simops.h $(INCLUDE)
  endian.o: endian.c $(INCLUDE)
  table.o: table.c
Index: mn10200/Makefile.in
===================================================================
RCS file: /cvs/src/src/sim/mn10200/Makefile.in,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 Makefile.in
*** Makefile.in	1999/04/26 18:33:09	1.1.1.2
--- Makefile.in	2001/03/27 20:07:40
***************
*** 48,52 ****
  	rm -f table.c simops.h gencode
  
  interp.o: interp.c table.c $(INCLUDE)
! simops.o: simops.c $(INCLUDE)
  table.o: table.c
--- 48,52 ----
  	rm -f table.c simops.h gencode
  
  interp.o: interp.c table.c $(INCLUDE)
! simops.o: simops.c simops.h $(INCLUDE)
  table.o: table.c
Index: mn10300/Makefile.in
===================================================================
RCS file: /cvs/src/src/sim/mn10300/Makefile.in,v
retrieving revision 1.2
diff -c -r1.2 Makefile.in
*** Makefile.in	2000/03/03 23:25:10	1.2
--- Makefile.in	2001/03/27 20:07:40
***************
*** 152,158 ****
  
  
  interp.o: interp.c $(MN10300_INTERP_DEP) $(INCLUDE)
! simops.o: simops.c $(INCLUDE)
  table.o: table.c
  
  clean-extra: clean-igen
--- 152,158 ----
  
  
  interp.o: interp.c $(MN10300_INTERP_DEP) $(INCLUDE)
! simops.o: simops.c simops.h $(INCLUDE)
  table.o: table.c
  
  clean-extra: clean-igen
Index: v850/Makefile.in
===================================================================
RCS file: /cvs/src/src/sim/v850/Makefile.in,v
retrieving revision 1.3
diff -c -r1.3 Makefile.in
*** Makefile.in	2001/03/14 21:51:31	1.3
--- Makefile.in	2001/03/27 20:07:41
***************
*** 135,140 ****
  	rm -f table.c simops.h gencode
  
  #interp.o: interp.c table.c $(INCLUDE)
! simops.o: simops.c $(INCLUDE) targ-vals.h
  #table.o: table.c
  semantics.o: $(INCLUDE)
--- 135,140 ----
  	rm -f table.c simops.h gencode
  
  #interp.o: interp.c table.c $(INCLUDE)
! simops.o: simops.c simops.h $(INCLUDE) targ-vals.h
  #table.o: table.c
  semantics.o: $(INCLUDE)



-- 
J.T. Conklin
RedBack Networks

Re: [RFA]: simulator build failures with parallel make

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> With gmake -j, the d10v, mn10200, mn10300 and v850 simulators can
> fail to build because the generated header simops.h is included by
> simops.c, but is not listed as a dependency for that file.
> 
> There are similar failures with the ppc simulator.  I'll submit a
> patch for it as soon as I get a few moments to address it.
> 
>         --jtc
> 
> (I have this change log entry in each of the four simulator directories)
> 
> 2001-03-27  J.T. Conklin  <jtc@redback.com>
> 
>         * Makefile.in (simops.o): Add simops.h to dependency list.

With that dependency added without -j does the generator get run twice?
I've this memory of a strange querk with make dependencies and files
being created as a sideeffect.

Any way, assuming you've played with it with using both make and gmake
and it appears ok then yes.

	Andrew

> Index: d10v/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/sim/d10v/Makefile.in,v
> retrieving revision 1.2
> diff -c -r1.2 Makefile.in
> *** Makefile.in 2000/02/22 08:52:21     1.2
> --- Makefile.in 2001/03/27 20:07:40
> ***************
> *** 48,53 ****
>         rm -f table.c simops.h gencode
> 
>   interp.o: interp.c table.c $(INCLUDE)
> ! simops.o: simops.c $(INCLUDE)
>   endian.o: endian.c $(INCLUDE)
>   table.o: table.c
> --- 48,53 ----
>         rm -f table.c simops.h gencode
> 
>   interp.o: interp.c table.c $(INCLUDE)
> ! simops.o: simops.c simops.h $(INCLUDE)
>   endian.o: endian.c $(INCLUDE)
>   table.o: table.c
> Index: mn10200/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/sim/mn10200/Makefile.in,v
> retrieving revision 1.1.1.2
> diff -c -r1.1.1.2 Makefile.in
> *** Makefile.in 1999/04/26 18:33:09     1.1.1.2
> --- Makefile.in 2001/03/27 20:07:40
> ***************
> *** 48,52 ****
>         rm -f table.c simops.h gencode
> 
>   interp.o: interp.c table.c $(INCLUDE)
> ! simops.o: simops.c $(INCLUDE)
>   table.o: table.c
> --- 48,52 ----
>         rm -f table.c simops.h gencode
> 
>   interp.o: interp.c table.c $(INCLUDE)
> ! simops.o: simops.c simops.h $(INCLUDE)
>   table.o: table.c
> Index: mn10300/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/sim/mn10300/Makefile.in,v
> retrieving revision 1.2
> diff -c -r1.2 Makefile.in
> *** Makefile.in 2000/03/03 23:25:10     1.2
> --- Makefile.in 2001/03/27 20:07:40
> ***************
> *** 152,158 ****
> 
> 
>   interp.o: interp.c $(MN10300_INTERP_DEP) $(INCLUDE)
> ! simops.o: simops.c $(INCLUDE)
>   table.o: table.c
> 
>   clean-extra: clean-igen
> --- 152,158 ----
> 
> 
>   interp.o: interp.c $(MN10300_INTERP_DEP) $(INCLUDE)
> ! simops.o: simops.c simops.h $(INCLUDE)
>   table.o: table.c
> 
>   clean-extra: clean-igen
> Index: v850/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/sim/v850/Makefile.in,v
> retrieving revision 1.3
> diff -c -r1.3 Makefile.in
> *** Makefile.in 2001/03/14 21:51:31     1.3
> --- Makefile.in 2001/03/27 20:07:41
> ***************
> *** 135,140 ****
>         rm -f table.c simops.h gencode
> 
>   #interp.o: interp.c table.c $(INCLUDE)
> ! simops.o: simops.c $(INCLUDE) targ-vals.h
>   #table.o: table.c
>   semantics.o: $(INCLUDE)
> --- 135,140 ----
>         rm -f table.c simops.h gencode
> 
>   #interp.o: interp.c table.c $(INCLUDE)
> ! simops.o: simops.c simops.h $(INCLUDE) targ-vals.h
>   #table.o: table.c
>   semantics.o: $(INCLUDE)

Re: [RFA]: simulator build failures with parallel make

[Frank Ch. Eigler]

jtc wrote:

> With gmake -j, the d10v, mn10200, mn10300 and v850 simulators can
> fail to build because the generated header simops.h is included by
> simops.c, but is not listed as a dependency for that file. [...]

Another fix is ".NOTPARALLEL: *.o" :-)

- FChE

Re: [RFA]: simulator build failures with parallel make

[Eli Zaretskii]

On 6 Apr 2001, Frank Ch. Eigler wrote:

> > With gmake -j, the d10v, mn10200, mn10300 and v850 simulators can
> > fail to build because the generated header simops.h is included by
> > simops.c, but is not listed as a dependency for that file. [...]
> 
> Another fix is ".NOTPARALLEL: *.o" :-)

This is not supported by all brands of Make which have a parallel 
option.  You should at least add ".NO_PARALLEL:".  But even that doesn't 
cover, e.g., the SGI Make.

Re: [RFA]: simulator build failures with parallel make

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> With that dependency added without -j does the generator get
Andrew> run twice?  I've this memory of a strange querk with make
Andrew> dependencies and files being created as a sideeffect.

No.  

But now that you've mentioned it, I recall that rules with multiple
targets will be executed once per target with -j (at least with GNU
make).  This can be worked around by creating a psuedo-target to 
serialize the process.  I've confirmed that simops.h is either a 
the sole target of a rule (most of the cases), or that there is a 
pseudo-target (v850).

Andrew> Any way, assuming you've played with it with using both make and gmake
Andrew> and it appears ok then yes.

Thanks.  This will be going in shortly.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: [RFA]: simulator build failures with parallel make

[H . J . Lu]

On Sun, Apr 15, 2001 at 12:54:34PM -0700, J.T. Conklin wrote:
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> With that dependency added without -j does the generator get
> Andrew> run twice?  I've this memory of a strange querk with make
> Andrew> dependencies and files being created as a sideeffect.
> 
> No.  
> 
> But now that you've mentioned it, I recall that rules with multiple
> targets will be executed once per target with -j (at least with GNU
> make).  This can be worked around by creating a psuedo-target to 

Please don't add any workaround. Just provide complete dependencies,
any make, including GNU make, will be happy.



H.J.

Re: [RFA]: simulator build failures with parallel make

[J.T. Conklin]

>>>>> "HJ" == H J Lu <hjl@lucon.org> writes:
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> With that dependency added without -j does the generator get
Andrew> run twice?  I've this memory of a strange querk with make
Andrew> dependencies and files being created as a sideeffect.
>> 
>> No.  
>> 
>> But now that you've mentioned it, I recall that rules with multiple
>> targets will be executed once per target with -j (at least with GNU
>> make).  This can be worked around by creating a psuedo-target to 

HJ> Please don't add any workaround.  Just provide complete
HJ> dependencies, [...]

And just what workaround do you think I'm adding? 

HJ> [...] any make, including GNU make, will be happy.

Untrue.  GNU make will invoke the commands for a rule with multiple
targets multiple times when used with -j.  Bug or feature, this must
be accomidated.

For example:

        $ cat Makefile
        all: foo.tab.c foo.tab.h

        foo.tab.c foo.tab.h: foo.y
                $(YACC) -b foo -p foo -d $?

        $ gmake -j
        yacc -b foo -p foo -d foo.y
        yacc -b foo -p foo -d foo.y

In many cases, this must be guarded against.  A rule with two targets
occured only once in the four simulator makefiles I touched. And that
one already handled it by introducing a pseudo-target to serialize 
the make.  For the above makefile, the equivalent would be:

        $ cat Makefile
        all: foo.tab.c foo.tab.h

        foo.tab.c foo.tab.h: foo-stamp

        foo-stamp: foo.y
                $(YACC) -b foo -p foo -d $?
                touch $@

So what exactly is your complaint about my patch.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: [RFA]: simulator build failures with parallel make

[H . J . Lu]

On Sun, Apr 15, 2001 at 01:47:27PM -0700, J.T. Conklin wrote:
> >>>>> "HJ" == H J Lu <hjl@lucon.org> writes:
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> With that dependency added without -j does the generator get
> Andrew> run twice?  I've this memory of a strange querk with make
> Andrew> dependencies and files being created as a sideeffect.
> >> 
> >> No.  
> >> 
> >> But now that you've mentioned it, I recall that rules with multiple
> >> targets will be executed once per target with -j (at least with GNU
> >> make).  This can be worked around by creating a psuedo-target to 
> 
> HJ> Please don't add any workaround.  Just provide complete
> HJ> dependencies, [...]
> 
> And just what workaround do you think I'm adding? 
> 
> HJ> [...] any make, including GNU make, will be happy.
> 
> Untrue.  GNU make will invoke the commands for a rule with multiple
> targets multiple times when used with -j.  Bug or feature, this must
> be accomidated.
> 
> For example:
> 
>         $ cat Makefile
>         all: foo.tab.c foo.tab.h
> 
>         foo.tab.c foo.tab.h: foo.y
>                 $(YACC) -b foo -p foo -d $?
> 
>         $ gmake -j
>         yacc -b foo -p foo -d foo.y
>         yacc -b foo -p foo -d foo.y
> 
> In many cases, this must be guarded against.  A rule with two targets
> occured only once in the four simulator makefiles I touched. And that
> one already handled it by introducing a pseudo-target to serialize 
> the make.  For the above makefile, the equivalent would be:
> 
>         $ cat Makefile
>         all: foo.tab.c foo.tab.h
> 
>         foo.tab.c foo.tab.h: foo-stamp
> 
>         foo-stamp: foo.y
>                 $(YACC) -b foo -p foo -d $?
>                 touch $@
> 
> So what exactly is your complaint about my patch.
> 

That is a bug in Makefile and that is why we have ylwrap. See how it is
done in ld/Makefile.*, binutils/Makefile.* and gas/Makefile.*. Do

# grep YLWRAP */Makefile.in

in binutils tree. I can anaswer any questions if those Makefile.in
files are not clear enough.


H.J.

Re: [RFA]: simulator build failures with parallel make

[Eli Zaretskii]

On Sun, 15 Apr 2001, H . J . Lu wrote:

> >         foo.tab.c foo.tab.h: foo-stamp
> > 
> >         foo-stamp: foo.y
> >                 $(YACC) -b foo -p foo -d $?
> >                 touch $@
> > 
> > So what exactly is your complaint about my patch.
> > 
> 
> That is a bug in Makefile and that is why we have ylwrap. See how it is
> done in ld/Makefile.*, binutils/Makefile.* and gas/Makefile.*.

With GNU Make, you can avoid the problem with pattern rules (which 
specifically target cases like Yacc and Bison).

IMVHO, ylwrap is a kludge.  It might be okay to have users of non-GNU 
Make to need it, but GNU Make should have a cleaner feature for when
a command produces several target files in a single run.  (Pattern rules 
only work well when all the files created by the program have the same 
stem; if not, you need to define your patterns ``creatively''.)