https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #22 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #21) > (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? I have since evolved to something close to this. I am moving all the relation_intersect and relation_union calling locations to instead go through the existing value_relation class. This stores a relation and 2 operands, and isolates all the smarts for swapping operands and reversing relations as needed. (this is how the oracle internally handles it). That class then knows whether this is a floating point relation or not an can make adjustments based on that, keeping it isolated to one place. We wont have the actual floating point status of NAN and such, but we can at least not get it wrong for this release in those cases. THen decide how to add the required knowledge properly for the next release... maybe just adding a couple of extra relations will be enough. Patch forthcoming soon.
