On May 10, 2011, at 1:27 PM, Gedare Bloom wrote:
> 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.
Gabe is right, we probably should bump the min version number up to 4.0 now, as
no one really tests with 3.4.X anymore.
>
>
> 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.
This should be cast to (uint32_t). I've got a patch that does this and I'll
commit it reasonably soon.
>
> 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 have no idea how gcc doesn't figure out they're being protected by the same
condition. Is there some way to initialize NPC with 0 so this doesn't happen?
Gabe?
>
>
> 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.
Gcc 3.4 must not support that option. We don't change options depending on
compiler. Another reason to perhaps deprecate 3.4.
>
> 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
I'm not sure about this one...
Ali
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
