[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2023-12-03 00:00:00         |2023-12-01 0:00

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #2)
> (In reply to Kewen Lin from comment #1)
> 
> > 
> > ranger makes use of type precision directly instead of something like
> > types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> > to make ranger unrestrict this check a bit, the justification is that for
> > float type its precision information is encoded in its underlying
> > real_format, if two float types underlying modes are the same, the precision
> > are actually the same. 
> > 
> > btw, the operand_check_ps seems able to call range_compatible_p?
> 
> It could, but just a precision check seemed enough at the time.
> The patch also went thru many iterations and it was only the final version
> that operand_check_p() ended up with types as the parameter rather than
> ranges.
> 
> You bring up a good point tho. I just switched those routines to call
> range_compatible_p() and checked it in.  Now it is all centralized in the
> one routine going forward. 

Nice! Thanks a lot for your prompt enhancement!

>  
> It does seem wrong that the float precision don't match, and weird that its
> hard to fix :-)   

Yes, I dislike it and thought it's not sensible and tried to fix, but as the
discussion in the thread mentioned above showed there were some historical
reasons and practical issues to fix it. At the time, Segher mentioned he had
some patches to avoid different modes having the same format but encountered
some issues before and would have a re-try, but now stage 1 passed again, I
guessed we have to stay with it in this release.

> It should now be possible to have range_compatible_p check
> the underlying mode for floats rather than the precision...  If there's a
> good argument for it, and you want to give that a shot...

I have to admit this idea is just a workaround, even the actual float precision
is encoded in the format associated to the underlying mode, but it's still
unexpected to have two types with the same underlying mode but different type
precision. I'm going to make and test a workaround patch since it affected the
build again as reported. :(