incorrect data layout string generated on some targets with the new llvm logic

[ghost]

Zig Version

0.11.0-dev.4088+c43ee5bb2

Steps to Reproduce and Observed Behavior

Try to compile literally anything (even an empty file reproduces the error) with zig build-exe blah.zig -target wasm32-emscripten

Error:

====== expected this output: =========
e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-f128:64-n32:64-S128-ni:1:10:20␃

======== instead found this: =========
e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20␃

======================================
First difference occurs on line 1:
expected:
e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-f128:64-n32:64-S128-ni:1:10:20
                                     ^ ('\x66')
found:
e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20
                                     ^ ('\x6e')
thread 7254 panic: attempt to unwrap error: TestExpectedEqual
/home/yujiri/code/zig/lib/std/testing.zig:635:9: 0x40c1492 in expectEqualStrings (zig)
        return error.TestExpectedEqual;
        ^
/home/yujiri/code/zig/src/codegen/llvm.zig:865:25: 0x40c3495 in init (zig)
                ) catch unreachable;
                        ^
/home/yujiri/code/zig/src/codegen/llvm.zig:741:32: 0x40c6625 in create (zig)
        obj.* = try Object.init(gpa, options);
                               ^
/home/yujiri/code/zig/src/link/Wasm.zig:527:49: 0x40cff0c in createEmpty (zig)
        wasm.llvm_object = try LlvmObject.create(gpa, options);
                                                ^
/home/yujiri/code/zig/src/link/Wasm.zig:364:27: 0x40e3813 in openPath (zig)
        return createEmpty(allocator, options);
                          ^
/home/yujiri/code/zig/src/link.zig:351:49: 0x40e7580 in openPath (zig)
                    break :f &(try Wasm.openPath(allocator, sub_path, options)).base;
                                                ^
/home/yujiri/code/zig/src/Compilation.zig:1428:48: 0x40f295a in create (zig)
        const bin_file = try link.File.openPath(gpa, .{
                                               ^
/home/yujiri/code/zig/src/main.zig:3078:36: 0x41e642c in buildOutputType (zig)
    const comp = Compilation.create(gpa, .{
                                   ^
/home/yujiri/code/zig/src/main.zig:269:31: 0x405eb31 in mainArgs (zig)
        return buildOutputType(gpa, arena, args, .{ .build = .Exe });
                              ^
/home/yujiri/code/zig/src/main.zig:213:20: 0x405bf85 in main (zig)
    return mainArgs(gpa, arena, args);
                   ^
/home/yujiri/code/zig/lib/std/start.zig:608:37: 0x405b9de in main (zig)
            const result = root.main() catch |err| {
                                    ^
???:?:?: 0x7f3bd1f3287f in ??? (???)
???:?:?: 0x7ffdfa0eaaa6 in ??? (???)
fish: Job 1, 'zig build-exe client/main_web.z…' terminated by signal SIGABRT (Abort)

Okay, what the heck even is this? How am I getting a test failure when I'm not running a test?

Expected Behavior

Normal attempt to compile the file...

I have a project that was building successfully for this target in the last few weeks. I think this must be recent.

[rohlem]

Okay, what the heck even is this?

I don't think it's a crazy miscompilation / screw-up, just a part of the compiler using std.testing.expectEqualSlices for equivalence testing. Mentioned lines support this:

zig/src/codegen/llvm.zig

Lines 862 to 865 in 426e737

	std.testing.expectEqualStrings(
	std.mem.span(rep),
	builder.data_layout.toSlice(&builder).?,
	) catch unreachable;

IMO kind of smart and not the worst idea for pointing out the actual issue (to whoever understands what's happening in that part of the code).

[ghost]

New information: it also happens for me with windows instead of emscripten, and on wasm64 instead of wasm32, but does not happen on freestanding.

[andrewrk]

That's an assertion that the LLVM backend generated the data layout string correctly. Good thing it was added because it caught an issue for you that would have been very difficult to track down otherwise. cc @jacobly0

[xdBronch]

i know the support is (extremely) experimental for now but im getting the same type of error with xtensa

====== expected this output: =========
e-m:e-p:32:32-i64:64-i128:128-n32␃

======== instead found this: =========
e-m:e-p:32:32-i64:32-f64:32␃

======================================
First difference occurs on line 1:
expected:
e-m:e-p:32:32-i64:64-i128:128-n32
                  ^ ('\x36')
found:
e-m:e-p:32:32-i64:32-f64:32

should this (or a separate issue) be reopened? should it just be left until xtensa is more supported?