I can't reproduce these scons errors and they don't seem to happen from a clean
build. Can we blow away the current build directory on zizzer and re-run the
regression tester? I would do it myself, but I don't have access to zizzer.
Thanks,
Brad
-Original Message-
From:
I deleted the build directory but I'll let it rerun naturally tonight.
If somebody wants to rerun them manually go ahead.
Gabe
Quoting Beckmann, Brad brad.beckm...@amd.com:
I can't reproduce these scons errors and they don't seem to happen
from a clean build. Can we blow away the current
This is likely due to my push last night, though I ran the full
regression suite before I pushed. My guess is that the directory
needs to be blown away so a fresh build can happen.
Can someone do that for me? I'm in the car about to go camping.
Nate
On Sat, Apr 16, 2011 at 12:56 AM, Cron
/z/m5/regression/zizzer/m5/build has been deleted. I'm pretty sure that
will do it, but let me know if I need to remove anything else.
Gabe
On 04/16/11 11:13, nathan binkert wrote:
This is likely due to my push last night, though I ran the full
regression suite before I pushed. My guess is
We've had multiple discussions on this (search the list archives for
m5-stable and you should find them). We had some debate about how
frequently m5-stable should be updated, and how long we want a
changeset to mature in m5 before we consider promoting it to
m5-stable, but I think we found some
Compilation of POWER was broken by this change when the closing bracket
for a namespace was removed:
changeset: 8181:f789b9aac5f4
user:Korey Sewell ksew...@umich.edu
date:Sat Mar 26 09:23:52 2011 -0400
summary: mips: cleanup ISA-specific code
Compilation was unavoidably
Good point about regression carefulness Gabe.
Although I'm pretty sure I compiled MIPS before I committed this, I
had forgot I touched other ISAs and obviously broke one of them.
That's just an error on my part.
This brings up a few issues:
- Should the regressions be more resilient? In other
On Tue, Mar 29, 2011 at 10:34 AM, Korey Sewell ksew...@umich.edu wrote:
Good point about regression carefulness Gabe.
Although I'm pretty sure I compiled MIPS before I committed this, I
had forgot I touched other ISAs and obviously broke one of them.
That's just an error on my part.
This
On 03/29/11 13:34, Korey Sewell wrote:
Good point about regression carefulness Gabe.
Although I'm pretty sure I compiled MIPS before I committed this, I
had forgot I touched other ISAs and obviously broke one of them.
That's just an error on my part.
Yeah, I didn't want to pick on you,
On Tue, Mar 29, 2011 at 10:54 AM, Gabe Black gbl...@eecs.umich.edu wrote:
That makes sense and was what I was hoping we could use m5-stable for,
but we didn't end up doing that because we wanted m5-stable to be even
more stable than that (although it tends to just be old, not necessarily
I'd prefer to see us just start updating m5-stable more regularly so
it can fulfill its original purpose. We keep discussing this but
never actually follow through.
Is this any harder than just setting up a cronjob to push whatever is
in m5-dev to m5-stable once per month (?)
- Korey
You could do that, but there is no guarentee you'd pick a non-broken version to
push. We wouldn't want to push anything from the last week with all the
compilation issues.
Ali
On Mar 29, 2011, at 6:19 PM, Korey Sewell wrote:
I'd prefer to see us just start updating m5-stable more regularly
I pushed in patch that imports math in MI_example.py
--
Nilay
On Mon, 28 Mar 2011, Cron Daemon wrote:
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby
FAILED!
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby
FAILED!
*
The two issues below are copied from ARM_FS, but other targets had the
same problems.
These errors are making the build fail.
build/ARM_FS/cpu/testers/networktest/networktest.cc: In member
function 'void NetworkTest::completeRequest(Packet*)':
On Tue, 22 Mar 2011, Gabriel Michael Black wrote:
The two issues below are copied from ARM_FS, but other targets had the same
problems.
These errors are making the build fail.
build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void
The warnings related to networktest.cc got added yesterday.
These I think have been around for quite a while.
Either way, we should be eliminating warnings.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
You may already be taking care of this, but networktest.cc also had an
error (ambiguous use of the pow function) that made all the regressions
fail. That needs to be fixed quickly, regardless of what happens with
the warnings or who originally worked on the code. Also, code that
doesn't compile
time to do it today.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Gabe Black
Sent: Tuesday, March 22, 2011 1:04 PM
To: m5-dev@m5sim.org
Subject: Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-
regression quick
You may
On Sat, March 19, 2011 3:26 am, Cron Daemon wrote:
scons: *** Found dependency cycle(s):
I am looking at the output of the regression from last night. What do the
following errors mean?
scons: *** Found dependency cycle(s):
Internal Error: no cycle found for node
The X86_FS regressions have failed the last couple nights. The first
time I attributed to it not catching my change to M5_PATH and something
flaky happening with nfs. That was even more of a stretch the second
time. My new theory is that scons didn't see that the files the
regression uses or that
IIRC, I was expecting some response from Ali as to why M5_DUMMY_RETURN
should or should not work. I did not poke in any further. To me it is a
compiler bug that we have to work with. I think return panic(); works
with both 4.2 and 4.4 series, but we probably do not want that.
--
Nilay
On Tue,
IIRC, I was expecting some response from Ali as to why M5_DUMMY_RETURN
should or should not work. I did not poke in any further. To me it is a
compiler bug that we have to work with. I think return panic(); works
with both 4.2 and 4.4 series, but we probably do not want that.
What I didn't
The reason M5_DUMMY_RETURN didn't work is for gcc it's #defined to nothing
because in theory gcc respects __attribute__(no return), but apparently not in
this case.
Ali
On Mar 9, 2011, at 7:00 AM, Nilay wrote:
IIRC, I was expecting some response from Ali as to why M5_DUMMY_RETURN
should or
I just manually started a new set of regressions that should run this time.
Ali
On Mar 7, 2011, at 2:00 AM, Cron Daemon wrote:
See /z/m5/regression/regress-2011-03-07-03:00:01 for details.
___
m5-dev mailing list
m5-dev@m5sim.org
I looked at this error, and it seems to be another 4.2.4 oddity. It
builds fine with my normal compiler, but if I switch to that version I
get a linking issue that doesn't make sense. Basically it complains that
the constructor for the MicroPanic microop doesn't exist even though
it's built into
Perhaps we should upgrade zizzer?
Nate
On Tue, Feb 15, 2011 at 7:40 PM, Gabe Black gbl...@eecs.umich.edu wrote:
I looked at this error, and it seems to be another 4.2.4 oddity. It
builds fine with my normal compiler, but if I switch to that version I
get a linking issue that doesn't make
I wouldn't complain, although someone might try to use 4.2.4 so it's not
necessarily a bad thing to fix this stuff.
Gabe
On 02/15/11 11:50, nathan binkert wrote:
Perhaps we should upgrade zizzer?
Nate
On Tue, Feb 15, 2011 at 7:40 PM, Gabe Black gbl...@eecs.umich.edu wrote:
I looked at
Ah, ok, I figured it out. There was an errant inline before the
constructor in the .cc. I don't know if that's supposed to allow the
compiler to eliminate that symbol from the resulting object file, but
that seems to be what it was doing sometimes. I'll make sure that fix is
doing what I expect it
...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Gabe Black
Sent: Tuesday, February 08, 2011 12:15 AM
To: M5 Developer List
Subject: Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-
regression quick
Hmm. I didn't realize all the build targets for ruby protocols had their own
The X86 o3 regressions will fail until somebody blasts the build
directory. Building O3 is now default, but it won't be picked up into
existing build directories.
Gabe
On 02/05/11 00:10, Cron Daemon wrote:
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/o3-timing FAILED!
*
The X86 o3 regressions will fail until somebody blasts the build
directory. Building O3 is now default, but it won't be picked up into
existing build directories.
Couldn't that somebody be you? :)
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
On 02/05/11 07:23, nathan binkert wrote:
The X86 o3 regressions will fail until somebody blasts the build
directory. Building O3 is now default, but it won't be picked up into
existing build directories.
Couldn't that somebody be you? :)
Nate
I don't know for sure where the right directory is, and I don't want to
go deleting things willy nilly.
zizzer:/z/m5/regression/zizzer/m5/build
Tomorrow night (or maybe tonight?) it will run from scratch anyway.
Nate
___
m5-dev mailing list
This looks like a stale build directory still. It's apparently obsolete
intermediate swig files that get mixed in when they shouldn't.
[SWIG] X86_SE/python/m5/internal/param_RubySystem.i - _wrap.cc, .py
scons: *** [build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc]
Error 1
scons:
Actually, I take that back. It looks like param_RubySystem.i isn't being
regenerated even though RubySystem.py was changed to not have a
RubyDebug parameter. I don't know why, but an obvious guess is
incomplete dependencies.
Gabe
Gabe Black wrote:
This looks like a stale build directory still.
I initially thought this was your RubyDebug.hh change, Nate, but I don't
see RubyDebug in the repository anywhere now. In the past I've run into
problems where left over files make a build break until you wipe it out
and rebuild, specifically having to do with the python stuff. I suspect
if you
I also received this error after I pulled in Nate's changeset. Removing
the build directory fixed the problem for me.
Nilay
On Tue, January 11, 2011 4:35 am, Gabe Black wrote:
I initially thought this was your RubyDebug.hh change, Nate, but I don't
see RubyDebug in the repository anywhere now.
I also received this error after I pulled in Nate's changeset. Removing
the build directory fixed the problem for me.
That rings a bell. I think it happened, but I'm not sure why that
happened. I'll blow away the build directory on zizzer.
Nate
I tried M5_DUMMY_RETURN and it it not working. I checked its definition.
It would evaluate to nothing, in which case I do not see why it should
help in avoiding the warning. I tried putting a return statement before
panic();
return panic(not implemented);
This works with GCC 4.2.2.
I
Did you try with debug, opt, and fast?
I see these errors a lot in the regressions:
/z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:127:
warning: no return statement in function returning non-void
I am using GCC 4.4, I never see any of these warnings. Let me try with
4.2.4.
Nilay
On Thu, 23 Dec 2010, Steve Reinhardt wrote:
Did you try with debug, opt, and fast?
I see these errors a lot in the regressions:
Steve, you had commented that panic() and fatal() are marked as no
return. Then, why should these warnings appear? And why would the
compiler be fine with ERROR_MSG?
--
Nilay
On Thu, 23 Dec 2010, Nilay Vaish wrote:
I am using GCC 4.4, I never see any of these warnings. Let me try with
It could be an issue with gcc 4.2.4 not properly handling the no return
attribute in some cases... that being a bug that's fixed in 4.4 would
explain why it works for you. That's just speculation on my part though.
Does anyone else have any experience with this? Does the error go away on
4.2.4
I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings.
On Thu, 23 Dec 2010, Steve Reinhardt wrote:
It could be an issue with gcc 4.2.4 not properly handling the no return
attribute in some cases... that being a bug that's fixed in 4.4 would
explain why it works for you.
I am able to reproduce the warning. But I have to compile the files on my
own (as in, write the compilation command on the command line) in order to
reproduce the warning.
This is the proposed patch.
--
Nilay
diff --git a/src/mem/ruby/system/PerfectCacheMemory.hh
Do you mean you have to enter the compilation command manually to use the
different version of gcc? You can override the default compiler by setting
CC=path as a scons argument (or something like that... typing from memory
here).
Or was there another reason?
Steve
On Thu, Dec 23, 2010 at 11:10
Something else must be going on. There are a lot of cases where this
sort of thing happens, so something must be different about the
compilation environment for these files. Perhaps we should try to
compile on zizzer with VERBOSE=True to see what happens. We can also
give Nilay an account on
A better solution would be to put M5_DUMMY_RETURN there. I know there'd were
some issues with some versions of gcc not respecting the attribute no return.
This might be the case.
Ali
Sent from my ARM powered device
On Dec 23, 2010, at 1:10 PM, Nilay Vaish ni...@cs.wisc.edu wrote:
I am able
48 matches
Mail list logo
