Why would this CPS sum overflow only in Debug?

Debug builds have tail calls off, and Release has them on. sumK calling itself is compiled to a jump either way, so building the chain is fine. The overflow is k (s + x), a call through a closure in tail position. Without tail calls it is a plain callvirt with no tail. prefix, and when k 0 finally runs, a million closures each add a frame. The switch is the Tailcalls property in the project, --tailcalls on the command line.

So the same text is a working program in one configuration and a crash in the other. That puts the tail call guarantee at the build layer, which is an odd layer for something the program's meaning depends on. The [<TailCall>] attribute looks like the fix at the right layer. Mark sumK with it and the requirement is written in the source, so the Debug build has to emit the prefix too.

I hoped so too and tried it first. [<TailCall>] only adds a check. The compiler warns when a recursive call to the marked function isn't in tail position, and what it emits stays the same. On sumK it stays silent, because the recursive call already is in tail position, and the Debug build overflows exactly as before. The closures that would need covering aren't the marked function anyway.

Is there a reason Debug turns them off beyond habit? My guess is the call stack. A frame replaced by a tail call is gone, so the debugger and exception stack traces skip those steps, and that view is what people open Debug for. If that's it, turning Tailcalls on for Debug trades some of that view for a program that runs, which feels like a decision per project rather than a default to flip everywhere.

That sounds right to me. For this project the program itself depends on tail calls, so they're on for both configurations now, and Debug prints 1000000 too.

<PropertyGroup>
  <Tailcalls>true</Tailcalls>
</PropertyGroup>

Maybe a library would be better off rewriting sumK so it doesn't need the prefix, since its users pick their own build settings.