#4212 closed defect (fixed)
Wrong code generation for function calls involving cross product and MultiBody.Frames.Rotation records
| Reported by: | Francesco Casella | Owned by: | Martin Sjölund |
|---|---|---|---|
| Priority: | high | Milestone: | 1.12.0 |
| Component: | Code Generation | Version: | |
| Keywords: | Cc: |
Description
Consider the following test model:
model TestCrossFunction
import Modelica.Mechanics.MultiBody.Frames;
Frames.Orientation R = Frames.nullRotation();
Real v1[3], v2[3];
function f
input Frames.Orientation R;
input Real v1[3];
output Real v2[3];
algorithm
v2 := Frames.resolveRelative(cross(Frames.angularVelocity2(R), v1), R, R);
end f;
equation
v1 = {0, 0, 0};
v2 = f(R, v1);
end TestCrossFunction;
When building the model, the C compiler complains that
TestCrossFunction_functions.c: In function 'omc_TestCrossFunction_f': TestCrossFunction_functions.c:143:26: error: lvalue required as unary '&' operand cross_alloc_real_array(&omc_Modelica_Mechanics_MultiBody_Frames_angularVelocity2(threadData, _R), &tmp1, &tmp2);
Apparently some part of the code generation algorithm assumes that the first argument of the C implementation of the cross() function is a variable and not the result of a function call, so it incorrectly tries to to get its address.
Attachments (1)
Change History (8)
by , 9 years ago
| Attachment: | TestCrossFunction.mo added |
|---|
comment:1 by , 9 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → accepted |
follow-up: 4 comment:2 by , 9 years ago
comment:4 by , 9 years ago
Replying to sjoelund.se:
Want this fixed for 1.11.0 as well?
For my purposes, I already introduced a workaround in our model in terms of explicitly assigning the result of the first function call to an additional protected variable, so this is not really necessary.
That said, if back-porting this feature to 1.11 is a low-risk operation, please go ahead - this might also be useful for other people.
If the test works for you, you may also close the ticket.
comment:5 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
If it was still at beta1 I would have ported it. It shouldn't make a negative impact on the library coverage, but we don't have any tests for this so I'll just keep it 1.12 only.

Want this fixed for 1.11.0 as well?