Bug 256948 - devel/llvm10 compiles with make but not with poudriere on RPI3
Summary: devel/llvm10 compiles with make but not with poudriere on RPI3
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm64 Any
: --- Affects Only Me
Assignee: Brooks Davis
Depends on:
Reported: 2021-07-02 22:40 UTC by Bob Prohaska
Modified: 2021-08-11 22:23 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (brooks)


Note You need to log in before you can comment on or make changes to this bug.
Description Bob Prohaska 2021-07-02 22:40:11 UTC
A Raspberry Pi3 running -current builds devel/llvm10 successfully using make in
the ports tree but attempts to use poudriere fail:

> In file included from
> lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11138:50: error: expected expression
>        /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, /*RC*//*AMDGPU::SReg_64RegClassID:
>                                                 ^
> lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11138:118: error: expected expression
>        /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, /*RC*//*AMDGPU::SReg_64RegClassID:
> lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11237:48: error: expected expression
>      /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, /*RC*//*AMDGPU::VGPR_32RegClassID:
>                                               ^
> lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11237:116: error: expected expression
>      /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, /*RC*//*AMDGPU::VGPR_32RegClassID:

The Pi is running -current, main-n247590-5dd84e315a9: Sat Jun 26 10:09:51 PDT 2021
Comment 1 Mark Millard 2021-07-03 00:47:41 UTC
I will note that 2779096485 == 0xA5A5A5A5u and when junk:false
is set in /etc/malloc.conf , the value changes to 0 instead.

Bob should describe more of his poudriere configuration, such as
things controlling how many cores are active and how memory use
tradeoffs are made. Or he should references to the appropriate
list messages that have such information.

My attempt to partially simulate Bob's environment failed to
reproduce the problem.

Bob has not reported trying some of the types of tests that I've
suggested, such as having kernel and world be from an official
artifacts (or snapshot) build instead of his personal buildworld
buildkernel results.

So far this has been and looks to be messy to investigate.
Comment 2 Mark Millard 2021-07-03 01:49:01 UTC
(In reply to Bob Prohaska from comment #0)

For folks that may try to replicate the issue,
it would be appropriate to be explicit about the
RPi3B variant in use and other such context
details, such as spinning rust being in use
and file systems in use and the like.

I say this in part because of my failed attempts
at replication via partial matching of some
aspects Bob's context. For example, I imposed a
1 GiByte RAM size via total_mem=1024 in config.txt
on the RPi4B that I used for some of my attempts.
(Not that it is known what all is actually
Comment 3 Mark Millard 2021-07-03 01:53:41 UTC
(In reply to Bob Prohaska from comment #0)

I'll note that the *.inc files are outputs from llvm-tblgen
so it is the llvm-tblgen results that are odd, something
only later noticed when the files are put to use.
Comment 4 Mark Millard 2021-07-03 03:08:57 UTC
(In reply to Bob Prohaska from comment #0)

I'll note that the files with the failures can
vary from build attempt to build attempt. The
following are from a sequence of 8 builds. Note
that *GenGlobalISel.inc is always the case but
the match to the * varies. (Mips does repeat once
in the this particular subrange of builds.)
which llvm-tblgen run(s) generate the problem
files varies.

lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11769:39: error: expected expression
lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:11769:98: error: expected expression
2 errors generated.

lib/Target/RISCV/RISCVGenGlobalISel.inc:6049:41: error: expected expression
lib/Target/RISCV/RISCVGenGlobalISel.inc:6049:95: error: expected expression
2 errors generated.

lib/Target/X86/X86GenGlobalISel.inc:3035:50: error: expected expression
lib/Target/X86/X86GenGlobalISel.inc:3035:112: error: expected expression
lib/Target/X86/X86GenGlobalISel.inc:3370:50: error: expected expression
lib/Target/X86/X86GenGlobalISel.inc:3370:112: error: expected expression
4 errors generated.

lib/Target/Mips/MipsGenGlobalISel.inc:19214:48: error: expected expression
lib/Target/Mips/MipsGenGlobalISel.inc:19214:112: error: expected expression
4 errors generated.

lib/Target/ARM/ARMGenGlobalISel.inc:28417:41: error: expected expression
lib/Target/ARM/ARMGenGlobalISel.inc:28417:94: error: expected expression
2 errors generated.

lib/Target/Mips/MipsGenGlobalISel.inc:20078:48: error: expected expression
lib/Target/Mips/MipsGenGlobalISel.inc:20078:112: error: expected expression
2 errors generated.

lib/Target/AArch64/AArch64GenGlobalISel.inc:20390:41: error: expected expression
lib/Target/AArch64/AArch64GenGlobalISel.inc:20390:99: error: expected expression
2 errors generated.
Comment 5 Mark Millard 2021-07-03 03:10:06 UTC
(In reply to Mark Millard from comment #4)

A subrange spanning 7 builds, not 8. (Typo, sorry.)
Comment 6 Mark Millard 2021-07-05 19:48:44 UTC
My understanding is that this was solved by having
/usr/local/poudriere/poudriere-system updated to match
the /usr/src that was in use for the jail that had
been created with:

poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT

Worded differently: The /usr/src was tracking the
boot context updates but the world install in
/usr/local/poudriere/poudriere-system was not.)

In other words: operator error --so it should be closed
as not-a-bug.

Side note:
My own mistaken report about the mismatched status
contributed to there not being updates to
/usr/local/poudriere/poudriere-system : I gave Bob
bad advice when I first noticed the mismatch.