0.8.25 with VIA_IR fails with "InternalCompilerError: Assembly exception for bytecode" (0.8.24 or without via_ir works ok)

[vicnaum]

Description

When switching from 0.8.24 to 0.8.25 the compiler fails with "Assembly exception for bytecode":

[⠊] Compiling...
[⠒] Compiling 229 files with 0.8.25
[⠑] Solc 0.8.25 finished in 4.65s
Error: 
Compiler run failed:
Error: Internal compiler error (/solidity/libsolidity/interface/CompilerStack.cpp:1410):Assembly exception for bytecode
InternalCompilerError: Assembly exception for bytecode

Environment

• Compiler version: 0.8.25
• Target EVM version (as per compiler settings): paris
• Framework/IDE (e.g. Truffle or Remix): foundry
• EVM execution environment / backend / blockchain client: during compilation
• Operating system: MacOS Ventura 13.6
• via_ir: true

Steps to Reproduce

I don't know which part of the code reproduces the bug exactly, but it can be reproduces by cloning and trying to compile Lens Protocol public repo:

1. git clone https://github.com/lens-protocol/core.git
2. forge install
3. edit "foundry.toml" to change the solc_version to "0.8.25" and uncomment via_ir = true line to enable compilation via_ir
4. build with forge b --skip test (skipping tests to make it faster)

Switching solc_version to "0.8.24" makes it compile again (so that's the latest working version).
Turning via_ir off also makes it compile - so the problem is using both: 0.8.25 and via_ir=true

[nikola-matic]

An ICE is not really something that you should be seeing, so it does look like a bug. Looking a bit further into it, the assertion that's triggered is this one.

Was likely introduced here for the 0.8.25 release.

[cameel]

We discussed it on the chat today and it seems to be a regression introduced by the fix for #14863. @ekpyron's diagnosis sounds very plausible:

But yeah, before #14864 we generally overallocated the tag sizes - after that PR, we rely on the code size estimate to be accurate (as in: precise or overestimating) - which is probably broken in a few corner cases (I've seen some in the PUSH0 PR even IIRC) - which would break with that assert in some corner cases - that's my best guess.

Also, regarding the possibility that it's 0.8.24 that is broken and the assertion wasn't being triggered due to incorrect code being generated:

In fact the miscalculation we had in that code before could have lead to something quite similar to that (i.e. allocating too small of space for tags and then just overwriting code when inserting them), but we did already have assertions against that back then

Overall, this is all still speculation since the repro is quite unwieldy (it's a whole repo - a small snippet would be much more helpful) so we'll need to confirm this before fixing, but it's probably correct considering all the info we have so far.

Finally, this bug also highlights a small related issue, i.e. that "assembly exception" for some reason does not include the original message from the assertion that @nikola-matic pointed at. Having it there would have made things clearer from the beginning. We should fix that too.