search for: ternopinit

...= Val->getValue(); assert(TheInit != this && "Infinite loop detected!"); if (Init *I = TheInit->getFieldInit(R, RV, FieldName)) // *** return I; else return 0; } return 0; } The line marked with *** doesn't evaluate TheInit as a TernOpInit correctly. It goes to the Init base class of getFieldInit and returns 0. Do we need to add a getFieldInit method on TernOpInit to evaluate the !if() and return the requested field of the result ("Val" in this case) ? On Thu, Jan 31, 2013 at 9:35 AM, Jakob Stoklund Olesen <stoklund at...

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, const Init *rhs,...

...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