Support for C++11/14 in SystemC 2.3.2

[Philipp A Hartmann]

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.

[Philipp A Hartmann]

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

 

[katang]

In SystemC's CMakeLists.txt  file I set
 

set (CMAKE_CXX_STANDARD 11 CACHE STRING
     "C++ standard to build all targets. Supported values are 98, 11, and 14.")

In my own CMakeLists.txt file I set
 

 set(CMAKE_CXX_STANDARD "11")

However, my system keeps telling

In function `__static_initialization_and_destruction_0(int, int)':
/usr/local/systemc-2.3.2/include/sysc/kernel/sc_ver.h:182: 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)'

I have a newly installed Ubuntu 18.04, and I attempted all variants and tips, for one and a half day. I give up and going back to the previous version.

[Roman Popov]

1 hour ago, katang said:

In SystemC's CMakeLists.txt  file I set

set (CMAKE_CXX_STANDARD 11 CACHE STRING
     "C++ standard to build all targets. Supported values are 98, 11, and 14.")

 

 Most likely you have C++98 in CMake cache. 

You don't need to modify SystemC CMakeLists, just set c++ standard from command line. Check here for detailed instructions https://stackoverflow.com/questions/46875731/setting-up-a-systemc-project-with-cmake-undefined-reference-to-sc-core

[katang]

Surely not, I emptied directory "build".

The problem here is that I need to use some 3rd-party components. This error message comes up when I attempt to combine some of them with SystemC.

BTW: if SystemC builds with any of the C++ standards, what is the reason of enforcing a certain standard? The rest of the world typically does not use it,and as I see, it causes several issues, and at least needs to understand and edit foreign packages, which without this enforcing cooperated perfectly? If you like, you can use compiler switch when configuring SystemC. If you like.

[Roman Popov]

--Deleted--

I've re-read original post from Philipp and it provides detail explanation why it was made this way.