[Bug middle-end/52640] [4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 08:03:44 UTC --- Any progress on this? Does the branch patch not work on the trunk?
[Bug c++/55643] [4.7/4.8 Regression] [C++11] incorrect warning: variable ‘myVar’ set but not used with an enum class-typed variable is casted to double for the use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55643 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 08:06:31 UTC --- Created attachment 28922 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28922 gcc48-pr55643.patch Untested fix.
[Bug target/47961] media-libs/xvid-1.3.0 fails to build on SPARC unless -mvis flag stripped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47961 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||FIXED --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 08:30:34 UTC --- Presumably fixed.
[Bug java/44495] [4.6/4.7/4.8 regression] ICE in java_mangle_resource_name, at java/mangle.c:658
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44495 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-11 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 08:32:07 UTC --- Does this still occur?
[Bug java/34426] GCC 4.2.2 compile failed in java due to error in java class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34426 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||WONTFIX --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 08:33:58 UTC --- 4.2.x is no longer supported.
[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54404 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 08:55:01 UTC --- The question is what remaining failures are actually regressions and which SVN revision introduced them if they are regressions.
[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 08:57:24 UTC --- Ping.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-11 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 08:59:53 UTC --- Indeed, looks like HWI issue, as I can reproduce it with i686-linux - hppa cross, but not x86_64-linux - hppa. The first difference starts during ivcanon, looking into it.
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-11 CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.7.3 Summary|ICE at extract_insn, at |[4.7/4.8 regression] ICE at |recog.c:2123 sparc64|extract_insn, at ||recog.c:2123 with ||-fprofile-generate Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 09:46:34 UTC --- Yup.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Summary|TSAN crashes for Fortran|TSAN: Fortran/OMP yields ||false positives --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-11 09:47:43 UTC --- Adjusting the subject, as the crashes have gone (checked also building CP2K with -fsanitize=thread) but the false positives remain.
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 09:47:45 UTC --- Investigating.
[Bug middle-end/52640] [4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 09:59:13 UTC --- (In reply to comment #17) Any progress on this? Does the branch patch not work on the trunk? Simply task of forward-porting and testing.
[Bug tree-optimization/55645] skipping unlike branch in vectorized loops using movmsk or equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55645 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-11 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:02:03 UTC --- Interesting idea ...
[Bug tree-optimization/55645] skipping unlike branch in vectorized loops using movmsk or equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55645
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2012-12-11 10:03:27
UTC ---
(In reply to comment #0)
// possible syntax
void compute() {
for (int i=0;i!=1024;++i) {
if likely(a[i]b[i]) // very often
c[i]=a[i]+b[i];
else // rare
c[i]=a[i]-b[i];
}
}
You may want to make the rare computation more expensive than that, I am not
sure there is a real speed improvement here (mask+compare+branch might take
about as long as minus+blend).
Interesting idea. First step would be to create a REDUC_TRUTH_AND_EXPR or
something like that to be able to represent _mm256_movemask_ps(mask) == 255 at
tree level.
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:06:20 UTC --- Author: rguenth Date: Tue Dec 11 10:06:15 2012 New Revision: 194388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194388 Log: 2012-12-11 Richard Biener rguent...@suse.de PR tree-optimization/55079 * tree-vrp.c (extract_range_from_binary_expr_1): Handle MAX/MIN_EXPR for more cases. (register_edge_assert_for_2): Register asserts for post-in/decrement tests. (check_array_ref): Dump what expression we emit array bound warnings for. (search_for_addr_array): Likewise. * gcc.dg/Warray-bounds-9.c: New testcase. * gcc.dg/Warray-bounds-10.c: Likewise. * gcc.dg/tree-ssa/ssa-pre-1.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-10.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:07:23 UTC --- That would be a bogus warning ... all uses of e are within FOR_EACH_EDGE. Trying to reproduce.
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:07:58 UTC --- All fixable testcases from this bug fixed.
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:13:10 UTC --- I am preparing a first patch, we of course need to verify the assertions in it are true ;)
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:19:32 UTC --- Author: rguenth Date: Tue Dec 11 10:19:21 2012 New Revision: 194389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194389 Log: 2012-12-11 Richard Biener rguent...@suse.de PR other/54324 * doc/install.texi (Tools/packages necessary for building GCC): State ISO C++98 host compiler requirement. Increment minimum GCC version required for building all languages for a cross-compiler to 3.4 or later. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:20:28 UTC --- Fixed as far as I am concerned.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 10:22:49 UTC --- Created attachment 28923 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28923 gcc48-pr55633.patch Untested fix.
[Bug target/55642] [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55642 --- Comment #1 from Kyrill Tkachov kyrylo.tkachov at arm dot com 2012-12-11 10:25:10 UTC --- Created attachment 28924 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28924 Reduced testcase
[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.0 Resolution||FIXED Target Milestone|4.6.4 |4.8.0 Known to fail||4.6.4, 4.7.2 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:26:30 UTC --- The original reason for this bug, compile-time and code-size growth of SPEC CPU 2006 and Polyhedron on AMD Barcelona with -march=native has been fixed (back to levels before the -fprefetch-loop-arrays defaulting). For 4.8, that is. Backporting not really possible (requires preserving of loop structure), thus wontfix on the branches.
[Bug target/55642] [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55642 Kyrill Tkachov kyrylo.tkachov at arm dot com changed: What|Removed |Added CC||kyrylo.tkachov at arm dot ||com --- Comment #2 from Kyrill Tkachov kyrylo.tkachov at arm dot com 2012-12-11 10:28:11 UTC --- Regression introduced with r193724. The abssi2 patterns in thumb2.md output two instructions but the enclosing it block thinks it's only one and therefore has the wrong number of t's (it instead of itt). Currently testing a patch to fix this. Thanks, Kyrill
[Bug tree-optimization/44061] [4.6/4.7/4.8 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44061 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:35:29 UTC --- Created attachment 28925 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28925 patch I was not happy with Old patch attached for reference.
[Bug fortran/55362] [4.6/4.7/4.8 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug regression/55451] [4.8 regression] FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/55645] skipping unlike branch in vectorized loops using movmsk or equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55645 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 10:40:10 UTC --- One problem is how to represent likely vs. unlikely COND_EXPR after ifcvt (plus also teach the vectorizer to create the GIMPLE_COND, and then/else bb's with some vectorized stmts duplicated and some just in one of those bbs.
[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55562 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|powerpc*-*-*|powerpc*-*-* ia64-*-* Priority|P3 |P1 Host|powerpc*-*-*| Target Milestone|--- |4.8.0 Build|powerpc*-*-*|
[Bug debug/55608] [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.6.4
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 10:41:55 UTC --- Author: jakub Date: Tue Dec 11 10:41:44 2012 New Revision: 194392 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194392 Log: PR middle-end/43631 PR bootstrap/55615 * var-tracking.c (emit_note_insn_var_location): If insn is followed by BARRIER, put note after the BARRIER. (next_non_note_insn_var_location): Skip over BARRIERs. (emit_notes_in_bb): If call is followed by BARRIER, put note after the BARRIER. * g++.dg/other/pr43631.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr43631.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug bootstrap/55615] [4.8 Regression] Failed to bootstrap with --with-arch=core2 --with-cpu=atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55615 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 10:42:01 UTC --- Author: jakub Date: Tue Dec 11 10:41:44 2012 New Revision: 194392 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194392 Log: PR middle-end/43631 PR bootstrap/55615 * var-tracking.c (emit_note_insn_var_location): If insn is followed by BARRIER, put note after the BARRIER. (next_non_note_insn_var_location): Skip over BARRIERs. (emit_notes_in_bb): If call is followed by BARRIER, put note after the BARRIER. * g++.dg/other/pr43631.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr43631.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug rtl-optimization/55627] [4.8 Regression] FAIL: g++.dg/bprob/g++-bprob-1.C execution, -Os -fprofile-arcs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55627 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/55645] skipping unlike branch in vectorized loops using movmsk or equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55645
--- Comment #4 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-12-11 10:43:21 UTC ---
sure use c[i]=std::sqrt(a[i]/b[i]);
Recent literature is plenty of examples mostly related to GPU code
see for instance
Random Variable Recycling - Numerical Algorithms Group
www.nag.co.uk/.../gpus/random_variable_recycling_note.pdf
In particular the erfinv implementations by Mike Giles
Approximating the erfinv function - Mathematical Institute
people.maths.ox.ac.uk/gilesm/files/gems_erfinv.pdf
(very simple, copy paste from last page or look below!)
the Acklam's one
http://home.online.no/~pjacklam/notes/invnorm/
(code at the bottom of
http://home.online.no/~pjacklam/notes/invnorm/impl/lea/lea.c)
or Shaw et al (http://arxiv.org/abs/0901.0638)
I'm currently experimenting with Giles' code
#include approx_exp.h
#include approx_log.h
#include cmath
#define likely(x) (__builtin_expect(x, true))
inline
float erfinv_like(float w) {
w = w - 2.50f;
float p = 2.81022636e-08f;
p = 3.43273939e-07f + p*w;
p = -3.5233877e-06f + p*w;
p = -4.39150654e-06f + p*w;
p = 0.00021858087f + p*w;
p = -0.00125372503f + p*w;
p = -0.00417768164f + p*w;
p = 0.246640727f + p*w;
p = 1.50140941f + p*w;
return p;
}
inline
float erfinv_unlike(float w) {
w = std::sqrt(w) - 3.00f;
float p = -0.000200214257f;
p = 0.000100950558f + p*w;
p = 0.00134934322f + p*w;
p = -0.00367342844f + p*w;
p = 0.00573950773f + p*w;
p = -0.0076224613f + p*w;
p = 0.00943887047f + p*w;
p = 1.00167406f + p*w;
p = 2.83297682f + p*w;
return p;
}
inline float erfinv(float x) {
float w, p;
w = - unsafe_logf8((1.0f-x)*(1.0f+x));
if likely( w 5.00f )
p = erfinv_like(w);
else
erfinv_unlike(w);
}
return p*x;
}
float a[1024];
float b[1024];
void compute() {
for (int i=0;i!=1024;++i)
b[i]=erfinv(a[i]);
}
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 10:49:24 UTC --- Fixed.
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 10:53:53 UTC --- works for me ...
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 11:19:11 UTC --- Jakub, I presume it's an oversight that the combined tldo_add + store patterns have a =r constraint on the source operand: (define_insn *tldo_stb_sp32 [(set (mem:QI (plus:SI (unspec:SI [(match_operand:SI 2 register_operand r) (match_operand 3 tld_symbolic_operand )] UNSPEC_TLSLDO) (match_operand:SI 1 register_operand r))) (match_operand:QI 0 register_operand =r))] TARGET_TLS TARGET_ARCH32 stb\t%0, [%1 + %2], %%tldo_add(%3) [(set_attr type store)])
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636 --- Comment #5 from janus at gcc dot gnu.org 2012-12-11 11:22:15 UTC --- For completeness: The regression was apparently introduced by the following revision ... http://gcc.gnu.org/viewcvs?view=revisionrevision=187472 Btw, how is it a build failure?
[Bug middle-end/55630] [4.8 Regression] FAIL: g++.dg/pr48660.C -std=c++98 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55630 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 11:34:16 UTC --- Can't reproduce with a cross compiler, not even 32-bit HWI one.
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 11:41:04 UTC --- Created attachment 28926 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28926 gcc48-pr54926.patch Richard discovered that adding it unconditionally doesn't work with system compilers, either too old g++'s or perhaps other vendor compilers. Untested fix attached.
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 11:51:29 UTC --- (In reply to comment #4) Jakub, I presume it's an oversight that the combined tldo_add + store patterns have a =r constraint on the source operand: (define_insn *tldo_stb_sp32 [(set (mem:QI (plus:SI (unspec:SI [(match_operand:SI 2 register_operand r) (match_operand 3 tld_symbolic_operand )] UNSPEC_TLSLDO) (match_operand:SI 1 register_operand r))) (match_operand:QI 0 register_operand =r))] TARGET_TLS TARGET_ARCH32 stb\t%0, [%1 + %2], %%tldo_add(%3) [(set_attr type store)]) Obviously. Please remove the = from all the tldo_st*_sp* patterns. I bet I've created them from the tldo_ld* patterns initially by swapping the operands.
[Bug regression/55451] [4.8 regression] FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 12:14:31 UTC --- Okay, I can submit the patch to gcc-patches, but can't do testing of it easily.
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #22 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-12-11 12:18:23 UTC --- (In reply to comment #21) What I don't understand is what is bad with Rolf's proposal of defining STAMP? Stamping is not that unusual in the build process. Up to now it was not needed, but is it that critical to set STAMP like proposed above?
[Bug libgcc/55451] [4.8 regression] FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 --- Comment #5 from gretay at gcc dot gnu.org 2012-12-11 12:28:55 UTC --- Sorry, Jakub, I meant to say I am *not* entirely following the explanation... I can run a regression test with this patch for arm-none-eabi on qemu and/or bootstrap on arm. Would that be enough for testing this change? Thanks, Greta
[Bug libgcc/55451] [4.8 regression] FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 12:45:59 UTC --- I think so. Let me post to gcc-patches.
[Bug tree-optimization/54570] [4.8 Regression] FAIL: gcc.dg/builtin-object-size-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54570 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2012-12-11 12:54:43 UTC --- An alternative suggestion was to allow arbitrary complex addresses (well, arbitrary == gimplified ADDR_EXPRs) in call arguments (either in general or just for specially marked builtins). That way they escape SSA based CSE. Yet another variant would be to have an optional 2nd operand for ADDR_EXPRs for the Frontend to fill in, specifying the size of the object at that address. Preserving that across propagation/substitution would be required of course (details on what the 'size' of a[2] with int a[4]; would be is still to be determined). I'm leaning towards trying to have explicit information tracked from their origin rather than trying to re-discover them after optimizations obfuscated them.
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-11 Ever Confirmed|0 |1 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-12-11 13:56:47 UTC --- This may be related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55519 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496
[Bug c/55646] New: Array of data as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55646
Bug #: 55646
Summary: Array of data as argument
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bratsi...@gmail.com
If wrote this:
fwrite(\xAA\xBB\xCC\x0A, 1, 4, stdout);
gcc put in .data/.text section one piece of data, something like that:
.string \252\273\314\n
But if wrote this:
fwrite((uint8_t[]){0xAA,0xBB,0xCC,0x0A}, 1, 4, stdout);
gcc will put the data bit by bit in stack, something like that:
movb $-86, (%rsp)
movb $-69, 1(%rsp)
movb $-52, 2(%rsp)
movb $10, 3(%rsp)
P.S. Build with -O3
[Bug c/55646] Array of data as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55646
--- Comment #1 from Alexander bratsinot at gmail dot com 2012-12-11 14:07:21
UTC ---
If write this:
static const uint8_t qwe[] = {0xAA,0xBB,0xCC,0x0A};
fwrite(qwe, 1, 4, stdout);
gcc put data in one piece, something like that:
qwe.2230:
.byte -86
.byte -69
.byte -52
.byte 10
P.S.S. Sorry for my mistakes, English not my native language.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #6 from nightstrike nightstrike at gmail dot com 2012-12-11 14:14:47 UTC --- Tobias, what is your full configure line alongside --disable-nls?
[Bug target/55642] [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55642 --- Comment #3 from ktkachov at gcc dot gnu.org 2012-12-11 14:17:33 UTC --- Author: ktkachov Date: Tue Dec 11 14:17:28 2012 New Revision: 194398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194398 Log: gcc/ChangeLog 2012-12-11 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/55642 * config/arm/thumb2.md (*thumb2_abssi2): Set ce_count attribute to 2. (*thumb2_neg_abssi2): Likewise. gcc/testsuite/ChangeLog 2012-12-11 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/55642 * gcc.target/arm/pr55642.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/arm/pr55642.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/thumb2.md trunk/gcc/testsuite/ChangeLog
[Bug target/55642] [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55642 --- Comment #4 from Kyrill Tkachov kyrylo.tkachov at arm dot com 2012-12-11 14:20:57 UTC --- Should be fixed in trunk now
[Bug target/55642] [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55642 --- Comment #5 from Kyrill Tkachov kyrylo.tkachov at arm dot com 2012-12-11 14:29:59 UTC --- (In reply to comment #4) Should be fixed in trunk now Can you please check that it works for you now? http://gcc.gnu.org/viewcvs?view=revisionrevision=194398 Thanks, Kyrill
[Bug tree-optimization/55645] skipping unlike branch in vectorized loops using movmsk or equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55645 --- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-12-11 14:34:45 UTC --- in principle, one could add the movmsk unconditionally (well, if advantagious) after the compare and evaluate only one one of legs of the branch in case the result is 0 or all ones. My understanding is that this is similar to what CUDA does for instance.
[Bug tree-optimization/54570] [4.8 Regression] FAIL: gcc.dg/builtin-object-size-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54570 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 14:35:06 UTC --- Author: jakub Date: Tue Dec 11 14:34:57 2012 New Revision: 194401 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194401 Log: PR tree-optimization/54570 * gcc.dg/builtin-object-size-8.c: Xfail. * gcc.dg/builtin-object-size-13.c: New test. Added: trunk/gcc/testsuite/gcc.dg/builtin-object-size-13.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtin-object-size-8.c
[Bug tree-optimization/54570] [4.8/4.9 Regression] FAIL: gcc.dg/builtin-object-size-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54570 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |4.9.0 Summary|[4.8 Regression] FAIL: |[4.8/4.9 Regression] FAIL: |gcc.dg/builtin-object-size- |gcc.dg/builtin-object-size- |8.c execution test |8.c execution test --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 14:45:27 UTC --- Deferring for 4.9.0, this isn't safely fixable for 4.8.0 and hopefully doesn't cause problems in too many real-world programs.
[Bug fortran/55362] [4.6/4.7/4.8 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-11
14:46:03 UTC ---
Untested patch. However, I think we need to do more. I think it won't cover the
DIM= argument and other intrinsics are presumably also affected.
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3593,4 +3593,11 @@ gfc_try
gfc_check_size (gfc_expr *array, gfc_expr *dim, gfc_expr *kind)
{
+ if (array-ts.type == BT_PROCEDURE)
+{
+ gfc_error ('%s' argument of '%s' intrinsic at %L may not be a
procedure,
+gfc_current_intrinsic_arg[0]-name, gfc_current_intrinsic,
+array-where);
+ return FAILURE;
+}
if (array_check (array, 0) == FAILURE)
return FAILURE;
[Bug fortran/55482] gfortran.dg/class_array_7.f03 execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55482 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #4 from Tom Tromey tromey at gcc dot gnu.org 2012-12-11 15:09:26 UTC --- (In reply to comment #3) BTW, the debug info for the classes looks wrong, break 25 [...] The DWARF seems reasonable enough to me. I think this is a gdb bug. Basically, the Fortran type-printer always prints the target type of a pointer type. This causes infinite recursion. I don't know Fortran well enough to say what the best fix would be. If someone can tell me what it ought to do, I can implement it.
[Bug libitm/55648] New: [4.8 Regression] FAIL: libitm.c++/eh-1.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55648 Bug #: 55648 Summary: [4.8 Regression] FAIL: libitm.c++/eh-1.C execution test Classification: Unclassified Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: howa...@bromo.med.uc.edu, ia...@gcc.gnu.org, r...@gcc.gnu.org Host: x86_64-apple-darwin* Target: x86_64-apple-darwin* Build: x86_64-apple-darwin* Between revisions 193270 (OK) and 193279 (fail, likely r193271) the test libitm.c++/eh-1.C has started to fail with -m32/-m64: FAIL: libitm.c++/eh-1.C execution test I think this pr is different from pr52220. Valgrind gives ==41280== Memcheck, a memory error detector ==41280== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==41280== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==41280== Command: a.out ==41280== ==41280== Invalid write of size 4 ==41280==at 0x116D3: f1() (eh-1.C:12) ==41280==by 0x11715: f2() (eh-1.C:18) ==41280==by 0x11780: main (eh-1.C:29) ==41280== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==41280== ==41280== ==41280== Process terminating with default action of signal 11 (SIGSEGV) ==41280== Access not within mapped region at address 0x0 ==41280==at 0x116D3: f1() (eh-1.C:12) ==41280==by 0x11715: f2() (eh-1.C:18) ==41280==by 0x11780: main (eh-1.C:29) ==41280== If you believe this happened as a result of a stack ==41280== overflow in your program's main thread (unlikely but ==41280== possible), you can try to increase the size of the ==41280== main thread stack using the --main-stacksize= flag. ==41280== The main thread stack size used in this run was 67104768. ==41280== ==41280== HEAP SUMMARY: ==41280== in use at exit: 7,192 bytes in 10 blocks ==41280== total heap usage: 10 allocs, 0 frees, 7,192 bytes allocated ==41280== ==41280== LEAK SUMMARY: ==41280==definitely lost: 0 bytes in 0 blocks ==41280==indirectly lost: 0 bytes in 0 blocks ==41280== possibly lost: 24 bytes in 1 blocks ==41280==still reachable: 7,080 bytes in 8 blocks ==41280== suppressed: 88 bytes in 1 blocks ==41280== Rerun with --leak-check=full to see details of leaked memory ==41280== ==41280== For counts of detected and suppressed errors, rerun with: -v ==41280== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault
[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54404 --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-11 15:52:40 UTC --- Actually we need one for post-darwin11 failures and another for those unique to post-darwin12. Jack, I don't have access to darwin11 or 12. Could you open the PR(s) you think necessary, then I'll close this one as fixed.
[Bug libitm/55648] [4.8 Regression] FAIL: libitm.c++/eh-1.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55648 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|4.4.0 |4.8.0 Target Milestone|--- |4.8.0
[Bug target/54061] [4.8 Regression] gcc.c-torture/compile/mipscop-*.c ICEs with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54061 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 16:01:10 UTC --- Fixed then.
[Bug libstdc++/55649] New: libstdcxx gdb python pretty printer for tr1 not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55649 Bug #: 55649 Summary: libstdcxx gdb python pretty printer for tr1 not working Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: david.simmo...@igmarkets.com The Tr1UnorderedMapPrinter pretty printer, and other tr1 pretty printers look for variables starting with _M_, the actual variable names start with m_ For example, should be m_element_count rather than _M_element_count
[Bug libstdc++/55649] libstdcxx gdb python pretty printer for tr1 not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55649
--- Comment #1 from Dave Simmonds david.simmonds at igmarkets dot com
2012-12-11 16:19:09 UTC ---
(gdb) print g_epicmap-m_Map
$1 = Traceback (most recent call last):
File /usr/share/gdb/python/libstdcxx/v6/printers.py, line 536, in to_string
return '%s with %d elements' % (self.typename,
self.val['_M_element_count'])
RuntimeError: There is no member or method named _M_element_count.
Traceback (most recent call last):
File /usr/share/gdb/python/libstdcxx/v6/printers.py, line 555, in children
data = self.flatten (itertools.imap (self.format_one, Tr1HashtableIterator
(self.val)))
File /usr/share/gdb/python/libstdcxx/v6/printers.py, line 477, in __init__
self.n_buckets = hash['_M_element_count']
RuntimeError: There is no member or method named _M_element_count.
(gdb) print /r g_epicmap-m_Map
$2 = {
std::tr1::hashtablechar const*, std::pairchar const* const,
boost::shared_ptrCEpicRecord , std::allocatorstd::pairchar const* const,
boost::shared_ptrCEpicRecord , Internal::extract1ststd::pairchar const*
const, boost::shared_ptrCEpicRecord , _ConstCharPtrCmp, _ConstCharHash,
Internal::mod_range_hashing, Internal::default_ranged_hash,
Internal::prime_rehash_policy, false, false, true = {
Internal::rehash_baseInternal::prime_rehash_policy,
std::tr1::hashtablechar const*, std::pairchar const* const,
boost::shared_ptrCEpicRecord , std::allocatorstd::pairchar const* const,
boost::shared_ptrCEpicRecord , Internal::extract1ststd::pairchar const*
const, boost::shared_ptrCEpicRecord , _ConstCharPtrCmp, _ConstCharHash,
Internal::mod_range_hashing, Internal::default_ranged_hash,
Internal::prime_rehash_policy, false, false, true = {No data fields},
Internal::hash_code_basechar const*, std::pairchar const* const,
boost::shared_ptrCEpicRecord , Internal::extract1ststd::pairchar const*
const, boost::shared_ptrCEpicRecord , _ConstCharPtrCmp, _ConstCharHash,
Internal::mod_range_hashing, Internal::default_ranged_hash, false = {
m_extract = {No data fields},
m_eq = {No data fields},
m_h1 = {No data fields},
m_h2 = {No data fields}
},
Internal::map_basechar const*, std::pairchar const* const,
boost::shared_ptrCEpicRecord , Internal::extract1ststd::pairchar const*
const, boost::shared_ptrCEpicRecord , true, std::tr1::hashtablechar
const*, std::pairchar const* const, boost::shared_ptrCEpicRecord ,
std::allocatorstd::pairchar const* const, boost::shared_ptrCEpicRecord ,
Internal::extract1ststd::pairchar const* const,
boost::shared_ptrCEpicRecord , _ConstCharPtrCmp, _ConstCharHash,
Internal::mod_range_hashing, Internal::default_ranged_hash,
Internal::prime_rehash_policy, false, false, true = {No data fields},
members of std::tr1::hashtablechar const*, std::pairchar const* const,
boost::shared_ptrCEpicRecord , std::allocatorstd::pairchar const* const,
boost::shared_ptrCEpicRecord , Internal::extract1ststd::pairchar const*
const, boost::shared_ptrCEpicRecord , _ConstCharPtrCmp, _ConstCharHash,
Internal::mod_range_hashing, Internal::default_ranged_hash,
Internal::prime_rehash_policy, false, false, true:
m_node_allocator = {
__gnu_cxx::new_allocatorInternal::hash_nodestd::pairchar const*
const, boost::shared_ptrCEpicRecord , false = {No data fields}, No
data fields},
m_buckets = 0x2aaac010,
m_bucket_count = 92203,
m_element_count = 69182,
m_rehash_policy = {
m_max_load_factor = 1,
m_growth_factor = 2,
m_next_resize = 92203
}
}, No data fields}
[Bug middle-end/55623] [ARM] GCC should not prefer long dependency chains, they inhibit performance on superscalar processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55623 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-12-11 16:33:25 UTC --- (In reply to comment #8) You can also adjust --param tree-reassoc-width or have the target implement the sched.reassociation_width target hook (for the default). I did try it on an A9 when the hook came out and it made bugger all difference to the benchmarks I cared about on a range of values. It's possible this might help on some of the newer cores. ramana
[Bug libstdc++/55649] libstdcxx gdb python pretty printer for tr1 not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55649 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-11 16:34:09 UTC --- (In reply to comment #0) The Tr1UnorderedMapPrinter pretty printer, and other tr1 pretty printers look for variables starting with _M_, the actual variable names start with m_ No they don't: http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/tr1/unordered_map.h?view=markup
[Bug libstdc++/55649] libstdcxx gdb python pretty printer for tr1 not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55649 --- Comment #3 from Dave Simmonds david.simmonds at igmarkets dot com 2012-12-11 16:49:17 UTC --- (In reply to comment #2) (In reply to comment #0) The Tr1UnorderedMapPrinter pretty printer, and other tr1 pretty printers look for variables starting with _M_, the actual variable names start with m_ No they don't: http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/tr1/unordered_map.h?view=markup Thanks for your reply, but the link isn't showing any variables with _M_ or with m_, so doesn't help. Why do you say they don't? Certainly it's not working for me as is, and if I create my own pretty printer with _M_ replaced by m_ it works.
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 16:51:31 UTC --- Author: jakub Date: Tue Dec 11 16:51:16 2012 New Revision: 194404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194404 Log: PR c++/55619 * semantics.c (finish_asm_stmt): Don't call decay_conversion on input operands that can be only in memory. * g++.dg/ext/asm12.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/asm12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 16:54:20 UTC --- Fixed.
[Bug middle-end/52640] [4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #19 from Jan Smets jan.sm...@alcatel-lucent.com 2012-12-11 16:55:30 UTC --- Steven's example only contains 10 000 entries. I need to recompile a symbol table of 270.000 entries a dozen times each day. (and so do a lot of other people) With the 'fix' it still takes 12+ seconds to compile it on a state of the art machine and then another 4+ seconds to assemble. CLANG2.8 spends 15.5 sec and CLANG3.1 16.5 sec. I'm already happy with the work around but I'd really like to see a more structural solution, whichever that may be. Thanks
[Bug libstdc++/55649] libstdcxx gdb python pretty printer for tr1 not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55649 Dave Simmonds david.simmonds at igmarkets dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Dave Simmonds david.simmonds at igmarkets dot com 2012-12-11 16:56:19 UTC --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #0) The Tr1UnorderedMapPrinter pretty printer, and other tr1 pretty printers look for variables starting with _M_, the actual variable names start with m_ No they don't: http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/tr1/unordered_map.h?view=markup Thanks for your reply, but the link isn't showing any variables with _M_ or with m_, so doesn't help. Why do you say they don't? Certainly it's not working for me as is, and if I create my own pretty printer with _M_ replaced by m_ it works. OK, I looked at the include file, I compiled against gcc 4.1.2, which has m_, 4.7.2 has _M_ Problem is that redhat el5 comes with gcc 4.1.2 and a pretty printer with _M_ which doesn't work togther
[Bug middle-end/52640] [4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 17:05:33 UTC --- Created attachment 28927 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28927 gcc48-pr52640.patch Patch I'm going to bootstrap/regtest on the trunk. No point to #include pointer-set.h when it is already included (it is included twice in 4.7 varams.c), and the var should be IMHO defined only if ASM_OUTPUT_EXTERNAL is defined, otherwise it is unused local var.
[Bug libstdc++/55649] libstdcxx gdb python pretty printer for tr1 not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55649 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-11 17:10:29 UTC --- (In reply to comment #3) Thanks for your reply, but the link isn't showing any variables with _M_ or with m_, so doesn't help. Sorry, I should have used http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/tr1/hashtable_policy.h?view=markup or http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/tr1/hashtable.h?view=markup
[Bug gcov-profile/55650] New: [4.8 Regression] Firefox profiledbuild: libxul.so: cannot map zero-fill pages: Cannot allocate memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55650
Bug #: 55650
Summary: [4.8 Regression] Firefox profiledbuild: libxul.so:
cannot map zero-fill pages: Cannot allocate memory
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de
Building Firefox with:
make -f client.mk profiledbuild
Results in:
...
/var/tmp/moz-build-dir/dist/bin/xpcshell: error while loading shared libraries:
libxul.so: cannot map zero-fill pages: Cannot allocate memory
make[4]: *** [prepare-package] Error 127
% readelf -lSW ./libxul.so
There are 41 section headers, starting at offset 0x103e7f10:
Section Headers:
[Nr] Name TypeAddress OffSize ES Flg
Lk Inf Al
...
[28] .bss NOBITS 0bfaabe0 bfa9be0 80186ae8c 00
WA 0 0 32
Adding Wl,-Map,libxul.map when linking libxul shows:
...
.bss..LPBX10x0ccb3be0 0x8
/var/tmp/moz-build-dir/toolkit/library/../components/protobuf/once.i_o
Reducing once.cpp leads to:
% cat test.ii
class A
{
virtual void Run ();
};
class B:public A
{
public:
B ();
void Run ()
{
}
};
void *operator new (unsigned long)
__attribute__ ((__externally_visible__));
void *moz_xmalloc ();
inline void *operator
new (unsigned long)
{
return moz_xmalloc ();
}
inline A *
NewCallback ()
{
return new B;
}
% c++ -c -fprofile-generate -fdata-sections -O2 test.ii
% readelf -lSW ./test.o | grep 8
[11] .bss..LPBX1 NOBITS 000120 8 00
WA 0 0 32
[Bug target/54974] [4.7 Regression] [ARM] [thumb] Incorrect placement of constant pools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54974 --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-12-11 17:36:34 UTC --- Matt, Are you planning on backporting this to 4.7 ? regards Ramana
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-12-11 17:52:41 UTC --- Assuming fixed - if there is a problem a new PR can be filed.
[Bug rtl-optimization/55193] [4.8 Regression] ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 18:01:19 UTC --- Author: jakub Date: Tue Dec 11 18:01:09 2012 New Revision: 194405 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194405 Log: PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug c++/54416] [4.7/4.8 Regression] ICE (segv) in codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54416 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-12-11 18:17:00 UTC --- Author: jason Date: Tue Dec 11 18:16:50 2012 New Revision: 194408 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194408 Log: PR c++/54416 * pt.c (maybe_process_partial_specialization): Don't accept definition of a specialization without the appropriate header. Added: trunk/gcc/testsuite/g++.dg/template/error48.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/template/crash105.C
[Bug c/55651] New: gcc hangs when -Wp, is passed on the command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651 Bug #: 55651 Summary: gcc hangs when -Wp, is passed on the command line Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: steve.ulr...@broadcom.com If a user neglects to add the required parameter at the end of the -Wp, prefix and just lists -Wp, on the command line, gcc hangs. To reproduce, issue the following commands: $ cp /dev/null testfile.c $ gcc -Wp, -c testfile.c This has been reproduced on a GCC cross compiler for PowerPC, and also for ARM, so is believed to be reproducible regardless of the target CPU architecture. gcc -v output: Using built-in specs. COLLECT_GCC=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr/bin/arm-broadcom-linux-uclibcgnueabi-gcc COLLECT_LTO_WRAPPER=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr/libexec/gcc/arm-broadcom-linux-uclibcgnueabi/4.7.2/lto-wrapper Target: arm-broadcom-linux-uclibcgnueabi Configured with: /projects/broadcom-linux/Northstar/tools/output/toolchain/gcc-4.7.2/configure --prefix=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-broadcom-linux-uclibcgnueabi --enable-languages=c,c++ --with-sysroot=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr/arm-broadcom-linux-uclibcgnueabi/sysroot --with-build-time-tools=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr/arm-broadcom-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr --with-mpfr=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr --with-mpc=/projects/nwsoft-toolchains/brl/brl_2.1/brl_2.1.0/northstar/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a9 --with-pkgversion='Buildroot 2012.11-git-00621-gc13e2bc-dirty' --with-bugurl=http://bugs.buildroot.net/ --with-pkgversion='Broadcom Linux v2.1' Thread model: posix gcc version 4.7.2
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #15 from Zdenek Dvorak rakdver at gcc dot gnu.org 2012-12-11
18:19:40 UTC ---
Created attachment 28928
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28928
A proposed patch
This patch fixes the error (and also makes the code more clearly match what is
described in the comments). Long story: we try to avoid rewriting computations
that define bivs, as that is usually unnecessary. However, there is a special
case where rewriting is still needed; e.g.,
loop
{
tmp = biv + 1;
use (tmp);
biv = tmp + 1; (*)
}
Ivopts may decide to eliminate the temporary variable tmp by expressing its use
in some other way (based on a different biv, etc.). So, if we did not rewrite
(*), it would refer to a variable that is no longer defined.
And in this case, we used a wrong way of expressing the biv computation that
may cause signed overflows. The patch makes us instead to fall back to the
general rewriting case, which does not have this problem. Untested (beyond the
single testcase + C-only bootstrap).
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 18:42:37 UTC --- Author: ebotcazou Date: Tue Dec 11 18:42:31 2012 New Revision: 194410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194410 Log: PR target/54121 * config/sparc/sparc.md (tldo_stb_sp32): Fix pasto. (tldo_stb_sp64): Likewise. (tldo_sth_sp32): Likewise. (tldo_sth_sp64): Likewise. (tldo_stw_sp32): Likewise. (tldo_stw_sp64): Likewise. (tldo_stx_sp64): Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr54121.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md trunk/gcc/testsuite/ChangeLog
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 18:44:57 UTC --- Author: ebotcazou Date: Tue Dec 11 18:44:48 2012 New Revision: 194411 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194411 Log: PR target/54121 * config/sparc/sparc.md (tldo_stb_sp32): Fix pasto. (tldo_stb_sp64): Likewise. (tldo_sth_sp32): Likewise. (tldo_sth_sp64): Likewise. (tldo_stw_sp32): Likewise. (tldo_stw_sp64): Likewise. (tldo_stx_sp64): Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr54121.c - copied unchanged from r194410, trunk/gcc/testsuite/gcc.dg/pr54121.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sparc/sparc.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 18:45:52 UTC --- Author: jakub Date: Tue Dec 11 18:45:45 2012 New Revision: 194412 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194412 Log: PR bootstrap/54926 * Makefile.am (AM_CFLAGS): Remove -frandom-seed=$@. * configure.ac: If --with-target-subdir, add -frandom-seed=$@ to EXTRA_FLAGS unconditionally, otherwise check whether the compiler accepts it. * Makefile.in: Regenerated. * configure: Regenerated. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/Makefile.am trunk/libbacktrace/Makefile.in trunk/libbacktrace/configure trunk/libbacktrace/configure.ac
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 18:46:30 UTC --- Author: ebotcazou Date: Tue Dec 11 18:46:20 2012 New Revision: 194413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194413 Log: PR target/54121 * config/sparc/sparc.md (tldo_stb_sp32): Fix pasto. (tldo_stb_sp64): Likewise. (tldo_sth_sp32): Likewise. (tldo_sth_sp64): Likewise. (tldo_stw_sp32): Likewise. (tldo_stw_sp64): Likewise. (tldo_stx_sp64): Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/sparc/sparc.md
[Bug target/54121] [4.7/4.8 regression] ICE at extract_insn, at recog.c:2123 with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-11 18:47:49 UTC --- Thanks for reporting the problem.
[Bug c++/55643] [4.7/4.8 Regression] [C++11] incorrect warning: variable ‘myVar’ set but not used with an enum class-typed variable is casted to double for the use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55643 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 19:01:51 UTC --- Author: jakub Date: Tue Dec 11 19:01:45 2012 New Revision: 194415 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194415 Log: PR c++/55643 * expr.c (mark_exp_read): Handle FLOAT_EXPR similarly to NOP_EXPR. * g++.dg/warn/Wunused-var-19.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55643] [4.7/4.8 Regression] [C++11] incorrect warning: variable ‘myVar’ set but not used with an enum class-typed variable is casted to double for the use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55643 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 19:06:23 UTC --- Author: jakub Date: Tue Dec 11 19:06:19 2012 New Revision: 194416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194416 Log: PR c++/55643 * expr.c (mark_exp_read): Handle FLOAT_EXPR similarly to NOP_EXPR. * g++.dg/warn/Wunused-var-19.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/warn/Wunused-var-19.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/expr.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/55643] [4.7/4.8 Regression] [C++11] incorrect warning: variable ‘myVar’ set but not used with an enum class-typed variable is casted to double for the use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55643 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 19:07:41 UTC --- Fixed.
[Bug c++/55652] New: [C++11][4.8] ICE (segfault) with templates and structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55652
Bug #: 55652
Summary: [C++11][4.8] ICE (segfault) with templates and structs
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.abdurachma...@gmail.com
Created attachment 28929
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28929
testcase used.
Hi folks,
I have started re-compiling my RPMs with GNU GCC 4.8.0 (revision 194323) to
check the status.
Below your will find the smallest test case I currently could produce showing
setfault (ICE). Yet I am still not fully sure what is causing it. I compiles w/
C++03, but not w/ C++11. It also compiles w/ GCC 4.7.2.
I am attaching *.ii.
## TESTCASE ##
#include map
template typename T1, typename T2
struct P {
T1 first;
T2 second;
P() : first(T1()), second(T2()) {}
};
struct E {
};
struct B {
B();
B(const B obj) throw(E);
};
int main(void) {
PB, std::mapB, B a;
return 0;
}
## COMPILE LINE ##
g++ -v -save-temps -std=c++11 -c -o test.o ./test.cxx
## GCC OUTPUT ##
./test.cxx: In function 'int main()':
./test.cxx:19:25: internal compiler error: Segmentation fault
PB, std::mapB, B a;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
## GCC FULL OUTPUT ##
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../configure
--prefix=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--disable-multilib --disable-nls --enable-languages=c,c++,fortran
--enable-gold=yes --enable-lto
--with-gmp=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-mpfr=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-mpc=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-isl=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--with-cloog=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0
--disable-isl-version-check --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'
CPP=cpp CXXCPP='c++ -E'
Thread model: posix
gcc version 4.8.0 20121208 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-o' 'test.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-E -quiet -v -iprefix
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/
-D_GNU_SOURCE ./test.cxx -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -o test.ii
ignoring nonexistent directory
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include
ignoring duplicate directory
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
ignoring duplicate directory
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu
ignoring duplicate directory
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
ignoring duplicate directory
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
ignoring duplicate directory
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
ignoring nonexistent directory
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu
[Bug rtl-optimization/55193] [4.8 Regression] ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 19:15:21 UTC --- Fixed.
[Bug c++/55643] [4.7/4.8 Regression] [C++11] incorrect warning: variable ‘myVar’ set but not used with an enum class-typed variable is casted to double for the use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55643 --- Comment #9 from Daniel Holbert dholbert at cs dot stanford.edu 2012-12-11 19:20:34 UTC --- Thanks for the quick turnaround!
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #154 from Teresa Johnson tejohnson at google dot com 2012-12-11 19:30:53 UTC --- What was the size of the gcc lto/pgo binary before the change to use the histogram? Was it close to the gcc 4.7 lto/pgo size? In that case that is a very large increase, ~25%. Markus, could you attach to the bug one of the gcda files so that I can see the program summary and figure out how far off the old hot bb threshold is from the new histogram-based one? Also, it would be good to see the -fdump-ipa-inline dumps before and after the regression (if necessary, the before one could be from 4_7).
[Bug middle-end/55653] New: Unnecessary initialization of vector register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55653
Bug #: 55653
Summary: Unnecessary initialization of vector register
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: josh.m.con...@gmail.com
When initializing all lanes of a vector register, I notice that the register is
first initialized to zero and then all lanes of the vector are independently
initialized, resulting in extra code.
Specifically, I'm looking at the aarch64 target, with the following source:
void
fmla_loop (double * restrict result, double * restrict mul1,
double mul2, int size)
{
int i;
for (i = 0; i size; i++)
result[i] = result[i] + mul1[i] * mul2;
}
Compiled with:
aarch64-linux-gnu-gcc -std=c99 -O3 -ftree-vectorize -S -o test.s test.c
The resultant code to initialize a vector register with two instances of mul2
is:
adr x3, .LC0
ld1 {v3.2d}, [x3]
ins v3.d[0], v0.d[0]
ins v3.d[1], v0.d[0]
...
.LC0:
.word 0
.word 0
.word 0
.word 0
Where the first two instructions (that initialize the vector register) are
unnecessary, as is the space for .LC0.
Note that this initialization is being performed here in store_constructor:
/* Inform later passes that the old value is dead. */
if (!cleared !vector REG_P (target))
emit_move_insn (target, CONST0_RTX (GET_MODE (target)));
right after another check to see if the vector needs to be cleared out (and
determine that it doesn't).
Instead of the emit_move_insn, that code used to be:
emit_insn (gen_rtx_CLOBBER (VOIDmode, target));
But was changed in r101169, with the comment:
The expr.c change elides an extra move that's creeped in since we
changed clobbered values to get new registers in reload.
(see full checkin text here:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01584.html)
It's not clear to me whether this can be changed back, or if later passes
should be recognizing this initialization as redundant, or whether we need a
new expand pattern to match vector fill (vector duplicate). At any rate, the
code is certainly not ideal as it stands.
Thanks!
[Bug c++/55624] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55624 --- Comment #4 from shawn.pringle at gmail dot com 2012-12-11 19:45:23 UTC --- On 10/12/2012 6:44 AM, rguenth at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55624 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 09:44:34 UTC --- (In reply to comment #2) gcc: internal compiler error: Killed (program cc1plus) Also means the program was killed by the kernel because out of memory. And -DBOOST_SPIRIT_THREADSAFE hints at the usual incredibly memory-hungry spirit... Get more memory. I enabled a swap partition. That does fix that problem. It seems to me, that an 'out of memory' message would be better than 'internal compiler error' message. Thank you for your help. Shawn Pringle
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #23 from Rolf Ebert rolf.ebert.gcc at gmx dot de 2012-12-11 19:57:34 UTC --- I see Eric's point in that the patch in comment #5 hides another bug in the Makefile chemistry. There seems to be an unnecessary dependency from the gnattools on multilibs. Reminds me of #19959
[Bug middle-end/55653] Unnecessary initialization of vector register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55653
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Target||aarch64-*-*
CC||pinskia at gcc dot gnu.org
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-11
20:06:00 UTC ---
I think there are two different issues here. The first issue is a target issue
as {0.0, 0.0} should be done as just an xor which really resolves this issue as
it is able to optimize that out (though it is a good thing to do even without
the other part).
The other issue shouldn't !vector be false here as we have a vector?
[Bug target/55654] New: objc/obj-c++ failures present under darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55654 Bug #: 55654 Summary: objc/obj-c++ failures present under darwin10 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The following failures remain in the objc and objc++ test suite under darwin10... === obj-c++ tests === FAIL: obj-c++.dg/torture/strings/string1.mm -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) FAIL: obj-c++.dg/torture/strings/string1.mm -O2 -flto -fnext-runtime (test for excess errors) for both -m32 and -m64 === objc tests === FAIL: objc.dg/torture/strings/string1.m -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/string1.m -O2 -flto -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/string2.m -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/string2.m -O2 -flto -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/string3.m -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/string3.m -O2 -flto -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/string4.m -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/string4.m -O2 -flto -fnext-runtime (test for excess errors) for both -m32 and -m64
[Bug target/55654] objc/obj-c++ failures present under darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55654 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-11 20:14:46 UTC --- The obj-c++ failures are of the form... Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/obj-c++/../../xg++ -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/obj-c++/../../ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121211/gcc/testsuite/obj-c++.dg/torture/strings/string1.mm -fno-diagnostics-show-caret -nostdinc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121211/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121211/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121211/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -flto-partition=none -fnext-runtime -mno-constant-cfstrings /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121211/gcc/testsuite/obj-c++.dg/torture/strings/../../../objc-obj-c++-shared/nsconstantstring-class-impl.mm -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libobjc/.libs -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libobjc/.libs -multiply_defined suppress -lobjc -lm -m32 -o ./string1.exe(timeout = 300) ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in /var/tmp//cc8Sbh9W.lto.o^M output is: ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in /var/tmp//cc8Sbh9W.lto.o^M FAIL: obj-c++.dg/torture/strings/string1.mm -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) Excess errors: ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in /var/tmp//cc8Sbh9W.lto.o
[Bug c++/55655] New: cannot export specialized template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55655 Bug #: 55655 Summary: cannot export specialized template Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mw_tr...@users.sourceforge.net Let us say I have a generic template class, e.g. my_smart_ptr. Let us also say I have a class 'foo', 'clas foo : public my_smart_ptrbar' that is part of some library public API. And last, let us say that 'foo' needs to specialize 'my_smart_ptrbar'. As far as I can tell, it is impossible to export this instantiation with proper symbol visibility in this configuration. I do NOT want to make all possible instantiations of my_smart_ptr have default visibility (someone, somewhere may have an instantiation that should have hidden visibility). I need to do two things, but they are mutually contradictory: 1. I need to explicitly instantiate the template in order to give it default visibility. However, if I do this first, it prevents specialization. (I also get compiler errors for my specific use case, as generic instantiation is not possible.) 2. I need to declare specialization prior to instantiation. However, if I do this before instantiation, I cannot set default visibility on the instantiation and I get link errors. I think there should be a way to do this... Right now I am forced to not export the template, requiring each user to use their own instantiation, which creates a fragile ABI.
[Bug target/55654] objc/obj-c++ failures present under darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55654 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-11 20:16:06 UTC --- The objc failures are of the form... Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121211/gcc/testsuite/objc.dg/torture/strings/string1.m -fno-diagnostics-show-caret -O2 -flto -flto-partition=none -fnext-runtime -mno-constant-cfstrings -Wno-deprecated-declarations -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libobjc/.libs -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libobjc/.libs /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121211/gcc/testsuite/objc.dg/torture/strings/../../../objc-obj-c++-shared/nsconstantstring-class-impl.m -lobjc -lm -m32 -o ./string1.exe(timeout = 300) ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in /var/tmp//ccaDuzKj.lto.o^M output is: ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in /var/tmp//ccaDuzKj.lto.o^M FAIL: objc.dg/torture/strings/string1.m -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) Excess errors: ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in /var/tmp//ccaDuzKj.lto.o
