[Bug libstdc++/23667] New: [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[Bug libstdc++/23667] New: [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[jsm28 at gcc dot gnu dot org]

Between 20050829 and 20050830

FAIL: tr1/6_containers/unordered/hashtable/23465.cc execution test

appeared on both mainline and 4.0 branch, on hppa64-hp-hpux11.11 and
arm-none-eabi; this failure is a test which formerly reliably passed now
consistently timing out; gcc-testresults shows this timeout on some other
platforms as well.

-- 
           Summary: [4.0/4.1 Regression]
                    tr1/6_containers/unordered/hashtable/23465.cc execution
                    test times out
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jsm28 at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug libstdc++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-01 08:32 -------
Hi. Can you have a quick look at what is going on outside the testsuite? (as
usual, just change testsuite_hooks.h to cassert and any VERIFY to assert). For
reference, on a P4-2400/linux running the test takes around 1/4 of sec, therefore
I suspect something is going seriously wrong in the compiler... But, if it's just
a matter of making the testcase a little simpler (on the border of timing out on
those platforms), not a big deal, just let me know.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug libstdc++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcarlini at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug libstdc++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-09-02 16:12 -------
Subject: Re:  [4.0/4.1 Regression]
 tr1/6_containers/unordered/hashtable/23465.cc execution test times out

On Thu, 1 Sep 2005, pcarlini at suse dot de wrote:

> Hi. Can you have a quick look at what is going on outside the testsuite? (as
> usual, just change testsuite_hooks.h to cassert and any VERIFY to assert). For
> reference, on a P4-2400/linux running the test takes around 1/4 of sec, therefore
> I suspect something is going seriously wrong in the compiler... But, if it's just
> a matter of making the testcase a little simpler (on the border of timing out on
> those platforms), not a big deal, just let me know.

Running outside the testsuite, it appears to hang (taking at least 3min) 
on hppa64-hp-hpux11.11, whereas by comparison on the same machine but 
configured for hppa2.0w-hp-hpux11.11 (32-bit rather than 64-bit) it takes 
19s user time.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug libstdc++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-02 16:16 -------
(In reply to comment #2)
> Running outside the testsuite, it appears to hang (taking at least 3min) 
> on hppa64-hp-hpux11.11, whereas by comparison on the same machine but 
> configured for hppa2.0w-hp-hpux11.11 (32-bit rather than 64-bit) it takes 
> 19s user time.

I see. Everthing considered, I will make the testcase simpler, at least 10
times faster here and much lower memory consumption, will remain sufficiently
strict. Should not hang, however, we'll see...



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug libstdc++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-02 16:37 -------
An important note: I'm currently using an updated compiler (didn't in my
previous messages), 20050901, and I can confirm that on x86 (too) there is a
very large slow-down of the generated executable, of 1-2 orders of magnitude!
This means, that this problem is *real* and due to the compiler. Should be
definitely further investigated.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug libstdc++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-02 19:08 -------
A couple of numbers: the above mentioned 1/4 sec on P4-2400/linux has become
43 secs! :( The amended 23465 takes about 3.5 secs. This is with current mainline,
4_0-branch very similar. I'm currently trying to profile a bit this horrible
thing.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-02 19:18 -------
I am thinking this was caused by the patch for         PR c++/23099.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |c++
           Keywords|                            |missed-optimization
   Target Milestone|---                         |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug libstdc++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-02 19:23 -------
Now hashtable<>::m_rehash dominates the profile, more than 10 times bigger
than the second entry, hashtable<>::m_find_node. Before, when the things were
sane, the latter dominated it and m_rehash was much lower. Something is going
badly wrong.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++
           Keywords|missed-optimization         |
   Target Milestone|4.0.2                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |c++
           Keywords|                            |missed-optimization
   Target Milestone|---                         |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-02 19:31 -------
(In reply to comment #6)
> I am thinking this was caused by the patch for         PR c++/23099.
I should say how I came to this conclusion.
The only non front-end patches which changes code gen that went on both branches are:

2005-08-31  Richard Henderson  <rth@redhat.com>

        * expr.c (expand_expr_real_1) <VIEW_CONVERT_EXPR>: Force subregs
        into a pseudo before applying gen_lowpart.

2005-08-30  Richard Henderson  <rth@redhat.com>

        PR target/23630
        * expr.c (expand_expr_real_1) <VIEW_CONVERT_EXPR>: Use gen_lowpart
        whenever the mode sizes match.

But that should only improve things and not hurt things as we are no longer storing things on stacks.
And then the it could only be a C++ patch and that is the one only went in around the time noted here 
which could have caused a code gen:
2005-08-30  Volker Reichelt  <reichelt@igpm.rwth-aachen.de>

        PR c++/23586
        * parser.c (cp_parser_namespace_name): Move diagnostic for
        invalid namespace-name to here from ...
        * name-lookup.c (do_namespace_alias): ... here and ...
        (do_using_directive): ... here.  Remove dead code.

2005-08-28  Mark Mitchell  <mark@codesourcery.com>

        PR c++/23099
        * cp-tree.h (saved_scope): Add skip_evaluation.
        * decl.c (start_decl): Use DECL_INITIALIZED_IN_CLASS_P, not
        DECL_INITIAL, to determine whether or not a static data member was
        initialized in the class-specifier.
        (cp_finish_decl): Add comment.
        * init.c (integral_constant_value): Subtitute into the
        initializers for static data members in templates.
        * name-lookup.c (push_to_top_level): Save skip_evaluation.
        (pop_from_top_level): Restore it.
        * pt.c (instantiate_class_template): Do not substitute into the
        intializers of static data members when instantiating a class.
        (regenerate_decl_from_template): Simplify.
        (instantiate_decl): Tidy.  Substitute into the initializer for a
        static data member even when the definition of the data member is
        not available.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-02 21:29 -------
(In reply to comment #8)
> (In reply to comment #6)
> > I am thinking this was caused by the patch for         PR c++/23099.
> I should say how I came to this conclusion.
...

Thanks a lot Andrew.  Over the we I will try reverting a few patches and more
generally I will further investigate the issue.  Any additional help is much
appreciated, of course!

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-03 01:16 -------
Ok, I can confirm that Andrew's guess, about the involvment of Mark's patch:
what is happening is that, inside hashtable<>::m_rehash, X<0>::n_primes == 0
whereas, at line 383 of tr1/hashtable we find:

  template<int dummy>
    struct X
    {
      static const int n_primes = 256;
      static const unsigned long primes[n_primes + 1];
    };

therefore, n_primes is supposed to be 256. Then everything goes nuts, in
short, at every insertion a very costly rehashing happens.

Mark, can you please have a look at this issue? 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-03 01:31 -------
Sorry about the typo: X<0>::n_primes is found wrongly equal to zero (instead of
256) inside prime_rehash_policy::need_rehash.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-09-03 18:52 -------
Does anyone happen to have a smallish test-case for this one?

Obviously, I can build one of the affected toolchains, but if someone has a
cut-down test case handy, I'll take it. :-)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-03 19:04 -------
(In reply to comment #12)
> Does anyone happen to have a smallish test-case for this one?
> 
> Obviously, I can build one of the affected toolchains, but if someone has a
> cut-down test case handy, I'll take it. :-)

It effects all targets, just the slower the machine, the more likely the timeout.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-09-03 20:08 -------
Subject: Re:  [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc
 execution test times out

pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-03 19:04 -------
> (In reply to comment #12)
> 
>>Does anyone happen to have a smallish test-case for this one?
>>
>>Obviously, I can build one of the affected toolchains, but if someone has a
>>cut-down test case handy, I'll take it. :-)
> 
> 
> It effects all targets, just the slower the machine, the more likely the timeout.

Yes, but that makes it no easier for me to test and debug the problem.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-03 23:06 -------
(In reply to comment #14)
> Yes, but that makes it no easier for me to test and debug the problem.

Hi, today I tried, quickly, but failed to find a simple testcase. Tomorrow,
I'll try again, harder. Thanks for taking care of this issue: as far as I'm
concerned, tr1/unordered* are completely broken (now that we sorted out the
most important bugs and would be seriously usable for 4.0.2 :(
And the issue seems serious in general, anyway.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-09-04 03:08 -------
Subject: Re:  [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc
 execution test times out

pcarlini at suse dot de wrote:
> ------- Additional Comments From pcarlini at suse dot de  2005-09-03 23:06 -------
> (In reply to comment #14)
> 
>>Yes, but that makes it no easier for me to test and debug the problem.
> 
> 
> Hi, today I tried, quickly, but failed to find a simple testcase. Tomorrow,
> I'll try again, harder. Thanks for taking care of this issue: as far as I'm
> concerned, tr1/unordered* are completely broken (now that we sorted out the
> most important bugs and would be seriously usable for 4.0.2 :(
> And the issue seems serious in general, anyway.

Definitely!  One way or the other, I'll get this fixed, but I appreciate 
your help.  Please do make sure that you've got the patch I checked in 
today; it's possible that patch magically fixed the problem.  (We can hope!)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-09-04 14:10 -------
By the way, the error message I get with mainline (or current 4_0-branch):

reduced_2005_09_04.cc: In function 'int main()':
reduced_2005_09_04.cc:66: error: '(((int)X<0>::n_primes) == 256)' is not a valid
template argument for type 'bool' because it is a non-constant expression

is *very* interesting: non-constant?!?!?!

For comparison, with 4.0.1 (which is OK), if I change 256 -> 0:

reduced_2005_09_04.cc: In function 'int main()':
reduced_2005_09_04.cc:66: error: invalid use of undefined type 'struct
static_assert<false>'
reduced_2005_09_04.cc:59: error: declaration of 'struct static_assert<false>'

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-05 16:12 -------
Subject: Bug 23667

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2005-09-05 16:12:15

Modified files:
	gcc/cp         : ChangeLog pt.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/template: static15.C 

Log message:
	PR c++/23667
	* pt.c (tsubst_decl): Clear DECL_TEMPLATE_INSTANTIATED when
	copying a VAR_DECL.
	
	PR c++/23667
	* g++.dg/template/static15.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4870&r2=1.4871
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1028&r2=1.1029
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6010&r2=1.6011
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/static15.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-05 16:13 -------
Subject: Bug 23667

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	mmitchel@gcc.gnu.org	2005-09-05 16:13:03

Modified files:
	gcc/cp         : ChangeLog pt.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/template: static15.C 

Log message:
	PR c++/23667
	* pt.c (tsubst_decl): Clear DECL_TEMPLATE_INSTANTIATED when
	copying a VAR_DECL.
	
	PR c++/23667
	* g++.dg/template/static15.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.90&r2=1.4648.2.91
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.21&r2=1.978.2.22
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.377&r2=1.5084.2.378
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/static15.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667

[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-09-05 16:15 -------
Fixed in 4.0.2.

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


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667