[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #16 from jv244 at cam dot ac dot uk 2010-08-29 06:38 --- adjust summary according to the last timings -- jv244 at cam dot ac dot uk changed: What|Removed |Added Last reconfirmed|2010-08-29 05:31:37 |2010-08-29 06:38:26 date|| Summary|[4.6 Regression] compile|[4.6 Regression] compile |time increases 5x. |time increases 3x. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug target/44474] GCC inserts redundant test instruction due to incorrect clobber
--- Comment #2 from astrange at ithinksw dot com 2010-08-29 06:39 --- Still happens with the new combine work (not that I really expected it to change). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44474
[Bug pch/45441] New: PCH: invalid file in error messages
Hello.
$ cat 1.h
void f();
$ cat 2.h
# include 1.h
$ cat 1.c
#include 2.h
int main()
{
a = b;
}
$ gcc 1.c
1.c: In function 'int main()':
1.c:5: error: 'a' was not declared in this scope
1.c:5: error: 'b' was not declared in this scope
But:
$ g++ 1.h
$ ls
1.c 1.h 1.h.gch 2.h
$ gcc 1.c
2.h: In function 'int main()':
2.h:5: error: 'a' was not declared in this scope
2.h:5: error: 'b' was not declared in this scope
Now error is located in 2.h instead of 1.c. If 1.c includes 1.h
directly (not through 2.h) everything is ok.
--
Summary: PCH: invalid file in error messages
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gavv dot ml at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45441
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-08-29 09:25 --- tree iv optimization : 32.57 (20%) usr 0.10 ( 5%) sys 32.73 (20%) wall 322095 kB (18%) ggc 20% is still completely unreasonable for IV optimization. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2010-08-29 06:38:26 |2010-08-29 09:25:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-29 09:56 --- Subject: Bug 45439 Author: janus Date: Sun Aug 29 09:56:45 2010 New Revision: 163626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163626 Log: 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/45439 * match.c (gfc_match_select_type): Give the associate-name the FL_VARIABLE attribute. 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/45439 * gfortran.dg/select_type_16.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/select_type_16.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-29 09:57 --- Fixed with r163626. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug c++/45442] New: std::operator discards appropriate floating-point values (Inf, -Inf, NaN)
The following code
-
#include limits
#include iostream
int main () {
double a = std::numeric_limitsdouble::infinity();
double b = -1;
std::cout a std::endl;
std::cin b;
std::cout b std::cin.fail() std::endl;
return 0;
}
-
outputs
-
inf
0 1
-
when the user types infreturn, while one could expect
-
inf
inf 0
-
The same kind of behavior happens for -inf and nan.
I know that this is implementation-defined, and as such it is an acceptable
behavior, but it would be nice if and could be more symmetric.
I don't know what conversion functions exactly are called by , but the
__convert_to_v() functions in libstdc++-v3/config/locale/gnu/c_locale.cc
contain lines like:
else if (__v == numeric_limitsdouble::infinity())
{
__v = numeric_limitsdouble::max();
__err = ios_base::failbit;
}
[this condition is not the one run by the above-mentioned code, as we get a
value 0 instead of numeric_limitsdouble::max(), but you get the idea]
It seems strange that these perfectly appropriate floating-point values that
can be given by strtod are discarded for no apparent reason.
--
Summary: std::operator discards appropriate floating-point
values (Inf, -Inf, NaN)
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot buchlin at ias dot u-psud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45442
[Bug c++/45442] std::operator discards appropriate floating-point values (Inf, -Inf, NaN)
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-29 10:23 --- *** This bug has been marked as a duplicate of 27904 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45442
[Bug libstdc++/27904] operator to floating point variable does not support inf, infinity, or nan
--- Comment #15 from paolo dot carlini at oracle dot com 2010-08-29 10:23 --- *** Bug 45442 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||eric dot buchlin at ias dot ||u-psud dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug c++/45437] Loses reference during update
--- Comment #9 from redi at gcc dot gnu dot org 2010-08-29 11:28 --- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1944 proposed the changes to sequencing wording, revised in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2239.html The new wording makes it clear that a compound assignment such as |= has this sequence: - evaluation of operands - assignment - evaluation of assignment expression i.e. evaluating result of (a|=b) for use in another expression However I don't think that affects this case. The builtin |= operator is not a function (see 5p2) and does not obey the rules of operand types of function calls, so it is not appropriate to describe the effects in terms of bool c = a; bool d = f(); operator|=(c, d) The operand to the builtin |= is an lvalue expression, not a reference. The new wording also makes it clear it is only evaluated once, before the assignment. It is not specified whether evaluation of the left operand is sequenced before evaluation of the right operand, therefore the compiler is still permitted to evaluate sz.b (as false) then evaluate f(...) ( also false) then perform the assignment of sz.b=(false|false) Thus, invalid. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug spam/45443] New: GCC documentation for -O3 flag doesn't mention -fipa-cp-clone
In in gcc-4.4.4 (and likely in many other versions), the man gcc paragraph about -O3 is: Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload and -ftree-vectorize options. The above list of optimizations, as well as http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, don't mention -fipa-cp-clone, although -O3 turns enables it: $ gcc -c -Q -O3 --help=optimizers /tmp/O3-opts $ gcc -c -Q -O2 --help=optimizers /tmp/O2-opts $ diff /tmp/O2-opts /tmp/O3-opts #9130; grep enabled -fgcse-after-reload [enabled] -finline-functions [enabled] -fipa-cp-clone [enabled] -fpredictive-commoning [enabled] -ftree-vectorize[enabled] -funswitch-loops[enabled] -- Summary: GCC documentation for -O3 flag doesn't mention -fipa-cp- clone Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: spam AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ristioja at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45443
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #18 from jv244 at cam dot ac dot uk 2010-08-29 15:07 --- FYI, these are the 4.5 branch timings: Execution times (seconds) garbage collection: 0.47 ( 1%) usr 0.00 ( 0%) sys 0.47 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.05 ( 0%) usr 0.01 ( 1%) sys 0.09 ( 0%) wall 5996 kB ( 1%) ggc callgraph optimization: 0.21 ( 0%) usr 0.02 ( 1%) sys 0.26 ( 0%) wall 606 kB ( 0%) ggc ipa cp: 0.09 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 1381 kB ( 0%) ggc ipa reference : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.06 ( 0%) usr 0.01 ( 1%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.39 ( 1%) usr 0.00 ( 0%) sys 0.51 ( 1%) wall 2459 kB ( 0%) ggc trivially dead code : 0.34 ( 1%) usr 0.00 ( 0%) sys 0.30 ( 1%) wall 0 kB ( 0%) ggc df multiple defs : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.33 ( 1%) usr 0.00 ( 0%) sys 0.27 ( 1%) wall 0 kB ( 0%) ggc df live regs : 2.08 ( 4%) usr 0.01 ( 1%) sys 2.19 ( 4%) wall 0 kB ( 0%) ggc df liveinitialized regs: 0.98 ( 2%) usr 0.00 ( 0%) sys 0.92 ( 2%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.24 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.93 ( 2%) usr 0.00 ( 0%) sys 1.04 ( 2%) wall 5756 kB ( 1%) ggc register information : 0.51 ( 1%) usr 0.01 ( 1%) sys 0.39 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 0.78 ( 1%) usr 0.01 ( 1%) sys 0.91 ( 2%) wall 22384 kB ( 3%) ggc alias stmt walking: 0.50 ( 1%) usr 0.03 ( 2%) sys 0.38 ( 1%) wall 5563 kB ( 1%) ggc register scan : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc parser: 0.82 ( 2%) usr 0.13 ( 9%) sys 0.94 ( 2%) wall 55603 kB ( 6%) ggc inline heuristics : 0.20 ( 0%) usr 0.01 ( 1%) sys 0.16 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.38 ( 1%) usr 0.03 ( 2%) sys 0.40 ( 1%) wall 46588 kB ( 5%) ggc tree eh : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.04 ( 0%) usr 0.02 ( 1%) sys 0.05 ( 0%) wall 11964 kB ( 1%) ggc tree CFG cleanup : 0.47 ( 1%) usr 0.00 ( 0%) sys 0.79 ( 1%) wall 1829 kB ( 0%) ggc tree VRP : 1.46 ( 3%) usr 0.05 ( 4%) sys 1.27 ( 2%) wall 56376 kB ( 6%) ggc tree copy propagation : 0.09 ( 0%) usr 0.02 ( 1%) sys 0.22 ( 0%) wall 746 kB ( 0%) ggc tree find ref. vars : 0.09 ( 0%) usr 0.01 ( 1%) sys 0.07 ( 0%) wall 3806 kB ( 0%) ggc tree PTA : 0.30 ( 1%) usr 0.00 ( 0%) sys 0.33 ( 1%) wall 3836 kB ( 0%) ggc tree PHI insertion: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 3194 kB ( 0%) ggc tree SSA rewrite : 0.24 ( 0%) usr 0.01 ( 1%) sys 0.29 ( 1%) wall 13860 kB ( 2%) ggc tree SSA other: 0.13 ( 0%) usr 0.02 ( 1%) sys 0.11 ( 0%) wall 418 kB ( 0%) ggc tree SSA incremental : 0.89 ( 2%) usr 0.06 ( 4%) sys 0.97 ( 2%) wall 6811 kB ( 1%) ggc tree operand scan : 0.34 ( 1%) usr 0.23 (17%) sys 0.59 ( 1%) wall 44776 kB ( 5%) ggc dominator optimization: 0.29 ( 1%) usr 0.01 ( 1%) sys 0.35 ( 1%) wall 5152 kB ( 1%) ggc tree CCP : 0.51 ( 1%) usr 0.02 ( 1%) sys 0.43 ( 1%) wall 4620 kB ( 1%) ggc tree PHI const/copy prop: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 106 kB ( 0%) ggc tree split crit edges : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 2019 kB ( 0%) ggc tree reassociation: 0.12 ( 0%) usr 0.01 ( 1%) sys 0.12 ( 0%) wall 2946 kB ( 0%) ggc tree PRE : 0.92 ( 2%) usr 0.00 ( 0%) sys 0.95 ( 2%) wall 7315 kB ( 1%) ggc tree FRE : 0.45 ( 1%) usr 0.04 ( 3%) sys 0.35 ( 1%) wall 5518 kB ( 1%) ggc tree code sinking : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1400 kB ( 0%) ggc tree linearize phis : 0.02 ( 0%) usr 0.01 ( 1%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.18 ( 0%) usr 0.02 ( 1%) sys 0.16 ( 0%) wall 10006 kB ( 1%) ggc tree conservative DCE : 0.05 ( 0%) usr 0.01 ( 1%) sys 0.13 ( 0%) wall 576 kB ( 0%) ggc tree aggressive DCE : 0.28 ( 1%) usr 0.01 ( 1%) sys 0.37 ( 1%) wall 8853 kB ( 1%) ggc tree buildin call DCE : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree DSE : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 132 kB ( 0%) ggc PHI merge : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 37 kB ( 0%) ggc tree loop bounds : 0.22 ( 0%)
[Bug bootstrap/45444] New: [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
Attempting to bootstrap gcc-4.6-20100828 on armv5tel-linux-gnueabi fails in stage 2 with: /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c: In function 'arm_get_pcs_model': /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:3725:7: error: passing argument 1 of 'stdarg_p' discards 'const' qualifier from pointer target type [-Werror] /home/mikpe/gcc-4.6-20100828/gcc/tree.h:4851:13: note: expected 'tree' but argument is of type 'const_tree' /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c: In function 'locate_neon_builtin_icode': /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17969:20: note: 'itype' should be initialized /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error: in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17970:13: note: 'bits' should be initialized /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17971:24: note: 'codes' should be initialized /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17972:22: note: 'num_vars' should be initialized /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c: In function 'arm_output_asm_insn': /home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:22649:3: error: function might be possible candidate for 'gnu_printf' format attribute [-Werror=missing-format-attribute] cc1: all warnings being treated as errors make[3]: *** [arm.o] Error 1 make[3]: Leaving directory `/home/mikpe/objdir46/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/mikpe/objdir46' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/mikpe/objdir46' make: *** [bootstrap] Error 2 The first error in arm_ge_pcs_model () was reported 11 days ago as PR45321. The other 'uninitialized const member' warnings/errors are new since then. I can't see any obvious recent changes in arm.c that would explain them, so I suspect they're caused by some C front-end change. -- Summary: [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC host triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #1 from mikpe at it dot uu dot se 2010-08-29 16:26 --- Created an attachment (id=21586) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21586action=view) preliminary fixes for arm.c stage2 errors This gets me past the arm.c stage2 errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug rtl-optimization/45434] x86 missed optimization: use high register (ah, bh, ch, dh) when available to make comparisons
--- Comment #2 from ubizjak at gmail dot com 2010-08-29 16:40 ---
A bit simpler testcase:
int test(int i)
{
return (i 0xFF) == ((i 0xFF00) 8);
}
fails two combine attempts:
Trying 8 - 9:
Failed to match this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (subreg:DI (reg/v:SI 63 [ i ]) 0)
(const_int 8 [0x8])
(const_int 8 [0x8]))
(reg:SI 65)))
Trying 8, 6 - 9:
Failed to match this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (subreg:QI (lshiftrt:SI (reg/v:SI 63 [ i ])
(const_int 8 [0x8])) 0)
(subreg:QI (reg/v:SI 63 [ i ]) 0)))
However, contrary to the first attempt, 8 - 9 substitution in the second
attempt is over-optimized from ZERO_EXTRACT to LSHIFTRT. i386.md expects
ZERO_EXTRACT form.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-29 17:22 --- cf. PR 44529 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-29 17:32 --- Jason, any hint about the best way to attack this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
[Bug libfortran/45436] [4.6 Regression] Failed to bootstrap
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2010-08-29 17:39 --- The commit fixes it for me. Sorry about this! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2010-08-29 17:41 --- I did LEADZ and TRAILZ, I guess I should do these. Assigning to me. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-27 07:13:23 |2010-08-29 17:41:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug c++/45437] Loses reference during update
--- Comment #10 from igodard at pacbell dot net 2010-08-29 18:00 --- I agree that Nelson's proposal (in particular 5.17p1 -assignment and compound assignment operators) defines the ordering as: - evaluation of operands - assignment - evaluation of assignment expression i.e. evaluating result of (a|=b) for use in another expression However you beg the question because you assume that evaluation of operands means evaluation of rvalues derived from the operands. It does not; it means evaluation of an lvalue (i.e. a reference) and an rvalue respectively, because otherwise the assignment would not have an lvalue to assign to. Hence the function f() must be called before |= (the assignment) is performed. I have left the report as Resolved Invalid because I'm sure that you are sick of me reopening it. However, that there is such a disagreement on the language semantics suggests that Nelson's wording is unclear at best and ambiguous at worse, and I have sent him a note to that effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug fortran/44529] [F03] array allocation with SOURCE
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-29 18:05 --- Cf. also PR 45440 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44529
[Bug bootstrap/45445] New: [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
Attempting to bootstrap gcc-4.6-20100828 on armv5tel-linux-gnueabi, after applying the preliminary fixes for PR45444, fails with comparison failures after stage 3: make[3]: Leaving directory `/home/mikpe/objdir46' Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/lto-cgraph.o differs gcc/value-prof.o differs gcc/expr.o differs gcc/tree-ssa-loop-ivopts.o differs gcc/lto-streamer-out.o differs gcc/stor-layout.o differs gcc/tree-ssa-loop-ivcanon.o differs gcc/loop-iv.o differs gcc/double-int.o differs gcc/expmed.o differs gcc/dbxout.o differs gcc/tree.o differs gcc/sreal.o differs gcc/cfgloopanal.o differs gcc/explow.o differs libcpp/expr.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/mikpe/objdir46' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/mikpe/objdir46' make: *** [bootstrap] Error 2 This looks almost identical to the failure in the presumed-fixed PR45162. Configured with: /home/mikpe/gcc-4.6-20100828/configure --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale --build=armv5tel-brewer-linux-gnueabi --with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin --disable-lto --disable-libmudflap -- Summary: [4.6 regression] ARM bootstrap failure: comparison failures after stage 3 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC host triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug c++/45437] Loses reference during update
--- Comment #11 from igodard at pacbell dot net 2010-08-29 18:24 ---
Note to Nelson, for the record here:
There is a disagreement about C++ sequence semantics happening in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
The gist is the following code:
bool b = false;
bool f() { b = true; return false; }
b |= f();
The question is whether this is well defined (with b having the value true
after the assignment) or undefined. Your proposal states:
5.17p1 (assignment and compound assignment operators):
The assignment operator (=) and the compound assignment operators all group
right-to-left. All require a modifiable lvalue as their left operand and return
an lvalue with the type and value of the left operand after the assignment has
taken place an lvalue referring to the left operand. The result in all cases is
a bit-field if the left operand is a bit-field. In all cases, the assignment is
sequenced after the value computation of the right and left operands, and
before the value computation of the assignment expression. With respect to an
indeterminately-sequenced function call, the operation of a compound assignment
is a single evaluation. [ Note: Therefore, a function call shall not intervene
between the lvalue-to-rvalue conversion and the side effect associated with any
single compound assignment operator. —end note ]
All agree that this governs; the question is what the value computation of the
right and left operands of the |= assignment means.
In one interpretation, it means the rvalue evaluation of b and f(); in this
interpretation the ordering of the operand evaluations is undefined and hence
the value of b at and after the assignment is also undefined. It is unclear how
the assignment receives an lvalue to assign to in this interpretation.
In the second interpretation, it means the lvalue evaluation of b and the
rvalue evaluation of f(); in this interpretation the lvalue-to-rvalue
conversion of b takes place within the assignment, so consequently f() must be
evaluated before the conversion takes place. Hence, the assignment receives the
(lvalue) b with a well-defined rvalue of true, and the value after the
assignment is also well-defined and true.
Whichever of these interpretations you had intended, the extent of the
disagreement suggests that the proposed wording, while fine for simple
assignment, might be clarified for the compound assignment operators.
Respectfully,
Ivan Godard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug rtl-optimization/45434] x86 missed optimization: use high register (ah, bh, ch, dh) when available to make comparisons
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-29 18:34 --- Combine seems to prefer LSHIFTRT over ZERO_EXTRACT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
[Bug rtl-optimization/45434] x86 missed optimization: use high register (ah, bh, ch, dh) when available to make comparisons
--- Comment #4 from ubizjak at gmail dot com 2010-08-29 18:59 ---
(In reply to comment #3)
Combine seems to prefer LSHIFTRT over ZERO_EXTRACT.
It seems so. Slightly changed testcase:
char test(int a, int b, int i, int j)
{
return (i 0xFF) == ((j 0xFF00) 8);
}
and changed *cmpqi_ext_3_insn_rex64 pattern:
(define_insn *cmpqi_ext_3_insn_rex64
[(set (reg FLAGS_REG)
(compare
(subreg:QI
(lshiftrt:SI
;; (zero_extract:SI
(match_operand 0 ext_register_operand Q)
;;(const_int 8)
(const_int 8)) 0)
(match_operand:QI 1 nonmemory_operand Qn)))]
TARGET_64BIT ix86_match_ccmode (insn, CCmode)
cmp{b}\t{%1, %h0|%h0, %1}
[(set_attr type icmp)
(set_attr modrm 1)
(set_attr mode QI)])
result in:
cmpb%dl, %ch
sete%al
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
[Bug rtl-optimization/45434] x86 missed optimization: use high register (ah, bh, ch, dh) when available to make comparisons
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-08-29 19:12 --- Combine seems to prefer LSHIFTRT over ZERO_EXTRACT. The former is the canonical form of the latter for internal computations, but the latter should be reinstantiated when matching instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
[Bug rtl-optimization/45434] x86 missed optimization: use high register (ah, bh, ch, dh) when available to make comparisons
--- Comment #6 from ubizjak at gmail dot com 2010-08-29 19:20 ---
Some other examples:
char test(int a, int b, int i, int j)
{
return (i 0xFF) + ((j 0xFF00) 8);
}
movzbl %ch, %eax
addl%edx, %eax
ret
char test(int a, int b, int i, int j)
{
return (i 0xFF) - ((j 0xFF00) 8);
}
movzbl %ch, %ecx
movl%edx, %eax
subb%cl, %al
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
[Bug c++/44991] [4.4/4.5/4.6 Regression] default argument with '' cause compilation error
--- Comment #3 from jason at gcc dot gnu dot org 2010-08-29 19:24 --- Subject: Bug 44991 Author: jason Date: Sun Aug 29 19:24:37 2010 New Revision: 163629 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163629 Log: PR c++/44991 * parser.c (cp_parser_parameter_declaration): Pop parameter decls after tentative parsing. Added: trunk/gcc/testsuite/g++.dg/parse/defarg15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44991
[Bug c++/45437] Loses reference during update
--- Comment #12 from redi at gcc dot gnu dot org 2010-08-29 20:50 --- (In reply to comment #10) However you beg the question because you assume that evaluation of operands means evaluation of rvalues derived from the operands. I assume nothing of the sort. It does not; it means evaluation of an lvalue (i.e. a reference) Of course it means an lvalue, but that does not imply a reference. If you read Clause 5 you'll see that the requirements on operands are in terms of lvalues, rvalues etc. and not references. You're still assuming that invocation of a builtin operator results in a function call, and reasoning in terms of the requirements of a function call. 5p2 makes it clear that the requirements on operands of builtin operators are different to the requirements on function calls. If that was not the case, why would the standard say that replacing a builtin operator with a user-defined oeprator uses the requirements of a function call? and an rvalue respectively, because otherwise the assignment would not have an lvalue to assign to. Hence the function f() must be called before |= (the assignment) is performed. Yes, f() is called before the assignment, but it is indeterminately sequenced w.r.t the evaluation of sz.b -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-29 21:10 --- Mine (working on a patch). -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-15 18:40:31 |2010-08-29 21:10:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #29 from janus at gcc dot gnu dot org 2010-08-29 21:29 --- Subject: Bug 42769 Author: janus Date: Sun Aug 29 21:29:38 2010 New Revision: 163631 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163631 Log: 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/42769 * resolve.c (resolve_structure_cons): For derived types, make sure the type has been resolved. (resolve_typebound_procedures): Make sure the vtab has been generated. 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/42769 * gfortran.dg/dynamic_dispatch_11.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_11.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #30 from janus at gcc dot gnu dot org 2010-08-29 21:36 --- r163631 fixes comment #27, but the other stuff still fails: 1) the original test case (comment #1, ICE) 2) the reduced version (comment #8, ICE) 3) the variant in comment #24 (wrong-code) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug c++/45437] Loses reference during update
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-29 22:39 ---
Here's a reduced testcase, struct s is not relevant:
bool f(bool b) {
b = true;
return false;
}
int main() {
bool b = false;
b |= f(b);
return b;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug lto/45446] New: FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr
On powerpc-apple-darwin9 (and apparently powerpc-gnu-linux), the following lto testcase fails on execution... FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr The failure occurs as... terminate called after throwing an instance of 'int' -- Summary: FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o- cp_lto_20081109_1.o execute -O2 -fwhopr Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45446
[Bug lto/45446] FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-08-30 00:03 --- Created an attachment (id=21587) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21587action=view) g++.dg/lto/20081109_0 testcase with intermediate files on powerpc-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45446
[Bug lto/45446] FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-08-30 00:06 --- Attached files created with... /Users/howarth/darwin_objdir/gcc/testsuite/g++/../../g++ -B/Users/howarth/darwin_objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/libstdc++-v3/include/powerpc-apple-darwin9.8.0 -I/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/libstdc++-v3/include -I/Users/howarth/gcc/libstdc++-v3/libsupc++ -I/Users/howarth/gcc/libstdc++-v3/include/backward -I/Users/howarth/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -fwhopr -c --save-temps -o cp_lto_20081109_0.o /Users/howarth/gcc/gcc/testsuite/g++.dg/lto/20081109_0.C /Users/howarth/darwin_objdir/gcc/testsuite/g++/../../g++ -B/Users/howarth/darwin_objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/libstdc++-v3/include/powerpc-apple-darwin9.8.0 -I/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/libstdc++-v3/include -I/Users/howarth/gcc/libstdc++-v3/libsupc++ -I/Users/howarth/gcc/libstdc++-v3/include/backward -I/Users/howarth/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -fwhopr -c --save-temps -o cp_lto_20081109_1.o /Users/howarth/gcc/gcc/testsuite/g++.dg/lto/20081109_1.C /Users/howarth/darwin_objdir/gcc/testsuite/g++/../../g++ -B/Users/howarth/darwin_objdir/gcc/testsuite/g++/../../ cp_lto_20081109_0.o cp_lto_20081109_1.o -nostdinc++ -I/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/libstdc++-v3/include/powerpc-apple-darwin9.8.0 -I/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/libstdc++-v3/include -I/Users/howarth/gcc/libstdc++-v3/libsupc++ -I/Users/howarth/gcc/libstdc++-v3/include/backward -I/Users/howarth/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -fwhopr -L/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/./libstdc++-v3/src/.libs -B/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/./libstdc++-v3/src/.libs -L/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/./libstdc++-v3/src/.libs -L/Users/howarth/darwin_objdir/powerpc-apple-darwin9.8.0/./libiberty -multiply_defined suppress --save-temps -o g++-dg-lto-20081109-11 Using built-in specs. COLLECT_GCC=dist/bin/g++ COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/powerpc-apple-darwin9.8.0/4.6.0/lto-wrapper Target: powerpc-apple-darwin9.8.0 Configured with: ../gcc/configure --prefix=/Users/howarth/dist --enable-languages=c,c++,lto --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-checking CC=gcc-4.2 CXX=g++-4.2 Thread model: posix gcc version 4.6.0 20100829 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45446
[Bug preprocessor/45447] New: ICE with `-g -femit-struct-debug-baseonly'
the following test-case: #ifndef __GNUC_VA_LIST #define __GNUC_VA_LIST typedef __builtin_va_list __gnuc_va_list; #endif triggers the following ICE: % /arm-none-linux-eabi/libexec/gcc/arm-none-linux-eabi/4.5.2/cc1 -v ./test-case.c -g -femit-struct-debug-baseonly -o ./test-case.o ignoring nonexistent directory /arm-none-linux-eabi/arm-none-linux-eabi//sys-root/x-tools/arm-none-linux-eabi/arm-none-linux-eabi//sys-root/include ignoring duplicate directory /data/src/toolchain/build/x-tools/arm-none-linux-eabi/arm-none-linux-eabi//sys-root/usr/include #include ... search starts here: #include ... search starts here: /arm-none-linux-eabi/lib/gcc/arm-none-linux-eabi/4.5.2/include /arm-none-linux-eabi/lib/gcc/arm-none-linux-eabi/4.5.2/include-fixed /arm-none-linux-eabi/lib/gcc/arm-none-linux-eabi/4.5.2/../../../../arm-none-linux-abi/include End of search list. In file included from ./test-case.c:1:0: /arm-none-linux-eabi/lib/gcc/arm-none-linux-eabi/4.5.2/include/stdarg.h:40:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The stack trace is the following: Program received signal SIGSEGV, Segmentation fault. 0x08358433 in should_emit_struct_debug () Current language: auto; currently asm #0 0x08358433 in should_emit_struct_debug () #1 0x08201a26 in gen_struct_or_union_type_die () #2 0x08202338 in gen_type_die_with_usage () #3 0x08202390 in gen_type_die () #4 0x081f3f0f in modified_type_die () #5 0x081fda5f in add_type_attribute () #6 0x08201ed4 in gen_typedef_die () #7 0x08202fe6 in gen_decl_die () #8 0x08203916 in dwarf2out_decl () #9 0x08203324 in dwarf2out_type_decl () #10 0x0835bd65 in rest_of_decl_compilation () #11 0x080d265c in finish_decl () #12 0x08133677 in c_parser_declaration_or_fndef () #13 0x08133153 in c_parser_external_declaration () #14 0x08132e08 in c_parser_translation_unit () #15 0x08141d23 in c_parse_file () #16 0x08126063 in c_common_parse_file () #17 0x08426ae9 in compile_file () #18 0x08428973 in do_compile () #19 0x08428a38 in toplev_main () #20 0x0814a172 in main () dump of should_emit_struct_debug(): 0x08358410 should_emit_struct_debug+101: lea-0x1c(%ebp),%edx 0x08358413 should_emit_struct_debug+104: mov%eax,0x4(%esp) 0x08358417 should_emit_struct_debug+108: mov%edx,(%esp) 0x0835841a should_emit_struct_debug+111: call 0x8581c07 expand_location 0x0835841f should_emit_struct_debug+116: sub$0x4,%esp 0x08358422 should_emit_struct_debug+119: movzbl -0x10(%ebp),%eax 0x08358426 should_emit_struct_debug+123: test %al,%al 0x08358428 should_emit_struct_debug+125: je 0x8358430 should_emit_struct_debug+133 0x0835842a should_emit_struct_debug+127: movb $0x1,-0x31(%ebp) 0x0835842e should_emit_struct_debug+131: jmp0x8358461 should_emit_struct_debug+182 0x08358430 should_emit_struct_debug+133: mov-0xc(%ebp),%eax 0x08358433 should_emit_struct_debug+136: mov0x10(%eax),%eax ^^^ crash above ^^^ 0x08358436 should_emit_struct_debug+139: lea-0x2c(%ebp),%edx 0x08358439 should_emit_struct_debug+142: mov%eax,0x4(%esp) 0x0835843d should_emit_struct_debug+146: mov%edx,(%esp) 0x08358440 should_emit_struct_debug+149: call 0x8581c07 expand_location 0x08358445 should_emit_struct_debug+154: sub$0x4,%esp 0x08358448 should_emit_struct_debug+157: mov-0x2c(%ebp),%eax 0x0835844b should_emit_struct_debug+160: mov%eax,(%esp) 0x0835844e should_emit_struct_debug+163: call 0x8358335 matches_main_base 0x08358453 should_emit_struct_debug+168: test %eax,%eax 0x08358455 should_emit_struct_debug+170: je 0x835845d should_emit_struct_debug+178 0x08358457 should_emit_struct_debug+172: movb $0x1,-0x31(%ebp) 0x0835845b should_emit_struct_debug+176: jmp0x8358461 should_emit_struct_debug+182 0x0835845d should_emit_struct_debug+178: movb $0x0,-0x31(%ebp) 0x08358461 should_emit_struct_debug+182: movzbl -0x31(%ebp),%eax 0x08358465 should_emit_struct_debug+186: leave 0x08358466 should_emit_struct_debug+187: ret and registers: (gdb) info registers eax0x0 0 [...] C source matching is left to the reader :) In case that help, this compiler was build with the latest GMP/MPC/MPFR. Compilers from the same code tree, but built for PowerPC or Sparc target, run fine. -- Summary: ICE with `-g -femit-struct-debug-baseonly' Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lacombar at gmail dot com GCC build triplet: i686-pc GCC host triplet: i686-pc GCC target triplet: arm-none-linux-eabi
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #20 from davidxl at gcc dot gnu dot org 2010-08-30 03:10 --- (In reply to comment #16) adjust summary according to the last timings I am surprised to see such big differences between trunk and previous releases. Compiling this test case with the those options on my core2 box (2.4GHz ) took only 56seconds which is comparable with the timing with a 4.4.3 compiler (with google local patches including ivopt improvements). David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug lto/45448] New: FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
On powerpc-apple-darwin9 at -m64 (as well as powerpc linux), an ICE occurs on testcase... FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error) This appears as... Executing on host: /Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/ c_lto_20090116_0.o -O1 -fwhopr -fPIC -r -nostdlib -O0 -m64 -o g cc-dg-lto-20090116-01(timeout = 300) In file included from :0:0: /Users/howarth/gcc/gcc/testsuite/gcc.dg/lto/20090116_0.c: In function 'foo': /Users/howarth/gcc/gcc/testsuite/gcc.dg/lto/20090116_0.c:5:5: internal compiler error: in insert_value_copy_on_edge, at tree-outof-ssa.c:243 Using built-in specs. COLLECT_GCC=dist/bin/gcc COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/powerpc-apple-darwin9.8.0/4.6.0/lto-wrapper Target: powerpc-apple-darwin9.8.0 Configured with: ../gcc/configure --prefix=/Users/howarth/dist --enable-languages=c,c++,lto --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-checking CC=gcc-4.2 CXX=g++-4.2 Thread model: posix gcc version 4.6.0 20100829 (experimental) (GCC) -- Summary: FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o- c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #21 from davidxl at gcc dot gnu dot org 2010-08-30 03:19 --- (In reply to comment #17) tree iv optimization : 32.57 (20%) usr 0.10 ( 5%) sys 32.73 (20%) wall 322095 kB (18%) ggc 20% is still completely unreasonable for IV optimization. There was a patch in trunk that may double the time in ivopt -- i.e. find_optimal_iv_set_1 is done twice, one with the original iv set while the other with full set. This probably needs to be revisited. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-08-30 03:20 --- Created an attachment (id=21588) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21588action=view) gdb log stepping from tree-outof-ssa.c:243 breakpoint to crash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448
[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-08-30 03:24 --- Created an attachment (id=21589) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21589action=view) archive with ltrans files generated for failing linkage -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448
[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-08-30 03:24 --- Intermediate files generated with... /Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/ c_lto_20090116_0.o -O1 -fwhopr -fPIC -r -nostdlib -O0 -m64 --save-temps -v -o gcc-dg-lto-20090116-01 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-08-30 03:26 --- Fixed in current gcc trunk. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
