Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting LLVM ERROR: Branch target out of insn range #1367

Closed
kupermind opened this issue Jun 15, 2023 · 7 comments · Fixed by #1400
Closed

Getting LLVM ERROR: Branch target out of insn range #1367

kupermind opened this issue Jun 15, 2023 · 7 comments · Fixed by #1400
Assignees

Comments

@kupermind
Copy link

kupermind commented Jun 15, 2023

Hi guys! When compiling a code for solana via solang I am getting the following error if I add one more state variable in the contract:

info: contract ServiceRegistrySolana uses at least 4152 bytes account data
info: Generating LLVM IR for contract ServiceRegistrySolana with target solana
LLVM ERROR: Branch target out of insn range
zsh: abort      npm run build

The working code is located here:
https://github.com/valory-xyz/autonolas-registries/tree/solana

Steps to reproduce the working code:

git clone --recursive https://github.com/valory-xyz/autonolas-registries.git
git checkout 573ced9e1d1d3d070bc26a58da8b6b04e5291be6
cd autonolas-registries/integrations/solana
yarn
npm run build
npm run test

Now try to declare a single variable on line 66, for example, address public var, in the following file:
https://github.com/valory-xyz/autonolas-registries/tree/573ced9e1d1d3d070bc26a58da8b6b04e5291be6/integrations/solana/contracts/ServiceRegistrySolana.sol

Then try to recompile with npm run build or a custom solang build command, and the build will fail with the specified error.

The Solang version is v0.3.0, the platform is MacOs, although tried on the latest Linux as well and got the same result.

In order to make it work with that additional state variable, I need to comment the code out starting from the line 797, which might point to some contract size issues. Although if I were to add mapping instead of a primitive variable, then the original code would compile, just increasing the bytes account data. So the issue is really related to the primitive state variables.

Thanks a lot for your help!

@LucasSte
Copy link
Contributor

Hey @kupermind,
Can you provide the exact contract that fails for you?
I copied the file you liked and added a new variable address public var in line 66, but I could not replicate the error.

@kupermind
Copy link
Author

Hi @LucasSte,

Please checkout the following branch: llvm_insn_range_solana
The ServiceRegistrySolana.sol contract fails right from the start, you just need to do the described steps:

git clone --recursive https://github.com/valory-xyz/autonolas-registries.git
git checkout llvm_insn_range_solana
cd autonolas-registries/integrations/solana
yarn
npm run build

The build must fail with the specified error.

Thanks a lot!

@LucasSte
Copy link
Contributor

Thanks @kupermind, I was able to replicate the error. I'll look into it and keep you posted.

@LucasSte LucasSte self-assigned this Jun 19, 2023
@LucasSte
Copy link
Contributor

I am still investigating the problem, but I've found some options that make your contract work, so you can continue your development until we find a fix.

You can use the --release flag to build your contract if you do not care about the print() function or runtime error messages.

If you care about them for testing, use the -Oless flag, which disables LLVM optimizations. This option makes your contract slower and consume more compute units.

@kupermind
Copy link
Author

That is great! Thank you very much for the hints!!

@LucasSte
Copy link
Contributor

I've found the problem and a fix: #1386. I can't merge that yet because your contract also causes a stack overflow in constant folding, so I need to solve this first.

@kupermind
Copy link
Author

Hey @LucasSte,

Great and thanks a lot for the update! We were happy with your previous --release flag recommendation, however it would be great once the fix is merged, easier to see reverts by default :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants