Opened 10 years ago

Last modified 6 years ago

#3121 assigned defect

Missing bindings in flattened operator overloading example

Reported by: anonymous Owned by: perost
Priority: low Milestone: 2.1.0
Component: New Instantiation Version: trunk
Keywords: Cc:

Description (last modified by casella)

This model contains errors (in operator "+" inputs should be a BugRecord type).
Trace is attached.

model Bug
  operator record BugRecord
    Integer x;

    operator function '+'
      input Bug b1;
      input Bug b2;
      output BugRecord rec(x = b1.x + b2.x);
    end '+';
  end BugRecord;

  BugRecord bugRecord = BugRecord(1) + BugRecord(0);
end Bug;

Attachments (1)

bug.log (1022.3 KB) - added by anonymous 10 years ago.

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by anonymous

comment:1 Changed 7 years ago by casella

  • Component changed from *unknown* to NF - New FrontEnd
  • Description modified (diff)
  • Owner changed from somebody to mahge930
  • Status changed from new to assigned
  • Summary changed from Stack overflow in operator to Wrong behaviour of operator overloading example

OMEdit still crashes with this test case as of OpenModelica-v1.13.0-dev-63-g453e1c7-64bit. It doesn't crash with the new frontend -d=newInst, but it still doesn't compile, because the code is probably wrong. If the reporter meant this model instead:

model Bug
  operator record BugRecord
    Integer x;

    encapsulated operator function '+'
      input BugRecord b1;
      input BugRecord b2;
      output BugRecord rec(x = b1.x + b2.x);
    algorithm 
      annotation(Inline = true);
    end '+';

  end BugRecord;
  BugRecord bugRecord = BugRecord(1) + BugRecord(0);
end Bug;

in fact we still have a problem even with the new front-end, which reports

[Bug: 15:3-15:52]: Expected BugRecord to be a function, but found class instead.

For the record, Dymola simulates this updated model correctly.

Last edited 6 years ago by casella (previous) (diff)

comment:2 Changed 7 years ago by perost

  • Component changed from NF - New FrontEnd to New Instantiation

Move all tickets from NF - New Frontend to New Instantiation so we don't have two different categories for the same thing.

comment:3 Changed 6 years ago by casella

  • Milestone changed from Future to 2.0.0
  • Owner changed from mahge930 to perost

With the old front-end, the model works fine. With the NF, the flattened model looks like this:

function BugRecord.'+' "Inline before index reduction"
  input BugRecord b1;
  input BugRecord b2;
  output BugRecord rec;
algorithm
end BugRecord.'+';

class Bug
  Integer bugRecord.x;
equation
  bugRecord = BugRecord.'+'(BugRecord(1), BugRecord(0));
end Bug;

so it seems the NF loses the bindings in the output record declaration, which causes a template error when trying to simulate the model.

comment:4 follow-up: Changed 6 years ago by casella

As of v1.13.0-dev-739-g9878b52ae, the model compiles with the NF, runs, and produces the correct results. However, the flattened model is

function Bug.BugRecord "Automatically generated record constructor for Bug.BugRecord"
  input Integer x;
  output BugRecord res;
end Bug.BugRecord;

function BugRecord.'+' "Inline before index reduction"
  input BugRecord b1;
  input BugRecord b2;
  output BugRecord rec;
algorithm
end BugRecord.'+';

class Bug
  Integer bugRecord.x;
equation
  bugRecord = BugRecord.'+'(Bug.BugRecord(1), Bug.BugRecord(3));
end Bug;

which is kind of messed up, because all the bindings are lost, so it is not clear how correct code can be produced, unless there is a bug in the function generating the flattened code from the internal AST representation. Please check that

comment:5 in reply to: ↑ 4 Changed 6 years ago by perost

Replying to casella:

which is kind of messed up, because all the bindings are lost, so it is not clear how correct code can be produced, unless there is a bug in the function generating the flattened code from the internal AST representation. Please check that

The binding is there in the DAE, but it's not output by DAEDump for some reason. It's probably doing something similar to how record constructors are handled, and trying to fetch the binding from the function's output type instead of from the output itself.

Last edited 6 years ago by perost (previous) (diff)

comment:6 Changed 6 years ago by casella

  • Milestone changed from 2.0.0 to 2.1.0
  • Priority changed from high to low
  • Summary changed from Wrong behaviour of operator overloading example to Missing bindings in flattened operator overloading example

It would be nice to have the correct DAEDump, but it's not high priority now.

Note: See TracTickets for help on using tickets.