I confirm the bug has been fixed in trunk gcc and in fedora rawhide's gcc, closing the issue.
Fri, Mar 15
Wed, Mar 6
I'd rather have it here than in lit. As a test environment, I love it when there's as few environment values that depends on the launch site as possible. It makes reproducibility easier.
LGTM, do you have commit rights?
Thu, Feb 28
Tue, Feb 26
@jmittert sorry for the long delay, but I'm finally fine with this patch now. I like how it explicitly emphasizes on the Windows/Linux difference. However the patch needs to be rebased against master, can you update it?
I've reported this strange behavior to gcc https://bugzilla.redhat.com/show_bug.cgi?id=1678613
@sylvestre.ledru up :-)
Mon, Feb 25
@sgraenitz It's fixed! I'm dropping this patch then, thanks for investigating o/
Wed, Feb 20
@sgraenitz : it's possible that r352382 fixes my issue. I'll double check that first!
@hans agreed; Thanks for taking the time to try to reproduce the original issue o/
Tue, Feb 19
Fedora is currently using gcc-9.0.1, svn revision 268719 (see https://src.fedoraproject.org/rpms/gcc/blob/master/f/gcc.spec) which triggers this issue. I'll forward the test case to the gcc team and report here.
Mon, Feb 18
Some follow-up on this review: I had to revert the associated commit because it was breaking on buildbot, on test case I failed to reproduce locally.
There should be an rvalue overload of std::vector<T>::push_back - is there not? ( https://en.cppreference.com/w/cpp/container/vector/push_back )
@sgraenitz I currently have this patch applied to LLVM 8rc1 source tree for fedora, because it wasn't working automagically otherwise. Reading the discussion, I don't think I missed some configuration stuff, or what did I miss when configuring the build of lldb in standalone mode?
Sun, Feb 17
Yeah, especially as he copy constructor is deleted, push_back implies a copy, so relying on the compiler to optimize to a move seems fragile.
Feb 16 2019
Feb 15 2019
Feb 14 2019
Feb 13 2019
Feb 12 2019
Feb 11 2019
@MarcoFalke it's in, thanks for the patch o/
LGTM, do you have commit right?
Feb 9 2019
@chandlerc patch updated, using inheritance to avoid too much duplication.
Feb 8 2019
@jmittert I tried the following (simpler) patch on Linux and it seems to work nice for both Python2 and Python3
@chandlerc there's indeed some redundancy that can be removed unfortunately, as you feared, defaulting seems incompatible with per-member specialization, or at least it hits my c++ knowledge limit.
Feb 5 2019
@andrew-boyarshin : It's in! Thanks for the contribution o/
@andrew-boyarshin do you have commit right?
Jan 31 2019
It's in, thanks @rsmith for the review.
Jan 30 2019
Patch updated to take into account @rsmith remarks. Test case added as an illustration.
Jan 28 2019
Jan 24 2019
Also validates ok with clang 6.0.1 and gcc 4.8.5
@ruiu It works fine, I just moved the comdat-related insertion after the flag check. It compiles and validates fine on my setup.
Thanks @roxma for the patch!
Jan 23 2019
This validates with gcc 8.2. Given the history of llvm::Optional, I'm going to try to build with other compilers too.
@ruiu is this minimal patch ok to you?
Jan 22 2019
@uabelho top-of-tree should be fine now.
@roxma: do you want me to commit this on your behalf?
@Wallbraker if you don't have commit rights I can commit this one for you.
Yeah, I do a final test round and I'll push that one. It's a very touchy piece of code, so I don't want to make all builders fail again...
Slightly cleaner implementation, added comments and tested with polly.
Jan 21 2019
A few comments missing but I'd like to know if this now works correctly on gcc 4.9, @fedor.sergeev , @Anastasia and @sylvestre.ledru . I successfully passed test on a dedicated setup so I guess it's ok...
Patch to be tested available on https://reviews.llvm.org/D57018
https://godbolt.org/z/KaJ2is seems to be aportable implementaiton of `std::is_copy_assignable`. I'm investigating that.
Yeah, I knew from the start that compiling with gcc 8 and clang 6 was not enough for my tests. I've already fixed a few issues with gcc 6, let me try to move forward.
Jan 18 2019
@rsmith thanks a lot for the final review. I rebased the patch, did a final check with both GCC and Clang, and everything looks fine now. Waiting for a green light!
Jan 17 2019
For some reason, all the specialization were not required, so we end up with a very clean implementation. Thanks a lot @rsmith for pointing that out!
Jan 16 2019
Partial support of SHT_GROUP without flag