Hi Kevin, The error is quite odd, and it does look like it was hardware resource related.
Can you try building gem5 from the official docker images here? The images have newer versions of gcc and scons I believe. If the problem persists then it's probably a bug in gem5. https://www.gem5.org/documentation/general_docs/building Regards, Hoa Nguyen On Sun, Aug 6, 2023, 03:26 Eliot Moss via gem5-users <gem5-users@gem5.org> wrote: > On 8/6/2023 1:50 AM, Kaiwen Xue via gem5-users wrote: > > On Sat, Aug 5, 2023 at 5:13 AM Eliot Moss via gem5-users > > <gem5-users@gem5.org> wrote: > >> > >> On 8/5/2023 2:16 AM, Kaiwen Xue via gem5-users wrote: > >>> Hi, > >>> > >>> I'm new to gem5 and trying to follow the official tutorial [1] to > >>> build an x86 opt target from commit hash 48b4788. > >>> > >>> The compilation failed with Error 134. Outputs didn't seem to be > >>> meaningful - they are just normal building messages and ended with > >>> Error 134. I shall attach a detailed build output at the end of this > >>> email. > >>> > >>> The build command I used was `python3 `which scons` > >>> build/X86/gem5.opt`. My python3 version is 3.8.10. My scons version is > >>> 3.1.2. I've checked all the other dependencies and they seem to be > >>> fine. My machine is a physical server with ubuntu 20.04 running Linux > >>> 5.15. > >>> > >>> In addition, every time I remove the built directory and rebuilt, the > >>> file names before the Error 134 message are different. e.g., the > >>> attached output has "scons: *** [build/X86/cpu/o3/O3Checker.py.cc] > >>> Error 134", but the file name would different across different builds. > >>> > >>> Is there a way to narrow down this issue? > >>> > >>> Thanks! > >>> Kevin > >> > >> My guess is that you ran out of memory - some of the compilations need > quite a > >> lot! Since scons typically builds in parallel, you get some variation > in > >> which jobs are running when. You *might* try compiling just one thing > at a > >> time (-j1). No need to rm everything - you can continue where it > aborted. > >> But still, if even one job demands too much memory, you will fail again. > > > > Hi Eliot, > > > > Thanks for the response! However, I have more than abundant resources > > on my server. It's not a virtual machine. It has more than 200GB of > > free disk space and 100GB of free memory. I can't continue where it > > aborted as well, because the error seemed to start repeating every > > time and more compilation wouldn't make more progress. > > > > I'm suspecting that might be a compiler bug though. The parser > > reported shift/reduce conflict: > > Generating LALR tables > > WARNING: 4 shift/reduce conflicts > > WARNING: 1 reduce/reduce conflict > > WARNING: reduce/reduce conflict in state 98 resolved using rule > > (params -> empty) > > WARNING: rejected rule (types -> empty) in state 98 > > > > which might lead to the following return type warnings in the cache > > coherence .sm file: > > MESI_Two_Level-L1cache.sm:246: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L1cache.sm:248: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L1cache.sm:887: Warning: Non-void return ignored, > > return type is 'Tick' > > MESI_Two_Level-L1cache.sm:999: Warning: Non-void return ignored, > > return type is 'Tick' > > MESI_Two_Level-L1cache.sm:740: Warning: Unused action: > > e_sendAckToRequestor, send invalidate ack to requestor (could be L2 or > > L1) > > MESI_Two_Level-L2cache.sm:235: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L2cache.sm:237: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L2cache.sm:594: Warning: Unused action: > > fw_sendFwdInvToSharers, invalidate sharers for request > > MESI_Two_Level-L2cache.sm:764: Warning: Unused action: > > kk_removeRequestSharer, Remove L1 Request sharer from list > > MESI_Two_Level-L2cache.sm:780: Warning: Unused action: > > mm_markExclusive, set the exclusive owner > > MESI_Two_Level-dir.sm:160: Warning: Non-void return ignored, return > > type is 'bool' > > MESI_Two_Level-dir.sm:294: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:298: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:302: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:348: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:351: Warning: Unused action: > > p_popIncomingDMARequestQueue, Pop incoming DMA queue > > MESI_Two_Level-dma.sm:189: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dma.sm:193: Warning: Non-void return ignored, return > > type is 'Tick' > > > > Any idea why those happened? Any response or hints are appreciated! > > That looks to me like something coming from ruby, and that parser may be > quite distinct from the one in g++. But I don't use ruby so I don't > really know ... Sorry - EM > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
