Bug 1540620 - llvm5.0 package fails to build with gcc 8
Summary: llvm5.0 package fails to build with gcc 8
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm5.0
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tom Stellard
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-01-31 14:35 UTC by Tom Stellard
Modified: 2018-03-10 00:48 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-02-02 01:31:56 UTC
Type: Bug

Attachments (Terms of Use)
Patch which fixes the compilation error. (1.27 KB, patch)
2018-02-01 18:35 UTC, Tilmann Scheller
no flags Details | Diff

Description Tom Stellard 2018-01-31 14:35:03 UTC
Description of problem:
llvm5.0 package fails to build with gcc 8.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. fedpkg clone llvm5.0
2. cd llvm5.0 && fedpkg scratch-build

Actual results:

Build fails with error:
{standard input}: Assembler messages:
{standard input}: Error: .size expression for lli.cpp does not evaluate to a constant

Expected results:
Package builds successfully.

Comment 1 Marek Polacek 2018-01-31 14:37:31 UTC
This error doesn't seem to be the real culprit.  Does the log file say something about
error: cannot convert ... to ... in return

Comment 2 Tom Stellard 2018-01-31 14:48:10 UTC
I don't see that error in the scratch build on koji, but when I do a local build, I get:

In file included from ../tools/lli/lli.cpp:30:
../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:36: 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);

Comment 3 Marek Polacek 2018-01-31 14:51:06 UTC
Ok, that's likely
which wouldn't be a GCC bug.  Would be nice to have a preprocessed source file to verify.

Comment 4 Tilmann Scheller 2018-02-01 18:35:53 UTC
Created attachment 1389687 [details]
Patch which fixes the compilation error.

This looks indeed quite similar to

Does not reproduce with LLVM trunk (r323878) or with the LLVM 6.0 release
candidate when compiling with GCC 8.0.1. Looks like this was fixed upstream as
part of a refactoring in September 2017 (r312500).

Attaching a trivial patch which fixes the type mismatch. Verified that it fixes the Mock build of the llvm5.0 package.

Comment 5 Tom Stellard 2018-02-02 01:31:56 UTC
Fixed in llvm5.0-5.0.1-3.fc28.

Comment 6 Adam Williamson 2018-03-10 00:48:36 UTC
Note, llvm 4.0 actually had the same issue. I'll try using the same patch.

Note You need to log in before you can comment on or make changes to this bug.