possible C++14 issue
There has been indirect reports that C++14 is causing trouble within LBNE. Below is the edited conversation that indicates some of this trouble. Can someone contact Ben or others to find out specific details of what the failure is to determine how we might help to address it? To reiterate, I would like information collected about the failures that are happening in regards to C++14 in order to then figure out what needs to be done do to alleviate them.
In addition, I would like someone to find out about the the white paper that is mentioned. Please find and obtain it so a meeting can be scheduled to discuss it.
——— relevant parts of the email thread ———
I got another LBNE complaint (I attached the thread below). This is my summary:
- Art contains C++14 code
- This restricts the number of older systems that can be support
- Debugging tools also on recent platforms are not fully usable with C++14
- There exists a set of changes to make Art/lower level libraries C++11 compliant
In general, the decision to use C++14 code in Art/lower level libraries is questioned, because it is cutting edge and limits platform possibilities. The tool set is not yet fully C++14 capable, especially in the area of debugging.
FYI the issue it's not the first time the issue of C++14 is being discussed. A few people in and
around LBNE (certainly including myself) did not hear any compelling reasons why this revision
of the standard needs to be used right away. And frankly, it just looks gratuitous. Ben, Brett and
Patrick are doing infrastructure work for art not because they have nothing better to do but because
people encountered real problems with the art environment. We did not receive any feedback
to the white paper in Dec'14 and no assistance along the lines described in this paper. I…
Begin forwarded message:
From: Brett Viren <firstname.lastname@example.org>
To: "Morgan, Ben" <Ben.Morgan@warwick.ac.uk>
Cc: Maxim Potekhin <email@example.com>, Elizabeth S Sexton-Kennedy <firstname.lastname@example.org>
Subject: Re: Building current Art in C++11 w/GCC/Clang
Date: March 6, 2015 at 12:05:14 PM CST
Maxim, Liz, I recommend you forward Ben's report to Oli.
"Morgan, Ben" <Ben.Morgan@warwick.ac.uk> writes:
I’m cc’ing Maxim and Liz in this as they might find it of interest given the state things were left
before New Year with LBNE.
To update and get to a common starting point - I got back to compiling everything up to the art
level both on Linux with GCC 4.9 and Mac with Clang (Xcode 6). Thanks to Brett and Patrick’s
work, we have a working release of Art 1.13.01 sans UPS on LBNE GitHub. It’s this that I came back to.
Whilst everything was working nicely on Linux/GCC, I had issues
yesterday building on Mac/Clang because some tests in FhiclCPP were
failing and I could not debug these.
That is due to an issue with the Clang not fully being able to output
debug info for all C++14 constructs. A deficiency/bug for sure, but
illustrates how close to the bleeding edge the Art team are sailing,
if true cross platform/compiler support is intended.
I’ve therefore done something rather simple (or crazy/stupid depending on your point of view).
I took the current LBNE release of Art/lower level libraries and made it C++11 compliant. This
only took me this afternoon. You can see the full set of changes here:
What have we gained by this?
i) We can now build all of Art’s dependencies on both platforms, and
all tests, bar one on Mac pass. The difference if that debugging can
now be done on Mac with lldb. In addition, a much wider range of
systems can be supported “out the box”.
ii) There has been minimal change to the code - in other words, the
move to C++14 (and most of the features were used) brought nothing to
the usability or functionality of Art. Where
there were larger changes, std::make_unique and string literals, these can be supported by
C++11 backports (ala cpp0x).
iii) Traded code for time - sure C++14 is nice, what’s the price? Is
it really so bad to wait 6-12 months for tools on all platforms to
What have we lost by this?
i) Use of C++14. I actually do want to use this - but only when the tools are ready. Yes, we
should hope that system compilers keep step with developments, sure we
can build our own compiler but also why go the the bleeding edge when
there’s no technical requirement to do so. As the code diffs above
show, Art has gained nothing practical by this move, at least
obviously, given the price in loss of portability and consequent
All of that comes with a great big caveat that this is purely a “it builds, pass tests, and runs”.
Nevertheless, check the actual diffs - not much has changed ultimately…
#1 Updated by Oliver Gutsche about 5 years ago
Here is the white paper:
#3 Updated by Adam Lyon about 5 years ago
The XCode beta 6.3 release notes say...
Apple LLVM Compiler Version 6.1
• Xcode 6.3 updates the Apple LLVM compiler to version 6.1.0. This new compiler includes full support for the C++14 language standard, a wide range of enhanced warning diagnostics, and new optimizations. Support for the arm64 architecture has been significantly revised to align with ARM’s implementation, where the most visible impact is that a few of the vector intrinsics have changed to match ARM’s specifications.
It doesn't say anything about the debugger, but hopefully that's updated for C++14 too.
I think the official XCode 6.2 doesn't have this.
#4 Updated by Marc Paterno about 5 years ago
There are at least two issues discussed here, and we're working on both of them.
First, I am working on getting into contact with Ben Morgan to obtain more specific information regarding the problem he has encountered with C++14.
The second issue is the white paper. At our regular art issues handling meeting this morning, we agreed that Jim Amundson is going to take the lead in contacting the authors of the paper to understand the issues raised in the paper.
#5 Updated by Adam Lyon about 5 years ago
XCode 6.3, with the C++14 compatible clang, is out of beta and is now the official release. See https://itunes.apple.com/us/app/xcode/id497799835?ls=1&mt=12 .
#6 Updated by Marc Paterno about 5 years ago
Marc spoke with Ben for about half and hour to get the details of the C++14 language issue.
The tool that failed to understand the C++14 feature was some combination of the clang compiler and the lldb debugger. In the Xcode release Ben was using, clang could not emit debugging symbols for some C++14 constructs. So the lldb debugger could not understand the resulting code.The C++14 features that caused the problem were two:
- return type deduction for functions (using 'auto' as the return type)
- generic lambdas (using 'auto' to deduce argument types in a lambda expression)
The failing program that Ben was trying to debug was one of the tests in fhiclcpp: parse_document_test.cc, in particular the "bad_lookup" test case.
The newest XCode is: Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn). This came out of beta (as Adam noted above) more recently than the original report of failure. Marc and Ben each have done some very simple test of the new release that seem encouraging, but these tests are not sufficient for us to be sure the problem is solved in the new release.
Ben has agreed to take a look at the result of building the code with the new version of clang, and will report on the success or failure when he is able.
#8 Updated by Ben Morgan about 5 years ago
Just a quick update on this for the Stakeholders Meeting - since talking to Marc, I haven't had the time to perform the needed checks. I hope to do so within the next two-three weeks. There is a patch release to Xcode (6.3.1), but the LLVM/Clang version does not appear to have changed. Since the new 1.14 release of art is out, but the Clang tests are using 1.13.1:
I'll check everything with this first, then assuming things work, check with 1.14. Note that there is still a hard "no go" (I think) at present with Clang due to the use of gccxml for dictionary generation. At least, I was never able to get dictionaries generated or compiled with clang as gccxml's parser/compiler. That should resolve with support for Root6/rootcling dictionaries, but that's another issue.