Cannot bootstrap compiler with 2.0.2 and --mm:orc due to codegen error

[metagn]

Description

Attempting to bootstrap the current compiler (a4f3bf374238df96f0982b7106e3702da6b485b1) with Nim 2.0.2 and the command:

.\koch boot -d:release -d:nimStrictMode --lib:lib

fails on the first iteration due to codegen errors on my machine. Bootstrapping with --mm:refc works (this is what I was doing when I thought updating to 2.0.2 would fix it). This is on gcc 6.3.0 using mingw on Windows 11 but the problem doesn't look platform specific.

Nim Version

a4f3bf374238df96f0982b7106e3702da6b485b1/2.0.2

Current Output

@m..@slib@ssystem.nim.c: In function 'reset__stdZexitprocs_u58':
@m..@slib@ssystem.nim.c:9141:33: error: incompatible type for argument 1 of 'eqdestroy___stdZexitprocs_u126'
  eqdestroy___stdZexitprocs_u126((*obj_p0));
                                 ^
In file included from @m..@slib@ssystem.nim.c:4:0:
@m..@slib@ssystem.nim.c:4840:31: note: expected 'tyObject_Fun__inHA9bTDPGs0YY1PIIXlvBg * {aka struct tyObject_Fun__inHA9bTDPGs0YY1PIIXlvBg *}' but argument is of type 'tyObject_Fun__inHA9bTDPGs0YY1PIIXlvBg {aka struct tyObject_Fun__inHA9bTDPGs0YY1PIIXlvBg}'
 N_LIB_PRIVATE N_NIMCALL(void, eqdestroy___stdZexitprocs_u126)(tyObject_Fun__inHA9bTDPGs0YY1PIIXlvBg* dest_p0);
                               ^
lib/nimbase.h:240:57: note: in definition of macro 'N_NIMCALL'
 #    define N_NIMCALL(rettype, name) rettype __fastcall name
                                                         ^~~~
@m..@slib@ssystem.nim.c: In function 'reset__options_u2776':
@m..@slib@ssystem.nim.c:10107:28: error: incompatible type for argument 1 of 'eqdestroy___options_u2792'
  eqdestroy___options_u2792((*obj_p0));
                            ^
In file included from @m..@slib@ssystem.nim.c:4:0:
@m..@slib@ssystem.nim.c:4866:31: note: expected 'tyTuple__QeWl6B6ffS4pU6WWrtcrDw * {aka struct tyTuple__QeWl6B6ffS4pU6WWrtcrDw *}' but argument is of type 'tyTuple__QeWl6B6ffS4pU6WWrtcrDw {aka struct tyTuple__QeWl6B6ffS4pU6WWrtcrDw}'
 N_LIB_PRIVATE N_NIMCALL(void, eqdestroy___options_u2792)(tyTuple__QeWl6B6ffS4pU6WWrtcrDw* dest_p0);
                               ^
lib/nimbase.h:240:57: note: in definition of macro 'N_NIMCALL'
 #    define N_NIMCALL(rettype, name) rettype __fastcall name
                                                         ^~~~
@m..@slib@ssystem.nim.c: In function 'reset__ast_u3245':
@m..@slib@ssystem.nim.c:12586:24: error: incompatible type for argument 1 of 'eqdestroy___ast_u3261'
  eqdestroy___ast_u3261((*obj_p0));

Expected Output

successful bootstrap

Possible Solution

No response

Additional Information

No response

[metagn]

Can anyone else reproduce this?

[ringabout]

I cannot reproduce it on Linux. You might need to remove bin/nim and bin/nim_temp before booting the compiler using an older binary.

[rockcavera]

Can anyone else reproduce this?

I managed to reproduce your error using gcc 6.4.0 and Nim 2.0.2 for bootstrap devel. (note: it was necessary to comment out hint[LineTooLong]=off in nim.cfg)

Using csource_v2 this error does not occur.

[Araq]

That's just the "var T" destructor changes. You're building Nim in a way that is not supported and I don't know if it's fixable.

Or maybe it's something else.

[metagn]

(note: it was necessary to comment out hint[LineTooLong]=off in nim.cfg)

This probably refreshes the nimcache which reveals the problem. @ringabout This might be why it worked for you, I don't know if cleaning bin would change anything (the command that koch showed pointed to my 2.0.2 installation) but I did clean the nimcache.

That's just the var T destructor changes.

The csources_v2 version doesn't seem to have these changes, 2.0 does (which is almost a year ahead). So, the var T destructor changes could be breaking the Nim compiler, is how I interpreted it. If the Nim compiler codebase needs to be updated to be compatible with the var T destructor changes then I understand but does the compiler do anything that would violate them?

Also it's weird that booting in CI doesn't catch this, which is why I'm still not sure what's wrong.

Edit: Adding -f to the successive boot operations might show the problem in Cı, again because of the nimcache.

[ringabout]

@metagn Could you boot the compiler with the nightlies?

[metagn]

Works on today's nightly. Still might be in version-2-0 branch, will try adding -f to boot CI as written above this won't do anything, the problem isn't whether the version-2-0 compiler can bootstrap itself, it's whether it can compile the devel compiler.

[metagn]

The problem is that the version-2-0 compiler cannot compile the devel compiler. This is hard to test, let alone bisect (git checkout abcd1234; nim c compiler/nim; git checkout devel; compiler/nim c compiler/nim), so we could leave it alone and update csources later to a devel commit we know works, like today's nightly or later. It would still be nice if we had an idea of which commit we could backport so the var T destructor changes aren't broken on 2.0.

Also yeah, version-2-0 needs to define nimHasNoLineTooLong.

[ringabout]

It would still be nice if we had an idea of which commit we could backport so the var T destructor changes aren't broken on 2.0.

In order

https://github.com/nim-lang/Nim/pull/22147 https://github.com/nim-lang/Nim/pull/22167 https://github.com/nim-lang/Nim/pull/22207 https://github.com/nim-lang/Nim/pull/22225 https://github.com/nim-lang/Nim/pull/22810 https://github.com/nim-lang/Nim/pull/22975

[narimiran]

FWIW, I had the same error when I tried to update my devel version of Nim one month ago.

It worked once I downloaded nim binary from nightlies, and @Araq said to me it is because "you need to use a nim binary from csources_v2".