Philipp A Hartmann

Support for C++11/14 in SystemC 2.3.2

2 posts in this topic

In the SystemC 2.3.2 review thread 

 Ameya Vikram Singh (@AmeyaVS) reported the following observation:

On 3/4/2017 at 7:14 PM, AmeyaVS said:

Hello,

Also hit a build issue when mixing different compiler standard compiler flags:

The build error:


SystemC review error: when building example using c++11 option and compiler supports: C++14 also.

CMakeFiles/systemc.run.dir/src/main.cpp.o: In function `__static_initialization_and_destruction_0':
/home/ameya/sysc2.3.2_rew/include/sysc/kernel/sc_ver.h:179: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)'

Compiler used g++ 6.3

Using same compiler to build systemc-2.3.1a results in no issues, also when mixing C++ standard compiler flags to build SystemC models.

While building the SystemC_2.3.2_draft one has to maintain the C++ standard compiler flags(-std=c++11 or -std=c++14), that is supported by the g++ compiler by default and any project using overridden standard compiler flags also needed to be updated to to default compiler standard flags.

Here are the differences in the symbols generated by the same compiler over different versions of systemc:

SystemC-2.3.1a: (Using g++ 6.3.0)


000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)
000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)
000000000000002c b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config
000000000000002a b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config_seen

SystemC-2.3.2-draft review:(Using g++ 6.3.0)


00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)
00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)
0000000000000028 b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config
000000000000002c b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config_seen

Can anyone comment why C++ standard specific API specs are required?

For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system.

Is the SystemC library will be following this trend to build different version supporting different compiler standard flags?

  • Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models.

 

Would like to hear community members thoughts on this?

Best Regards,

Ameya Vikram Singh

I'll open a separate topic to discuss the details.

Share this post


Link to post
Share on other sites

Hi Ameya,

you're right: The SystemC 2.3.2 release selects a particular C++ standard to build upon and enforces consistency of this selection between the model and the library at link-time.

Users can override the detection by setting the SC_CPLUSPLUS macro at build time to a (usually earlier) C++ version, as documented in the RELEASENOTES and INSTALL files of the SystemC 2.3.2 public review release.

RELEASENOTES:

5) Initial support for C++11/14
===============================

This package includes an initial implementation of the C++11/14 proposal,
presented at DVCon Europe 2016 ("Moving SystemC to a new C++ Standard").

This includes the addition of two new preprocessor symbols:

 - IEEE_1666_CPLUSPLUS (read-only)

   This symbol indicates the availability of certain SystemC features
   which depend on a particular version of the ISO C++ standard (see below).

 - SC_CPLUSPLUS (overridable)

   By default, the most recent supported version of the C++ standard for the
   current platform/compiler is automatically detected and reflected by the
   SC_CPLUSPLUS macro.

   Users can override (i.e. usually downgrade) the assumed C++ standard to an
   earlier version for compatiblity.  The value of this macro has to be set
   consistently across the SystemC library build and all linked models
   (see INSTALL).


The values of these macros follow the values defined by the C++ standards.
Currently supported versions are:

 - 199711L (C++03, ISO/IEC 14882:1998, 14882:2003)
 - 201103L (C++11, ISO/IEC 14882:2011)
 - 201402L (C++14, ISO/IEC 14882:2014) 


The following features currently require a dedicated C++ standard version
beyond ISO/IEC 14882:2003 (aka C++03):

 - C++11 (IEEE_1666_CPLUSPLUS==201103L)

   o explicit sc_bitref_r<>::operator bool() const

     Restricts direct boolean conversion of bitvector element references
     to explicit boolean contexts (e.g. `if` expressions).
     Use the `to_bool()` function on earlier setups.


In the future, further language features depending on modern C++ language
constructs may be added.

INSTALL:

 * SC_CPLUSPLUS -
   Override automatically detected C++ standard support

   This setting allows downgrading the assumed version of the
   underlying C++ standard on the current platform.  By default,
   the latest supported version is chosen.

   Supported values are
     * SC_CPLUSPLUS=199701L (C++03, ISO/IEC 14882:1998, 14882:2003)
     * SC_CPLUSPLUS=201103L (C++11, ISO/IEC 14882:2011)
     * SC_CPLUSPLUS=201402L (C++14, ISO/IEC 14882:2014)

   Note: This symbol needs to be consistently defined in the library
         and any application linking against the built library.

 

On 3/4/2017 at 7:14 PM, AmeyaVS said:

Can anyone comment why C++ standard specific API specs are required?

For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system.

Is the SystemC library will be following this trend to build different version supporting different compiler standard flags?

  • Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models.

Especially the last note in the RELEASENOTES is relevant to your question:

Quote

In the future, further language features depending on modern C++ language constructs may be added.

In order to reduce the complexity of all the different C++ language support differences across compiler versions, the LWG decided to at least enforce a consistent selection of the C++ baseline in the proof-of-concept implementation.  Of course, other vendors may chose to allow more flexibility here, although sometimes even a consistent compiler version selection is mandated.

With this decision, the implementation does not have to worry about binary compatibility across different (C++ standard dependent) feature sets in the future.  As of today, the (currently internal) classes sc_type_index, sc_string_view differ depending on the platform's C++ standard support. Future extensions might change other classes as well.  Not worrying about the ABI compatibility is a helpful simplification here.

As described above, you can set -DSC_CPLUSPLUS=... consistently on the compiler command-line to build a single library build across several GCC versions.  If supported by your platform/compiler, you can still use the different -std=c++XY flags (or their defaults) from the compilers, provided that they generate compatible code across the selected C++ standard version.

Hope that clarifies the rationale behind the current implementation.

Greetings from Duisburg,
  Philipp

 

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