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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org
   Last reconfirmed|                            |2026-08-05
             Target|x86_64-pc-linux-gnu         |x86_64-pc-linux-gnu,
                   |                            |aarch64*
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> I think we’re storing past what we can store in r->sig[].  Can someone try
> this and see if it fails, since I can’t reproduce on either ppc64le or
> aarch64?
> 
> diff --git a/gcc/real.cc b/gcc/real.cc
> index 29cb6a1edd2..6a76d26ad65 100644
> --- a/gcc/real.cc
> +++ b/gcc/real.cc
> @@ -399,6 +399,7 @@ cmp_significand_0 (const REAL_VALUE_TYPE *a)
>  static inline void
>  set_significand_bit (REAL_VALUE_TYPE *r, unsigned int n)
>  {
> +  gcc_assert (n < SIGNIFICAND_BITS);
>    r->sig[n / HOST_BITS_PER_LONG]
>      |= (unsigned long)1 << (n % HOST_BITS_PER_LONG);
>  }

Yeah, the assert hits for me

during GIMPLE pass: ethread
/opt/buildAgent/work/5c94c4ced6ebfcd0/libgfortran/intrinsics/trigd.c: In
function 'sind_r4':
/opt/buildAgent/work/5c94c4ced6ebfcd0/libgfortran/intrinsics/trigd.c:296:
internal compiler error: in set_significand_bit, at real.cc:402
  296 |
mv -f .deps/barrier.Tpo .deps/barrier.Plo
mv -f .deps/beginend.Tpo .deps/beginend.Plo
mv -f .deps/method-serial.Tpo .deps/method-serial.Plo
0x20cf70b internal_error(char const*, ...)
       
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/diagnostic-global-context.cc:787
0x82be47 fancy_abort(char const*, int, char const*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/diagnostics/context.cc:1813
0x82b00f set_significand_bit
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/real.cc:402
0xe3f15f set_significand_bit
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/real.cc:5401
0xe3f15f real_nextafter(real_value*, format_helper, real_value const*,
real_value const*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/real.cc:5394
0xe1f123 frange_nextafter(machine_mode, real_value&, real_value const&)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/range-op-float.cc:314
0x121ccfb frange_fusible_p
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/value-range.cc:1041
0x121ccfb frange::set_pairs(frange_pair*, unsigned int)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/value-range.cc:1129
0x121d707 frange::union_(vrange const&)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/value-range.cc:1394
0xe206c3 float_widen_lhs_range
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/range-op-float.cc:2430
0xe23497 operator_minus::op2_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/range-op-float.cc:2516
0xb96bfb gimple_range_op_handler::calc_op2(vrange&, vrange const&, vrange
const&, relation_trio)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/gimple-range-op.cc:256
0xb8ddd3 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, fur_source&, value_relation*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/gimple-range-gori.cc:1261
0xb8e983 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/gimple-range-gori.cc:679
0xb8eee7 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/gimple-range-gori.cc:791
0xb8ffd7 gori_compute::edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/gimple-range-gori.cc:1443
0x109b133 path_range_query::compute_ranges_in_block(basic_block_def*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/gimple-range-path.cc:421
0x109b59b path_range_query::compute_ranges(bitmap_head const*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/gimple-range-path.cc:588
0x11219df back_threader::find_taken_edge_cond(vec<basic_block_def*, va_heap,
vl_ptr> const&, gcond*)
       
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-ssa-threadbackward.cc:321
0x11220ab back_threader::maybe_register_path(back_threader_profitability&)
       
/opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-ssa-threadbackward.cc:245

I'm not a floating point expert either... It looks like float_widen_bound can
create floating point values that are not inside the targets representable
range during the

  if (!flag_rounding_math
      && !MODE_COMPOSITE_P (TYPE_MODE (type))
      && real_isfinite (&bound))
    {
      /* If not -frounding-math nor IBM double double, actually widen
         just by 0.5ulp rather than 1ulp.  */
      REAL_VALUE_TYPE tem;
      real_arithmetic (&tem, PLUS_EXPR, &bound, &res);
      real_arithmetic (&res, RDIV_EXPR, &tem, &dconst2);
    }

part.

So if bound is the smallest positive float subnormal

bound = 2^-149

then

res = +0.0
(bound + res) / 2
  = (2^-149 + 0) / 2
  = 2^-150

and 2^-150 isn't representative as a float, but is encodable in GCC's internal
REAL_VALUE_TYPE.

real_nextafter then collapses

  int np2 = SIGNIFICAND_BITS - fmt->p;
  /* For denormals adjust np2 correspondingly.  */
  if (x->cl == rvc_normal && REAL_EXP (x) < fmt->emin)
    np2 += fmt->emin - REAL_EXP (x);
..
  set_significand_bit (&u, np2);

into np2 = SIGNIFICAND_BITS - fmt->p + fmt->emin - REAL_EXP (x)

so based on gcc/real.cc:3115

fmt->emin - fmt->p = -149
fmt->p = 24, fmt->emin = -125

and so

  np2 = SIGNIFICAND_BITS - 24 + (-125 - -149)
      = SIGNIFICAND_BITS - 24 + 24
      = SIGNIFICAND_BITS

which means SIGNIFICAND_BITS is out of bounds.

So I guess real_nextafter needs to detect this and do something else?

But equally I'm unsure if the range code is supposed to be able to create
ranges that aren't representative in the target format.

So I'll leave it to an FP expert :)

Reply via email to