Configure.pl --cgoto=0 doesn't work
Nicholas Clark
perl Configure.pl --cgoto=0 && make all test
then the build fails with:
ccache /usr/local/bin/gcc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -I/usr/local/include -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wpadded -Wdisabled-optimization -I./include -DHAS_JIT -DI386 -o jit_cpu.o -c jit_cpu.c
In file included from jit_cpu.c:39:
include/parrot/jit_emit.h:2302:39: parrot/oplib/core_ops_cgp.h: No such file or directory
In file included from jit_cpu.c:39:
include/parrot/jit_emit.h: In function `Parrot_jit_begin':
include/parrot/jit_emit.h:2349: `cgp_core' undeclared (first use in this function)
include/parrot/jit_emit.h:2349: (Each undeclared identifier is reported only once
include/parrot/jit_emit.h:2349: for each function it appears in.)
*** Error code 1
And if I don't disable cgoto I run out of swap. :-(
I've got 96M of swap, which happens to be enough to build world, perl and
gcc 3.2
I've not tried X yet :-)
Nicholas Clark
Simon Glover
On Thu, 20 Feb 2003, Nicholas Clark wrote:
> If I
>
> perl Configure.pl --cgoto=0 && make all test
>
> then the build fails with:
>
> ccache /usr/local/bin/gcc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -I/usr/local/include -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wpadded -Wdisabled-optimization -I./include -DHAS_JIT -DI386 -o jit_cpu.o -c jit_cpu.c
> In file included from jit_cpu.c:39:
> include/parrot/jit_emit.h:2302:39: parrot/oplib/core_ops_cgp.h: No such file or directory
> In file included from jit_cpu.c:39:
> include/parrot/jit_emit.h: In function `Parrot_jit_begin':
> include/parrot/jit_emit.h:2349: `cgp_core' undeclared (first use in this function)
> include/parrot/jit_emit.h:2349: (Each undeclared identifier is reported only once
> include/parrot/jit_emit.h:2349: for each function it appears in.)
> *** Error code 1
The problem is that an ifdef in jit/i386/jit_emit.h is defining JIT_CGP
based on whether or not the compiler is GCC, and not on whether
HAS_COMPUTED_GOTO is defined. The attached patch fixes this, but I'm
not sure if the __GCC__ bit is still necessary. Leo?
Simon
--- jit/i386/jit_emit.h.old Thu Feb 20 20:59:11 2003
+++ jit/i386/jit_emit.h Thu Feb 20 20:58:52 2003
@@ -8,7 +8,7 @@
#include <assert.h>
-#ifdef __GNUC__
+#if defined HAS_COMPUTED_GOTO && defined __GCC__
# define JIT_CGP
#endif
Simon Glover
On Thu, 20 Feb 2003, Simon Glover wrote:
>
> On Thu, 20 Feb 2003, Nicholas Clark wrote:
>
> > If I
> >
> > perl Configure.pl --cgoto=0 && make all test
> >
> > then the build fails with:
> >
> > ccache /usr/local/bin/gcc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -I/usr/local/include -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wpadded -Wdisabled-optimization -I./include -DHAS_JIT -DI386 -o jit_cpu.o -c jit_cpu.c
> > In file included from jit_cpu.c:39:
> > include/parrot/jit_emit.h:2302:39: parrot/oplib/core_ops_cgp.h: No such file or directory
> > In file included from jit_cpu.c:39:
> > include/parrot/jit_emit.h: In function `Parrot_jit_begin':
> > include/parrot/jit_emit.h:2349: `cgp_core' undeclared (first use in this function)
> > include/parrot/jit_emit.h:2349: (Each undeclared identifier is reported only once
> > include/parrot/jit_emit.h:2349: for each function it appears in.)
> > *** Error code 1
>
> The problem is that an ifdef in jit/i386/jit_emit.h is defining JIT_CGP
> based on whether or not the compiler is GCC, and not on whether
> HAS_COMPUTED_GOTO is defined. The attached patch fixes this, but I'm
> not sure if the __GCC__ bit is still necessary. Leo?
OK, let's try this again, with the _correct_ spelling this time...
Simon
--- jit/i386/jit_emit.h.old Thu Feb 20 21:43:53 2003
+++ jit/i386/jit_emit.h Thu Feb 20 21:43:20 2003
@@ -8,7 +8,7 @@
#include <assert.h>
-#ifdef __GNUC__
+#if defined HAVE_COMPUTED_GOTO && defined __GCC__
# define JIT_CGP
#endif
Leopold Toetsch
> If I
>
> perl Configure.pl --cgoto=0 && make all test
>
> then the build fails with:
We need to sort out different cases:
1) $cc doesn't have computed goto
2) user doesn't want to build core_ops_cg.c
Case 1) shouldn't matter, as the CGP core is only called from JIT/i386/gnucc
Case 2) should disable only core_ops_cg.c but not core_ops_cgp.c
leo
Nicholas Clark
>
> On Thu, 20 Feb 2003, Simon Glover wrote:
> >
> > On Thu, 20 Feb 2003, Nicholas Clark wrote:
> >
> > > If I
> > >
> > > perl Configure.pl --cgoto=0 && make all test
> > >
> > > then the build fails with:
> > The problem is that an ifdef in jit/i386/jit_emit.h is defining JIT_CGP
> > based on whether or not the compiler is GCC, and not on whether
> > HAS_COMPUTED_GOTO is defined. The attached patch fixes this, but I'm
> > not sure if the __GCC__ bit is still necessary. Leo?
>
> OK, let's try this again, with the _correct_ spelling this time...
Thanks, applied.
Nicholas Clark
Nicholas Clark
But surely we'd also like a flag to disable core_ops_cgp.c but leave
core_ops_cg.c?
How many cores are there now? Is there a way to make a modular flag system
that lets people configure any arbitrary combination that they wish to build?
And an easy way for the tinderbox machines to build all applicable, and
run tests for each built core in turn?
Nicholas Clark
Leopold Toetsch
> On Fri, Feb 21, 2003 at 08:34:05AM +0100, Leopold Toetsch wrote:
>>Case 2) should disable only core_ops_cg.c but not core_ops_cgp.c
>>
>
> But surely we'd also like a flag to disable core_ops_cgp.c but leave
> core_ops_cg.c?
IMHO no. Why disable the faster and much smaller core, and keep the big
and slow core?
> How many cores are there now? Is there a way to make a modular flag system
> that lets people configure any arbitrary combination that they wish to build?
In the long run, we should build the "normal" function based core (used
e.g. for trace and the fastest core, that is available. Though I can
imagine, that we additionally want to have the most memory efficient
core too - which would not be a prederefed one.
Here is a summary in terms of speed:
JIT
CGP (obsoletes CGoto & Prederef)
Switched Prederef (obsoletes Prederef)
Switched
Normal
When PBC code size matters we could have:
CGoto
Switched
Normal
So, the plain prederefed core is always obsolete now.
> And an easy way for the tinderbox machines to build all applicable, and
> run tests for each built core in turn?
$ make quickfulltest
> Nicholas Clark
leo
Nicholas Clark
> Nicholas Clark wrote:
>
> >On Fri, Feb 21, 2003 at 08:34:05AM +0100, Leopold Toetsch wrote:
>
> >>Case 2) should disable only core_ops_cg.c but not core_ops_cgp.c
> >>
> >
> >But surely we'd also like a flag to disable core_ops_cgp.c but leave
> >core_ops_cg.c?
>
>
> IMHO no. Why disable the faster and much smaller core, and keep the big
> and slow core?
It might just be that on someone's machine the faster and smaller core
triggers a compiler bug. And
> Here is a summary in terms of speed:
> JIT
> CGP (obsoletes CGoto & Prederef)
> Switched Prederef (obsoletes Prederef)
> Switched
> Normal
>
> When PBC code size matters we could have:
> CGoto
you've already found a reason why someone might want the "obsoleted" CGoto
core.
I'm not saying that we recommend using, or even default to building any
obsolete cores that we ship source for. Merely that we ensure that the
configure system is flexible enough to let anyone build any arbitrary
combination of cores they ask for. (Providing they answer yes enough times
to "do you really want to do that?"). It strikes me that having rules in
the configure system to explicitly forbid compiling certain combinations of
cores is actually more complex than not having such rules.
I forget who I'm misquoting, but good tools can be used in ways their makers
never even thought of.
Nicholas Clark
Leopold Toetsch
> On Sat, Feb 22, 2003 at 12:31:09PM +0100, Leopold Toetsch wrote:
>
> It might just be that on someone's machine the faster and smaller core
> triggers a compiler bug. And
>>When PBC code size matters we could have:
>>CGoto
> you've already found a reason why someone might want the "obsoleted" CGoto
> core.
[...]
> I forget who I'm misquoting, but good tools can be used in ways their makers
> never even thought of.
Ok, ok, you have convinced me. Let's just select a default core set
build according to the mentioned hierarchies and the possibility to
build every combination, if the user wants to.
> Nicholas Clark
leo
Dan Sugalski
>>I forget who I'm misquoting, but good tools can be used in ways their makers
>>never even thought of.
>
>
>Ok, ok, you have convinced me. Let's just select a default core set
>build according to the mentioned hierarchies and the possibility to
>build every combination, if the user wants to.
Cool. When we do that I'd like to look at revamping the tinderbox
system to run tests on all the core types.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 2:33 PM +0100 2/23/03, Leopold Toetsch wrote:
>> Ok, ok, you have convinced me. Let's just select a default core set
>> build according to the mentioned hierarchies and the possibility to
>> build every combination, if the user wants to.
>
>
> Cool. When we do that I'd like to look at revamping the tinderbox system
> to run tests on all the core types.
s. 4) below - that's easy
While you say it "tinderbox", currently the reports are really
suboptimal. Some are red (stating not even parrot was built), but only
have failing tests, sometimes the error reason is not show in the brief
log, making it a PITA to read the full log (on my 64Kbit ISDN line).
So to make tinderboxen really more useful, they would need some improvement:
1) sync with CVS
Currently tinderboxen seem to delete the whole tree and start from
scratch. This generates a lot of traffic (albeit - thanks - not mine),
but this is IMHO not necessary:
$ cvs -z3 update [-d...] -dP parrot >$FULL_LOG 2>&1 &&
perl Configure.pl [--options] >> $FULL_LOG 2>&1 &&
make distclean ...
With appropriate error checking should do it.
Make normal entry in brief log is something like
echo "Parrot sync src ok" > $BRIEF_LOG
2) building parrot
$ perl Configure.pl [--options] >> $FULL_LOG 2>&1 &&
make -s > $BUILD_LOG 2>&1
- [/me dreaming:] Filter $BUILDLOG to contain the first warning of some
type and then only a repeat count and may be maximal 1 line per
occurance of this warning, by deleting the line number and run the
output through some kind of "sort|uniq". The error parser of your
$EDITOR should contain the necessary regexen to get the real
warning/error message even from the normally multiline mess{,age}.
- show all errors
- append status to $BRIEF_LOG and $FULL_LOG
If this fails stop here.
3) building imcc
$ cd languages/imcc
$ make -s > ...
$ cd -
Same procedure as above - but *don't stop* if this fails, only generate
report.
4) run parrot tests (if 2) succeeded)
$ make quickfulltest
This runs normal, -j, -P, and -g i.e. all major cores.
In case of test failure show enough lines in the brief log, to really
get the start of the problem. This is one line after the last running
test. The output of the test (expected/got) is normally not of much
value, but could be included e.g. as a diff.
5) if imcc did build ok:
$ cd languages/imcc
$ make test
Summary:
The brief log should really contain all kinds of problems but reall be
*brief* and the full log would be just a check, that brief log is ok.
my 2¢ & TIA,
leo
Nicholas Clark
> Cool. When we do that I'd like to look at revamping the tinderbox
> system to run tests on all the core types.
I know I'm asking a needless question (because I should be able to work it
out from the source and the list archive) but what remains to be done before
we can use imcc rather than assemble.pl as the default assembler for the
regression tests? imcc is a lot (>20 times) faster.
Nicholas Clark
Zach Lipton
[SNIP]
>
> While you say it "tinderbox", currently the reports are really
> suboptimal. Some are red (stating not even parrot was built), but only
> have failing tests, sometimes the error reason is not show in the brief
> log, making it a PITA to read the full log (on my 64Kbit ISDN line).
generate this log, it's automatically generated by the server, but I can
hack around this. As for redness that should really be yellow, that's an
error in the regexp's client config file. I'll try to make them a little
more robust by default.
>
> So to make tinderboxen really more useful, they would need some improvement:
>
> 1) sync with CVS
> Currently tinderboxen seem to delete the whole tree and start from
> scratch. This generates a lot of traffic (albeit - thanks - not mine),
> but this is IMHO not necessary:
>
> $ cvs -z3 update [-d...] -dP parrot >$FULL_LOG 2>&1 &&
> perl Configure.pl [--options] >> $FULL_LOG 2>&1 &&
> make distclean ...
>
> With appropriate error checking should do it.
> Make normal entry in brief log is something like
> echo "Parrot sync src ok" > $BRIEF_LOG
the unlink because it was causing trees to become corrupted. I'll probably
add this as an option in the next version defaulting to not unlink the tree.
>
> 2) building parrot
>
> $ perl Configure.pl [--options] >> $FULL_LOG 2>&1 &&
> make -s > $BUILD_LOG 2>&1
>
> - [/me dreaming:] Filter $BUILDLOG to contain the first warning of some
> type and then only a repeat count and may be maximal 1 line per
> occurance of this warning, by deleting the line number and run the
> output through some kind of "sort|uniq". The error parser of your
> $EDITOR should contain the necessary regexen to get the real
> warning/error message even from the normally multiline mess{,age}.
>
> - show all errors
> - append status to $BRIEF_LOG and $FULL_LOG
log and sends it to the server, but I'll see.
>
> If this fails stop here.
>
> 3) building imcc
>
> $ cd languages/imcc
> $ make -s > ...
> $ cd -
>
> Same procedure as above - but *don't stop* if this fails, only generate
> report.
fails.
> 4) run parrot tests (if 2) succeeded)
>
> $ make quickfulltest
>
> This runs normal, -j, -P, and -g i.e. all major cores.
>
> In case of test failure show enough lines in the brief log, to really
> get the start of the problem. This is one line after the last running
> test. The output of the test (expected/got) is normally not of much
> value, but could be included e.g. as a diff.
>
> 5) if imcc did build ok:
>
> $ cd languages/imcc
> $ make test
>
> Summary:
> The brief log should really contain all kinds of problems but reall be
> *brief* and the full log would be just a check, that brief log is ok.
client side of this done at least, the server side will bit a bit harder.
Zach
Juergen Boemmels
> 1) sync with CVS
> Currently tinderboxen seem to delete the whole tree and start from
> scratch. This generates a lot of traffic (albeit - thanks - not mine),
> but this is IMHO not necessary:
>
>
> $ cvs -z3 update [-d...] -dP parrot >$FULL_LOG 2>&1 &&
> perl Configure.pl [--options] >> $FULL_LOG 2>&1 &&
> make distclean ...
>
> With appropriate error checking should do it.
> Make normal entry in brief log is something like
> echo "Parrot sync src ok" > $BRIEF_LOG
One good idea is to use the -q option to cvs. This will suppress the
unnecessary output
cvs server: Updating parrot/LICENSES
put preserves the output like
C parrot/languages/imcc/imcparser.c
So command would be somthing like
$ cd parrot && cvs -z3 -q update -dP > $FULL_LOG
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Juergen Boemmels
make test IMCC=1
Leo had introduced this several days ago, shortly after the
macro-support for imcc went in.
Juergen Boemmels
> > we can use imcc rather than assemble.pl as the default assembler for the
> > regression tests? imcc is a lot (>20 times) faster.
>
> make test IMCC=1
> Leo had introduced this several days ago, shortly after the
> macro-support for imcc went in.
Arggh, first testing then posting. The correct commandline for the
quick test is:
make test IMCC=languages/imcc/imcc
This gets makes the testsuite really fast. Even more than replacing
assemble.pl with exec languages/imcc/imcc
> bye
> boe