[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

------- Comment #10 from mmitchel at gcc dot gnu dot org  2005-10-31 03:11 -------
I had another round of thoughts about this bug.  It's clear that we need better
data structures to get this right.  It's not clear that I know what they should
be. 

In any case, yes, we should try to ameliorate this problem; leaving as P2.


-- 


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

------- Comment #11 from mmitchel at gcc dot gnu dot org  2005-11-06 00:55 -------
I thought that a key observation is that we only need to know (a) what empty
subobjects are at offset zero, and (b) what empty subobjects occur before the
location where we will next place a non-empty field or base.  Therefore, we can
avoid recording the offsets for any of the empty objects in the array other
than those at offset zero.

However, I forgot that empty classes do not necessarily have size one:

  class A {}; 
  class B : public A {};
  class C : public A, public B {}; // C empty, sizeof (C) == 2

So, the observation above has to be modified -- instead of just offset zero we
must care about empty objects at offsets < N, where N is the sizeof the largest
empty class we have thus far encountered in the translation unit.

That should still permit very considerable improvement.  I plan to work on
implementing this improvement soon.


-- 


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

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


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

------- Comment #12 from mmitchel at gcc dot gnu dot org  2005-11-06 19:41 -------
Subject: Bug 21308

Author: mmitchel
Date: Sun Nov  6 19:41:18 2005
New Revision: 106566

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106566
Log:
        PR c++/21308
        * class.c (sizeof_biggest_empty_class): New variable.
        (record_subobject_offsets): Don't record offsets past biggest
        empty class for data members.  Replace vbases_p parameter with
        is_data_member parameter.
        (build_base_field): Adjust call.
        (layout_class_type): Likewise.  Maintain
        sizeof_biggest_empty_class.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/class.c


-- 


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

------- Comment #13 from mmitchel at gcc dot gnu dot org  2005-11-06 19:53 -------
*** Bug 18462 has been marked as a duplicate of this bug. ***


-- 
Bug 21308 depends on bug 18462, which changed state.

Bug 18462 Summary: [3.4 Regression] Segfault on declaration of large array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

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

[Bug c++/21308] [3.4/4.0 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

------- Comment #14 from mmitchel at gcc dot gnu dot org  2005-11-06 19:56 -------
Fixed in 4.1.0.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.4/4.0/4.1 Regression]    |[3.4/4.0 Regression] Very
                   |Very high compile time      |high compile time


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

[Bug c++/21308] [3.4/4.0 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

------- Comment #15 from mmitchel at gcc dot gnu dot org  2005-11-07 23:10 -------
*** Bug 23457 has been marked as a duplicate of this bug. ***


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laurent dot deniau at cern
                   |                            |dot ch


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

[Bug c++/21308] [3.4/4.0 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |4.0.4


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

[Bug c++/21308] [4.0 Regression] Very high compile time

[echristo at apple dot com]

------- Comment #16 from echristo at apple dot com  2006-08-26 00:10 -------
Should this be closed as "unlikely to fix in 4.0"?


-- 


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

[Bug c++/21308] [4.0 Regression] Very high compile time

[laurent dot deniau at cern dot ch]

------- Comment #17 from laurent dot deniau at cern dot ch  2006-08-28 07:42 -------
Subject: Re:  [4.0 Regression] Very high compile time

echristo at apple dot com wrote:
> ------- Comment #16 from echristo at apple dot com  2006-08-26 00:10 -------
> Should this be closed as "unlikely to fix in 4.0"?

No idea. I am not the poster of this bug report.

Regards,

        Laurent.


-- 


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

[Bug c++/21308] [4.0 Regression] Very high compile time

[gdr at gcc dot gnu dot org]

------- Comment #18 from gdr at gcc dot gnu dot org  2007-01-18 04:05 -------
Fixed in GCC-4.1.1.
Won't fix in GCC-4.0.x


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.0.4                       |4.1.1


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-22 21:13 -------
Moving to 4.0.2 pre Mark.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.5                       |4.0.2


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.4                       |3.4.5


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-05-09 15:26 -------
Do we really have to call walk_subobject_offsets on every single array element?
Couldn't we delay that to the time anybody would be looking at that info?
Say extend the offsets splay tree, so that there would not only be INTEGER_CST
key nodes representing particular offsets, but also nodes representing an
offset interval, with value a TREE_VEC that could then be used to recreate
that information (i.e. contain enough info to call walk_subobject_offsets
in a loop with record_subobject_offset fn).
Instead of calling walk_subobject_offsets here 1 << 21 times, we could e.g.
call it on the first and last array element only and represent the middle
of the array (if any) with an interval.

-- 


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 02:29 -------
Removing 3.3.3 as the code which caused this is there just not active as -fabi-version=2 is needed to 
reproduce it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|3.3.3                       |3.2.3


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 02:10 -------
Both this and PR 18462 are caused by:
2002-09-30  Mark Mitchell  <mark@codesourcery.com>

        * class.c (walk_subobject_offsets): Correct the calculation of
        offsets for virtual bases.  Correct the counting of array 
        elements.
....

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org
            Summary|[4.0/4.1 Regression] Very   |[3.4/4.0/4.1 Regression]
                   |high compile time           |Very high compile time
   Target Milestone|4.0.1                       |3.4.4


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