When building for AVR error: Alias and aliasee types don't match (Producer: 'zig 0.17.0' Reader: 'LLVM 21.1.8') #32108

kaasboteram commented 2026年04月28日 16:32:52 +02:00

Zig Version

0.17.0-dev.76+ff612334f

Steps to Reproduce and Observed Behavior

Write a repro.zig with any code:

exportfnanything()void{}

Compile to any target with the AVR architecture:

zig build-obj repro.zig -target avr-freestanding-none

Output:

error: Alias and aliasee types don't match (Producer: 'zig 0.17.0' Reader: 'LLVM 21.1.8')

Expected Behavior

The code compiles successfully.

### Zig Version 0.17.0-dev.76+ff612334f ### Steps to Reproduce and Observed Behavior Write a `repro.zig` with any code: ```zig export fn anything() void {} ``` Compile to any target with the AVR architecture: ```sh zig build-obj repro.zig -target avr-freestanding-none ``` Output: ``` error: Alias and aliasee types don't match (Producer: 'zig 0.17.0' Reader: 'LLVM 21.1.8') ``` ### Expected Behavior The code compiles successfully.

nektro commented 2026年04月28日 21:02:57 +02:00

for posterity llvm 22 switch happened at 0.17.0-dev.209+a83aad152, if that may be relevant

for posterity llvm 22 switch happened at 0.17.0-dev.209+a83aad152, if that may be relevant

mattnite commented 2026年05月31日 08:14:11 +02:00

I started looking into this issue. Working off of 7d7752ed411222276ccdbf6b45b21edddbc05caa. I'm able to reproduce on LLVM 22.1.4, and I found exactly one location where Alias and aliasee types don't match is located in LLVM, llvm/lib/Bitcode/Reader/BitcodeReader.cpp:3177:

 while (!IndirectSymbolInitWorklist.empty()) {
 unsigned ValID = IndirectSymbolInitWorklist.back().second;
 if (ValID >= ValueList.size()) {
 IndirectSymbolInits.push_back(IndirectSymbolInitWorklist.back());
 } else {
 Expected<Constant *> MaybeC = getValueForInitializer(ValID);
 if (!MaybeC)
 return MaybeC.takeError();
 Constant *C = MaybeC.get();
 GlobalValue *GV = IndirectSymbolInitWorklist.back().first;
 if (auto *GA = dyn_cast<GlobalAlias>(GV)) {
 if (C->getType() != GV->getType()) {
 return error("Alias and aliasee types don't match"); // <-- HERE
 }
 GA->setAliasee(C);
 } else if (auto *GI = dyn_cast<GlobalIFunc>(GV)) {
 GI->setResolver(C);
 } else {
 return error("Expected an alias or an ifunc");
 }
 }
 IndirectSymbolInitWorklist.pop_back();
 }

I added an assert right before the error is returned, lldb gives me this backtrace:

 * frame #0: 0x00007ffff7d6795c libc.so.6`___lldb_unnamed_symbol3701 + 268
 frame #1: 0x00007ffff7d12cc2 libc.so.6`raise + 18
 frame #2: 0x00007ffff7cfb4ac libc.so.6`abort + 34
 frame #3: 0x00007ffff7cfb420 libc.so.6`___lldb_unnamed_symbol3180 + 18
 frame #4: 0x00000000141e70ac zig`(anonymous namespace)::BitcodeReader::resolveGlobalAndIndirectSymbolInits() (.cold) + 124
 frame #5: 0x00000000141f55ec zig`(anonymous namespace)::BitcodeReader::parseModule(unsigned long, bool, llvm::ParserCallbacks) + 4012
 frame #6: 0x0000000014206f17 zig`llvm::BitcodeModule::getModuleImpl(llvm::LLVMContext&, bool, bool, bool, llvm::ParserCallbacks) (.localalias) + 5959
 frame #7: 0x00000000142082fd zig`llvm::parseBitcodeFile(llvm::MemoryBufferRef, llvm::LLVMContext&, llvm::ParserCallbacks) + 653
 frame #8: 0x00000000141c5a9a zig`LLVMParseBitcodeInContext2.localalias + 106
 frame #9: 0x0000000007ecb20c zig`codegen.llvm.Object.emit + 20284
 frame #10: 0x0000000007eab354 zig`Compilation.flush + 5716
 frame #11: 0x0000000007ea6d2c zig`Compilation.update + 25676
 frame #12: 0x0000000007d972fc zig`main.updateModule + 76
 frame #13: 0x0000000007440d32 zig`main.buildOutputType + 129458
 frame #14: 0x0000000007492839 zig`main.mainArgs + 2025
 frame #15: 0x00000000073e5e6a zig`main.main + 1258
 frame #16: 0x00000000073e410a zig`start.main + 1098
 frame #17: 0x00007ffff7cfcca8 libc.so.6`___lldb_unnamed_symbol3282 + 120
 frame #18: 0x00007ffff7cfcd65 libc.so.6`__libc_start_main + 133
 frame #19: 0x000000000be67421 zig`_start + 33

