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

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

[peturrun at internet dot is]

Compiling this program takes a very long time with GCC 4.x compared with GCC
3.3. GCC 3.4 fails to compile it, which has already been reported as PR18462.

Compile times for current mainline, GCC 4.0 and GCC 3.3 on a 500 MHz Pentium III
with 512 MB RAM:

[petur@interim cgx]$ time g++-cvs -O3 -c CheckersGameX.ii

real    0m41.298s
user    0m39.016s
sys     0m0.958s
[petur@interim cgx]$ g++-cvs -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-cvs/configure --program-suffix=-cvs
--enable-threads=posix --enable-languages=c,c++ --enable-__cxa_atexit
--prefix=/home/petur/opt/gcc-cvs --disable-checking
Thread model: posix
gcc version 4.1.0 20050430 (experimental)
[petur@interim cgx]$ time g++400 -O3 -c CheckersGameX.ii

real    0m43.372s
user    0m39.739s
sys     0m0.966s
[petur@interim cgx]$ g++400 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --program-suffix=400
--enable-version-specific-runtime-libs --enable-threads=posix
--enable-languages=c,c++,java --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.0
[petur@interim cgx]$ time g++335 -O3 -c CheckersGameX.ii

real    0m0.115s
user    0m0.051s
sys     0m0.018s
[petur@interim cgx]$ g++335 -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs
Configured with: ../gcc-3.3.5/configure --program-suffix=335
--enable-threads=posix --enable-version-specific-runtime-libs
--enable-languages=c,c++
Thread model: posix
gcc version 3.3.5

-- 
           Summary: [4.0/4.1 Regression] Very high compile time
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: peturrun at internet dot is
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

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

[peturrun at internet dot is]

------- Additional Comments From peturrun at internet dot is  2005-04-30 21:39 -------
Created an attachment (id=8775)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8775&action=view)
Preprocessed source code


-- 


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

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

[peturrun at internet dot is]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8775|application/octet-stream    |text/plain
          mime type|                            |


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

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

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-30 23:07 -------
All the time is in walk_subobject_offsets.
...

#10 0x080e8dc9 in walk_subobject_offsets (type=0x400d08dc, f=0x80e8188
<record_subobject_offset>, offset=0x400261b0, offsets=0x8877418,
    max_offset=0x0, vbases_p=1) at class.c:3258
#11 0x080e9655 in record_subobject_offsets (type=0x400d08dc, offset=0x400261b0,
offsets=0x8877418, vbases_p=1) at class.c:3320
#12 0x080f0e88 in layout_class_type (t=0x400d0af8, virtuals_p=0xbfffec3c) at
class.c:4674
#13 0x080f287e in finish_struct_1 (t=0x400d0af8) at class.c:4942
#14 0x080f4002 in finish_struct (t=0x400d0af8, attributes=0x0) at class.c:5137
#15 0x08128075 in cp_parser_class_specifier (parser=0x400c0750) at parser.c:12494


-- 


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

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

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-30 23:25 -------
If we used integers instead of computing this all using size_binop, this
testcase would take no time at all

-- 


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

[Bug c++/21308] [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-04-30 23:36 -------
Note this is a reduced testcase from ssb:
struct T { struct {} t [1<<21]; };

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |compile-time-hog
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-30 23:36:34
               date|                            |
   Target Milestone|---                         |4.0.1


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

[Bug c++/21308] [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-04-30 23:47 -------
Depending on the 3.4 bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |18462
      Known to fail|                            |4.0.0 4.1.0
      Known to work|                            |3.3.3
   Target Milestone|4.0.1                       |3.4.4


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

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

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.4                       |4.0.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

[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

[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

[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

[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

[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|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

[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/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]

-- 

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 #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]

------- 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