This is an archive of the discontinued LLVM Phabricator instance.

Switch Clang's default C++ language target to C++14
ClosedPublic

Authored by t.p.northover on Dec 7 2017, 3:26 AM.

Details

Summary

Hi all,

So, I've finally managed to run all the tests I wanted and get this out for review. Sorry it's taken so long. This patch switches Clang's default C++ target to C++14 across all platforms and updates the test-suite to pass.

I've managed to test Linux, macOS and iOS on both the regression tests and the test-suite (minus externals on Linux because it's my home machine). There's a separate patch for the test-suite which I'll attach to a follow-up message here.

I think most of the test changes are pretty straightforward and fall into a few broad categories:

  • Changes to how the operands for "operator new" are promoted and otherwise wrangled in C++14. Slightly different CodeGen but essentially fine.
  • Some tests explicitly testing C++ mode differences left the C++98 line without a -std=... argument, I added it.
  • OpenMP CodeGen changes. As far as I can tell both are correct, but the tests are essentially unreadable so I gave up trying to adapt the output and just set it to C++98 mode.

I'm happy to rework anything people think needs changing.

Diff Detail

Repository
rC Clang

Event Timeline

t.p.northover created this revision.Dec 7 2017, 3:26 AM
Hahnfeld added a subscriber: Hahnfeld.
Hahnfeld added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
1732

This comment should be removed.

RKSimon added a subscriber: RKSimon.Dec 7 2017, 9:59 AM
probinson edited edge metadata.

+rjmccall for the codegen bits.

clang/test/SemaCXX/new-array-size-conv.cpp
1

I think the intent here was "whatever the current default is" and not specifically gnu++98, because the next line explicitly specifies c++98. So, unless this test fails miserably for C++14 (which I wouldn't expect) I think it should be adapted to whatever gets reported for that dialect.

bcain added a subscriber: bcain.Dec 7 2017, 12:49 PM
t.p.northover added inline comments.Dec 7 2017, 12:49 PM
clang/test/SemaCXX/new-array-size-conv.cpp
1

The original commit of this file (r107229 from Doug Gregor) called out the fact that what's being tested is a GNU and C++0x extension.

I think that implies that the 3 run lines really *should* test gnu++98, c++98 and c++11.

rsmith added inline comments.Dec 7 2017, 1:25 PM
clang/test/CodeGenCXX/new-overflow.cpp
88

The changes in this file are a regression; C++14 requires us to check whether the array bound prior to promotion is negative. Can you file a bug on that?

clang/test/CodeGenCXX/vtable-available-externally.cpp
1–2

Why does this one need a -std= flag?

clang/test/Parser/cxx1z-nested-namespace-definition.cpp
3–4

I think these two should also be -std=c++98, right?

clang/test/SemaCXX/unknown-type-name.cpp
98

Huh, we should probably have a -Wvexing-parse warning for this. Can you file a bug?

110–111

Maybe delete this (incorrect in C++14) FIXME?

Thanks Richard. I'll file the bugs tomorrow for the issues you suggest. Do you see either of them blocking the change to C++14 as a default? On a scale of "no", "no but I want a commitment to fix them" and "yes" sort of thing.

Tonight I've just got one comment that may or may not be useful context before I give you a proper answer tomorrow:

clang/test/CodeGenCXX/vtable-available-externally.cpp
1–2

It's a bit late here so I'll just give the proximal cause this evening in case that makes it obvious to you. I'll dig deeper tomorrow if not.

In this particular case (without the std flag) on the -O2 run line the "vtable for Test11::D" does not get marked "available_externally".

The diff on line 1 is definitely unneeded.

clang/test/Parser/cxx1z-nested-namespace-definition.cpp
3–4

Probably; I'll convince myself of that fact tomorrow.

clang/test/SemaCXX/unknown-type-name.cpp
110–111

Sounds sensible.

rsmith edited edge metadata.Dec 7 2017, 2:54 PM

Thanks Richard. I'll file the bugs tomorrow for the issues you suggest. Do you see either of them blocking the change to C++14 as a default? On a scale of "no", "no but I want a commitment to fix them" and "yes" sort of thing.

I don't think these should block the change of default. The new-expression one is actually a missing C++14 feature -- we're supposed to be generating a call to a new ABI entry point in the negative-array-bound case to throw a std::bad_array_new_length (we missed it because it's a feature added by a core issue rather than by a paper as I recall). I see no problem with shipping a Clang 6 that doesn't implement the full feature, including throwing the new exception. I'm not entirely happy about shipping Clang 6 without fixing the negative-bound check, since that means we'll generate code that is less hardened against certain common attacks by default, but I don't think I would be release-blocker-level unhappy.

clang/test/CodeGenCXX/vtable-available-externally.cpp
1–2

See comment below.

275

To make this test work in C++11 onwards, you need to add a virtual move assignment operator here:

virtual D& operator=(D&&);

Updating with tentative fixes to review comments.

t.p.northover added inline comments.Dec 8 2017, 6:06 AM
clang/test/CodeGenCXX/new-overflow.cpp
88

I've filed https://llvm.org/PR35573. Not quite sure what to do about this test until it's fixed though. Add a second RUN line to check both variants and then XFAIL it?

clang/test/CodeGenCXX/vtable-available-externally.cpp
275

That didn't quite work. The issue appears to be that D has both of those implicitly defined in C++14 mode, but only the move assignment operator is used below. Speculative VTable emission requires all of them to be used.

So adding a "d = d;" line to the second g function fixes the test. Does that sound sane to you, or am I missing the point?

clang/test/SemaCXX/unknown-type-name.cpp
98

I've filed https://llvm.org/PR35576. You may want to sanity check it though, I was pretty light on the detail because I wasn't sure of the exact diagnostic being proposed.

filcab added a subscriber: filcab.Dec 8 2017, 7:00 AM
filcab added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
1733

Why are you changing the PS4 default too?

t.p.northover added inline comments.Dec 8 2017, 7:43 AM
clang/lib/Frontend/CompilerInvocation.cpp
1733

Paul Robinson indicated that it was feasible back in March: http://lists.llvm.org/pipermail/cfe-dev/2017-March/052986.html. If that's changed I'd be happy to put it back to C++11, but he's one of the main people (rightly) bugging me about this so I'd be slightly surprised.

I also notice the comment crept back in. Bother.

filcab added inline comments.Dec 8 2017, 10:03 AM
clang/lib/Frontend/CompilerInvocation.cpp
1733

Sounds good, then. If Paul is happy with that change, I don't see a problem there (assuming you do get rid of the comment for good :-) ).

Thank you,

Filipe

probinson added inline comments.Dec 8 2017, 12:23 PM
clang/lib/Frontend/CompilerInvocation.cpp
1733

Yes, PS4 product management is happy to move forward.

rsmith accepted this revision.Dec 8 2017, 1:13 PM

LGTM with the PS4 comment removed. Thank you!

Please also update the documentation and the release notes.

clang/test/CodeGenCXX/vtable-available-externally.cpp
275

This sounds like a good approach, thanks.

This revision is now accepted and ready to land.Dec 8 2017, 1:13 PM

Thanks Richard, and all other reviewers. I committed this as r320250, with a couple of sanitizer test fixes as r320251 and r320284 (thanks Ahmed!).