Going to bed now, will pick this back up tomorrow.

I started looking into this issue. Working off of `7d7752ed411222276ccdbf6b45b21edddbc05caa`. I'm able to reproduce on LLVM 22.1.4, and I found exactly one location where `Alias and aliasee types don't match` is located in LLVM, `llvm/lib/Bitcode/Reader/BitcodeReader.cpp:3177`: ```cpp while (!IndirectSymbolInitWorklist.empty()) { unsigned ValID = IndirectSymbolInitWorklist.back().second; if (ValID >= ValueList.size()) { IndirectSymbolInits.push_back(IndirectSymbolInitWorklist.back()); } else { Expected<Constant *> MaybeC = getValueForInitializer(ValID); if (!MaybeC) return MaybeC.takeError(); Constant *C = MaybeC.get(); GlobalValue *GV = IndirectSymbolInitWorklist.back().first; if (auto *GA = dyn_cast<GlobalAlias>(GV)) { if (C->getType() != GV->getType()) { return error("Alias and aliasee types don't match"); // <-- HERE } GA->setAliasee(C); } else if (auto *GI = dyn_cast<GlobalIFunc>(GV)) { GI->setResolver(C); } else { return error("Expected an alias or an ifunc"); } } IndirectSymbolInitWorklist.pop_back(); } ``` I added an assert right before the error is returned, lldb gives me this backtrace: ``` * frame #0: 0x00007ffff7d6795c libc.so.6`___lldb_unnamed_symbol3701 + 268 frame #1: 0x00007ffff7d12cc2 libc.so.6`raise + 18 frame #2: 0x00007ffff7cfb4ac libc.so.6`abort + 34 frame #3: 0x00007ffff7cfb420 libc.so.6`___lldb_unnamed_symbol3180 + 18 frame #4: 0x00000000141e70ac zig`(anonymous namespace)::BitcodeReader::resolveGlobalAndIndirectSymbolInits() (.cold) + 124 frame #5: 0x00000000141f55ec zig`(anonymous namespace)::BitcodeReader::parseModule(unsigned long, bool, llvm::ParserCallbacks) + 4012 frame #6: 0x0000000014206f17 zig`llvm::BitcodeModule::getModuleImpl(llvm::LLVMContext&, bool, bool, bool, llvm::ParserCallbacks) (.localalias) + 5959 frame #7: 0x00000000142082fd zig`llvm::parseBitcodeFile(llvm::MemoryBufferRef, llvm::LLVMContext&, llvm::ParserCallbacks) + 653 frame #8: 0x00000000141c5a9a zig`LLVMParseBitcodeInContext2.localalias + 106 frame #9: 0x0000000007ecb20c zig`codegen.llvm.Object.emit + 20284 frame #10: 0x0000000007eab354 zig`Compilation.flush + 5716 frame #11: 0x0000000007ea6d2c zig`Compilation.update + 25676 frame #12: 0x0000000007d972fc zig`main.updateModule + 76 frame #13: 0x0000000007440d32 zig`main.buildOutputType + 129458 frame #14: 0x0000000007492839 zig`main.mainArgs + 2025 frame #15: 0x00000000073e5e6a zig`main.main + 1258 frame #16: 0x00000000073e410a zig`start.main + 1098 frame #17: 0x00007ffff7cfcca8 libc.so.6`___lldb_unnamed_symbol3282 + 120 frame #18: 0x00007ffff7cfcd65 libc.so.6`__libc_start_main + 133 frame #19: 0x000000000be67421 zig`_start + 33 ``` Going to bed now, will pick this back up tomorrow.

mattnite commented 2026年06月01日 01:19:40 +02:00

Here is a dump of the buffer in parseBitcodeFile()

Here is a dump of the buffer in `parseBitcodeFile()`

aerphanas commented 2026年06月22日 04:12:27 +02:00

i able to compile with Zig version 0.15.2

~/Projects/intra/zigavr/test $ ls
~/Projects/intra/zigavr/test $ echo "export fn anything() void {}" > repro.zig
~/Projects/intra/zigavr/test $ ~/Projects/archive/Zig/zig-x86_64-linux-0.16.0/zig build-obj repro.zig -target avr-freestanding-none
error: Alias and aliasee types don't match (Producer: 'zig 0.16.0' Reader: 'LLVM 21.1.0')
~/Projects/intra/zigavr/test $ ~/Projects/archive/Zig/zig-x86_64-linux-0.15.2/zig build-obj repro.zig -target avr-freestanding-none
~/Projects/intra/zigavr/test $ ls
repro.o repro.zig
~/Projects/intra/zigavr/test $ 

i able to compile with Zig version 0.15.2 ```sh ~/Projects/intra/zigavr/test $ ls ~/Projects/intra/zigavr/test $ echo "export fn anything() void {}" > repro.zig ~/Projects/intra/zigavr/test $ ~/Projects/archive/Zig/zig-x86_64-linux-0.16.0/zig build-obj repro.zig -target avr-freestanding-none error: Alias and aliasee types don't match (Producer: 'zig 0.16.0' Reader: 'LLVM 21.1.0') ~/Projects/intra/zigavr/test $ ~/Projects/archive/Zig/zig-x86_64-linux-0.15.2/zig build-obj repro.zig -target avr-freestanding-none ~/Projects/intra/zigavr/test $ ls repro.o repro.zig ~/Projects/intra/zigavr/test $ ```

mattnite commented 2026年07月09日 01:11:01 +02:00

@mlugg, I think I found the root cause! I don't have the know-how or time to put a patch together for a fix, but I'm hoping this information will enable someone else. TLDR there are multiple copies of addrspace stuffed in the bitcode, LLVM expects them to match, and they do not in the code that Zig generates for AVR.

Log debugging

I added a log to print out the types when we hit this error message:

diff --git a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
index 9dd993f0d..f3b27c946 100644
--- a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -3173,8 +3173,12 @@ Error BitcodeReader::resolveGlobalAndIndirectSymbolInits() {
 Constant *C = MaybeC.get();
 GlobalValue *GV = IndirectSymbolInitWorklist.back().first;
 if (auto *GA = dyn_cast<GlobalAlias>(GV)) {
- if (C->getType() != GV->getType())
+ if (C->getType() != GV->getType()) {
+ errs() << "=== ALIAS TYPE CHECK ===\n"
+ << " alias '" << GV->getName() << "': " << *GV->getType() << "\n"
+ << " aliasee '" << C->getName() << "': " << *C->getType() << "\n";
 return error("Alias and aliasee types don't match");
+ }
 GA->setAliasee(C);
 } else if (auto *GI = dyn_cast<GlobalIFunc>(GV)) {
 GI->setResolver(C);

And we can see there is something going on with addrspace:

mattnite@ugluk ~/c/zig (fix-avr-codegen) [SIGINT]> ./build/stage3/bin/zig build-obj ./repro.zig -target avr-freestanding-none
=== ALIAS TYPE CHECK ===
 alias 'anything': ptr
 aliasee 'repro.anything': ptr addrspace(1)
error: Alias and aliasee types don't match (Producer: 'zig 0.17.0' Reader: 'LLVM 22.1.7')

looking at llvm/lib/Bitcode/Reader/BitcodeReader.cpp, the ALIAS seems to
have addrspace included in its serialization:

Error BitcodeReader::parseGlobalIndirectSymbolRecord(
 unsigned BitCode, ArrayRef<uint64_t> Record) {
 // v1 ALIAS_OLD: [alias type, aliasee val#, linkage] (name in VST)
 // v1 ALIAS: [alias type, addrspace, aliasee val#, linkage, visibility,
 // dllstorageclass, threadlocal, unnamed_addr,
 // preemption specifier] (name in VST)
 // v1 IFUNC: [alias type, addrspace, aliasee val#, linkage,
 // visibility, dllstorageclass, threadlocal, unnamed_addr,
 // preemption specifier] (name in VST)
 // v2: [strtab_offset, strtab_size, v1]

Dump Analysis

Note that I'm using the bitcode dump from LLVM memory that I attached above, it's from an older version of the Zig compiler. That should be fine? First we take the dump attached earlier and we convert the xxd output to raw bitcode:

mattnite@ugluk ~/c/zig (fix-avr-codegen)> xxd -r dump.txt > dump.bc

Taking the dump.txt from earlier, we can't convert it to text format because we hit THE error:

mattnite@ugluk ~/c/zig (fix-avr-codegen)> llvm-dis --version
LLVM (http://llvm.org/):
 LLVM version 22.1.7
 Optimized build with assertions.
mattnite@ugluk ~/c/zig (fix-avr-codegen)> llvm-dis dump.bc
=== ALIAS TYPE CHECK ===
 alias 'anything': ptr
 aliasee 'repro.anything': ptr addrspace(1)
llvm-dis: error: Alias and aliasee types don't match (Producer: 'zig 0.17.0' Reader: 'LLVM 22.1.7')

So I found out there is a tool called llvm-bcanalyzer which is able to dump the contents:

llvm-bcanalyzer --dump > dump.analyze

There is only one ALIAS line:

<ALIAS abbrevid=8 op0=33 op1=8 op2=24 op3=0 op4=1 op5=0 op6=0 op7=0 op8=0 op9=0 op10=0/>

Builder.zig only calls writeAbbrev on an alias once:

trymodule_block.writeAbbrev(ModuleBlock.Alias{.strtab_offset=strtab.offset,.strtab_size=strtab.size,.type_index=global.type,.addr_space=global.addr_space,.aliasee=constant_adapter.getConstantIndex(alias.aliasee),.linkage=global.linkage,.visibility=global.visibility,.thread_local=alias.thread_local,.unnamed_addr=global.unnamed_addr,.dllstorageclass=global.dll_storage_class,.preemption=global.preemption,});

writeAbbrev writes the fields in order after abbrevid, and a literal, leaving op3 to be addr_space. Leaving us with a value of 0, and here we see that it is from global.addr_space. Popping up the stack, In llvm codegen we have two instances of addAlias and they look identical:

constalias=tryo.builder.addAlias(exp_name,llvm_global_ty,.default,global_index.toConst(),);

addAlias has the signature:

pubfnaddAlias(self:*Builder,name:StrtabString,ty:Type,addr_space:AddrSpace,aliasee:Constant,)Allocator.Error!Alias.Index

It's a wrapper around addAliasAssumeCapacity, which passes down the .default
addrspace:

pubfnaddAliasAssumeCapacity(self:*Builder,name:StrtabString,ty:Type,addr_space:AddrSpace,aliasee:Constant,)Alias.Index{constalias_index:Alias.Index=@enumFromInt(self.aliases.items.len);self.aliases.appendAssumeCapacity(.{.global=self.addGlobalAssumeCapacity(name,.{.addr_space=addr_space,.type=ty,.kind=.{.alias=alias_index},}),.aliasee=aliasee});returnalias_index;}

Here is the addr space numbers for AVR:

pubconstAddrSpace=enum(u24){default,// ...// See llvm/lib/Target/AVR/AVR.hpubconstavr=struct{pubconstdata:AddrSpace=@enumFromInt(0);pubconstprogram:AddrSpace=@enumFromInt(1);pubconstprogram1:AddrSpace=@enumFromInt(2);pubconstprogram2:AddrSpace=@enumFromInt(3);pubconstprogram3:AddrSpace=@enumFromInt(4);pubconstprogram4:AddrSpace=@enumFromInt(5);pubconstprogram5:AddrSpace=@enumFromInt(6);};// ...};

By passing in .default to addAlias, we're unconditionally setting the serialized address space to 0, and in AVR land that means .data. in AVRs Harvard architecture, functions need to be in a program addrspace, AKA flash in std.lang. Sema.zig seems to do this correctly in places like zirPtrType(), and special cases AVR:

constaddress_space:std.lang.AddressSpace=if(inst_data.flags.has_addrspace)blk:{constref:Zir.Inst.Ref=@enumFromInt(sema.code.extra[extra_i]);extra_i+=1;break:blktrysema.resolveAddressSpace(block,addrspace_src,ref,.pointer);}elseif(elem_ty.zigTypeTag(zcu)==.@"fn"andtarget.cpu.arch==.avr).flashelse.generic;

Solution

AFAICT, the solution is replacing those .default literals with a dynamic lookup of the address space of the aliasee. Beyond that, I'm not sure if there's other areas that need fixing.

@mlugg, I think I found the root cause! I don't have the know-how or time to put a patch together for a fix, but I'm hoping this information will enable someone else. TLDR there are multiple copies of addrspace stuffed in the bitcode, LLVM expects them to match, and they do not in the code that Zig generates for AVR. ## Log debugging I added a log to print out the types when we hit this error message: ``` diff --git a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp index 9dd993f0d..f3b27c946 100644 --- a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp +++ b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp @@ -3173,8 +3173,12 @@ Error BitcodeReader::resolveGlobalAndIndirectSymbolInits() { Constant *C = MaybeC.get(); GlobalValue *GV = IndirectSymbolInitWorklist.back().first; if (auto *GA = dyn_cast<GlobalAlias>(GV)) { - if (C->getType() != GV->getType()) + if (C->getType() != GV->getType()) { + errs() << "=== ALIAS TYPE CHECK ===\n" + << " alias '" << GV->getName() << "': " << *GV->getType() << "\n" + << " aliasee '" << C->getName() << "': " << *C->getType() << "\n"; return error("Alias and aliasee types don't match"); + } GA->setAliasee(C); } else if (auto *GI = dyn_cast<GlobalIFunc>(GV)) { GI->setResolver(C); ``` And we can see there is something going on with addrspace: ``` mattnite@ugluk ~/c/zig (fix-avr-codegen) [SIGINT]> ./build/stage3/bin/zig build-obj ./repro.zig -target avr-freestanding-none === ALIAS TYPE CHECK === alias 'anything': ptr aliasee 'repro.anything': ptr addrspace(1) error: Alias and aliasee types don't match (Producer: 'zig 0.17.0' Reader: 'LLVM 22.1.7') ``` looking at `llvm/lib/Bitcode/Reader/BitcodeReader.cpp`, the `ALIAS` seems to have addrspace included in its serialization: ``` Error BitcodeReader::parseGlobalIndirectSymbolRecord( unsigned BitCode, ArrayRef<uint64_t> Record) { // v1 ALIAS_OLD: [alias type, aliasee val#, linkage] (name in VST) // v1 ALIAS: [alias type, addrspace, aliasee val#, linkage, visibility, // dllstorageclass, threadlocal, unnamed_addr, // preemption specifier] (name in VST) // v1 IFUNC: [alias type, addrspace, aliasee val#, linkage, // visibility, dllstorageclass, threadlocal, unnamed_addr, // preemption specifier] (name in VST) // v2: [strtab_offset, strtab_size, v1] ``` ## Dump Analysis Note that I'm using the bitcode dump from LLVM memory that I attached above, it's from an older version of the Zig compiler. That should be fine? First we take the dump attached earlier and we convert the xxd output to raw bitcode: ``` mattnite@ugluk ~/c/zig (fix-avr-codegen)> xxd -r dump.txt > dump.bc ``` Taking the dump.txt from earlier, we can't convert it to text format because we hit THE error: ``` mattnite@ugluk ~/c/zig (fix-avr-codegen)> llvm-dis --version LLVM (http://llvm.org/): LLVM version 22.1.7 Optimized build with assertions. mattnite@ugluk ~/c/zig (fix-avr-codegen)> llvm-dis dump.bc === ALIAS TYPE CHECK === alias 'anything': ptr aliasee 'repro.anything': ptr addrspace(1) llvm-dis: error: Alias and aliasee types don't match (Producer: 'zig 0.17.0' Reader: 'LLVM 22.1.7') ``` So I found out there is a tool called `llvm-bcanalyzer` which is able to dump the contents: ```sh llvm-bcanalyzer --dump > dump.analyze ``` There is only one ALIAS line: ``` <ALIAS abbrevid=8 op0=33 op1=8 op2=24 op3=0 op4=1 op5=0 op6=0 op7=0 op8=0 op9=0 op10=0/> ``` `Builder.zig` only calls `writeAbbrev` on an alias once: ```zig try module_block.writeAbbrev(ModuleBlock.Alias{ .strtab_offset = strtab.offset, .strtab_size = strtab.size, .type_index = global.type, .addr_space = global.addr_space, .aliasee = constant_adapter.getConstantIndex(alias.aliasee), .linkage = global.linkage, .visibility = global.visibility, .thread_local = alias.thread_local, .unnamed_addr = global.unnamed_addr, .dllstorageclass = global.dll_storage_class, .preemption = global.preemption, }); ``` `writeAbbrev` writes the fields in order after `abbrevid`, and a literal, leaving `op3` to be `addr_space`. Leaving us with a value of 0, and here we see that it is from `global.addr_space`. Popping up the stack, In llvm codegen we have two instances of `addAlias` and they look identical: ```zig const alias = try o.builder.addAlias( exp_name, llvm_global_ty, .default, global_index.toConst(), ); ``` `addAlias` has the signature: ```zig pub fn addAlias( self: *Builder, name: StrtabString, ty: Type, addr_space: AddrSpace, aliasee: Constant, ) Allocator.Error!Alias.Index ``` It's a wrapper around `addAliasAssumeCapacity`, which passes down the `.default` addrspace: ```zig pub fn addAliasAssumeCapacity( self: *Builder, name: StrtabString, ty: Type, addr_space: AddrSpace, aliasee: Constant, ) Alias.Index { const alias_index: Alias.Index = @enumFromInt(self.aliases.items.len); self.aliases.appendAssumeCapacity(.{ .global = self.addGlobalAssumeCapacity(name, .{ .addr_space = addr_space, .type = ty, .kind = .{ .alias = alias_index }, }), .aliasee = aliasee }); return alias_index; } ``` Here is the addr space numbers for AVR: ```zig pub const AddrSpace = enum(u24) { default, // ... // See llvm/lib/Target/AVR/AVR.h pub const avr = struct { pub const data: AddrSpace = @enumFromInt(0); pub const program: AddrSpace = @enumFromInt(1); pub const program1: AddrSpace = @enumFromInt(2); pub const program2: AddrSpace = @enumFromInt(3); pub const program3: AddrSpace = @enumFromInt(4); pub const program4: AddrSpace = @enumFromInt(5); pub const program5: AddrSpace = @enumFromInt(6); }; // ... }; ``` By passing in `.default` to `addAlias`, we're unconditionally setting the serialized address space to 0, and in AVR land that means `.data`. in AVRs Harvard architecture, functions need to be in a `program` addrspace, AKA `flash` in `std.lang`. `Sema.zig` seems to do this correctly in places like `zirPtrType()`, and special cases AVR: ```zig const address_space: std.lang.AddressSpace = if (inst_data.flags.has_addrspace) blk: { const ref: Zir.Inst.Ref = @enumFromInt(sema.code.extra[extra_i]); extra_i += 1; break :blk try sema.resolveAddressSpace(block, addrspace_src, ref, .pointer); } else if (elem_ty.zigTypeTag(zcu) == .@"fn" and target.cpu.arch == .avr) .flash else .generic; ``` ## Solution AFAICT, the solution is replacing those `.default` literals with a dynamic lookup of the address space of the aliasee. Beyond that, I'm not sure if there's other areas that need fixing.