> Right. I'm not sure what we should do about it, but "emit an external > reference and assume it resolves" is probably not it. Ok, let's live w/o rtti for half at least for now. Looks like very low important :)
>>> + ICS.Standard.setToType(0, Context.FloatTy); >>> + AddConversionSequenceStep(ICS, Entity.getType()); >>> >>> This should be modeled in the standard-conversion logic. >> What do you mean? > > I mean that adding a single implicit conversion step should be sufficient, > and then PerformImplicitConversion should generate the AST you want from that. Well, maybe. I just wanted to play 'safe' - I just did not know whether we might have complex conversion paths for __fp16 and tried to 'preserve' almost all logic here. I'll think about this case. >> Here foo(float) should be selected. > Okay, but if foo(float) doesn't exist, foo(double) should be selected. So > there's at least a floating-point conversion from half to double. I'll check this case. The codegen for half <-> double conversion is done during codegen stage via implicit conversion to float step (so, we'll have half <-> float <-> double conversion chain). > If you really think it's important, the appropriate thing to do would be to > make PerformImplicitConversion do it in ICK_BooleanConversion. Ok. The main problem is that precise semantics of __fp16 operations are not defined. So, I'm just trying to strictly follow the "all operations should be promoted to float" clause :) Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
