Re: llvm10 build failure on Rpi3
- Reply: Mark Millard via freebsd-ports : "Re: llvm10 build failure on Rpi3"
- In reply to: bob prohaska : "Re: llvm10 build failure on Rpi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 26 Jun 2021 04:41:43 UTC
On 2021-Jun-25, at 20:52, bob prohaska <fbsd at www.zefox.net> wrote: > On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote: > [huge snip, hope the quotes are still correct] >>> So I'm going to suggest using an official kernel build >>> as built by the ci.freebsd.org systems, one that is not >>> GENERIC-MMCCAM. In: >>> > > World and kernel are updating now to -current as of yesterday. > I'll replace GENERIC-MMCCAM with GENERIC for simplicity. I still strongly recommend doing some testing of official builds instead of your personal builds. That includes kernel and world, if possible. Until an official build shows the problem, you are not as likely to get the problem worked on. (And, so far, you have the only known context for getting the problem.) >>> >>> I gather that no RPi4B is available to move the media >>> to? (Having more RAM but being able to force much of >>> it to be ignored can be handy as a test environment >>> for this kind of context.) >>> > > It's still patiently chewing away at www/chromium single-threaded. Note that system-clang just got updates for stable/11 stable/12 stable/13 and main for a defect that prevents building www/chromium with a clang that has assertions enabled (a form of debug build contribution): The branch main has been updated by dim: URL: https://cgit.FreeBSD.org/src/commit/?id=e7e517981a6591c79fb49cd8810361b0f3ad5983 commit e7e517981a6591c79fb49cd8810361b0f3ad5983 Author: Dimitry Andric <dim at FreeBSD.org> AuthorDate: 2021-06-21 18:46:34 +0000 Commit: Dimitry Andric <dim at FreeBSD.org> CommitDate: 2021-06-21 18:48:37 +0000 Fix clang assertion while building recent www/chromium Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): [clang] Don't assert in EmitAggregateCopy on trivial_abi types Fixes PR42961. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D97872 PR: 256721, 255570 Reported by: jbeich MFC after: 3 days --- contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp index 60ea1b2af037..f3ab91559d30 100644 --- a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp +++ b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp @@ -2056,7 +2056,7 @@ void CodeGenFunction::EmitAggregateCopy(LValue Dest, LValue Src, QualType Ty, Record->hasTrivialCopyAssignment() || Record->hasTrivialMoveConstructor() || Record->hasTrivialMoveAssignment() || - Record->isUnion()) && + Record->hasAttr<TrivialABIAttr>() || Record->isUnion()) && "Trying to aggregate-copy a type without a trivial copy/move " "constructor or assignment operator"); // Ignore empty classes in C++. > My mistake, but best to finish what's started.. Now that how to > use the packages created is known they can be tested. > >> >> So: no warning about being mis-tuned vs. the 1 GiByte of >> used RAM. (I do not know about your context for this.) >> > > My Pi3 does report too much swap. But I remain uncertain about > the practical significance of the warning. I gather the issue > is that a certain amount memory is set aside to "index", for > lack of a better word, the data stored in swap. If there's too > much swap relative to index, not all swap can be used. That > seems not much different than running out of swap. You are having problems that are hard to issolate and are also effectively asserting this warning does not indicate an issue that is contributing. If it were me, I'd be trying to find out if the failure can be reproduced when the FreeBSD test involved classifies that no warning is appropriate. >> All the ports that devel/llvm10 needs are already in place >> for poudriere's use for this experiment. I should have mentioned that I have not added any junk:??? controls. And my building in a releng/13 context means that 0xA5A5A5A5u would not be happening on allocation. Stronger: the build context uses my typical forced MALLOC_PRODUCTION style of build. >> Another point is: >> >> # more /usr/local/etc/poudriere.d/options/devel_llvm10/options >> # This file is auto-generated by 'make config'. >> # Options for llvm10-10.0.1_3 >> _OPTIONS_READ=llvm10-10.0.1_3 >> _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD >> OPTIONS_FILE_SET+=BE_AMDGPU >> OPTIONS_FILE_SET+=CLANG >> OPTIONS_FILE_SET+=DOCS >> OPTIONS_FILE_SET+=EXTRAS >> OPTIONS_FILE_SET+=LIT >> OPTIONS_FILE_SET+=LLD >> OPTIONS_FILE_SET+=LLDB >> OPTIONS_FILE_SET+=LLD_LINK >> OPTIONS_FILE_SET+=OPENMP >> OPTIONS_FILE_UNSET+=PYCLANG >> OPTIONS_FILE_UNSET+=BE_FREEBSD >> OPTIONS_FILE_SET+=BE_NATIVE >> OPTIONS_FILE_UNSET+=BE_STANDARD >> >> (So I normally build less than BE_STANDARD or >> BE_FREEBSD would build.) > > I'm my own worst enemy when it comes to customization. > The less changed the better 8-) Unless it avoids a problem? (I do it to avoid wasted time.) I'm not claiming it would avoid the problem, but it is one of the things that could be tried to see what happens. >> We will see if this is enough common context to >> replicate the general type of build problem. >> (Your details very from one attempt to the next >> so an exact match need not be expected, even if >> if this does also fail.) >> > > If you replicate the problem I'll be very pleased. > And just slightly relieved. > > My suspcions still center around things I might have > done to corrupt /usr/local/poudriere. Poudriere is not involved in initializing memory for llvm-tblgen's internal memory use. It could be that jails more generally have a problem, not just poudriere ones. But that would be a FreeBSD issue, not a poudriere one. > That leaves > me wondering how to proceed after world, kernel and ports > are updated. Delete /usr/local/poudriere (which would toss > the packages created so far), delete only the jail (not > sure if that'll delete existing packages library) or > something more selective that I don't know about? I see no likely gain from going down this path. Blaming poudriere for lack of memory initialization in llvm-tblgen makes no sense to me at all: poudriere is not involved in that memory allocation or what the bytes are set to before llvm-tblgen get the address of the memory. > The Pi3B is purely experimental, but I'd rather not throw > away usable progress given the extreme slowness of that > progress. > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)