IRGeneratorForStatements: Fix undefined order of functions when generating code for index expressions

This commit is contained in:
Kamil Śliwak 2023-06-28 13:52:24 +02:00
parent 69c034b1c0
commit 16220db759
2 changed files with 3 additions and 1 deletions

View File

@ -17,6 +17,7 @@ Compiler Features:
Bugfixes: Bugfixes:
* Code Generator: Fix not entirely deterministic order of functions in unoptimized Yul output. The choice of C++ compiler in some cases would result in different (but equivalent) bytecode (especially from native binaries vs emscripten binaries)
* Commandline Interface: Fix internal error when using ``--stop-after parsing`` and requesting some of the outputs that require full analysis or compilation. * Commandline Interface: Fix internal error when using ``--stop-after parsing`` and requesting some of the outputs that require full analysis or compilation.
* Commandline Interface: It is no longer possible to specify both ``--optimize-yul`` and ``--no-optimize-yul`` at the same time. * Commandline Interface: It is no longer possible to specify both ``--optimize-yul`` and ``--no-optimize-yul`` at the same time.
* SMTChecker: Fix encoding of side-effects inside ``if`` and ``ternary conditional``statements in the BMC engine. * SMTChecker: Fix encoding of side-effects inside ``if`` and ``ternary conditional``statements in the BMC engine.

View File

@ -2295,8 +2295,9 @@ void IRGeneratorForStatements::endVisit(IndexAccess const& _indexAccess)
} }
case DataLocation::Memory: case DataLocation::Memory:
{ {
string indexAccessFunction = m_utils.memoryArrayIndexAccessFunction(arrayType);
string const memAddress = string const memAddress =
m_utils.memoryArrayIndexAccessFunction(arrayType) + indexAccessFunction +
"(" + "(" +
IRVariable(_indexAccess.baseExpression()).part("mpos").name() + IRVariable(_indexAccess.baseExpression()).part("mpos").name() +
", " + ", " +