[Bug ipa/64694] New: [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[Bug ipa/64694] New: [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

            Bug ID: 64694
           Summary: [5 Regression] FAIL:
                    23_containers/unordered_set/insert/hash_policy.cc
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com

On Linux/x32, r219081 gave

FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
FAIL: 23_containers/unordered_set/max_load_factor/robustness.cc execution test

r219074 is OK.

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-20
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
It is caused by r219076.

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at ucw dot cz

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
r219076 has

1674        return target_cfa - current->cfa + target->args_size;
(gdb) bt
#0  uw_install_context_1 (current=current@entry=0xffffcc00, 
    target=target@entry=0xffffcce0)
    at ../../../../../../gcc/libgcc/unwind-dw2.c:1674
#1  0xf757fd4e in _Unwind_RaiseException (exc=<optimized out>)
    at ../../../../../../gcc/libgcc/unwind.inc:135
#2  0x00402bb6 in std::_Hashtable<int, int,
__gnu_cxx::throw_allocator_limit<int>, std::__detail::_Identity,
std::equal_to<int>, std::hash<int>, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits<false, true, true> >::_M_rehash
    (this=this@entry=0xffffd0c0, __n=<optimized out>, __state=@0xffffd0ac: 199)
    at
/export/gnu/import/git/gcc-regression/master/219077/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/include/bits/hashtable.h:1953
#3  0x00403533 in __rehash_policy (__pol=..., this=0xffffd0c0)
    at
/export/gnu/import/git/gcc-regression/master/219077/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/include/bits/hashtable.h:1291
#4  max_load_factor (__z=0.5, this=0xffffd0c0)
    at
/export/gnu/import/git/gcc-regression/master/219077/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/include/bits/hashtable_policy.h:953
#5  max_load_factor (__z=0.5, this=0xffffd0c0)
    at
/export/gnu/import/git/gcc-regression/master/219077/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/include/bits/unordered_set.h:678
#6  test01 ()
    at
/export/gnu/import/git/gcc-regression/gcc/libstdc++-v3/testsuite/23_conta---Type
<return> to continue, or q <return> to quit---
iners/unordered_set/max_load_factor/robustness.cc:48
#7  0x00400f78 in main ()
    at
/export/gnu/import/git/gcc-regression/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/max_load_factor/robustness.cc:75
(gdb) 

return target_cfa - current->cfa + target->args_size;

returns 0xd0.  But it should be 0x30.

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 34509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34509&action=edit
A testcase

Compile with -O2 -std=gnu++11 -mx32.

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
r219076 introduced:

      if (current_badness != badness)
        {
          if (edge_heap.min () && badness > edge_heap.min_key ())
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                  Does it look right?
            {
              edge->aux = edge_heap.insert (current_badness, edge);
              continue;
            }    
          else
            badness = current_badness;
        }

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
> 
> --- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
> r219076 introduced:
> 
>       if (current_badness != badness)
>         {
>           if (edge_heap.min () && badness > edge_heap.min_key ())
>                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                                   Does it look right?

This is a thinko, indeed.  I am testing a fix, but I doubdt this can affect
correctness
of a testcase.  I see it does inlining, but why it depends on inline decisions?

Honza
>             {
>               edge->aux = edge_heap.insert (current_badness, edge);
>               continue;
>             }    
>           else
>             badness = current_badness;
>         }
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
> 
> --- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
> > 
> > --- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
> > r219076 introduced:
> > 
> >       if (current_badness != badness)
> >         {
> >           if (edge_heap.min () && badness > edge_heap.min_key ())
> >                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >                                   Does it look right?
> 
> This is a thinko, indeed.  I am testing a fix, but I doubdt this can affect
> correctness
> of a testcase.  I see it does inlining, but why it depends on inline decisions?
I meant unwinding.

Honza

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jan Hubicka from comment #6)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
> > 
> > --- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
> > > 
> > > --- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
> > > r219076 introduced:
> > > 
> > >       if (current_badness != badness)
> > >         {
> > >           if (edge_heap.min () && badness > edge_heap.min_key ())
> > >                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >                                   Does it look right?
> > 
> > This is a thinko, indeed.  I am testing a fix, but I doubdt this can affect
> > correctness

This patch

---
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index da1afc6..aa93928 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -1794,7 +1794,7 @@ inline_small_functions (void)
 #endif
       if (current_badness != badness)
   {
-    if (edge_heap.min () && badness > edge_heap.min_key ())
+    if (edge_heap.min () && current_badness > edge_heap.min_key ())
       {
         edge->aux = edge_heap.insert (current_badness, edge);
         continue;
---

works for me.

> > of a testcase.  I see it does inlining, but why it depends on inline decisions?
> I meant unwinding.
> 

That is a very interesting question.

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed.

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I would say it most probably just gone latent again. Is the ICE actually a
failure to deliver an exception from simulated out-of-memory event?

Jan

[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jan Hubicka from comment #10)
> I would say it most probably just gone latent again. Is the ICE actually a
> failure to deliver an exception from simulated out-of-memory event?
> 

Yes, the crash happened due to exception handler failure to unwind
the stack.