Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4212 closed defect (fixed)

Wrong code generation for function calls involving cross product and MultiBody.Frames.Rotation records

Reported by: casella Owned by: sjoelund.se
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 casella 7 years ago.

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by casella

comment:1 Changed 7 years ago by sjoelund.se

  • Owner changed from lochel to sjoelund.se
  • Status changed from new to accepted

comment:2 follow-up: Changed 7 years ago by sjoelund.se

Want this fixed for 1.11.0 as well?

comment:3 Changed 7 years ago by sjoelund.se

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

comment:4 in reply to: ↑ 2 Changed 7 years ago by casella

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 Changed 7 years ago by sjoelund.se

  • Resolution set to fixed
  • Status changed from accepted to 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.

comment:6 Changed 7 years ago by casella

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

Note: See TracTickets for help on using tickets.