id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5235	Tuple call with array argument can cause invalid code to be generated	Per Östlund	Lennart Ochel	"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):
{{{#!mo
electricalPowerSensor.i_ =
  Modelica.Electrical.Machines.SpacePhasors.Functions.ToSpacePhasor(electricalPowerSensor.plug_p.pin.i)[1]
}}}
This causes the following function to be generated:
{{{#!c
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."	defect	closed	high	Future	Code Generation	v1.13.0-dev-nightly	fixed		Willi Braun Lennart Ochel