Summary: | sys-devel/llvm-5.0.2 invalid C++ code (detected by gcc-8.1.0) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Helmut Jarausch <jarausch> |
Component: | Current packages | Assignee: | LLVM support project <llvm> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chaneybenjamini, jstein, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=654766 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build log xz-compressed
patches.tar.bz2 Patch to resolve issue for llvm:5 |
Did you happen to test 6.0.0? (In reply to Michał Górny from comment #1) > Did you happen to test 6.0.0? I have no such problems with version 6.0.0-r1, but some packages depend on llvm:5 Thanks, Helmut Yeah, I was just wondering if it boils down to backporting something between the two versions. Created attachment 530358 [details]
patches.tar.bz2
Could you please try with the attached patches? I don't have hardware to build gcc8 at the moment.
(In reply to Michał Górny from comment #4) > Created attachment 530358 [details] > patches.tar.bz2 > > Could you please try with the attached patches? I don't have hardware to > build gcc8 at the moment. Yes, thanks, it compiles fine under gcc-8.1.0 Sadly, that includes some API changes, so I don't think I can backport that. I'm afraid I'll have to wait till someone writes a minimal patch for it. I'd look here. https://bugzilla.redhat.com/show_bug.cgi?id=1540620 in case it may be beneficial for others; see https://github.com/prototype99/prototype99 for an llvm ebuild containing the relevant patches that may be installed using layman. i was a little unsure on the versioning, so feel free to open an issue on it if it is incorrect. Created attachment 538578 [details, diff]
Patch to resolve issue for llvm:5
This patch taken from redhat's upstream lets llvm-5.0.2 build with gcc-8 on my machine
(In reply to Ben Chaney from comment #9) > Created attachment 538578 [details, diff] [details, diff] > Patch to resolve issue for llvm:5 > > This patch taken from redhat's upstream lets llvm-5.0.2 build with gcc-8 on > my machine Do I understand correctly that only this one patch is necessary? (In reply to Michał Górny from comment #10) > (In reply to Ben Chaney from comment #9) > > Created attachment 538578 [details, diff] [details, diff] [details, diff] > > Patch to resolve issue for llvm:5 > > > > This patch taken from redhat's upstream lets llvm-5.0.2 build with gcc-8 on > > my machine > > Do I understand correctly that only this one patch is necessary? That is correct. The patch also enabled llvm-4.0.1-r1 to compile without modification. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2deb2d52d186165bf0d2d45405438e91f6a9a6de commit 2deb2d52d186165bf0d2d45405438e91f6a9a6de Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-07-07 07:27:18 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-07-07 07:38:10 +0000 sys-devel/llvm: Patch gcc-8 compatibility in <6 Thanks to Ben Chaney for providing the patch. Closes: https://bugs.gentoo.org/655140 ...turn-type-in-ORC-readMem-client-interface.patch | 31 ++++++++++++++++++++++ sys-devel/llvm/llvm-4.0.1-r1.ebuild | 3 +++ sys-devel/llvm/llvm-5.0.2.ebuild | 3 +++ 3 files changed, 37 insertions(+) |
Created attachment 530300 [details] build log xz-compressed gcc-8.1.0 is more rigorous about type checking. It bails out with /include/llvm/ExecutionEngine/Orc/OrcRemoteTargetClient.h: In member function 'llvm::Expected<std::vector<char> > llvm::orc::remote::OrcRemoteTargetClient<ChannelT>::readMem(char*, llvm::JITTargetAddress, uint64_t)': include/llvm/ExecutionEngine/Orc/OrcRemoteTargetClient.h:722:26: error: could not convert '((llvm::orc::remote::OrcRemoteTargetClient<ChannelT>*)this)->callB<llvm::orc::remote::OrcRemoteTargetRPCAPI::ReadMem>(Src, Size)' from 'Expected<vector<unsigned char,allocator<unsigned char>>>' to 'Expected<vector<char,allocator<char>>>' return callB<ReadMem>(Src, Size);