Enable support for 'concepts' in GCC 6 and later #3638
Conversation
GCC 6.x and higher supports 'concepts' as defined in the Concepts TS ["C++ Extensions for concepts", ISO Technical Specification ISO/IEC TS 19217:2015](https://www.iso.org/standard/64031.html). With GCC 6.x, the `-fconepts` option enables support for concepts and defines `__cpp_concepts` to `201500`. With GCC 7.x, the `-fconepts` option enables support for concepts and defines `__cpp_concepts` to `201509`, as dictated by the TS. LLVM/clang and Intel ICC do not support 'concepts' yet.
|
@cmsbuild, please test |
|
The tests are being triggered in jenkins. |
|
A new Pull Request was created by @fwyzard (Andrea Bocci) for branch IB/CMSSW_10_0_X/gcc630. @cmsbuild, @smuzaffar, @gudrutis, @mrodozov can you please review it and eventually sign? Thanks. |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
|
@fwyzard , @davidlange6 , @Dr15Jones -fconcepts boost serialization . For now I am reverting it and we need to update build rules to drop flags which are not good for boost serialization. |
|
Can you just update the serialisation rules instead of reverting it ?
Actually, can we fix once and for all the rules used for serialisation to
pick up the llvm/clang flags, rather than the gcc ones ?
.A
|
|
this requires some non-trivial changes in build rules. |
|
On Dec 18, 2017, at 3:15 PM, Andrea Bocci ***@***.***> wrote:
Can you just update the serialisation rules instead of reverting it ?
Actually, can we fix once and for all the rules used for serialisation to
pick up the llvm/clang flags, rather than the gcc ones ?
i'm not sure I follow why the gcc flags should not be used? [perhaps my memory fails me about a previous thread]
…
.A
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@fwyzard what was the use case for turning on an experimental C++ feature? |
because we use clang to build the serialisation libraries, see CondFormats/Serialization/python/condformats_serialization_generate.py.
Well, I would say "to make use of it". While it may be experimental, is is a publish standard; so a more apt question would be why we are not using it yet. |
I understand, but it seems the special build rules need to be adjusted every time the GCC flags change. Also, why did the integration test not pick up the problem ? |
|
On Dec 18, 2017, at 4:06 PM, Andrea Bocci ***@***.***> wrote:
@davidlange6
i'm not sure I follow why the gcc flags should not be used?
because we use clang to build the serialisation libraries, see CondFormats/Serialization/python/condformats_serialization_generate.py.
ha - didn't know that. sounds like a fix for @ggovi to help with.
… @Dr15Jones
what was the use case for turning on an experimental C++ feature?
Well, I would say "to make use of it".
In particular, I'm working on an interface to the DQMStore's MonitorElements that is templated on the object it holds, rather than relying on internal consistency checks for every call to Fill().
Since the DQMStore supports only a limited set of scalars and ROOT objects, I would like to restrict the types available for template instantiation - and I'd rather do it without all the SFINAE complications.
While it may be experimental, is is a publish standard; so a more apt question would be why we are not using it yet.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@fwyzard ,
yes
For now, gcc-toolfile changes do not trigger built of any packages (actually it should rebuild full release). I will fix this this week. |
One improvement would be to fix rather than to get the clang-friendly flags. However when we build a release SCRAM passes the compiler options directly, to avoid the 30-40 calls to discover the flags (once per CondFormats package) and thus be faster. |
It was voted into the C++ 20 standard, however many compilers do not support it. GCC experimentally supports it but who knows how buggy or inefficient (both compile and run time) it is. |
I am not talking about the C++20 standard, but about the Technical Specification (which means that, yes, it is experimental). Interesting that you consider "buggy or inefficient" something you have not tried. |
|
On Dec 18, 2017, at 4:06 PM, Andrea Bocci ***@***.***> wrote:
While it may be experimental, is is a publish standard; so a more apt question would be why we are not using it yet.
It looks like GCC labels concepts as implemented but
"Because these Technical Specifications are still evolving toward future inclusion in a C++ standard, GCC's support is experimental. No attempt will be made to maintain backward compatibility with implementations of features that do not reflect the final standard."
(https://gcc.gnu.org/projects/cxx-status.html)
Such language s usually something worth staying away from in a large software stack unless there is a significant benefit both for compatibility across platforms and prevention of future surprises when upgrading (gcc in this case).
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Fair point - so, can we try it in the "next" branch, and see what it does on our large software stack ? |
|
I would be OK with trying this on DEVEL |
|
Naively ok for me - but how would you see the CMS development happening?
… On Dec 18, 2017, at 5:36 PM, Andrea Bocci ***@***.***> wrote:
Fair point - so, can we try it in the "next" branch, and see what it does on our large software stack ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Since we need anyway to keep our code compiling under clang and maybe intel, we can wrap the concept-related stuff with #if __cpp_concepts >= 201507
// concept-enabled stuff go here
#else
// non-concept fall back goes here
#endifFor example (here I use #if __cpp_concepts >= 201500
template<typename T>
concept bool CopyConstructibleAndAssignable() {
return std::is_copy_constructible<T>::value and std::is_copy_assignable<T>::value;
}
#else
#define CopyConstructibleAndAssignable typename
#endif
template <CopyConstructibleAndAssignable T>
class Container {
...
};or (more intrusive) #if __cpp_concepts >= 201500
template<typename T>
concept bool CopyConstructibleAndAssignable() {
return std::is_copy_constructible<T>::value and std::is_copy_assignable<T>::value;
}
#endif
#if __cpp_concepts >= 201500
template <CopyConstructibleAndAssignable T>
#else
template <typename T>
#endif
class Container {
...
}; |
|
The original "Concepts" idea IIRC failed (years ago) and later "Concepts Lite" was pursued. I think, the latest Concept work was approved for C++20. Some (short, 2 pages) proposal: If enabling Concepts TS does not affect C++ ABI (probably it doesn't), then enabling it should not be a problem. This also helps to iron out bugs within GCC toolchain and provide further feedback to C++ committee meetings (that CERN attends). The only request would be, that if code is broken due to Concepts implementation change within GCC then this should be fixed ASAP. Looks like Concepts might be already a bit different between Concepts TS (2015) and C++20 draft (now). |
GCC 6.x and higher supports 'concepts' as defined in the Concepts TS "C++ Extensions for concepts", ISO Technical Specification ISO/IEC TS 19217:2015.
With GCC 6.x, the
-fconeptsoption enables support for concepts and defines__cpp_conceptsto201500.With GCC 7.x, the
-fconeptsoption enables support for concepts and defines__cpp_conceptsto201509, as dictated by the TS.LLVM/clang and Intel ICC do not support 'concepts' yet.