Compiler bug: invalid Int32 when calling offsetof(lib union)

[HertzDevil]

{"" => [] of Int8}
{"" => [] of Int16}
{"" => [] of Int32}
{"" => [] of Int64}
{"" => [] of UInt8}
{"" => [] of UInt16}
{"" => [] of UInt32}

lib LibT
  union U
    x : Int32
    y : UInt8
  end
end

def instance_var_names(type : T.class) forall T
  {{ T.instance_vars.map(&.stringify) }}
end

p instance_var_names(LibT::U)
p offsetof(LibT::U, @y)

This snippet leads to the following compiler error on x86_64-unknown-linux-gnu 52c750e (LLVM 8.0.0):

Invalid Int32: 93825018395136 (ArgumentError)
  from ../../../../crystal/src/string.cr:428:5 in 'to_i32'
  from ../../../../crystal/src/compiler/crystal/codegen/codegen.cr:448:23 in 'accept'
  from ../../../../crystal/src/compiler/crystal/codegen/codegen.cr:2193:7 in 'prepare_call_args_non_external'
  from ../../../../crystal/src/compiler/crystal/codegen/call.cr:57:7 in 'visit'
  from ../../../../crystal/src/compiler/crystal/syntax/visitor.cr:27:12 in 'accept'
  from ../../../../crystal/src/compiler/crystal/codegen/codegen.cr:628:9 in 'accept'
  from ../../../../crystal/src/compiler/crystal/codegen/codegen.cr:2158:7 in 'codegen'
  from ../../../../crystal/src/compiler/crystal/compiler.cr:172:16 in 'compile'
  from ../../../../crystal/src/compiler/crystal/command.cr:210:5 in 'run_command'
  from ../../../../crystal/src/compiler/crystal/command.cr:62:5 in 'run'
  from ../../../../crystal/src/crystal/main.cr:105:5 in 'main'
  from src/env/__libc_start_main.c:94:2 in 'libc_start_main_stage2'
Error: you've found a bug in the Crystal compiler. Please open an issue, including source code that will allow us to reproduce the bug: https://github.com/crystal-lang/crystal/issues

On 0.35.1 the snippet compiles, but it also produces very incorrect results, as offsetof(LibT::U, @y) should be 0 because it is a C union.

The invalid integer is different every time the snippet is run; it seems to be some kind of corrupted pointer. What I believe is that the compiler tries to fix the value of offsetof before all types are known and finalized.

[BlobCodes]

Using Crystal 1.0.0, this compiles and gives the following output (LLVM 10.0.0, OpenSUSE Tumbleweed, x86_64-unknown-linux-gnu):

["x", "y"]
0

Seems to have been fixed in the meantime, can this be closed?

[HertzDevil]

This was never fixed, and it was by sheer coincidence that the last offsetof returns 0. A debug build of LLVM would trigger an assertion failure.