Is there a way to identify what is causing it in the source I am trying to compile? I might be able to rework it to stop this.

I isolated 'my' troublesome expression (it comes from mscp.c) by trial and error: using #if 0...#endif to disable large chunks of the C program until the error disappears or changes. The way I understand it, any nested expression with * / << or >> can potentially trigger this.

In new programs it's easy to workaround it. I still have hopes we can find a fix once we can put our mind to it. It will be a great boost for the memory card subproject. (But we always have cc65 as a backup for that.)

I just judge by glancing over the source code. When you're writing new code, it becomes evident along the way because you have the intermediate .gt1 files. You can dump these with Utils/gt1dump.py to see where you are. The author sure didn't add a lot of user messages, and when it crashes, it leaves nothing behind. Well, he did call it "rudimentary" for a reason.

656+9 bytes isn't too much by itself, but under 32K everything must be distributed over 96-byte segments as well. With code the compiler fixes that for you. With data it can't do that. I couldn't compile mscp.c yet for that reason: it needs the large unsegmented chunk above 32K.