Tuple call with array argument can cause invalid code to be generated

[Per Östlund]

Compiling Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_withLosses using -d=newInst causes the following equation to be generated (the [1] at the end is a tuple subscript, i.e. only the first result of the function is used):

electricalPowerSensor.i_ =
  Modelica.Electrical.Machines.SpacePhasors.Functions.ToSpacePhasor(electricalPowerSensor.plug_p.pin.i)[1]

This causes the following function to be generated:

void AIMC_withLosses_total_eqFunction_236(DATA *data, threadData_t *threadData)
{
  TRACE_PUSH
  const int equationIndexes[2] = {1,236};
  real_array tmp12;
  real_array tmp13;
  real_array_create(&tmp12, ((modelica_real*)&((&-(data->localData[0]->realVars[167] /* sineVoltage.i[1] variable */))[calc_base_index_dims_subs(1, 3, ((modelica_integer) 1))])), 1, 3);
  real_array_create(&tmp13, ((modelica_real*)&((&data->localData[0]->realVars[151] /* electricalPowerSensor.i_[1] variable */)[calc_base_index_dims_subs(1, 2, ((modelica_integer) 1))])), 1, 2);
  copy_real_array_data(omc_Modelica_Electrical_Machines_SpacePhasors_Functions_ToSpacePhasor(threadData, tmp12, NULL), &tmp13);
  TRACE_POP
}

The issue here is the first real_array_create call. CodegenCFunction.daeExpCallTuple uses daeExp which eventually uses daeExpCrefRhsSimContext to generate the real_array_create call, but daeExpCrefRhsSimContext assumes it can take the address of whatever contextCref returns. This is not always the case though, because contextCref looks electricalPowerSensor.plug_p.pin.i up in the SimCode and sees that it's a negated alias of sineVoltage.i. contextCref therefore returns -data->localData[0]->realVars[167], which is a temporary expressions due to the minus sign.

The new frontend can trivially expand all function arguments (just need to turn the -d=nfExpandFuncArgs flag on by default), which avoids the issue. But this causes other issues instead, and expanding all function arguments is not desirable either. The best solution would be if the code generation could handle this correctly, but I'm not sure how it could do that.

[Francesco Casella]

Fixed by ​PR #2919