mlir-{13/14} +universal (i386/x86_64): fatal error: error in backend: Unsupported expression in static initializer: zext (i32 ptrtoint ([7 x i8]* @.str.38 to i32) to i64)

[ryandesign (Ryan Carsten Schmidt)]

Cannot upgrade outdated ports because mlir-13 does not build:

:info:build [ 91%] Built target MLIRGPUOps
:info:build fatal error: error in backend: Unsupported expression in static initializer: zext (i32 ptrtoint ([7 x i8]* @.str.38 to i32) to i64)
:info:build clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
:info:build clang version 11.1.0
:info:build Target: i386-apple-darwin17.7.0
:info:build Thread model: posix
:info:build InstalledDir: /opt/local/libexec/llvm-11/bin
:info:build clang: note: diagnostic msg: Error generating preprocessed source(s) - cannot generate preprocessed source with multiple -arch options.

Update - Same thing affects mlir-14

[thetrial (alabay)]

It seems I have the same problem now with mlir-14 +universal. Looks like this happens only with the universal variant. There is no maintainer, nothing. What shall I, shall we do? mlir-14 and I think therefore clang-14 are stuck with El Capitan.

[kencu (Ken)]

mlir is only needed for flang I believe.

flang-14 is not needed for anything at present.

So…

[thetrial (alabay)]

I’m stuck …

--->  Computing dependencies for openal-soft
The following dependencies will be installed:
 clang-14
 mlir-14

clang-14 awaits it, ans clang-14 ist awaited by … so catch-22.

[kencu (Ken)]

that may be the way things are set up, but mlir is only needed to build flang, and flang is not needed for anything:

​https://github.com/llvm/llvm-project/blob/f6c79c6ae49f3a642bebe32a2346186c38bb83d7/llvm/CMakeLists.txt#L110

[kencu (Ken)]

of course, someone might best sort out what is wrong with the universal build of mlir and actually fix it, if possible.

[thetrial (alabay)]

So where to start? It seems, openal-soft starts that catch-22. It needs clang-14, this needs mlir-14. Both needed clang-11 that built yesterday the whole day on my laptop, just to be a leave later on (I know that from my desktop). And this, though clang-13 is onboard. These forced dependencies are hell.

So I might file a ticket for mlir-14 … but who’ll see that? I can’t assign it to anyone. Or shall I start with openal-soft and point to the dependency?

[thetrial (alabay)]

I’ve filed #65388, mentioning also all ports in the chain.

[kencu (Ken)]

[d6f8143777d33eb326230dcca97ae75a3e646c0f/macports-ports]

[jmroot (Joshua Root)]

That removed the dependency from clang, but this ticket is about mlir-13's universal variant not working; is that actually fixed?

[kencu (Ken)]

I took it to be that the op couldn’t upgrade his ports and now he can, but sure, this can trac the broken mlir build.

I suspect it likely is the i386 build is just broken, universal or not.

[cjones051073 (Chris Jones)]

Updated to track same issue in mlir-14

[cjones051073 (Chris Jones)]

b.t.w. I agree its likely just i386 is no longer supported.

Would be interesting to see if universal with x86_64 and arm works ...

[cjones051073 (Chris Jones)]

Its also a little odd to build the compiler itself universal, as the standard build already supports multiple platforms. i.e. this is what the regular llvm-14 build (on macOS12) supports

Oberon ~/Projects/MacPorts/ports > llc-mp-14 --version
LLVM (http://llvm.org/):
  LLVM version 14.0.6
  Optimized build.
  Default target: x86_64-apple-darwin21.5.0
  Host CPU: haswell

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    avr        - Atmel AVR Microcontroller
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    hexagon    - Hexagon
    lanai      - Lanai
    mips       - MIPS (32-bit big endian)
    mips64     - MIPS (64-bit big endian)
    mips64el   - MIPS (64-bit little endian)
    mipsel     - MIPS (32-bit little endian)
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc32le    - PowerPC 32 LE
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    ve         - VE
    wasm32     - WebAssembly 32-bit
    wasm64     - WebAssembly 64-bit
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore

Is there actually any advantage to building the compiler itself universal ?

[kencu (Ken)]

I thought of doing that a few years ago, but there are certain ports that use the llvm and clang libraries directly, and so universal is needed to support thst.

plus we get into trouble doing “fake unuversal” on some systems eg 10.6 or arm64/x86_64, where it actually must be real universal to work.

gcc builds are currently trying hard to change to “real universal” instead of “fake universal” for this reason.

[jmroot (Joshua Root)]

If mlir +universal won't work anywhere, setting universal_variant no is fine. If it just doesn't build for i386, that should be removed from supported_archs.

[jmroot (Joshua Root)]

Replying to kencu:

I took it to be that the op couldn’t upgrade his ports and now he can

That was the other ticket, with a different OP.

[thetrial (alabay)]

Yes, that was me :-) I haven’t been through this morning – with a Mac Pro 5 – compiling all that rat tail stuff. I’ll try port -b upgrade outdated …

[kencu (Ken)]

Replying to jmroot:

If mlir +universal won't work anywhere, setting universal_variant no is fine. If it just doesn't build for i386, that should be removed from supported_archs.

If you want to write it off, sure, that would do it.

I think the amount of effort so far expended in seeing if will still build i386 is basically zero though, so that might be premature. Fix could be trivial. Nobody official has said upstream doesn't support i386 any more that I am aware of. Up to you.

[jmroot (Joshua Root)]

Yes, of course if it can be fixed that's better.

[kencu (Ken)]

+1

[cjones051073 (Chris Jones)]

Now that mlir-X is only a dep of flang-X, which has limited use in current versions, the urgency to address this is low so indeed lets keep open until someone has time to investigate a bit.

[jmroot (Joshua Root)]

In df70d0f5151f4f33a3dadf03e061c97c69d73068/macports-ports (master):

mlir-1[3-5]: indicate that 32-bit build fails

See: #63734

[jmroot (Joshua Root)]

We now have successful mlir-16 builds on i386, but flang specifically refuses to build for 32-bit CPUs anyway.