This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Canonical types (1/3)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Doug Gregor <doug dot gregor at gmail dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Jan 2007 01:56:37 +0100
- Subject: Re: [PATCH] Canonical types (1/3)
- References: <24b520d20611280755x5117377fh7e4e1344575fb17d@mail.gmail.com> <4574C3CA.6080509@codesourcery.com> <24b520d20612050755u4b69fe2ey541f6e2a536abf03@mail.gmail.com> <4575A04A.2090008@codesourcery.com> <24b520d20612060704m543d0b77yf71fb80311cecb0b@mail.gmail.com>
Hi,
just for a record, this is memory tester report about this patch. I
think all the increases (generally in between 1-2% except for extreme
case of empty function) comes from extra field in the type tree node.
I would be bit curious why we produce so many types for empty function
we manage to gabrage collect somehow ;)
Honza
comparing empty function compilation at -O0 level:
Peak amount of GGC memory allocated before garbage collecting increased from 2235k to 2264k, overall 1.30%
Peak amount of GGC memory still allocated after garbage collectin increased from 1942k to 1954k, overall 0.62%
Amount of produced GGC garbage increased from 423k to 446k, overall 5.43%
Amount of memory still referenced at the end of compilation increased from 2273k to 2288k, overall 0.65%
Overall memory needed: 18329k
Peak memory use before GGC: 2235k -> 2264k
Peak memory use after GGC: 1942k -> 1954k
Maximum of released memory in single GGC run: 293k -> 310k
Garbage: 423k -> 446k
Leak: 2273k -> 2288k
Overhead: 446k -> 455k
GGC runs: 3
comparing empty function compilation at -O0 -g level:
Peak amount of GGC memory allocated before garbage collecting increased from 2263k to 2291k, overall 1.24%
Peak amount of GGC memory still allocated after garbage collectin increased from 1970k to 1981k, overall 0.56%
Amount of produced GGC garbage increased from 425k to 448k, overall 5.40%
Amount of memory still referenced at the end of compilation increased from 2305k to 2320k, overall 0.64%
Overall memory needed: 18345k
Peak memory use before GGC: 2263k -> 2291k
Peak memory use after GGC: 1970k -> 1981k
Maximum of released memory in single GGC run: 293k -> 310k
Garbage: 425k -> 448k
Leak: 2305k -> 2320k
Overhead: 450k -> 460k
GGC runs: 3
comparing empty function compilation at -O1 level:
Peak amount of GGC memory allocated before garbage collecting increased from 2235k to 2264k, overall 1.30%
Peak amount of GGC memory still allocated after garbage collectin increased from 1942k to 1954k, overall 0.62%
Amount of produced GGC garbage increased from 427k to 450k, overall 5.38%
Amount of memory still referenced at the end of compilation increased from 2275k to 2290k, overall 0.65%
Overall memory needed: 18433k -> 18437k
Peak memory use before GGC: 2235k -> 2264k
Peak memory use after GGC: 1942k -> 1954k
Maximum of released memory in single GGC run: 293k -> 310k
Garbage: 427k -> 450k
Leak: 2275k -> 2290k
Overhead: 446k -> 456k
GGC runs: 4
comparing empty function compilation at -O2 level:
Peak amount of GGC memory allocated before garbage collecting increased from 2236k to 2264k, overall 1.25%
Peak amount of GGC memory still allocated after garbage collectin increased from 1942k to 1954k, overall 0.62%
Amount of produced GGC garbage increased from 430k to 453k, overall 5.33%
Amount of memory still referenced at the end of compilation increased from 2275k to 2290k, overall 0.65%
Overall memory needed: 18445k -> 18449k
Peak memory use before GGC: 2236k -> 2264k
Peak memory use after GGC: 1942k -> 1954k
Maximum of released memory in single GGC run: 294k -> 310k
Garbage: 430k -> 453k
Leak: 2275k -> 2290k
Overhead: 447k -> 456k
GGC runs: 4
comparing empty function compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 2236k to 2264k, overall 1.25%
Peak amount of GGC memory still allocated after garbage collectin increased from 1942k to 1954k, overall 0.62%
Amount of produced GGC garbage increased from 430k to 453k, overall 5.33%
Amount of memory still referenced at the end of compilation increased from 2275k to 2290k, overall 0.65%
Overall memory needed: 18445k -> 18449k
Peak memory use before GGC: 2236k -> 2264k
Peak memory use after GGC: 1942k -> 1954k
Maximum of released memory in single GGC run: 294k -> 310k
Garbage: 430k -> 453k
Leak: 2275k -> 2290k
Overhead: 447k -> 456k
GGC runs: 4
comparing combine.c compilation at -O0 level:
Peak amount of GGC memory allocated before garbage collecting increased from 9255k to 9316k, overall 0.66%
Peak amount of GGC memory still allocated after garbage collectin increased from 8803k to 8864k, overall 0.69%
Amount of produced GGC garbage increased from 37143k to 37272k, overall 0.35%
Amount of memory still referenced at the end of compilation increased from 6470k to 6539k, overall 1.06%
Overall memory needed: 28497k -> 28589k
Peak memory use before GGC: 9255k -> 9316k
Peak memory use after GGC: 8803k -> 8864k
Maximum of released memory in single GGC run: 2609k
Garbage: 37143k -> 37272k
Leak: 6470k -> 6539k
Overhead: 4774k -> 4828k
GGC runs: 280 -> 279
comparing combine.c compilation at -O0 -g level:
Peak amount of GGC memory allocated before garbage collecting increased from 10834k to 10895k, overall 0.56%
Peak amount of GGC memory still allocated after garbage collectin increased from 10463k to 10524k, overall 0.58%
Amount of produced GGC garbage increased from 37748k to 37863k, overall 0.31%
Amount of memory still referenced at the end of compilation increased from 9330k to 9415k, overall 0.91%
Overall memory needed: 30573k -> 30641k
Peak memory use before GGC: 10834k -> 10895k
Peak memory use after GGC: 10463k -> 10524k
Maximum of released memory in single GGC run: 2365k
Garbage: 37748k -> 37863k
Leak: 9330k -> 9415k
Overhead: 5475k -> 5530k
GGC runs: 270 -> 271
comparing combine.c compilation at -O1 level:
Peak amount of GGC memory allocated before garbage collecting increased from 16963k to 17025k, overall 0.37%
Peak amount of GGC memory still allocated after garbage collectin increased from 16792k to 16854k, overall 0.37%
Amount of produced GGC garbage increased from 55489k to 55554k, overall 0.12%
Amount of memory still referenced at the end of compilation increased from 6482k to 6566k, overall 1.30%
Overall memory needed: 29474k -> 29534k
Peak memory use before GGC: 16963k -> 17025k
Peak memory use after GGC: 16792k -> 16854k
Maximum of released memory in single GGC run: 2219k
Garbage: 55489k -> 55554k
Leak: 6482k -> 6566k
Overhead: 9901k -> 9951k
GGC runs: 362
comparing combine.c compilation at -O2 level:
Peak amount of GGC memory allocated before garbage collecting increased from 16967k to 17027k, overall 0.35%
Peak amount of GGC memory still allocated after garbage collectin increased from 16792k to 16854k, overall 0.37%
Amount of memory still referenced at the end of compilation increased from 6604k to 6686k, overall 1.23%
Overall memory needed: 29474k -> 29530k
Peak memory use before GGC: 16967k -> 17027k
Peak memory use after GGC: 16792k -> 16854k
Maximum of released memory in single GGC run: 2299k
Garbage: 71654k -> 71633k
Leak: 6604k -> 6686k
Overhead: 11884k -> 11920k
GGC runs: 413 -> 412
comparing combine.c compilation at -O3 level:
Ovarall memory allocated via mmap and sbrk decreased from 29602k to 28650k, overall -3.32%
Peak amount of GGC memory allocated before garbage collecting increased from 18061k to 18122k, overall 0.34%
Peak amount of GGC memory still allocated after garbage collectin increased from 17592k to 17653k, overall 0.35%
Amount of produced GGC garbage increased from 105644k to 105772k, overall 0.12%
Amount of memory still referenced at the end of compilation increased from 6684k to 6768k, overall 1.26%
Overall memory needed: 29602k -> 28650k
Peak memory use before GGC: 18061k -> 18122k
Peak memory use after GGC: 17592k -> 17653k
Maximum of released memory in single GGC run: 3658k
Garbage: 105644k -> 105772k
Leak: 6684k -> 6768k
Overhead: 16756k -> 16805k
GGC runs: 462 -> 463
comparing insn-attrtab.c compilation at -O0 level:
Peak amount of GGC memory still allocated after garbage collectin increased from 44699k to 44750k, overall 0.11%
Amount of memory still referenced at the end of compilation increased from 9278k to 9580k, overall 3.26%
Overall memory needed: 89138k -> 89194k
Peak memory use before GGC: 70681k -> 70732k
Peak memory use after GGC: 44699k -> 44750k
Maximum of released memory in single GGC run: 37356k
Garbage: 130715k -> 130549k
Leak: 9278k -> 9580k
Overhead: 16498k -> 16550k
GGC runs: 207
comparing insn-attrtab.c compilation at -O0 -g level:
Peak amount of GGC memory still allocated after garbage collectin increased from 45966k to 46017k, overall 0.11%
Amount of memory still referenced at the end of compilation increased from 11221k to 11269k, overall 0.43%
Overall memory needed: 90314k -> 90370k
Peak memory use before GGC: 71842k -> 71893k
Peak memory use after GGC: 45966k -> 46017k
Maximum of released memory in single GGC run: 37356k -> 37357k
Garbage: 131602k -> 131708k
Leak: 11221k -> 11269k
Overhead: 16893k -> 16943k
GGC runs: 206
comparing insn-attrtab.c compilation at -O1 level:
Amount of memory still referenced at the end of compilation increased from 9343k to 9405k, overall 0.67%
Overall memory needed: 96722k -> 96782k
Peak memory use before GGC: 71858k -> 71901k
Peak memory use after GGC: 67990k -> 68033k
Maximum of released memory in single GGC run: 31412k
Garbage: 229157k -> 229266k
Leak: 9343k -> 9405k
Overhead: 29436k -> 29488k
GGC runs: 220 -> 222
comparing insn-attrtab.c compilation at -O2 level:
Overall memory allocated via mmap and sbrk increased from 109170k to 114090k, overall 4.51%
Amount of memory still referenced at the end of compilation increased from 9345k to 9403k, overall 0.62%
Overall memory needed: 109170k -> 114090k
Peak memory use before GGC: 79550k -> 79588k
Peak memory use after GGC: 73715k -> 73752k
Maximum of released memory in single GGC run: 29700k
Garbage: 281011k -> 281121k
Leak: 9345k -> 9403k
Overhead: 35299k -> 35351k
GGC runs: 241 -> 243
comparing insn-attrtab.c compilation at -O3 level:
Ovarall memory allocated via mmap and sbrk decreased from 109182k to 104470k, overall -4.51%
Amount of memory still referenced at the end of compilation increased from 9350k to 9408k, overall 0.62%
Overall memory needed: 109182k -> 104470k
Peak memory use before GGC: 79576k -> 79613k
Peak memory use after GGC: 73740k -> 73778k
Maximum of released memory in single GGC run: 29893k
Garbage: 281841k -> 281958k
Leak: 9350k -> 9408k
Overhead: 35529k -> 35580k
GGC runs: 243 -> 245
comparing Gerald's testcase PR8361 compilation at -O0 level:
Peak amount of GGC memory allocated before garbage collecting increased from 92333k to 93042k, overall 0.77%
Peak amount of GGC memory still allocated after garbage collectin increased from 91417k to 92120k, overall 0.77%
Amount of produced GGC garbage increased from 211566k to 212348k, overall 0.37%
Amount of memory still referenced at the end of compilation increased from 48116k to 49015k, overall 1.87%
Overall memory needed: 119038k -> 119830k
Peak memory use before GGC: 92333k -> 93042k
Peak memory use after GGC: 91417k -> 92120k
Maximum of released memory in single GGC run: 19249k -> 19382k
Garbage: 211566k -> 212348k
Leak: 48116k -> 49015k
Overhead: 21006k -> 21554k
GGC runs: 416 -> 415
comparing Gerald's testcase PR8361 compilation at -O0 -g level:
Peak amount of GGC memory allocated before garbage collecting increased from 104683k to 105317k, overall 0.61%
Peak amount of GGC memory still allocated after garbage collectin increased from 103645k to 104273k, overall 0.61%
Amount of produced GGC garbage increased from 218155k to 218932k, overall 0.36%
Amount of memory still referenced at the end of compilation increased from 71543k to 72441k, overall 1.26%
Overall memory needed: 131638k -> 132298k
Peak memory use before GGC: 104683k -> 105317k
Peak memory use after GGC: 103645k -> 104273k
Maximum of released memory in single GGC run: 18933k -> 19024k
Garbage: 218155k -> 218932k
Leak: 71543k -> 72441k
Overhead: 26909k -> 27458k
GGC runs: 389 -> 387
comparing Gerald's testcase PR8361 compilation at -O1 level:
Peak amount of GGC memory allocated before garbage collecting increased from 95302k to 95909k, overall 0.64%
Peak amount of GGC memory still allocated after garbage collectin increased from 94350k to 94957k, overall 0.64%
Amount of produced GGC garbage increased from 436278k to 437113k, overall 0.19%
Amount of memory still referenced at the end of compilation increased from 50189k to 51084k, overall 1.78%
Overall memory needed: 118462k -> 119078k
Peak memory use before GGC: 95302k -> 95909k
Peak memory use after GGC: 94350k -> 94957k
Maximum of released memory in single GGC run: 17923k -> 17925k
Garbage: 436278k -> 437113k
Leak: 50189k -> 51084k
Overhead: 100018k -> 100574k
GGC runs: 558 -> 557
comparing Gerald's testcase PR8361 compilation at -O2 level:
Peak amount of GGC memory allocated before garbage collecting increased from 95330k to 95935k, overall 0.63%
Peak amount of GGC memory still allocated after garbage collectin increased from 94378k to 94983k, overall 0.64%
Amount of produced GGC garbage increased from 491586k to 492472k, overall 0.18%
Amount of memory still referenced at the end of compilation increased from 51154k to 52050k, overall 1.75%
Overall memory needed: 118546k -> 119094k
Peak memory use before GGC: 95330k -> 95935k
Peak memory use after GGC: 94378k -> 94983k
Maximum of released memory in single GGC run: 18030k -> 17925k
Garbage: 491586k -> 492472k
Leak: 51154k -> 52050k
Overhead: 58593k -> 59229k
GGC runs: 612 -> 610
comparing Gerald's testcase PR8361 compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 97891k to 98502k, overall 0.62%
Peak amount of GGC memory still allocated after garbage collectin increased from 96012k to 96623k, overall 0.64%
Amount of produced GGC garbage increased from 511700k to 512636k, overall 0.18%
Amount of memory still referenced at the end of compilation increased from 51125k to 52027k, overall 1.77%
Overall memory needed: 121126k -> 121686k
Peak memory use before GGC: 97891k -> 98502k
Peak memory use after GGC: 96012k -> 96623k
Maximum of released memory in single GGC run: 18431k -> 18325k
Garbage: 511700k -> 512636k
Leak: 51125k -> 52027k
Overhead: 58539k -> 59108k
GGC runs: 616 -> 614
comparing PR rtl-optimization/28071 testcase compilation at -O0 level:
Amount of memory still referenced at the end of compilation increased from 8054k to 8080k, overall 0.33%
Overall memory needed: 137638k -> 137658k
Peak memory use before GGC: 81587k -> 81607k
Peak memory use after GGC: 58467k -> 58487k
Maximum of released memory in single GGC run: 44559k
Garbage: 147003k -> 146984k
Leak: 8054k -> 8080k
Overhead: 24963k -> 24980k
GGC runs: 80 -> 81
comparing PR rtl-optimization/28071 testcase compilation at -O0 -g level:
Amount of memory still referenced at the end of compilation increased from 9309k to 9336k, overall 0.28%
Overall memory needed: 138014k -> 137662k
Peak memory use before GGC: 82233k -> 82253k
Peak memory use after GGC: 59113k -> 59133k
Maximum of released memory in single GGC run: 44208k
Garbage: 147214k -> 147251k
Leak: 9309k -> 9336k
Overhead: 25458k -> 25475k
GGC runs: 88
comparing PR rtl-optimization/28071 testcase compilation at -O1 level:
Overall memory needed: 420994k -> 423018k
Peak memory use before GGC: 199539k -> 199561k
Peak memory use after GGC: 193352k -> 193374k
Maximum of released memory in single GGC run: 112477k -> 112475k
Garbage: 282488k -> 282521k
Leak: 29778k -> 29804k
Overhead: 32103k -> 32120k
GGC runs: 96
comparing PR rtl-optimization/28071 testcase compilation at -O2 level:
Overall memory needed: 343390k -> 342850k
Peak memory use before GGC: 199532k -> 199556k
Peak memory use after GGC: 193345k -> 193369k
Maximum of released memory in single GGC run: 111908k -> 111904k
Garbage: 359548k -> 359580k
Leak: 30361k -> 30387k
Overhead: 47259k -> 47276k
GGC runs: 103
comparing PR rtl-optimization/28071 testcase compilation at -O3 -fno-tree-pre -fno-tree-fre level:
Overall memory needed: 931438k -> 931542k
Peak memory use before GGC: 317673k -> 317693k
Peak memory use after GGC: 296148k -> 296168k
Maximum of released memory in single GGC run: 172457k
Garbage: 496461k -> 496497k
Leak: 45414k -> 45440k
Overhead: 59242k -> 59259k
GGC runs: 97
Head of the ChangeLog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2007-01-02 01:52:38.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2007-01-02 18:08:34.000000000 +0000
@@ -1,3 +1,143 @@
+2007-01-02 Kazu Hirata <kazu@codesourcery.com>
+
+ Revert:
+ 2007-01-02 Kazu Hirata <kazu@codesourcery.com>
+
+ * alias.c (init_alias_analysis): Use VEC_safe_grow_cleared.
+ * cfgbuild.c (find_basic_blocks): Likewise.
+ * cfgrtl.c (rtl_create_basic_block): Likewise.
+ * function.c (temp_slots_at_level): Likewise.
+ * reg-stack.c (stack_regs_mentioned): Likewise.
+ * regclass.c (allocate_reg_info): Likewise.
+ * tree-cfg.c (init_empty_tree_cfg, build_tree_cfg, create_bb,
+ set_bb_for_stmt, move_block_to_fn): Likewise.
+ * tree-complex.c (tree_lower_complex): Likewise.
+ * vec.h (VEC_safe_grow_cleared): New.
+
+2007-01-02 Ian Lance Taylor <iant@google.com>
+
+ * c-common.c (c_common_truthvalue_conversion): When warning about
+ using an assignment as a truth value, set TREE_NO_WARNING.
+
+2007-01-02 Manuel Lopez-Ibanez <manu@gcc.gnu.org>
+
+ PR middle-end/7651
+ * c.opt (Wold-style-declaration): New.
+ * doc/invoke.texi (C-only Warning Options): New.
+ (Wold-style-declaration): Document it.
+ (Wextra): Enabled by -Wextra.
+ * c-opts.c (c_common_post_options): Enabled by -Wextra.
+ * c-decl.c (declspecs_add_scspec): Replace -Wextra with
+ -Wold-style-declaration.
+
+2007-01-02 Kazu Hirata <kazu@codesourcery.com>
+
+ * alias.c (init_alias_analysis): Use VEC_safe_grow_cleared.
+ * cfgbuild.c (find_basic_blocks): Likewise.
+ * cfgrtl.c (rtl_create_basic_block): Likewise.
+ * function.c (temp_slots_at_level): Likewise.
+ * reg-stack.c (stack_regs_mentioned): Likewise.
+ * regclass.c (allocate_reg_info): Likewise.
+ * tree-cfg.c (init_empty_tree_cfg, build_tree_cfg, create_bb,
+ set_bb_for_stmt, move_block_to_fn): Likewise.
+ * tree-complex.c (tree_lower_complex): Likewise.
+ * vec.h (VEC_safe_grow_cleared): New.
+
+2007-01-02 Douglas Gregor <doug.gregor@gmail.com>
+
+ * c-common.c(c_common_nodes_and_builtins): Since variants of
+ void_type_node get built before it is given a name, we need to
+ give those variants the name, too.
+ (complete_array_type): We need to work with the canonical main
+ type of the array, from which we will build the qualified version.
+ * params.def (PARAM_VERIFY_CANONICAL_TYPES): New.
+ * print-tree.c (print_node): Display canonical type information
+ for each type.
+ * stor-layout.c (layout_type): When we don't know the
+ alignment of a type for which we're building an array, we end up
+ guessing wrong, so make the type require structural equality.
+ * tree.c (make_node_stat): When we build a new type, it is its
+ own canonical type.
+ (build_type_attribute_qual_variant): When building an attribute
+ variant, its canonical type is the non-attribute variant. However,
+ if the attributes are target-dependent and they differ, we need to
+ use structural equality checks for this type.
+ (build_qualified_type): A qualified type is not equivalent to its
+ unqualified variant; set the canonical type appropriately.
+ (build_distinct_type_copy): When building a distinct type from
+ another type, the new type is its own canonical type.
+ (build_variant_type_copy): When building a new type variant, we
+ assume that it is equivalent to the original type.
+ (build_pointer_type_for_mode): When building a pointer type, also
+ build a canonical type pointer.
+ (build_reference_type_for_mode): When building a reference type,
+ also build a canonical type reference.
+ (build_index_type): When we can't hash an index type (e.g.,
+ because its maximum value is negative), the index type requires
+ structural equality tests.
+ (build_array_type): Build the canonical form of an array type.
+ (build_function_type): Function types require structural equality,
+ because they contain default arguments, attributes, etc.
+ (build_method_type_directly): Ditto for method types.
+ (build_offset_type): Build the canonical offset type.
+ (build_complex_type): Build the canonical vector type.
+ (make_vector_type): Build the canonical vector type.
+ * tree.h (TYPE_CANONICAL): New.
+ (TYPE_STRUCTURAL_EQUALITY_P): New.
+ (SET_TYPE_STRUCTURAL_EQUALITY): New.
+ (struct tree_type): Added "canonical" field.
+ * params.h (VERIFY_CANONICAL_TYPES): New.
+ * doc/c-tree.texi (TYPE_CANONICAL): Document.
+ (TYPE_STRUCTURAL_EQUALITY_P): Document.
+ (SET_TYPE_STRUCTURAL_EQUALITY): Document.
+ * doc/invoke.texi (verify-canonical-types): Document --param
+ parameter for verifying canonical types.
+
+2007-01-02 Joseph Myers <joseph@codesourcery.com>
+
+ * config.gcc (powerpc-*-eabispe*, powerpc-*-eabisimaltivec*,
+ powerpc-*-eabisim*, powerpc-*-eabialtivec*, powerpc-*-eabi*,
+ powerpc-*-rtems*, powerpc-wrs-vxworks, powerpc-wrs-vxworksae,
+ powerpcle-*-eabisim*, powerpcle-*-eabi*): Add rs6000/e500.h to
+ tm_file.
+ * config/rs6000/e500.h: New.
+ * config/rs6000/eabi.h (TARGET_SPE_ABI, TARGET_SPE, TARGET_E500,
+ TARGET_ISEL, TARGET_FPRS, TARGET_E500_SINGLE, TARGET_E500_DOUBLE):
+ Remove.
+ * config/rs6000/linuxspe.h (TARGET_SPE_ABI, TARGET_SPE,
+ TARGET_E500, TARGET_ISEL, TARGET_FPRS, TARGET_E500_SINGLE,
+ TARGET_E500_DOUBLE): Remove.
+ * config/rs6000/vxworks.h (TARGET_SPE_ABI, TARGET_SPE,
+ TARGET_E500, TARGET_ISEL, TARGET_FPRS): Remove.
+ * config/rs6000/rs6000.h (CHECK_E500_OPTIONS): Define.
+ * config/rs6000/rs6000.c (rs6000_override_options): Use
+ CHECK_E500_OPTIONS.
+
+2007-01-02 Joseph Myers <joseph@codesourcery.com>
+
+ * config/rs6000/rs6000.c (print_operand): Check (TARGET_SPE ||
+ TARGET_E500_DOUBLE), not TARGET_E500, for %y.
+ (rs6000_generate_compare, rs6000_emit_sCOND, output_cbranch,
+ rs6000_emit_cmove): Don't check TARGET_E500.
+ * config/rs6000/rs6000.md (bunordered, bordered, sunordered,
+ sordered): Don't check TARGET_E500.
+
+2007-01-01 Eric Christopher <echristo@apple.com>
+
+ * config/mips/mips.c (mips_regno_mode_ok_for_base_p): Use
+ HARD_REGISTER_NUM_P.
+
+2007-01-01 Roger Sayle <roger@eyesopen.com>
+
+ * fold-const.c (fold_binary) <EQ_EXPR>: Fold "(X^C1) eq/ne C2" into
+ "X eq/ne (C1^C2)". Fold "(X^Z) eq/ne (Y^Z)" as "X eq/ne Y" when Z
+ has no side-effects. Fold "(X^C1) eq/ne (Y^C2)" as "(X^(C1^C2))
+ eq/ne Y".
+
+2007-01-01 Mike Stump <mrs@apple.com>
+
+ * configure.ac: Remove support for building with Apple's gcc-3.1.
+
2007-01-02 Joseph Myers <joseph@codesourcery.com>
PR middle-end/30311
@@ -53,4 +193,3 @@
* cgraphunit.c (cgraph_optimize): Call cgraph_add_new_functions
before starting IPA passes.
-
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp 2006-12-31 18:25:17.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog 2007-01-02 17:54:58.000000000 +0000
@@ -1,3 +1,63 @@
+2006-01-02 Ian Lance Taylor <iant@google.com>
+
+ * semantics.c (maybe_convert_cond): Optionally warn when using an
+ assignment as a condition.
+ * typeck.c (convert_for_assignment): Optionally warn about
+ assigning the result of an assignment to a bool.
+
+2007-01-02 Douglas Gregor <doug.gregor@gmail.com>
+
+ * pt.c (canonical_template_parms): Correct typo in comment.
+
+2007-01-02 Douglas Gregor <doug.gregor@gmail.com>
+
+ * typeck.c (structural_comptypes): Renamed from "comptypes".
+ (comptypes): Use canonical type information to perform fast type
+ comparison. When VERIFY_CANONICAL_TYPES, verify that the
+ canonical type comparison returns the same results as we would see
+ from the current, structural check. Support COMPARE_STRUCTURAL
+ when we need structural checks.
+ * decl.c (typename_compare): Fix comment.
+ (build_typename_type): TYPENAME_TYPE nodes require structural
+ equality checks, because they resolve different based on the
+ current class type.
+ (make_unbound_class_template): UNBOUND_CLASS_TEMPLATE nodes
+ require structural equality checks (for now).
+ (build_ptrmemfunc_type): Build the canonical pointer to member
+ function type.
+ (compute_array_index_type): Whenever we build a new index type
+ to represent the size of an array in a template, we need to mark
+ this index type as requiring structural equality. This goes for
+ arrays with value-dependent sizes with the current ABI, or all
+ arrays with ABI-1.
+ * tree.c (cplus_array_hash): New.
+ (struct cplus_array_info): New.
+ (cplus_array_compare): New.
+ (cplus_array_htab): New.
+ (build_cplus_array_type_1): Use a hash table to cache the array
+ types we build. Build the canonical array type for each array
+ type.
+ (cp_build_qualified_type_real): When building a cv-qualified array
+ type, use the hash table of array types and build canonical array
+ types as necessary.
+ (bind_template_template_parm): BOUND_TEMPLATE_TEMPLATE_PARM nodes
+ use structural equality (for now).
+ * cp-tree.h (COMPARE_STRUCTURAL): New.
+ * pt.c (canonical_template_parms): New.
+ (canonical_type_parameter): New.
+ (process_template_parm): Find the canonical type parameter.
+ (lookup_template_class): When we have named the primary template
+ type, set the canonical type for our template class to the primary
+ template type. If any of the template arguments need structural
+ equality checks, the template class needs structural equality
+ checks.
+ (tsubst): When reducing the level of a template template
+ parameter, we require structural equality tests for the resulting
+ parameter because its template parameters have not had their types
+ canonicalized. When reducing a template type parameter, find the
+ canonical reduced type parameter.
+ (any_template_arguments_need_structural_equality_p): New.
+
2006-12-31 Simon Martin <simartin@users.sourceforge.net>
PR c++/29731
The results can be reproduced by building a compiler with
--enable-gather-detailed-mem-stats targetting x86-64
and compiling preprocessed combine.c or testcase from PR8632 with:
-fmem-report --param=ggc-min-heapsize=1024 --param=ggc-min-expand=1 -Ox -Q
The memory consumption summary appears in the dump after detailed listing
of the places they are allocated in. Peak memory consumption is actually
computed by looking for maximal value in {GC XXXX -> YYYY} report.
Your testing script.