[Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361

[Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361

[asolokha at gmx dot com]

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

            Bug ID: 97721
           Summary: [11 Regression] ICE in verify_range, at
                    value-range.cc:361
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20201101 snapshot (g:590febb5f6624f78b36402a7c9a9c318978f1efa)
ICEs when compiling the following testcase w/ -O1 -fno-tree-dominator-opts:

int ot;

void
z6 (char *tw)
{
  while (ot >= 0)
    --ot;

  __builtin_strcpy (&tw[ot], tw);
}

% gcc-11.0.0 -O1 -fno-tree-dominator-opts -c xcjgghki.c
during GIMPLE pass: wrestrict
xcjgghki.c: In function 'z6':
xcjgghki.c:4:1: internal compiler error: in verify_range, at value-range.cc:361
    4 | z6 (char *tw)
      | ^~
0x726a05 irange::verify_range()
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/value-range.cc:361
0x10bc9bb irange::irange_intersect(irange const&)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/value-range.cc:1752
0x176007d irange::intersect(irange const&)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/value-range.h:541
0x176007d gori_compute::compute_name_range_op(irange&, gimple*, irange const&,
tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range-gori.cc:495
0x176363e gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range-gori.cc:575
0x176363e gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range-gori.cc:1280
0x17625e7 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range-gori.cc:1003
0x175e52e ranger_cache::iterative_cache_update(tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range-cache.cc:632
0x175ea72 ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range-cache.cc:804
0x175f22d ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range-cache.cc:585
0x1757a60 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:942
0x175843b gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:913
0x1757b5b gimple_ranger::range_on_exit(irange&, basic_block_def*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:963
0x1757d36 gimple_ranger::range_on_edge(irange&, edge_def*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:980
0x175b769 gimple_ranger::range_of_phi(irange&, gphi*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:504
0x175bc7d gimple_ranger::calc_stmt(irange&, gimple*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:374
0x175be5e gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:1020
0x1758508 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:910
0x1759864 gimple_ranger::range_of_range_op(irange&, gimple*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:427
0x175ba5a gimple_ranger::calc_stmt(irange&, gimple*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-range.cc:372

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |aldyh at gcc dot gnu.org
   Target Milestone|---                         |11.0

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com,
                   |                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|                            |2020-11-05
      Known to work|                            |10.2.0
      Known to fail|                            |11.0
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r11-4135-ge864d395b4e862ce.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
The ranger is analyzing a statement with an integer overflow, and creating a
non-legacy range that is invalid:

(gdb) p debug(stmt)
if (_1 != -1(OVF))

(gdb) p debug(op2_range)
int [-1(OVF), -1(OVF)]

(gdb) p op2_range.legacy_mode_p()
$8 = false

Legacy ranges allow TREE_OVERFLOW to creep in, as the verifier allows symbolics
and other end points that are not comparable at compile time (cmp == -2 below):

    case VR_ANTI_RANGE:
    case VR_RANGE:
      {
        gcc_assert (m_num_ranges == 1);
        int cmp = compare_values (tree_lower_bound (0), tree_upper_bound (0));
        gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
        return;
      }

However, we're a bit more strict in irange.  We don't allow un-comparable
endpoints and TREE_OVERFLOW integers are such.

I'm not sure where to fix this.

Is the original statement valid gimple?  Richard has mentioned that any time
there's a TREE_OVERFLOW in the IL, it's a sign of a bug.  If the IL is wrong,
we should tackle the source problem.

If the IL is ocrrect, then perhaps we could drop OVF at range creation.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems ivopts changes:
@@ -24,7 +24,7 @@ z6 (char * tw)
   <bb 3> [local count: 955630225]:
   # ot.1_12 = PHI <_1(6), ot.1_11(5)>
   _1 = ot.1_12 + -1;
-  if (_1 >= 0)
+  if (_1 != -1(OVF))
     goto <bb 6>; [89.00%]
   else
     goto <bb 9>; [11.00%]

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We have drop_tree_overflow, so perhaps ivopts could use if (TREE_OVERFLOW_P
(whatever)) whatever = drop_tree_overflow (whatever); somewhere.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #2)
> The ranger is analyzing a statement with an integer overflow, and creating a
> non-legacy range that is invalid:
> 
> (gdb) p debug(stmt)
> if (_1 != -1(OVF))
> 
> (gdb) p debug(op2_range)
> int [-1(OVF), -1(OVF)]
> 
> (gdb) p op2_range.legacy_mode_p()
> $8 = false
> 
> Legacy ranges allow TREE_OVERFLOW to creep in, as the verifier allows
> symbolics and other end points that are not comparable at compile time (cmp
> == -2 below):
> 
>     case VR_ANTI_RANGE:
>     case VR_RANGE:
>       {
> 	gcc_assert (m_num_ranges == 1);
> 	int cmp = compare_values (tree_lower_bound (0), tree_upper_bound (0));
> 	gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
> 	return;
>       }
> 
> However, we're a bit more strict in irange.  We don't allow un-comparable
> endpoints and TREE_OVERFLOW integers are such.
> 
> I'm not sure where to fix this.
> 
> Is the original statement valid gimple?  Richard has mentioned that any time
> there's a TREE_OVERFLOW in the IL, it's a sign of a bug.  If the IL is
> wrong, we should tackle the source problem.
> 
> If the IL is ocrrect, then perhaps we could drop OVF at range creation.

Yes, the IL is "correct", just inefficent and possibly confusing to passes.

The OVF flag on INTEGER_CST have _no_ semantic meaning in the IL so making
them "invalid" in ranger doesn't make sense.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Aldy Hernandez from comment #2)

> Yes, the IL is "correct", just inefficent and possibly confusing to passes.
> 
> The OVF flag on INTEGER_CST have _no_ semantic meaning in the IL so making
> them "invalid" in ranger doesn't make sense.

The ranger treating them invalid was a precaution since the conversion to trees
brought the use of compare_values_warnv(), which claims overflowed values
cannot be compared.  But if in fact they can be compared, then perhaps
compare_values_warnv is wrong in claiming the opposite:

  /* We cannot say anything more for non-constants.  */
  if (!cst1 || !cst2)
    return -2;

  if (!POINTER_TYPE_P (TREE_TYPE (val1)))
    {
      /* We cannot compare overflowed values.  */
      if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
        return -2;

What do you think?

It would seem to me that removing this restriction would work, especially since
tree_int_cst_compare, which this function uses, just degrades to wide ints,
which don't care about TREE_OVERFLOW.

[untested]

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index e00c034fee3..8702ad1ae8d 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -609,10 +609,6 @@ compare_values_warnv (tree val1, tree val2, bool
*strict_overflow_p)

   if (!POINTER_TYPE_P (TREE_TYPE (val1)))
     {
-      /* We cannot compare overflowed values.  */
-      if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
-       return -2;
-
       if (TREE_CODE (val1) == INTEGER_CST
          && TREE_CODE (val2) == INTEGER_CST)
        return tree_int_cst_compare (val1, val2);
@@ -635,13 +631,7 @@ compare_values_warnv (tree val1, tree val2, bool
*strict_overflow_p)
   else
     {
       if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
-       {
-         /* We cannot compare overflowed values.  */
-         if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
-           return -2;
-
-         return tree_int_cst_compare (val1, val2);
-       }
+       return tree_int_cst_compare (val1, val2);

       /* First see if VAL1 and VAL2 are not the same.  */
       if (operand_equal_p (val1, val2, 0))

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or when
folding some expression.  It just doesn't belong into the GIMPLE IL.
So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
somewhere in the IL not to set the range to that constant, but to
drop_tree_overflow of it.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[aldyh at gcc dot gnu.org]

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

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> when folding some expression.  It just doesn't belong into the GIMPLE IL.
> So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
> somewhere in the IL not to set the range to that constant, but to
> drop_tree_overflow of it.

That's certainly the easiest path for us.  We could drop_overflow in
get_tree_range while creating said ranges, and then no other changes to the
ranger are needed.

However, I wonder if compare_values_warnv is being unnecessarily restrictive. 
For example, here, we bail on overflow, even though tree_int_cst_compare,
through its use of wi::cmps, is perfectly capable of comparing these integers:

  if (!POINTER_TYPE_P (TREE_TYPE (val1)))
    {
      /* We cannot compare overflowed values.  */
      if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
        return -2;

      if (TREE_CODE (val1) == INTEGER_CST
          && TREE_CODE (val2) == INTEGER_CST)
        return tree_int_cst_compare (val1, val2);

as well as here:

     if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
        {
          /* We cannot compare overflowed values.  */
          if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
            return -2;

          return tree_int_cst_compare (val1, val2);
        }

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> > when folding some expression.  It just doesn't belong into the GIMPLE IL.
> > So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
> > somewhere in the IL not to set the range to that constant, but to
> > drop_tree_overflow of it.
> 
> That's certainly the easiest path for us.  We could drop_overflow in
> get_tree_range while creating said ranges, and then no other changes to the
> ranger are needed.
> 
> However, I wonder if compare_values_warnv is being unnecessarily
> restrictive.  For example, here, we bail on overflow, even though
> tree_int_cst_compare, through its use of wi::cmps, is perfectly capable of
> comparing these integers:
> 
>   if (!POINTER_TYPE_P (TREE_TYPE (val1)))
>     {
>       /* We cannot compare overflowed values.  */
>       if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> 	return -2;
> 
>       if (TREE_CODE (val1) == INTEGER_CST
> 	  && TREE_CODE (val2) == INTEGER_CST)
> 	return tree_int_cst_compare (val1, val2);
> 
> as well as here:
> 
>      if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> 	{
> 	  /* We cannot compare overflowed values.  */
> 	  if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> 	    return -2;
> 
> 	  return tree_int_cst_compare (val1, val2);
> 	}

VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
on some TREE_OVERFLOW bits therein.  This might be all long history
but the above is probably because of that.

Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
of the IL for VRP purposes (as said, some passes are "confused" about
existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
internal processing - which, nowadays should use wide_int).

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[aldyh at redhat dot com]

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

--- Comment #10 from Aldy Hernandez <aldyh at redhat dot com> ---
> > as well as here:
> >
> >      if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> >       {
> >         /* We cannot compare overflowed values.  */
> >         if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> >           return -2;
> >
> >         return tree_int_cst_compare (val1, val2);
> >       }
>
> VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
> on some TREE_OVERFLOW bits therein.  This might be all long history
> but the above is probably because of that.
>
> Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
> of the IL for VRP purposes (as said, some passes are "confused" about
> existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
> internal processing - which, nowadays should use wide_int).

Ok, let's let sleeping dogs lie then.  I'll drop the overflow will
building ranges.

Thanks for the explanation.

I'll commit the following if it passes tests.
Aldy

    Drop overflow from constants while building ranges in ranger.

    Sometimes overflow flag will leak into the IL.  Drop them while
    creating ranges.

    gcc/ChangeLog:

            PR tree-optimization/97721
            * gimple-range.cc (get_tree_range): Drop overflow from constants.

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr97721.c: New test.

diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index cf979845acf..6d351002830 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -165,6 +165,8 @@ get_tree_range (irange &r, tree expr)
   switch (TREE_CODE (expr))
     {
       case INTEGER_CST:
+    if (TREE_OVERFLOW_P (expr))
+      expr = drop_tree_overflow (expr);
     r.set (expr, expr);
     return true;

diff --git a/gcc/testsuite/gcc.dg/pr97721.c b/gcc/testsuite/gcc.dg/pr97721.c
new file mode 100644
index 00000000000..c2a2848ba13
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97721.c
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-O -fno-tree-dominator-opts" }
+
+int ot;
+
+void
+z6 (char *tw)
+{
+  while (ot >= 0)
+    --ot;
+
+  __builtin_strcpy (&tw[ot], tw);
+}

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:4ef0f1e90f1795b1f2d5bba05ed299e8c7635fd4

commit r11-4743-g4ef0f1e90f1795b1f2d5bba05ed299e8c7635fd4
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Thu Nov 5 12:40:51 2020 +0100

    Drop overflow from constants while building ranges in ranger.

    Sometimes the overflow flag will leak into the IL.  Drop it while
    creating ranges.

    There are various places we could plug this.  This patch just plugs things
    at get_tree_range which is the entry point for ranges from tree
expressions.
    It fixes the PR, and probably fixes the ranger entirely, but we may need
    to revisit this.

    For example, I looked to see if there were other places that created
    ranges with TREE_OVERFLOW set, and there are various.  For example,
    the following code pattern appears multiple times in vr-values.c:

      else if (is_gimple_min_invariant (op0))
        vr0.set (op0);

    This can pick up TREE_OVERFLOW from the IL if present.  However, the
    ranger won't see them so we're good.

    At some point we should audit all this.  Or perhaps just nuke all
    TREE_OVERFLOW's at irange::set.

    For now, this will do.

    gcc/ChangeLog:

            PR tree-optimization/97721
            * gimple-range.cc (get_tree_range): Drop overflow from constants.

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr97721.c: New test.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[aldyh at gcc dot gnu.org]

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

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

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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
fixed