Work in progress, just some notes for the moment. Issues, workarounds and notes regarding the use of C++11 with G4

Support of c++11 features in Geant4: notes

Windows related

No default in (virtual) destructor

This will fail at link time on windows (x86-win7-vc14-Seq):
class MyClass {
     [ ... nothing unusual here ...]
     virtual ~MyClass() = default;
The destructor code is not generated and you get an error at link time mentioning vtable of MyClass. The solution is to add explicitly the destructor.

default not allowed on move constructor and move-assignment operator

This is a limitation of VS, these two cannot be defaulted, see:

ICC notes

Current status of icc compilation: September 17th 2015Apr 17 2017

Prerequisite: To correctly compile Geant4 with c++11 enabled and icc version 15 we need gcc version 4.9.x (tested with x=2) to be setup, so icc can use this gcc headers and libraries. Note that more recent versions of gcc (e.g. 5.x) are not supported and should not be used. Note that if you do not perform this setup not all the c++11 features are available. For example: std::this_thread::sleep_for is not recognized by icc, even if it is perfectly valid.

*Problem with LEND module*: There are two files in the lend module that contain a very large static const data strucutre. These cannot be compiled: icc gets stuck in an infinite loop and starts to use a huge amount of memory eventually blocking the machine. I've confirmed that removing these two large static objects solve the problem. Should be fixed with hadr-lend-V10-01-02 tag, under testing

*Problem with -no-gcc option*: When using icc we add the -no-gcc option. This causes other compilation problems because intel headers may rely on macro __GNUC__ (e.g. TBB examples do not compile). Removing this -no-gcc and making a fix in tls.hh solves the problem (see later). New strategy is to use gcc-sys flag with icc (starting from tag cmake-V10-01-19).

ROOT6 problems: I've not managed to compile G4 against root6, however root5 works, so for the moment we suspend this issue.

*Current workaround for ctest/cdash*: For the moment, considering that pure native c++11 code is rare in G4, in ctest/cdash we do not setup a recent gcc compiler and instead use gcc 4.4.7, this mean that many features of c++11 may not be available. We will do the correct setup once the other errors are solved. Solved. Setup scripts modified to setup gcc 4.9.2

Issue with use default for mic compilation. This will not compile for derived classes with an issue related to noexcept (see

class G4BaseCalss {
   virtual ~G4BaseClass() = default;
Workarounds: or add noecept to the base class, but add the same to all derived classes: virtual ~G4BaseClass() noexcept = default; or simply write an empty destructor in base class: virtual ~G4BaseClass() {}

Compilation for MIC: We cannot compile CLHEP with icc (tested up to latest version 16.0) for Xeon Phi, the problem is due to missing support (only on MIC, not on host) of thread_local. See: I suspect the problem is related to footnote 5. in For example running:

icpc -v -E -x c++ - < /dev/null 
icpc version 15.0.0 (gcc version 4.9.0 compatibility)
/opt/intel/composer_xe_2015.0.090/bin/intel64/mcpcom    --lang=c++ -_g -mP3OPT_inline_alloca -D__ICC=1500 -D__INTEL_COMPILER=1500 -D__INTEL_COMPILER_UPDATE=0 -D__PTRDIFF_TYPE__=long "-D__SIZE_TYPE__=unsigned long" -D__WCHAR_TYPE__=int "-D__WINT_TYPE__=unsigned int" "-D__INTMAX_TYPE__=long int" "-D__UINTMAX_TYPE__=long unsigned int" -D__LONG_MAX__=9223372036854775807L -D__QMSPP_ -D__OPTIMIZE__ -D__NO_MATH_INLINES -D__NO_STRING_INLINES -D__GNUC_GNU_INLINE__ -D__GNUG__=4 -D__GNUC__=4 -D__GNUC_MINOR__=9 -D__GNUC_PATCHLEVEL__=0 -D__LP64__ -D_LP64 -D_GNU_SOURCE=1 -D__DEPRECATED=1 -D__GXX_WEAK__=1 -D__GXX_ABI_VERSION=1002 "-D__USER_LABEL_PREFIX__= " -D__REGISTER_PREFIX__= -D__INTEL_RTTI__ -D__EXCEPTIONS=1 -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -B -Dunix -Dlinux "-_Asystem(unix)" -D__ELF__ -D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ "-_Acpu(x86_64)" "-_Amachine(x86_64)" -D_MT -D__INTEL_COMPILER_BUILD_DATE=20140723 -D__INTEL_OFFLOAD -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -D__pentium4 -D__pentium4__ -D__tune_pentium4__ -D__SSE2__ -D__SSE2_MATH__ -D__SSE__ -D__SSE_MATH__ -D__MMX__ -_k -_8 -_l -_a -_b -E --gnu_version=490 -_W5 --gcc-extern-inline -p --bool -tused -x --multibyte_chars --array_section --simd --simd_func --offload_mode=1 --offload_target_names=gfx,GFX,mic,MIC --offload_unique_string=icpc783969220QEpfjr --bool -mP1OPT_print_version=FALSE -mP1OPT_version=15.0-intel64 -
#include "..." search starts here:
#include <...> search starts here:
End of search list.
# 1 "-"
Note the compatibility to 4.9.2, while the same for mic:
icpc -mmic -v -E -x c++ - < /dev/null 
icpc version 15.0.0 (gcc version 4.7.0 compatibility)
/opt/intel/composer_xe_2015.0.090/bin/intel64/mcpcom    --lang=c++ -_g -mP3OPT_inline_alloca -D__ICC=1500 -D__INTEL_COMPILER=1500 -D__INTEL_COMPILER_UPDATE=0 -D__PTRDIFF_TYPE__=long "-D__SIZE_TYPE__=unsigned long" -D__WCHAR_TYPE__=int "-D__WINT_TYPE__=unsigned int" "-D__INTMAX_TYPE__=long int" "-D__UINTMAX_TYPE__=long unsigned int" -D__LONG_MAX__=9223372036854775807L -D__QMSPP_ -D__OPTIMIZE__ -D__NO_MATH_INLINES -D__NO_STRING_INLINES -D__GNUC_GNU_INLINE__ -D__GNUG__=4 -D__GNUC__=4 -D__GNUC_MINOR__=7 -D__GNUC_PATCHLEVEL__=0 -D__LP64__ -D_LP64 -D_GNU_SOURCE=1 -D__DEPRECATED=1 -D__GXX_WEAK__=1 -D__GXX_ABI_VERSION=1002 "-D__USER_LABEL_PREFIX__= " -D__REGISTER_PREFIX__= -D__INTEL_RTTI__ -D__EXCEPTIONS=1 "-_Asystem(unix)" "-_Acpu(x86_64)" "-_Amachine(x86_64)" -D__ELF__ -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -B -Dunix -Dlinux -D__x86_64 -D__x86_64__ -D__k1om__ -D_MT -D__INTEL_COMPILER_BUILD_DATE=20140723 -D__KNC__ -D__KNC -D__MIC__ -D__MIC -_k -_8 -_l -_a -_b -E --gnu_version=470 -_W5 --gcc-extern-inline -p --bool -tused -x --multibyte_chars --diag_error=2348 --diag_error=2351 --array_section --simd --simd_func --offload_mode=0 --offload_unique_string=icpc1704057724lEv3R9 --bool -mP1OPT_print_version=FALSE -mP1OPT_version=15.0-intel64 -
#include "..." search starts here:
#include <...> search starts here:
End of search list.
# 1 "-"
Shows compatibility with gcc 4.7.0!

*Timeouts (infinite loops)*: Some examples enter an infinite loop. It seems related to a problem in RNG engine in CLHEP. Testing tag externals-V10-01-09 that should fix the problem. Currently disabling native MT treatment of RNG engines in CLHEP with tag global-V10-01-16.

Converging towards a correct icc compilation

One needs a GCC system setup correctly to use icc. To use reliably C++11 features, we need a recent compiler setup. However not all very recent compilers will do. It seems that icc 15 wants/supports gcc 4.9.x.
On my development machine I thus first setup gcc 4.9.2 and then use icc to compile G4. Two problems appear at this point:
  • Two files in lend module cannot be compiled, what happen is that the icc compiler starts to use an enormous amount of memory and the compilation job get killed. The problem is due to two very large static const data structures in the two files and files. The developers are informed and will find a solution. Note that in the past we have seen a gcc warning about the size of these two data structures but this warning was ignored (shame on us!). For the time being I've removed these large data structures and it can compile
  • TBB examples do not compile due to the option no-gcc option. This does not define __GNUC__ macro and this causes a problem at compilation of TBB examples. The problem comes from a tbb header: My feeling is that we should avoid to use no-gcc, in order to do that we need a patch to tls.hh to avoid to take the branch: adding !defined(__INTEL_COMPILER) seems to solve the problems.

Other notes

*NB*: It is my understanding that a given icc version is somehow linked/tailored towards a specific gcc version. For example, you cannot setup gcc 5.2 and then use icc 15 (see later), I've found several posts online talking about these issues. So let's focus on avoiding configuring an (alternative more recent) compiler when using icc.

No the above is not strictly true. We need more investigations. It is true that icc needs the system gcc to compile correctly, if you are using an old gcc many things can go wrong. For example the following snippet of code:

#include <thread>
#include <chrono>

int main(int,char**) {
    std::this_thread::sleep_for(std::chrono::duration<int,std::milli>(100) );
    return 0;

Does not compile of a RH6 machine (even with latest icc) and you get the error:

icpc -std=c++11 error: namespace "std::this_thread" has no member "sleep_for"
      std::this_thread::sleep_for(std::chrono::duration<int,std::milli>(100) );

compilation aborted for (code 2)

But if you first setup a recent compiler:

source /opt/gcc-5.2/
#On lxplus at CERN should be: source /afs/
icpc -std=c++11

Everything works as expected. But this does not compile G4 for other reasons... See first paragraph, with icc 15 one needs gcc 4.9.2

Debug Vs Release mode: a strange error

*This is solved setting up correctly gcc 4.9.2 before using icc* On a RH6 based machine with:
icpc --version
icpc (ICC) 15.0.0 20140723
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.
When configuring with:
I get lining errors when creating G4clhep target:
make G4clhep VERBOSE=1
ld: CMakeFiles/G4clhep.dir/src/ relocation R_X86_64_PC32 against undefined symbol `_ZN85_INTERNAL_63__home_adotti_Work_geant4_source_externals_clhep_src_DoubConv_cc_15b511b422__gthrw_pthread_cancelEm' can not be used when making a shared object; recompile with -fPIC
The problem *disappears* when compiling with
and avoiding debug symbols.
No more problem once gcc 4.9.2. is setup.

atomic and icc on RH6 based machines (i.e. gcc<4.5)

We have compilation errors with icc with c++11 and we use ROOT6 . See for example: The problem is the following:
  • ROOT6 uses the c++11 atomic feature
  • We compile G4 with the switch -no-gcc when using Intel Compiler: see line 217 of /cmake/Modules/Geant4MakeRules_cxx.cmake
  • With ICC if no-gcc is set the macros GNUC and GNUC_MINOR are not set
  • Intel’ compiler atomic header, in such a case, relies on system wide atomic see (your absolute path varies): /opt/intel/composer_xe_2015.1.133/compiler/include/atomic
  • If you are on a machine that has, as a default compiler, something older than gcc 4.5 (as it is for RH6 based one) you get the error

I see three alternatives here when compiling with ICC:

  • Remove the no-gcc compiler flag: this should be clarified, but we need this to have TLS to work correctly (ask Gabriele)
  • Leave the no-gcc flags but add to the compiler flags the defintion of: __USE_INTEL_ATOMICS Proposed solution
  • Setup, before using icc a recent compiler. Needed anyway

Possible variation of second approach from Ben: Alternately, would a configure time test work, i.e. logic like:

if(compiler is intel)
  check_cxx_source_compiles(“..code that exercises <atomic>…”, HAVE_ATOMIC)


For third option: Tried to setup gcc 5.2 and then icc, but this fails miserably:

-bash-4.1$ make test75
[  0%] Building CXX object source/externals/clhep/CMakeFiles/G4clhep.dir/src/
/opt/gcc-5.2/include/c++/5.2.0/bits/stl_iterator_base_types.h(154): error: class "std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>" has no member "iterator_category"
        typedef typename _Iterator::iterator_category iterator_category;
          detected during:
            instantiation of class "std::__iterator_traits<_Iterator, void> [with _Iterator=std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>]" at line 163
            instantiation of class "std::iterator_traits<_Iterator> [with _Iterator=std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>]" at line 4865 of "/opt/gcc-5.2/include/c++/5.2.0/bits/basic_string.h"
            instantiation of "std::__cxx11::basic_string<_CharT, _Traits, _Alloc> std::operator+(std::__cxx11::basic_string<_CharT, _Traits, _Alloc> &&, std::__cxx11::basic_strin
See first notes on "link" between a given icc version and a corresponding gcc one

ROOT6 issues with icc

*Ben's proposal works for this particular issue* However there are then tons of other errors specific to ROOT6, I do not think we can do so much with something like this:
/opt/root-6.04.02-gcc52-py27/include/root/libcpp_string_view.h(786): error: a template argument list is not allowed in a declaration of a primary template
  struct _LIBCPP_TYPE_VIS_ONLY hash<std::experimental::basic_string_view<_CharT, _Traits> > 
Moreover, and maybe this shows that we need to stop on this for the moment, on CentOS 6.5 and icc 15.0 I *cannot* compile ROOT6 itself. A compilation error is issued. I've open a ROOT bug report: I've note managed to solve this problem, even following ROOT people prescription. However on lxplus I managed to compile, thus there is a missing piece of configuration on my side. Given the other problems I have with icc ROOT6 is now suspended...

gcc on Mac

Mac Os X 10.9 : Tried to compile G4 with C++11 and GCC 5.2 (installed via homebrew). Failed with a crash at startup of applications when Qt(5) is enabled. However the problem is not due to Qt (actually the same problem happens with Qt4. The issue is that Mac OSX uses libc++ while GCC uses libstdc++, tried to compile with gcc requesting to use c++ instead (see It is my opinion that at the moment to compile with C++11 on Mac we need to restrict to clang. Also I think the problem is not related to Qt, the crash is in libstdc++ routine used in dynamic_cast.

Qt5 with remote displays

Linux (CentOS 6): Qt5 with C++11 causes a set of errors with exported displays (e.g. connecting via VNC or NX):;wap2 Problem seems not to be there with Qt4

ROOT6 TString fun

Use of ROOT6: In tests using ROOT6.04.02 w/ C++11 enabled and GCC 5.2 (on Linux box) we get the following error when mixing G4String (better std::string, since the former is an extension of the latter) and TString objects:
undefined reference to `TString::operator=(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
solution is to convert std::string to const char*:
G4String somestr = "SoBadIdeaToUseTStrings";
TString somerootstr = somestr.c_str();

-- AndreaDotti - 2015-07-24

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r17 - 2017-04-17 - AndreaDotti
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Geant4 All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback