Opened 5 years ago
Closed 5 years ago
#5235 closed defect (fixed)
Tuple call with array argument can cause invalid code to be generated
Reported by: | perost | Owned by: | lochel |
---|---|---|---|
Priority: | high | Milestone: | Future |
Component: | Code Generation | Version: | v1.13.0-dev-nightly |
Keywords: | Cc: | wbraun, lochel |
Description
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.
Change History (1)
comment:1 Changed 5 years ago by casella
- Resolution set to fixed
- Status changed from new to closed
Fixed by PR #2919