On Thu, 2022-08-18 at 11:44 +0200, Tim Lange wrote: > Hi, > > this is the revised version of my patch. I had trouble to get your > point regarding the float_visitor: > > > If the constant is seen first, then the non-constant won't be > > favored > > (though perhaps binary ops get canonicalized so that constants are > > on > > the RHS?). > > Only the assignment of m_result in visit_constant_svalue is guarded > by > !m_result, while the other two are not. So, there are two > possibilities: > 1. A constant is seen first and then assigned to m_result. > 1.1. A non-constant float operand is seen later and > overwrites m_result. > 1.2. There's no non-constant float operand, thus the > constant is the actual floating-point operand > and > is kept inside m_result. > 2. A non-constant is seen first, then m_result might be > overwritten with another non-constant later but never > with a constant. > Do I have a flaw in my thinking? (But they do seem to get > canonicalized, > so that shouldn't matter)
I think I was confused here, and that you're right. Sorry about that. > > > How about: > > -Wanalyzer-imprecise-float-arithmetic > > -Wanalyzer-imprecise-fp-arithmetic > > instead? (ideas welcome) > > I've chosen the second. I mostly tried to avoid float because it is > also > a reserved keyword in many languages and I wanted to avoid confusion > (might be overthinking that). Fair enough. > > - Tim > > This patch fixes the ICE reported in PR106181 and adds a new warning > to > the analyzer complaining about the use of floating-point operands. > > Regrtested on Linux x86_64. Thanks; the patch looks good for trunk. Dave
