SystemC 2.3.4 needs to be compiled with -std=c++11

[quark17]

The CI is currently failing on macos-11 and macos-12 environments, not because of any commits, but because of changes in the environments. Specifically, I believe that the Homebrew package manager is now providing SystemC 2.3.4 (and we were probably getting 2.3.3 a few months ago when the CI last ran and was passing).

The failures in the testsuite are in testsuite/bsc.bluesim/to_systemc/ and it shows that the C++ step (compiling the SystemC testbench and linking with the BSC-generated objects) fails. When there's a failure, the CI runs a script (testsuite/archive_logs.sh) to collect just the log files into a tar-archive and make it available for download as an artefact -- however, it isn't including the log files for C++ steps (something that should be fixed!), so I can't see what's going on there. Fortunately, I am able to see the failure on my Mac, after upgrading the systemc package on Homebrew to 2.3.4. The error I'm seeing is this:

Undefined symbols for architecture x86_64:
  "sc_core::sc_api_version_2_3_4_cxx199711L<&(sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_)>::sc_api_version_2_3_4_cxx199711L(sc_core::sc_writer_policy, bool)", referenced from:
      __GLOBAL__sub_I_mkGCD_systemc.cxx in mkGCD_systemc.o
      ___cxx_global_var_init in top-7d6c81.o
      ___cxx_global_var_init in TbGCD-c42d1d.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This can be fixed by adding -std=c++11 to the g++ call that BSC makes during its linking step and to the g++ call that the testsuite makes (when CXX is not set, although that should be fixed to use c++, to match what BSC does).

As you see in the message, the name ends with 199711L, which indicates the C++ standard that's expected:

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

and I guess the feature doesn't exist for C++03. The default standard used by c++/g++ on my Mac can be seen with this command:

$ c++ -dM -E -x c++ /dev/null | grep -F __cplusplus
#define __cplusplus 199711L

And so we've generated code that expects to find the C++03 version, and the SystemC library doesn't provide it. Interestingly, if we add -std=c++14, that still gives an error, only this time the symbol that's missing ends in 201402L, so I'd guess that means that the installed SystemC library has been explicitly compiled with C++11.

I see that SystemC 2.3.4 has introduced some requirements for modern standards (C++11/C++14), and expects to introduce more, per the release note: https://github.com/accellera-official/systemc/blob/39740075f47fedbce242808d357fcfb6d3d33957/RELEASENOTES#L573

I would guess that the Ubuntu systems are not encountering this because the default standard there is probably C++11.

I would guess that the fix here is for the CI to add std=c++11 to CXXFLAGS in the environment for macOS. I guess we'd need to test if this would break anything. Alternatively, the testsuite could add it, just during the execution of the SystemC tests.

However, another option could that BSC should explicitly add -std=c++11 when compiling its SystemC wrappers (if not for all its generated code?) and for the testsuite to also add -std=c++11 when compiling for SystemC. However, I assume that would cause problems on systems where the SystemC library has been compiled with a newer standard (where, say, the default used by c++ is newer)? That's why I'm thinking that the CI environment should specify any non-default flags that are needed.

Interestingly, I see that Bluesim is built as C++11:

$ grep -R -i "c++11" .
./src/bluesim/Makefile:	-std=c++11 \
./src/bluesim/Makefile:	$(CXX) -std=c++11 -c -o /dev/null test_hdr.cxx
./src/vendor/stp/src/Makefile.common:CXXFLAGS = $(CFLAGS) -Wall -std=c++11 -DTR1_UNORDERED_MAP -Wno-deprecated

So maybe, BSC is currently requiring C++11 (and not anything newer)? Should BSC's make process be updated to allow multiple (newer) standard?

Another option would be to hold back the version of SystemC on the macOS CI environments to 2.3.3. But we probably want to support 2.3.4 and should therefore test it. In fact, we may want to support multiple versions, so we should consider setting up the CI to run the tests with multiple versions.

[quark17]

I experimented with several approaches and decided to resolve this by adding a new option to the testsuite (TEST_SYSTEMC_CXXFLAGS) for specifying additional C++ flags that are needed when compiling and linking SystemC, and the CI job for running the testsuite on macOS will pass in -std=c++11. The source code of the Homebrew formula for SystemC has a section on testing the build, and it provides that flag. I found that all of the macOS CI jobs (for bsc-contrib, Toooba, BDW) would pass if the flag was added to CXXFLAGS; but I think it's good to test everything with the default compiler settings, so I decided not to go that route. I also found that this flag would cause the SystemC tests to fail on the Ubuntu VMs, because the default C++ standard there is C++14, and the SystemC library is installed for that. So hard-coding C++11 in the testsuite wasn't the right answer either. It's specific to the way SystemC is installed on the macOS VMs, so I added a targeted flag to the testsuite to allow adding C++ compiler flags for SystemC tests when needed (in this case, just the macOS job).