search for: ternopinits

...battery of tests on it, so it >> might cause other failures). >> >> Jakob, any idea about what the "right" fix is here? > > Sorry, no. > > I do recall seeing similar problems in the past where the ternary operators weren't properly evaluated, but left as TernOpInits in the final Records. > > I don't know of any use case where that would make sense, particularly since other operators get evaluated. Are they even in use in the tree? > > /jakob >

In the midst of making TableGen Inits unique, I've run into some very odd DenseMap behavior. I converted the TernOpInit to use a factory method that uses a DenseMap to unique objects. I have defined a DenseMapInfo for std::string that uses HashString from StringExtras.h. const TernOpInit *TernOpInit::get(TernaryOp opc, const Init *lhs, const Init *mhs,

...ere (I haven't run a full battery of tests on it, so it > might cause other failures). > > Jakob, any idea about what the "right" fix is here? Sorry, no. I do recall seeing similar problems in the past where the ternary operators weren't properly evaluated, but left as TernOpInits in the final Records. I don't know of any use case where that would make sense, particularly since other operators get evaluated. Are they even in use in the tree? /jakob

An extra call to resolveReferences after setting the value in the `let` does fix this, but I'm not sure that it is the right fix. The attached hackish patch seems to fix up a reduced version of the test case you gave here (I haven't run a full battery of tests on it, so it might cause other failures). Jakob, any idea about what the "right" fix is here? -- Sean Silva