)]}'
{
  "commit": "6f32166346de2d1c0f6253e4fe37e8a6edac655d",
  "tree": "a2e4abcc24f314f006fddb864180d5f42a1248d8",
  "parents": [
    "5c62a2771f2c7d5301ee6456f1817098c2fea113"
  ],
  "author": {
    "name": "Jakub Jelinek",
    "email": "jakub@redhat.com",
    "time": "Fri Jul 31 08:56:03 2026 +0200"
  },
  "committer": {
    "name": "Jakub Jelinek",
    "email": "jakub@gcc.gnu.org",
    "time": "Fri Jul 31 08:56:03 2026 +0200"
  },
  "message": "range-op-float: Fix up inf handling in other reverse ops [PR126464]\n\nOn Thu, Jul 30, 2026 at 09:31:17AM +0200, Richard Biener wrote:\n\u003e \u003e The following testcase is miscompiled since my r16-1108 change.\n\u003e \u003e The problem is if we handle a reverse of a narrowing float to float cast\n\u003e \u003e (in the example there are double -\u003e float and long double -\u003e double\n\u003e \u003e cast) and the lhs range is [-inf, -inf] or [+inf, +inf] (note, regardless\n\u003e \u003e of whether some NaNs are allowed or not, so not necessarily\n\u003e \u003e lhs.known_isinf ()), then handling that range in the wider type also\n\u003e \u003e as [-inf, -inf] or [+inf, +inf] is wrong, e.g. for the double -\u003e float\n\u003e \u003e conversion, [-inf, -0x0.ffffff8p+128] double range could map to just\n\u003e \u003e that [-inf, -inf].  We have already float_widen_lhs_range function\n\u003e \u003e but that just extends the range by +/-1ulp or 0.5ulp if the bounds\n\u003e \u003e are finite.  If the range isn\u0027t singleton (except for optional NaN),\n\u003e \u003e then the minimum (or maximum) finite is already in the range, so this just\n\u003e \u003e extends the case where they are singleton.\n\u003e \u003e I don\u0027t know how to portably figure out that 0x0.ffffff8p+128 for\n\u003e \u003e double -\u003e float (especially when in float_widen_lhs_range we don\u0027t know\n\u003e \u003e yet the wider type), so the patch just uses the +/-1ulp extension (i.e.\n\u003e \u003e [-inf, min_finite] or [+inf, max_finite] case.\n\nOn a second thought, this actually isn\u0027t specific to just reverse of\nnarrowing float to float casts, it is a problem for any other reverse binary\nops too.\n\nE.g. the following testcase is miscompiled at -O2 since r13-3926-gd4c2f1d376da\n(but works with -O0).  The lhs of the addition is [-inf, -inf], one of its\noperand is [-1e304, -1e300] and we think the other operand has to be\n[-inf, -inf].  That is obviously wrong, even much larger operands can result\nin -inf, anything below -DBL_MAX + -1e300 where x + -1e300 doesn\u0027t round to\n-DBL_MAX or higher but to -inf.\n\nSo, the following patch just widens lb of +inf and ub of -inf by 1ulp for\nall callers (and thus doesn\u0027t need the also_inf argument.\n\n2026-07-31  Jakub Jelinek  \u003cjakub@redhat.com\u003e\n\n\tPR tree-optimization/126464\n\t* range-op-float.cc (float_widen_lhs_range): Remove also_inf\n\targument, replace its uses as if it was always true.\n\t(operator_cast::op1_range): Don\u0027t pass third argument to\n\tfloat_widen_lhs_range.\n\n\t* gcc.dg/torture/pr126464.c: New test.\n\nReviewed-by: Richard Biener \u003crguenth@suse.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e4daa97b0be857892d87a827ba93a49d55aba6c6",
      "old_mode": 33188,
      "old_path": "gcc/range-op-float.cc",
      "new_id": "a625202f5312160c209ed492e4504524e3cd06ef",
      "new_mode": 33188,
      "new_path": "gcc/range-op-float.cc"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "c0dced1eedc0c72366731113415263cb7c8f2ed6",
      "new_mode": 33188,
      "new_path": "gcc/testsuite/gcc.dg/torture/pr126464.c"
    }
  ]
}