[Bug c/107967] New: The gcc commit 2f7f9edd28d caused the glibc make check fails.

[Bug c/107967] New: The gcc commit 2f7f9edd28d caused the glibc make check fails.

[caiyinyu at loongson dot cn]

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

            Bug ID: 107967
           Summary: The gcc commit 2f7f9edd28d caused the glibc make check
                    fails.
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: caiyinyu at loongson dot cn
  Target Milestone: ---

The gcc commit 2f7f9edd28d caused the following glibc fails with glibc
configuration on x86:
../configure \                    
  CFLAGS="-O2 -g" CXXFLAGS="-O2 -g" \
                --prefix=/usr \    
                --disable-werror

But when we changed "-O2" to "-O1", these fails passed.

FAIL: math/test-double-cosh
FAIL: math/test-double-exp10
FAIL: math/test-double-expm1
FAIL: math/test-double-tgamma
FAIL: math/test-float128-cosh
FAIL: math/test-float128-exp10
FAIL: math/test-float128-lgamma
FAIL: math/test-float128-pow
FAIL: math/test-float128-tgamma
FAIL: math/test-float32-cosh
FAIL: math/test-float32-expm1
FAIL: math/test-float32-tgamma
FAIL: math/test-float32x-cosh
FAIL: math/test-float32x-exp10
FAIL: math/test-float32x-expm1
FAIL: math/test-float32x-tgamma
FAIL: math/test-float64-cosh
FAIL: math/test-float64-exp10
FAIL: math/test-float64-expm1
FAIL: math/test-float64-tgamma
FAIL: math/test-float64x-cosh
FAIL: math/test-float64x-tgamma
FAIL: math/test-float-cosh
FAIL: math/test-float-expm1
FAIL: math/test-float-tgamma
FAIL: math/test-ldouble-cosh
FAIL: math/test-ldouble-tgamma

[Bug tree-optimization/107967] The gcc commit 2f7f9edd28d caused the glibc make check fails.

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |tree-optimization
                 CC|                            |jakub at gcc dot gnu.org
           Keywords|                            |wrong-code

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think there have been followup fixes to that commit, but I'm not sure about
the glibc testsuite state

[Bug tree-optimization/107967] The gcc commit 2f7f9edd28d caused the glibc make check fails.

[caiyinyu at loongson dot cn]

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

--- Comment #2 from caiyinyu <caiyinyu at loongson dot cn> ---
I tested with latest gcc(commit 102f3cef568), and these fails still exist.
My gcc configuration:

../configure --prefix=/usr --libdir=/usr/lib64 --disable-bootstrap 
--enable-__cxa_atexit --enable-threads=posix --with-system-zlib
--enable-libstdcxx-time --enable-checking=release --enable-default-pie
--enable-languages=c,c++

[Bug tree-optimization/107967] [13 regression] The gcc commit 2f7f9edd28d caused the glibc make check fails.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
            Summary|The gcc commit 2f7f9edd28d  |[13 regression] The gcc
                   |caused the glibc make check |commit 2f7f9edd28d caused
                   |fails.                      |the glibc make check fails.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org
            Summary|[13 regression] The gcc     |[13 regression] The gcc
                   |commit 2f7f9edd28d caused   |commit r13-3923 caused the
                   |the glibc make check fails. |glibc make check fails.

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d

Note, I've just committed the PR107879 fix, but that one is for the reverse
operations.
And, we have still unresolved the PR107608 which on the other side could very
well be related or the cause of this.
BTW, Aldy, is there a way to disable all range related optimizations through
some command line option?  In the past, -fno-tree-vrp would do the trick, but
now that the ranger is used in lots of passes, I don't know what else to use.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
> 
> Note, I've just committed the PR107879 fix, but that one is for the reverse
> operations.
> And, we have still unresolved the PR107608 which on the other side could
> very well be related or the cause of this.
> BTW, Aldy, is there a way to disable all range related optimizations through
> some command line option?  In the past, -fno-tree-vrp would do the trick,
> but now that the ranger is used in lots of passes, I don't know what else to
> use.

