Juergen Boemmels <[EMAIL PROTECTED]> writes:
> > 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.
A
Nicholas Clark <[EMAIL PROTECTED]> writes:
> On Sun, Feb 23, 2003 at 11:13:30AM -0500, Dan Sugalski wrote:
> > 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 w
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> 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
On 2/23/03 10:25 AM, "Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
[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, maki
On Sun, Feb 23, 2003 at 11:13:30AM -0500, Dan Sugalski wrote:
> 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 w
Dan Sugalski wrote:
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
At 2:33 PM +0100 2/23/03, Leopold Toetsch wrote:
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 ever
Nicholas Clark wrote:
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 "ob
On Sat, Feb 22, 2003 at 12:31:09PM +0100, Leopold Toetsch wrote:
> 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_cg
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
On Fri, Feb 21, 2003 at 08:34:05AM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >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 cor
On Thu, Feb 20, 2003 at 09:45:49PM -0500, Simon Glover wrote:
>
> 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
Nicholas Clark wrote:
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
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
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 -Wpoint
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 -Waggreg
16 matches
Mail list logo
