Jump to content
LookBad

make check return fail

Recommended Posts

Hi

I run "make install" and "make check" but I see this result:

============================================================================
Testsuite summary for SystemC 2.3.2
============================================================================
# TOTAL: 22
# PASS:  21
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See examples/sysc/test-suite.log
Please report to http://forums.accellera.org/forum/9-systemc/
============================================================================

In test-suite.log:

=================================================
   SystemC 2.3.2: examples/sysc/test-suite.log
=================================================

# TOTAL: 22
# PASS:  21
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: 2.3/simple_async/test.sh
==============================


        SystemC 2.3.2-Accellera --- Jun  6 2018 22:55:28
        Copyright (c) 1996-2017 by all Contributors,
        ALL RIGHTS RESERVED
test.sh: line 65: 32560 Abort trap: 6           ./test > run.log
***ERROR:
2,4c2,5
< Fatal: (F4) assertion failed: sem_trywait == 0
< In file: ../../../src/sysc/communication/sc_prim_channel.cpp:195
< Info: (I99) simulation aborted
---
> I'm busy!
> Asked to stop at time 10 ns
> The dog barks before the end of simulation
> Program completed

I don't know how to fix it :( Is anyone here who's got the same problem? Or know how to fix it? :) 

Share this post


Link to post
Share on other sites

Sure,
os: macOS High Sierra 10.13.5
compiler: 
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)

Share this post


Link to post
Share on other sites

Hello @LookBad,

Sorry, I don't have a macOS environment readily available with me.

Maybe someone else might be able to help you with that, or better would be if you could use a Linux VM for exploration.

Regards,

Ameya Vikram Singh

Share this post


Link to post
Share on other sites

I am able to reproduce the problem and will attempt a fix. Unless you are using async_request_update() in your code, you can safely ignore this problem for now.

CORRECTION: While there is a bug with the following deprecated feature issue, this does not solve the problem. Stay tuned for a real fix.

There is a bug in the implementation of SystemC due to Apple removing support for POSIX sem_init, which is a non-required API by the POSIX standard. See <https://stackoverflow.com/questions/1413785/sem-init-on-os-x/24617282> for details.

[Pure speculation: I suspect the reason for removing support was that Apple has recently moved to an all 64-bit coding model. Potentially because they are positioning themselves to be able to port quickly to Arm v8A lacking Aarch32 on certain hardware.]

When building on OSX using Cmake I noticed a clue:

Quote

[  9%] Building CXX object src/CMakeFiles/systemc.dir/sysc/communication/sc_prim_channel.cpp.o
In file included from /eda/osci/src/lwg/src/sysc/communication/sc_prim_channel.cpp:38:
/eda/osci/src/lwg/src/sysc/communication/sc_host_semaphore.h:74:30: warning: 'sem_init' is deprecated
      [-Wdeprecated-declarations]
    void do_init(int init) { sem_init( &m_sem, 0, init ); }
                             ^
/usr/include/sys/semaphore.h:55:42: note: 'sem_init' has been explicitly marked deprecated here
int sem_init(sem_t *, int, unsigned int) __deprecated;
                                         ^
/usr/include/sys/cdefs.h:176:37: note: expanded from macro '__deprecated'
#define __deprecated    __attribute__((deprecated))
                                       ^
1 warning generated.

I use the adage, "A warning is usually a potential bug leading to a real error." Never ignore warnings from compilations. Yes, I know there is a lot of code out there with superfluous warnings. Shame on them for leaving them in. So if you see a warning, track it down. If it is truly a don't care (rarely), then it can be overridden with a #pragma. Almost all warnings can be fixed with proper coding.

I am going to attempt a fix to sc_host_semaphore.h, but if you're in a hurry go to Linux.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×