Not really, as ranger clients are spread around various passes.  

I think you could return false from irange::supports_p() and
frange::supports_p() and that would block everyone using ranger.  It would
certainly stop range_of_expr and range_of_edge, which are the main workhorses.

If this is needed, perhaps we could check some global flag from these functions
to provide a way to disable ranger.  But I don't think it could be
-fno-tree-vrp because DOM uses ranger, but VRP is disabled for -O1.  Perhaps
some internal --param flag if this is only needed internally?

Richi at one time suggested that we should probably formalize what we mean by
range propagation and document what we are and aren't allowed to do.  Or
perhaps document that VRP might happen even for -fno-tree-vrp (as that's
definitely happening at -O1 through DOM's use of ranger (and previously evrp)).

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-12-05
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to caiyinyu from comment #2)
> I tested with latest gcc(commit 102f3cef568), and these fails still exist.

Do the glibc test logs provide some details on what exactly failed, if it is a
wrong-code issue or if the testcase expects some floating point exception that
isn't triggered?

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[caiyinyu at loongson dot cn]

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

--- Comment #6 from caiyinyu <caiyinyu at loongson dot cn> ---
Created attachment 54024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54024&action=edit
glibc tests build log and fails test result

build log: tmp-tst-math-2022-12-05.log
test results: test-xxx.out

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I can reproduce this, disabling all the +-*/ handlers fixes it.
It isn libm.so.6 that matters for the failures, not the tests themselves.
So far I've looked at the expm1 stuff, the failures are:
Failure: expm1 (0x1.86ap+16): Exception "Overflow" not set
Failure: expm1 (0x2.c5c4p+12): Exception "Overflow" not set
Failure: expm1 (0xf.ffffffffffff8p+1020): Exception "Overflow" not set
Failure: expm1 (0xf.fffffp+124): Exception "Overflow" not set
Failure: expm1_downward (0x1.86ap+16): Exception "Overflow" not set
Failure: Test: expm1_downward (0x1.86ap+16)
Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
Failure: expm1_downward (0x2.c5c4p+12): Exception "Overflow" not set
Failure: Test: expm1_downward (0x2.c5c4p+12)
Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
...
Failure: expm1_upward (0x1.86ap+16): Exception "Overflow" not set
Failure: expm1_upward (0x2.c5c4p+12): Exception "Overflow" not set
Failure: expm1_upward (0xf.ffffffffffff8p+1020): Exception "Overflow" not set
Failure: expm1_upward (0xf.fffffp+124): Exception "Overflow" not set

For all the arguments >= 710.0 or so (non-inf/nan), the path in the source is:
static const double
  huge = 1.0e+300,
  tiny = 1.0e-300,
  o_threshold = 7.09782712893383973096e+02;  /* 0x40862E42, 0xFEFA39EF */
...
          if (x > o_threshold)
            {
              __set_errno (ERANGE);
              return huge * huge;   /* overflow */
            }
and the file is compiled with -frounding-math.
So the reduced testcase for at least part of this PR is:
double
foo (void)
{
  const double huge = 1.0e+300;
  return huge * huge;
}
GCC 12 would compile this into return __builtin_inf (); only with
-fno-trapping-math,
not without it nor with -frounding-math.
Now, GCC trunk compiles this into return __builtin_inf (); with all of
-fno-trapping-math, default or -frounding-math.  For the default case, the
problem is the same as in 
PR107608.  But with -frounding-math, we have an extra problem with the value,
which
actually shouldn't be +INF but DBL_MAX.
E.g.
#include <fenv.h>
#include <stdio.h>

int
main ()
{
  volatile double huge = 1.0e+308;
  volatile double inf = __builtin_inf ();
  fesetround (FE_DOWNWARD);
  volatile double r1 = huge + huge;
  volatile double r2 = huge * huge;
  volatile double r3 = huge + inf;
  volatile double r4 = r2 + huge;
  volatile double r5 = inf - 1.0;
  volatile double r6 = inf - huge;
  fesetround (FE_TONEAREST);
  printf ("%e %e %e %e %e %e\n", r1, r2, r3, r4, r5, r6);
}
prints 1.797693e+308 1.797693e+308 inf 1.797693e+308 inf inf, so the behavior
seems to be if either operand is already inf, then the result should be inf
even when rounding to -inf (except special cases when it is nan), but if
neither operand is inf, when rounding downward it shouldn't be +inf but max
representable (or when rounding upward not -inf but min representable).
So I assume we should tweak frange_arithmetics for this behavior when
flag_rounding_math.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually, looking at:
288       // Be extra careful if there may be discrepancies between the
289       // compile and runtime results.
290       if ((mode_composite || (real_isneg (&inf) ? real_less (&result,
&value)
291                               : !real_less (&value, &result)))
292           && (inexact || !real_identical (&result, &value)))
I wonder if we didn't get it exactly wrong.
value is what is computed by real_arithmetic and result is that rounded to the
desired TYPE_MODE.
So, for non-mode_composite, if inf is negative, we want to find a low boundary.
Now, the value -> result conversion can round downward or upward or result can
be identical to value.
If real_less (&result, &value), it rounded it downward, if real_less (&value,
&result),
it rounded it upwards.
If we want low boundary and it was already rounded downward, we don't need to
round further.  So, I think we want
-         if ((mode_composite || (real_isneg (&inf) ? real_less (&result,
&value)
+         if ((mode_composite || (real_isneg (&inf) ? !real_less (&result,
&value)
                                  : !real_less (&value, &result)))
              && (inexact || !real_identical (&result, &value)))
which fixes the thinko/inconsistency.  Say on:
double
foo (void)
{
  const double huge = 1.0e+300;
  return huge * huge;
}

double
bar (void)
{
  const double huge = 1.0e+300;
  return huge * -huge;
}
current trunk optimizes foo to return Inf; but doesn't optimize bar to return
-Inf.

Now, at least for -fno-trapping-math -fno-rounding-math, I'd say we actually
want
return Inf; and return -Inf;, for -ftrapping-math per PR107608 resolution
compute
[Inf, Inf] or [-Inf, -Inf] ranges and only for -frounding-math use [DBL_MAX,
Inf]
and [-Inf, -DBL_MAX] ranges.
For that I guess we might want to special case
real_isinf (&result) && !real_isinf (&value) && !flag_rounding_math
cases or even just a subset of those when in round to even mode the computation
would
always round to infinity by far.

And another thing is mode_composite, if frange_nextafter is the right thing to
do
from infinity.  But I think (but can't find now where we say it) that double
double
is only supported in round to nearest mode, at least:
#include <fenv.h>
#include <stdio.h>

void
foo ()
{
  volatile double huge = 1.0e+308;
  volatile double inf = __builtin_inf ();
  fesetround (FE_DOWNWARD);
  volatile double r1 = huge + huge;
  volatile double r2 = huge * huge;
  volatile double r3 = huge + inf;
  volatile double r4 = r2 + huge;
  volatile double r5 = inf - 1.0;
  volatile double r6 = inf - huge;
  fesetround (FE_TONEAREST);
  printf ("%e %e %e %e %e %e\n", r1, r2, r3, r4, r5, r6);
}

void
bar ()
{
  volatile long double huge = 1.0e+308L;
  volatile long double inf = __builtin_infl ();
  fesetround (FE_DOWNWARD);
  volatile long double r1 = huge + huge;
  volatile long double r2 = huge * huge;
  volatile long double r3 = huge + inf;
  volatile long double r4 = r2 + huge;
  volatile long double r5 = inf - 1.0;
  volatile long double r6 = inf - huge;
  fesetround (FE_TONEAREST);
  printf ("%Le %Le %Le %Le %Le %Le\n", r1, r2, r3, r4, r5, r6);
}

int
main ()
{
  foo ();
  bar ();
  return 0;
}
goes wild on ppc64 and prints
1.797693e+308 1.797693e+308 inf 1.797693e+308 inf inf
1.797693e+308 -inf inf -inf inf inf
The -inf is quite far from +inf or LDBL_MAX.
Anyway, what I found is in libgcc/config/rs6000/ibm-ldouble-format is:
"Addition and subtraction are performed using library routines.  They
are not at present performed perfectly accurately, the result produced
will be within 1ulp of the range generated by adding or subtracting
1ulp from the input values, where a 'ulp' is 2^(e-106) given the
exponent 'e'.  In the presence of cancellation, this may be
arbitrarily inaccurate.  Subtraction is done by negation and addition.

Multiplication is also performed using a library routine.  Its result
will be within 2ulp of the correct result.

Division is also performed using a library routine.  Its result will
be within 3ulp of the correct result."
so for frange_arithmetics mode_composite we probably need to account for that
extra ulp on +-, 2ulps for * and 3ulps for /.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54029&action=edit
gcc13-pr107967.patch

Untested fix.  Deferring the mode_composite stuff for later.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[caiyinyu at loongson dot cn]

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

--- Comment #10 from caiyinyu <caiyinyu at loongson dot cn> ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 54029 [details]
> gcc13-pr107967.patch
> 
> Untested fix.  Deferring the mode_composite stuff for later.

There are still some fails and errors are almost all about "Exception "Divide
by zero" not set".

cat math/test-float64-lgamma.out:
testing _Float64 (without inline functions)
Failure: lgamma (-3): Exception "Divide by zero" not set
Failure: lgamma_downward (-3): Exception "Divide by zero" not set
Failure: lgamma_towardzero (-3): Exception "Divide by zero" not set
Failure: lgamma_upward (-3): Exception "Divide by zero" not set

Test suite completed:
  7880 test cases plus 5260 tests for exception flags and
    5260 tests for errno executed.
  4 errors occurred.


FAIL: math/test-double-lgamma
FAIL: math/test-double-log1p
FAIL: math/test-float-lgamma
FAIL: math/test-float-log1p
FAIL: math/test-float128-catan
FAIL: math/test-float128-catanh
FAIL: math/test-float128-lgamma
FAIL: math/test-float128-log
FAIL: math/test-float128-log1p
FAIL: math/test-float128-y0
FAIL: math/test-float128-y1
FAIL: math/test-float32-lgamma
FAIL: math/test-float32-log1p
FAIL: math/test-float32x-lgamma
FAIL: math/test-float32x-log1p
FAIL: math/test-float64-lgamma
FAIL: math/test-float64-log1p
FAIL: math/test-float64x-lgamma
FAIL: math/test-ldouble-lgamma

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[amacleod at redhat dot com]

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

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
> > 
> > Note, I've just committed the PR107879 fix, but that one is for the reverse
> > operations.
> > And, we have still unresolved the PR107608 which on the other side could
> > very well be related or the cause of this.
> > BTW, Aldy, is there a way to disable all range related optimizations through
> > some command line option?  In the past, -fno-tree-vrp would do the trick,
> > but now that the ranger is used in lots of passes, I don't know what else to
> > use.
> 
> Not really, as ranger clients are spread around various passes.  
> 
> I think you could return false from irange::supports_p() and
> frange::supports_p() and that would block everyone using ranger.  It would
> certainly stop range_of_expr and range_of_edge, which are the main
> workhorses.



yes, we could add some form of disable.. wmaybe add something like

--param=ranger-disable=[all|float|int|gori]
all - disables all ranger queries (ie, they return false)
float - removes support for folating point
int - removes support for integrals
gori - removes support for op1/op2 backwiding

I think we could do something like that if it was useful?  It would apply
across the board to any and all uses of ranger in all passes

We could also add a ranger dbgcnt counter too,which would we could trigger in
one or more of the routines...?

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2f187e9893916796992b60b278e743ec865f7418

commit r13-4549-g2f187e9893916796992b60b278e743ec865f7418
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Dec 8 10:34:26 2022 +0100

    range-op-float: Fix up frange_arithmetic [PR107967]

    The addition of PLUS/MINUS/MULT/RDIV_EXPR frange handlers causes
    miscompilation of some of the libm routines, resulting in lots of
    glibc test failures.  A part of them is purely PR107608 fold-overflow-1.c
    etc. issues, say when the code does
      return -0.5 / 0.0;
    and expects division by zero to be emitted, but we propagate -Inf
    and avoid the operation.
    But there are also various tests where we end up with different computed
    value from the expected ones.  All those cases are like:
     is:          inf   inf
     should be:   1.18973149535723176502e+4932   0xf.fffffffffffffff0p+16380
     is:          inf   inf
     should be:   1.18973149535723176508575932662800701e+4932  
0x1.ffffffffffffffffffffffffffffp+16383
     is:          inf   inf
     should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
     is:          inf   inf
     should be:   3.40282346e+38   0x1.fffffep+127
    and the corresponding source looks like:
    static const double huge = 1.0e+300;
    double whatever (...) {
    ...
      return huge * huge;
    ...
    }
    which for rounding to nearest or +inf should and does return +inf, but
    for rounding to -inf or 0 should instead return nextafter (inf, -inf);
    The rules IEEE754 has are that operations on +-Inf operands are exact
    and produce +-Inf (except for the invalid ones that produce NaN) regardless
    of rounding mode, while overflows:
    "a) roundTiesToEven and roundTiesToAway carry all overflows to â with the
    sign of the intermediate result.
    b) roundTowardZero carries all overflows to the formatâs largest finite
    number with the sign of the intermediate result.
    c) roundTowardNegative carries positive overflows to the formatâs largest
    finite number, and carries negative overflows to ââ.
    d) roundTowardPositive carries negative overflows to the formatâs most
    negative finite number, and carries positive overflows to +â."

    The behavior around overflows to -Inf or nextafter (-inf, inf) was actually
    handled correctly, we'd construct [-INF, -MAX] ranges in those cases
    because !real_less (&value, &result) in that case - value is finite
    but larger in magnitude than what the format can represent (but GCC
    internal's format can), while result is -INF in that case.
    But for the overflows to +Inf or nextafter (inf, -inf) was handled
    incorrectly, it tested real_less (&result, &value) rather than
    !real_less (&result, &value), the former test is true when already the
    rounding value -> result rounded down and in that case we shouldn't
    round again, we should round down when it didn't.

    So, in theory this could be fixed just by adding one ! character,
    -  if ((mode_composite || (real_isneg (&inf) ? real_less (&result, &value)
    +  if ((mode_composite || (real_isneg (&inf) ? !real_less (&result, &value)
                              : !real_less (&value, &result)))
    but the following patch goes further.  The distance between
    nextafter (inf, -inf) and inf is large (infinite) and expressions like
    1.0e+300 * 1.0e+300 always produce +inf in round to nearest mode by far,
    so I think having low bound of nextafter (inf, -inf) in that case is
    unnecessary.  But if it isn't multiplication but say addition and we are
    inexact and very close to the boundary between rounding to nearest
    maximum representable vs. rounding to nearest +inf, still using [MAX, +INF]
    etc. ranges seems safer because we don't know exactly what we lost in the
    inexact computation.

    The following patch implements that.

    2022-12-08  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/107967
            * range-op-float.cc (frange_arithmetic): Fix a thinko - if
            inf is negative, use nextafter if !real_less (&result, &value)
            rather than if real_less (&result, &value).  If result is +-INF
            while value is finite and -fno-rounding-math, don't do rounding
            if !inexact or if result is significantly above max representable
            value or below min representable value.

            * gcc.dg/pr107967-1.c: New test.
            * gcc.dg/pr107967-2.c: New test.
            * gcc.dg/pr107967-3.c: New test.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The rest is I believe dup of PR107608.