Summary: | devel/libslang2 crash during build | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Mikhail Teterin <mi> | ||||
Component: | Individual Port(s) | Assignee: | Renato Botelho <garga> | ||||
Status: | Closed Unable to Reproduce | ||||||
Severity: | Affects Only Me | CC: | dim, mi | ||||
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(garga) |
||||
Version: | Latest | ||||||
Hardware: | i386 | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Mikhail Teterin
![]() ![]() > Quite possibly, a problem with the base (compiler), rather than the compiler
Duh, rather than the *port* is what I meant, of course.
For the record:
1. The port's options are:
_OPTIONS_READ=libslang2-2.3.0
_FILE_COMPLETE_OPTIONS_LIST=DOCS ICONV ONIG PCRE PNG
OPTIONS_FILE_UNSET+=DOCS
OPTIONS_FILE_SET+=ICONV
OPTIONS_FILE_UNSET+=ONIG
OPTIONS_FILE_SET+=PCRE
OPTIONS_FILE_SET+=PNG
2. The port built fine with CC=clang60
This seems to be fixed by https://reviews.llvm.org/rL211155, which landed first in clang 3.5. I'm not sure if it makes sense to backport this fix to stable/10, since it is very unlikely any other releases are coming out, and packages will build against the last release. Probably building with clang40 or higher should be enough to work around this. (In reply to Dimitry Andric from comment #2) > I'm not sure if it makes sense to backport this fix to stable/10 Making stable more stable? Of course, it makes sense... > packages will build against the last release. So long as we keep publishing stable-10, I think, we ought to be fixing known problems. > Probably building with clang40 or higher should be enough to work around this. Yes, as I say in Comment #1, clang60 had no problem. Still, the base compiler ought to work too... A commit references this bug: Author: dim Date: Tue Jul 17 21:10:31 UTC 2018 New revision: 336429 URL: https://svnweb.freebsd.org/changeset/base/336429 Log: Pull in r211155 from upstream llvm trunk (by Tim Northover): DAG: move sret demotion into most basic LowerCallTo implementation. It looks like there are two versions of LowerCallTo here: the SelectionDAGBuilder one is designed to operate on LLVM IR, and the TargetLowering one in the case where everything is at DAG level. Previously, only the SelectionDAGBuilder variant could handle demoting an impossible return to sret semantics (before delegating to the TargetLowering version), but this functionality is also useful for certain libcalls (e.g. 128-bit operations on 32-bit x86). So this commit moves the sret handling down a level. rdar://problem/17242889 This should fix "Call result #3 has unhandled type i32" errors when building devel/libslang2 for i386. Direct commit to stable/10, since clang 3.5 and later already have this change. Reported by: mi PR: 229754 Changes: stable/10/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp Mikhail, can you please verify that it works for you after r336429? I couldn't reproduce it on a recent stable/10. If you can, please let me know and we re-open this issue |