Opened 5 years ago

Last modified 3 years ago

#5886 accepted defect

Use of undeclared identifier and undefined reference to *_array_get function — at Version 5

Reported by: federico.terraneo@… Owned by: Mahder Alemseged Gebremedhin
Priority: high Milestone:
Component: Code Generation Version: v1.16.0-dev
Keywords: Cc: francesco.casella@…

Description (last modified by Mahder Alemseged Gebremedhin)

The following model (Top in the Bug package) fails compilation.
For some reason, if z is 1, omc produces C code including calls to a nonexistent function Bug_Component_array_get. The calls to this function also reference a parameter components which does not exist in the caller's context.

Setting z to anything greater than 1 produces working code, where the Bug_Component_array_get is not declared not used anywhere.

Change History (6)

by federico.terraneo@…, 5 years ago

Attachment: Bug.mo added

Code causing the compilation error

comment:1 by Francesco Casella, 5 years ago

Owner: changed from Lennart Ochel to Mahder Alemseged Gebremedhin
Status: newassigned

@mahge930, could you have a quick look?

comment:2 by Francesco Casella, 5 years ago

Milestone: Future1.16.0

comment:3 by Mahder Alemseged Gebremedhin, 5 years ago

Status: assignedaccepted

comment:4 by Mahder Alemseged Gebremedhin, 5 years ago

in model Top the value of col is provided by the declaration

model Top
  parameter Integer z = 1;
  Component components[x](each cols = z);
  ...
end Top;

The array T in model Component is declared as

model Component
  ....
  Modelica.SIunits.Temperature T[rows, cols]
  ...
equation
  ...
  c * der(T[1, 1]) = gx * (T[1, 2] - T[1, 1])
                        + gy * (T[2, 1] - T[1, 1])
                        + gf * (inletFluidTemperature - T[1, 1])
                        + bottom.port[1].Q_flow;
  

As you can see, the second equation in model Component tries to access T[1,2] regardless of the value of cols.

This is where the problem is. If z is 1 then cols is set to 1 which means T is a [4,1] array. Trying to access [1,2] should normally cause out of range access error.

The way our simulation code operates right now, if it fails to find a variable in the list of simcode variables, in this case components[1].T[1,2] for example, it will assume it is a temporary variable and tries to generate function like code for it. You don't have to worry about the details normally. Until you run in to this kinds of odd errors.

I understand it would be nice to have better error messages in this case. However this is not something we can fix right now. At least not as a quick fix. For what it is worth I think this error is actually a bit better than having a silent out of bounds access.

Last edited 5 years ago by Mahder Alemseged Gebremedhin (previous) (diff)

comment:5 by Mahder Alemseged Gebremedhin, 5 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.