https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Andrew Macleod from comment #19) > Created attachment 54313 [details] > better patch > > A more consistent approach.. rather than directly call relation_intersect() > from multiple places, add the floating point fix to > value_relation::intersect and always go through that. > > This will cause the normal oracle and the path oracle to both make the > previous adjustment to intersect for floating point operations. untested, > running tests now. I thought (unless somebody proves otherwise) that relation_intersect is actually just fine, the only thing that is incorrect (IMHO) for floating point with NaNs are the relation_union (VREL_L[TE], VREL_G[TE]) and relation_union (VREL_G[TE], VREL_L[TE]) cases, because those return VREL_NE or VREL_VARYING even when those are actually LTGT_EXPR (aka ordered and not equal) or ORDERED_EXPR. So, if the callers of relation_union know whether it is a relation for floating point with NAN or integral/pointer/floating point fast math can't they just tweak those cases?
