3.4.6 is the hairy edge of what's supposed to work and may need to be
deprecated. I'm not sure what we support on the high end, but 4.5.1
seems up there. You might want to try something slightly older like
4.3.something. Ideally all versions of the compiler in the range we
support would work, but we really only test the ones we use personally
or on our regression tester and only exclude ones we know for sure
won't work for some reason.
You're fixes are mostly reasonable. We'll have to look into what's
going on with libelf. The return value in vfp.cc should be cast to a
(uint32_t) explicitly instead of changing its value. The template
change seems ok, but it's only a point fix to the problem. I'm going
to guess the similar problem with 4.5.1 is also invalid compiler
whining, but it's probably worth looking into.
Gabe
Quoting Gedare Bloom <[email protected]>:
Hi,
I had a couple of problems trying to build ARM_SE on Fedora 14 using
gcc/g++ version 3.4.6 (and gcc 4.5.1 also, see bottom) following the
instructions on the Wiki. I tried to report them on the bug tracker
but I couldn't see a way to report new bugs. I have resolved the
issues so that it works for me. The following summarizes the
modifications I made.
One problem I ran across was two errors (warnings but -Werror is in
use) of this form:
build/ARM_SE/arch/arm/insts/vfp.cc:849: warning: converting of
negative value `-0x00000000000000001' to `uint32_t'
I changed these to return 0, probably there should be a more robust
error / fault return but I don't know what that would be. These were
also in the m5-stable repo.
There were also two cases similar to the following:
[ CXX] ARM_SE/arch/arm/atomic_simple_cpu_exec.cc -> .fo
build/ARM_SE/arch/arm/atomic_simple_cpu_exec.cc: In member function
`virtual Fault ArmISAInst::Tbh::execute(AtomicSimpleCPU*,
Trace::InstRecord*) const':
build/ARM_SE/arch/arm/atomic_simple_cpu_exec.cc:55075: warning: 'NPC'
might be used uninitialized in this function
scons: *** [build/ARM_SE/arch/arm/atomic_simple_cpu_exec.fo] Error 1
For these I changed the templates in mem.isa for LoadExecute and
LoadCompleteAcc. The problem is that a variable is set in the first if
(fault == NoFault) {...} and then accessed in a second block
predicated on if (fault == NoFault) {...}, which seems to confuse gcc
about variable initialization. I modified the checks to be cascaded:
if (fault == NoFault) { ... if (fault == NoFault) { ... } }
I also had this error, which appears to be something that is protected
by an if-check in ext/libelf/SConscript:
cc1: error: unrecognized command line option "-Wno-pointer-sign"
I guess something is wrong when snooping the version number of gcc34
on Fedora. Perhaps the SConscript file is finding the gcc 4.5 and not
gcc 3.4. I simply removed the flag in my build for now.
I also tried with gcc 4.5.1, but had the following error which I
didn't try to debug:
[ CXX] ARM_SE/arch/arm/atomic_simple_cpu_exec.cc -> .fo
cc1plus: warnings being treated as errors
build/ARM_SE/cpu/simple_thread.hh: In member function 'Fault
ArmISAInst::MicroPackNeon2to2Uop<Element>::execute(AtomicSimpleCPU*,
Trace::InstRecord*) const [with Element = unsigned int, Fault =
RefCountingPtr<FaultBase>]':
build/ARM_SE/cpu/simple_thread.hh:291:37: error:
'destRegs.ArmISAInst::MicroPackNeon2to2Uop<Element>::execute(AtomicSimpleCPU*,
Trace::InstRecord*) const [with Element = unsigned int, Fault =
RefCountingPtr<FaultBase>]::DestRegs::fRegs[1]' may be used
uninitialized in this function
build/ARM_SE/arch/arm/atomic_simple_cpu_exec.cc:42600:15: note:
'destRegs.ArmISAInst::MicroPackNeon2to2Uop<Element>::execute(AtomicSimpleCPU*,
Trace::InstRecord*) const [with Element = unsigned int, Fault =
RefCountingPtr<FaultBase>]::DestRegs::fRegs[1]' was declared here
scons: *** [build/ARM_SE/arch/arm/atomic_simple_cpu_exec.fo] Error 1
scons: building terminated because of errors.
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
