Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#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)

TestCrossFunction.mo (418 bytes ) - added by Francesco Casella 8 years ago.

Download all attachments as: .zip

Change History (8)

by Francesco Casella, 8 years ago

Attachment: TestCrossFunction.mo added

comment:1 by Martin Sjölund, 8 years ago

Owner: changed from Lennart Ochel to Martin Sjölund
Status: newaccepted

comment:2 by Martin Sjölund, 8 years ago

Want this fixed for 1.11.0 as well?

comment:3 by Martin Sjölund, 8 years ago

PR1379 should fix it (also for other array operations).

in reply to:  2 comment:4 by Francesco Casella, 8 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 Martin Sjölund, 8 years ago

Resolution: fixed
Status: acceptedclosed

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.

comment:6 by Francesco Casella, 8 years ago

Ok. Please add the test reported in this ticket for 1.12, if possible.

Note: See TracTickets for help on using tickets.