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)
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
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: ↓ 5 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.
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.
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:
in fact we still have a problem even with the new front-end, which reports
For the record, Dymola simulates this updated model correctly.