[Bug gcov-profile/55650] [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 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-12 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug gcov-profile/55650] [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 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #1 from Jakub Jelinek 2012-12-12 08:08:35 UTC --- Created attachment 28933 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28933 gcc48-pr55650.patch Untested fix.
[Bug c++/55652] [4.8 Regression] ICE (segfault) with templates and structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55652 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/55652] [4.8 Regression] ICE (segfault) with templates and structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55652 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek 2012-12-12 09:18:06 UTC --- Created attachment 28934 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28934 gcc48-pr55652.patch Untested fix.
[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 #17 from Andreas Schwab 2012-12-12 09:32:47 UTC --- Author: schwab Date: Wed Dec 12 09:32:40 2012 New Revision: 194437 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194437 Log: PR tree-optimization/55079 * gcc.dg/tree-ssa/ssa-pre-1.c: Adjust. Modified: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-1.c
[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 --- Comment #10 from Jakub Jelinek 2012-12-12 09:33:00 UTC --- Author: jakub Date: Wed Dec 12 09:32:52 2012 New Revision: 194438 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194438 Log: PR fortran/55633 * tree-ssa-loop-niter.c (discover_iteration_bound_by_body_walk): Ignore bounds on which bound += double_int_one overflowed. * gcc.dg/torture/pr55633.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55633.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug libgcc/55451] [4.8 regression] FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 --- Comment #7 from Jakub Jelinek 2012-12-12 09:39:01 UTC --- Author: jakub Date: Wed Dec 12 09:38:56 2012 New Revision: 194439 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194439 Log: PR libgcc/55451 * fixed-bit.c (FIXED_SSADD, FIXED_SSSUB, FIXED_SSNEG): Avoid undefined signed overflows. Modified: trunk/libgcc/ChangeLog trunk/libgcc/fixed-bit.c
[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 #16 from Richard Biener 2012-12-12 09:43:18 UTC --- Thanks Zdenek - I'll give the patch further testing.
[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 #21 from Jakub Jelinek 2012-12-12 09:43:39 UTC --- Author: jakub Date: Wed Dec 12 09:43:33 2012 New Revision: 194441 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194441 Log: PR middle-end/52640 * varasm.c (pending_assemble_externals_set): New pointer set. (process_pending_assemble_externals): Destroy the pointer set. (assemble_external): See if decl is in pending_assemble_externals_set, and add it to pending_assemble_externals if necessary. (init_varasm_once): Allocate pending_assemble_externals_set. * gcc.c-torture/compile/limits-externdecl.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/limits-externdecl.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #22 from Jakub Jelinek 2012-12-12 09:44:42 UTC --- Fixed.
[Bug libgcc/55451] [4.8 regression] FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek 2012-12-12 09:45:18 UTC --- Hopefully fixed.
[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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek 2012-12-12 09:46:10 UTC --- Fixed.
[Bug lto/55660] [4.7/4.8 Regression] ICE instead of some warning during lto build with supplied different options (-funsigned-char vs none)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55660 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Known to work||4.6.3 Keywords||ice-checking, ||ice-on-valid-code, lto Last reconfirmed||2012-12-12 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Summary|ICE instead of some warning |[4.7/4.8 Regression] ICE |during lto build with |instead of some warning |supplied different options |during lto build with |(-funsigned-char vs none) |supplied different options ||(-funsigned-char vs none) Target Milestone|--- |4.7.3 Known to fail||4.7.2, 4.8.0 --- Comment #1 from Richard Biener 2012-12-12 09:54:49 UTC --- Confirmed. I'll have a looksee.
[Bug target/55659] [4.8 Regression] [SH] Build failure with ICE in dwarf2out_var_location, at dwarf2out.c:20748
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55659 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/55659] [4.8 Regression] [SH] Build failure with ICE in dwarf2out_var_location, at dwarf2out.c:20748
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55659 --- Comment #3 from Jakub Jelinek 2012-12-12 09:56:29 UTC --- Author: jakub Date: Wed Dec 12 09:56:22 2012 New Revision: 194442 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194442 Log: PR target/55659 Revert 2012-12-11 Jakub Jelinek PR middle-end/43631 * 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. 2012-12-06 Jakub Jelinek PR middle-end/43631 * var-tracking.c (emit_note_insn_var_location, emit_notes_in_bb): Clear BLOCK_FOR_INSN on notes emitted in between basic blocks, don't adjust BB_END when inserting note after BB_END of some bb. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[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 #20 from Jakub Jelinek 2012-12-12 09:56:28 UTC --- Author: jakub Date: Wed Dec 12 09:56:22 2012 New Revision: 194442 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194442 Log: PR target/55659 Revert 2012-12-11 Jakub Jelinek PR middle-end/43631 * 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. 2012-12-06 Jakub Jelinek PR middle-end/43631 * var-tracking.c (emit_note_insn_var_location, emit_notes_in_bb): Clear BLOCK_FOR_INSN on notes emitted in between basic blocks, don't adjust BB_END when inserting note after BB_END of some bb. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug c++/55513] [4.7/4.8 Regression] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513 --- Comment #12 from Pawel Sikora 2012-12-12 09:57:32 UTC --- (In reply to comment #11) > Fixed in trunk. no backport to 4.7 branch?
[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658 Richard Biener changed: What|Removed |Added Target||!SLOW_UNALIGNED_ACCESS Known to fail||3.3.6, 4.1.2, 4.5.3, 4.6.4, ||4.7.2, 4.8.0 Severity|normal |enhancement --- Comment #3 from Richard Biener 2012-12-12 10:00:33 UTC --- Confirmed for !SLOW_UNALIGNED_ACCESS targets. At least at -Os it should use an unaligned movq and mask out bits not needed.
[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 changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Target Milestone|--- |4.9.0 --- Comment #21 from Jakub Jelinek 2012-12-12 10:00:55 UTC --- Reopening, as the patch has been reverted.
[Bug target/55657] [4.8 Regression] objc/obj-c++ failures present under darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55657 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|objc/obj-c++ failures |[4.8 Regression] |present under darwin12 |objc/obj-c++ failures ||present under darwin12 --- Comment #4 from Richard Biener 2012-12-12 10:01:09 UTC --- I suppose these are all regressions?
[Bug target/55656] [4.8 Regression] objc/obj-c++ failures present under darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55656 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|objc/obj-c++ failures |[4.8 Regression] |present under darwin11 |objc/obj-c++ failures ||present under darwin11 --- Comment #1 from Richard Biener 2012-12-12 10:01:27 UTC --- I suppose these are all regressions?
[Bug target/55654] [4.8 Regression] objc/obj-c++ failures present under darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55654 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|objc/obj-c++ failures |[4.8 Regression] |present under darwin10 |objc/obj-c++ failures ||present under darwin10 --- Comment #5 from Richard Biener 2012-12-12 10:01:46 UTC --- I suppose these are all regressions?
[Bug target/55659] [4.8 Regression] [SH] Build failure with ICE in dwarf2out_var_location, at dwarf2out.c:20748
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55659 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2012-12-12 10:01:57 UTC --- Should be fixed now.
[Bug driver/55651] gcc hangs when "-Wp," is passed on the command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-12 Component|c |driver Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2012-12-12 10:07:21 UTC --- It looks like cc1 treats /usr/lib64/gcc/x86_64-suse-linux/4.6/cc1 -quiet -v "" t.c -quiet -dumpbase t.c -mtune=generic -march=x86-64 -auxbase t -version -o /tmp/ccYYppXF.s as reading from stdin? Yes, it does, gcc -Wp, -c t.c < /dev/null works just fine. Somewhat odd behavior though ;) Confirmed. The driver should either drop empty -Wp, or error.
[Bug libstdc++/55631] [4.7/4.8 Regression] Several ext/ headers can not be #included on their own
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55631 Jonathan Wakely changed: What|Removed |Added Known to work||4.6.3 Version|unknown |4.7.2 Target Milestone|4.8.0 |4.7.3 Summary|Several ext/ headers can|[4.7/4.8 Regression] |not be #included on their |Several ext/ headers can |own |not be #included on their ||own --- Comment #4 from Jonathan Wakely 2012-12-12 10:19:41 UTC --- The error is a regression so I'll fix the 4.7 branch too.
[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 #8 from Jonathan Wakely 2012-12-12 10:56:40 UTC --- (In reply to comment #7) > Another proposed patch. > http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00766.html I very strongly second what stevenb said: GCC 3.2 claims many things, but any GCC that has the old C++ parser has known non-conformances. IMHO we should only support GCC versions with the "new" C++ parser, i.e. GCC 3.4 and up. Expecting people to bootstap with GCC 3.2 to check it doesn't barf on some perfectly valid piece of C++ is unreasonable. If people didn't bootstrap with 3.2 then incompatibilities would creep in and not be found, so claiming that using 3.2 is possible would be a lie. Just say no.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-12 11:07:21 UTC --- > --- Comment #18 from Jakub Jelinek 2012-12-10 > 10:56:51 UTC --- > (In reply to comment #16) >> Not on Solaris/SPARC, unfortunately: there are still compilations in the >> libgo testsuite that take more than a day, which with PR go/54507 >> effectivly breaks unattended Solaris/SPARC bootstraps since they take >> insanely long. > > Which exact testcase? Can you pin-point it to a single *.go source file > compilation rather than several as the libgo testsuite usually compiles? > Can you see what all files would need to be attached to make it reproduceable > using cross-compiler from say x86_64-linux? I bet some *.gox files would be > needed... One example is reflect-check. It doesn't work with a single *.go file, but two do the trick. With -fno-var-tracking-assignements, it takes 3:41 on a 1.2 GHz UltraSPARC-T2, without it's on the order of a day. I'm attaching a tarball with all the files necessary to reproduce with a native sparc-sun-solaris2.10 compiler, including reflect.sh with the exact go1 invocation. Haven't tried a cross yet. Rainer
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #20 from Rainer Orth 2012-12-12 11:10:03 UTC --- Created attachment 28935 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28935 sparc-sun-solaris2.10 testcase
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55539
--- Comment #4 from Tobias Burnus 2012-12-12
11:16:33 UTC ---
(In reply to comment #3)
> Strangely enough I needed to add some epsilon to 0.5 so that
> the second test passes, because the exact value 0.5 appears
> to get rounded down to 0 in formatted output.
That should depend on the rounding mode; you have the choice between
RD (round down), RC (compatible), RN (nearest), RP (processor dependent), RU
(round up), RZ (round towards zero).
The default ("RD") in gfortran is NEAREST, which has to match IEEE 754-1985
(alias IEC 60559:1989), namely (cf. Note 10.14 in Fortran 2008):
"On processors that support IEEE rounding on conversions, the I/O rounding
modes COMPATIBLE and NEAREST will produce the same results except when the
datum is halfway between the two representable values. In that case, NEAREST
will pick the even value, but COMPATIBLE will pick the value away from zero.
The I/O rounding modes UP, DOWN, and ZERO have the same e ect as those speci ed
in IEC 60559:1989 for round toward +oo, round toward -oo, and round toward 0,
respectively."
And 0.5 rounded to even rounds down to "0" and not up to "1". (Seemingly,
decimal "0.5" is exactly representable in binary FP while decimal "0.1" isn't.)
[Bug target/55659] [4.8 Regression] [SH] Build failure with ICE in dwarf2out_var_location, at dwarf2out.c:20748
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55659 --- Comment #5 from Kazumoto Kojima 2012-12-12 11:18:39 UTC --- arm-elf and sh4-unknown-linux-gnu are built successfully with revision 194442. Thanks!
[Bug sanitizer/55661] New: options summary lists -fsanitize in wrong section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55661 Bug #: 55661 Summary: options summary lists -fsanitize in wrong section Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html lists -fsanitize=style under "Options for Debugging Your Program or GCC" but it's actually documented under "Options that Control Optimization" at http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #24 from Eric Botcazou 2012-12-12 11:35:07 UTC --- > What I don't understand is what is bad with Rolf's proposal of defining STAMP? We simply don't need to stamp anything for the gnattools. > 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? Well, building the gnattools works flawlessly for all targets except for AVR, because of a very questionable kludge. So it makes sense to fix the kludge.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #157 from Markus Trippelsdorf 2012-12-12 11:43:27 UTC --- With revision 193740 libxul's size is ~34MB, which is OK. (Unfortunately this new ICE happens with yesterdays gcc when linking libxul: /var/tmp/mozilla-central/content/base/src/nsDocument.cpp: In member function ‘CreateRange’: /var/tmp/mozilla-central/content/base/src/nsDocument.cpp:4999:0: internal compiler error: in cgraph_mark_address_taken_node, at cgraph.c:1409 I will open a new PR for this later.) Here are the requested files: (I don't know which of the ~3000 gcda files you need, so I've uploaded them all) http://www.trippelsdorf.de/gcda_before.tar.bz2 (4MB) http://www.trippelsdorf.de/gcda_after.tar.bz2 (4MB) (-fdump-ipa-inline output) http://www.trippelsdorf.de/libxul_before.inline.tar.bz2 (100MB) http://www.trippelsdorf.de/libxul_after.inline.tar.bz2 (68MB, everything 'till the ICE hit)
[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 #17 from Richard Biener 2012-12-12 13:07:26 UTC --- Author: rguenth Date: Wed Dec 12 13:07:19 2012 New Revision: 19 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=19 Log: 2012-12-12 Zdenek Dvorak PR tree-optimization/55481 * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Fall back to general rewriting if we cannot leave an original biv definition alone. * gcc.dg/torture/pr55481.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55481.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[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 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #18 from Richard Biener 2012-12-12 13:08:06 UTC --- Fixed.
[Bug tree-optimization/55662] New: SLP vectorization of sqrt fails if in a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55662
Bug #: 55662
Summary: SLP vectorization of sqrt fails if in a loop
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
CC: marc.gli...@ens.fr
given the code below
computeOne vectorizes, computeS does not
c++ -std=c++11 -Ofast -mavx2 -S sqrtV.cc; less sqrtV.s
gcc version 4.8.0 20121212 (experimental) [trunk revision 194442] (GCC)
funny enough it works with arbitrary (inlined) functions of mine (instead of
sqrtf) see computeA
computeL does "vectorize", not in the way I expected!
I really do not understand the code generated for computeAL
cat >> sqrtV.cc
#include
#include
typedef float __attribute__( ( vector_size( 16 ) ) ) float32x4_t;
typedef float __attribute__( ( vector_size( 32 ) ) ) float32x8_t;
typedef int __attribute__( ( vector_size( 32 ) ) ) int32x8_t;
float32x8_t va[1024];
float32x8_t vb[1024];
float32x8_t vc[1024];
template
inline
Vec apply(Vec v, F f) {
typedef typename std::remove_reference::type T;
constexpr int N = sizeof(Vec)/sizeof(T);
Vec ret;
for (int i=0;i!=N;++i) ret[i] = f(v[i]);
return ret;
}
void computeOne() {
vb[0]=apply(va[0],sqrtf);
}
void computeS() {
for (int i=0;i!=1024;++i)
vb[i]=apply(va[i],sqrtf);
}
void computeL() {
for (int i=0;i!=1024;++i)
for (int j=0;j!=8;++j)
vb[i][j]=sqrtf(va[i][j]);
}
template
inline
Float atanF(Float t) {
constexpr float PIO4F = 0.7853981633974483096f;
Float z= (t > 0.4142135623730950f) ? (t-1.0f)/(t+1.0f) : t;
// if( t > 0.4142135623730950f ) // * tan pi/8
Float z2 = z * z;
Float ret =
((( 8.05374449538e-2f * z2
- 1.38776856032E-1f) * z2
+ 1.99777106478E-1f) * z2
- 3.33329491539E-1f) * z2 * z
+ z;
// move back in place
return ( t > 0.4142135623730950f ) ? ret : ret + PIO4F;
return ret;
}
void computeA() {
for (int i=0;i!=1024;++i)
vb[i]=apply(va[i],atanF);
}
void computeAL() {
for (int i=0;i!=1024;++i)
for (int j=0;j!=8;++j)
vb[i][j]=atanF(va[i][j]);
}
[Bug c++/55663] New: [C++11] Alias template combined with constexpr function is considered non-const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55663
Bug #: 55663
Summary: [C++11] Alias template combined with constexpr
function is considered non-const
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
Using gcc 4.8.0 20121209 (experimental) and compile with flags
-Wall -std=c++11 -pedantic
rejects the following program:
//---
template
struct enable_if {};
template
struct enable_if { using type = T; };
template
using req = typename enable_if::type;
template
constexpr bool always() { return true; }
template
typename enable_if(), void>::type
foo1(T){}
template
req(), void>
foo2(T){}
int main() {
foo1(0); // OK
foo2(0); // Error #23
}
//---
the diagnostics being:
"main.cpp||In function 'int main()':|
main.cpp|23|error: no matching function for call to 'foo2(int)'|
main.cpp|23|note: candidate is:|
main.cpp|19|note: template req(), void> foo2(T)|
main.cpp|19|note: template argument deduction/substitution failed:|
main.cpp|19| required by substitution of 'template req(),
void> foo2(T) [with T = int]'|
main.cpp|23|required from here|
main.cpp|19|error: integral expression 'always()' is not constant|
main.cpp|19|error: trying to instantiate 'template using req
= typename enable_if::type'|
"
I found some similarity to bug 54648 but I'm not 100% sure whether this is a
dub
[Bug target/55657] [4.8 Regression] objc/obj-c++ failures present under darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55657 --- Comment #5 from Jack Howarth 2012-12-12 14:06:52 UTC --- (In reply to comment #4) > I suppose these are all regressions? In the strict sense, no. These are due to changes in the Objective-C ABI in later darwin SDKs. I haven't checked all of these yet, but I suspect most will disappear is --systroot= is used to select the previous MacOS X SDK (e.g. http://gcc.gnu.org/ml/gcc-bugs/2012-12/msg00586.html).
[Bug target/55656] [4.8 Regression] objc/obj-c++ failures present under darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55656 --- Comment #2 from Jack Howarth 2012-12-12 14:07:23 UTC --- (In reply to comment #1) > I suppose these are all regressions? In the strict sense, no. These are due to changes in the Objective-C ABI in later darwin SDKs. I haven't checked all of these yet, but I suspect most will disappear is --systroot= is used to select the previous MacOS X SDK (e.g. http://gcc.gnu.org/ml/gcc-bugs/2012-12/msg00586.html).
[Bug target/55654] [4.8 Regression] objc/obj-c++ failures present under darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55654 --- Comment #6 from Jack Howarth 2012-12-12 14:08:05 UTC --- (In reply to comment #5) > I suppose these are all regressions? In the strict sense, no. These are due to changes in the Objective-C ABI in later darwin SDKs. I haven't checked all of these yet, but I suspect most will disappear is --systroot= is used to select the previous MacOS X SDK (e.g. http://gcc.gnu.org/ml/gcc-bugs/2012-12/msg00586.html).
[Bug c++/55664] New: Missing diagnostic "dependent using declaration resolved to type without 'typename'"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55664
Bug #: 55664
Summary: Missing diagnostic "dependent using declaration
resolved to type without 'typename'"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
The following code is rejected by CLANG with:
test.cxx:17:24: error: dependent using declaration resolved to type
without 'typename'
using super_t::base_type;
^
I think the error is correct, but g++ doesn't diagnose it.
namespace std
{
namespace thrust
{
template < typename Derived >
class iterator_adaptor { typedef Derived base_type; };
template < typename Derived >
struct pointer_base_base {
typedef thrust::iterator_adaptor < Derived > type;
};
template < typename Derived >
class pointer_base : public pointer_base_base :: type
{
typedef typename pointer_base_base < Derived > :: type super_t;
using super_t::base_type;
};
template < unsigned int DummyParameterToAvoidInstantiation >
void mymalloc (thrust::pointer_base< void >) { };
}
}
[Bug tree-optimization/55662] SLP vectorization of sqrt fails if in a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55662 --- Comment #1 from Richard Biener 2012-12-12 14:18:04 UTC --- 27: not vectorized: no vectype for stmt: _4 = va[i_34]; scalar_type: float32x8_t The vectorizer does not handle loops that already have vector types. And basic-block vectorization isn't clever enough to scan all of the starting points of the basic-block (that code needs a rewrite).
[Bug lto/55660] [4.7/4.8 Regression] ICE instead of some warning during lto build with supplied different options (-funsigned-char vs none)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55660
--- Comment #2 from Richard Biener 2012-12-12
14:18:46 UTC ---
Ok, the issue is we preload char_type_node anyway, as show by
Index: gcc/tree-streamer.c
===
--- gcc/tree-streamer.c (revision 19)
+++ gcc/tree-streamer.c (working copy)
@@ -237,6 +237,12 @@ streamer_tree_cache_lookup (struct strea
static void
record_common_node (struct streamer_tree_cache_d *cache, tree node)
{
+ /* Verify we don't recursively pre-load nodes we do not want to preload. */
+ gcc_assert (node != char_type_node
+ && node != boolean_type_node
+ && node != boolean_true_node
+ && node != boolean_false_node);
+
/* We have to make sure to fill exactly the same number of
elements for all frontends. That can include NULL trees.
As our hash table can't deal with zero entries we'll simply stream
this is because we pre-load va_list_type_node (which is required, because
we compare that by pointer equality). But the x86 backend (and possibly
others) do:
static tree
ix86_build_builtin_va_list_abi (enum calling_abi abi)
{
tree f_gpr, f_fpr, f_ovf, f_sav, record, type_decl;
/* For i386 we use plain pointer to argument area. */
if (!TARGET_64BIT || abi == MS_ABI)
return build_pointer_type (char_type_node);
oops.
[Bug debug/55665] New: [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 Bug #: 55665 Summary: [4.8 Regression] Missing DW_TAG_lexical_block PC range Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com Target: x86_64-unknown-linux-gnu This is a regression for GDB gdb.cp/abstract-origin.exp. PASS: gcc (GCC) 4.7.3 20121212 (prerelease) FAIL: gcc (GCC) 4.8.0 20121212 (experimental) (regression sometimes in ~ the last month) PASS was: <1><9e>: Abbrev Number: 14 (DW_TAG_subprogram) <9f> DW_AT_abstract_origin: <0x5a> DW_AT_linkage_name: (indirect string, offset: 0xac): _ZN1AC2Ei [...] <2>: Abbrev Number: 16 (DW_TAG_lexical_block) DW_AT_low_pc : 0x40081e DW_AT_high_pc : 0x400891 <3>: Abbrev Number: 17 (DW_TAG_variable) DW_AT_abstract_origin: <0x7c> and above: <2><7b>: Abbrev Number: 11 (DW_TAG_lexical_block) <3><7c>: Abbrev Number: 12 (DW_TAG_variable) <7d> DW_AT_name: (indirect string, offset: 0x51): problem [...] BTW was missing DW_AT_abstract_origin <0x7b>; but GDB works with that. FAIL is: <1><9e>: Abbrev Number: 14 (DW_TAG_subprogram) <9f> DW_AT_abstract_origin: <0x5a> DW_AT_linkage_name: (indirect string, offset: 0xa9): _ZN1AC2Ei [...] This means GDB correctly inherits the DIE from inherited DIE tree: <2><7b>: Abbrev Number: 11 (DW_TAG_lexical_block) <3><7c>: Abbrev Number: 12 (DW_TAG_variable) <7d> DW_AT_name: (indirect string, offset: 0x97): problem [...] But that DW_TAG_lexical_block has no DW_AT_low/high_pc (it cannot have as it is not the concrete instance) which is a regression. GDB currently ignores DW_TAG_lexical_block without DW_AT_low/high_pc/range. While GDB could recognize DW_TAG_lexical_block without DW_AT_low/high_pc it would be still a debug info quality regression as the GCC-4.7 range there is more narrow than the DW_TAG_subprogram PC range.
[Bug debug/55665] [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/55664] Missing diagnostic "dependent using declaration resolved to type without 'typename'"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55664 --- Comment #1 from Jonathan Wakely 2012-12-12 15:41:21 UTC --- The template is never instantiated so no diagnostic is required. Even if you instantiate it I'm not sure the code is necessarily ill-formed, unles you use the name in a way that requires it to be known to be a type. 7.3.3p19 says: If a using-declaration uses the keyword typename and specifies a dependent name (14.6.2), the name introduced by the using-declaration is treated as a typedef-name (7.1.3). But it doesn't say the keyword typename *must* be used is the using-declaration specifies a dependent name.
[Bug c++/55664] Missing diagnostic "dependent using declaration resolved to type without 'typename'"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55664 --- Comment #2 from Jonathan Wakely 2012-12-12 15:49:30 UTC --- (In reply to comment #1) > But it doesn't say the keyword typename *must* be used is s/used is/used if/
[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 #11 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-12 15:53:49 UTC --- The extreme sparcv9 libgo compile times without -fno-var-tracking-assignments are handled in PR debug/54402, it seems. I haven't seen the ICE covered in this PR in quite some time. Rainer
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #17 from Jack Howarth 2012-12-12 15:57:03 UTC --- This issue is eliminated by the removal of the matrix-reorg code at... Author: rguenth Date: Fri Aug 10 14:19:09 2012 New Revision: 190298 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190298 Log: 2012-08-10 Richard Guenther * Makefile.in (OBJS): Remove matrix-reorg.o. (matrix-reorg.o): Remove dependence rule. (GTFILES): Remove matrix-reorg.c. * matrix-reorg.c: Remove. * passes.c (init_optimization_passes): Do not schedule pass_ipa_matrix_reorg. * tree-pass.h (pass_ipa_matrix_reorg): Remove. * common.opt (fipa-matrix-reorg): Stub out. * doc/invoke.texi (fipa-matrix-reorg): Remove documentation. * gcc.dg/matrix/*.c: Adjust and move ... * gcc.dg/torture/: ... here. * gcc.dg/matrix: Remove directory.
[Bug debug/55665] [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 --- Comment #1 from Jan Kratochvil 2012-12-12 16:00:45 UTC --- Created attachment 28936 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28936 gdb.cp/abstract-origin.cc from FSF GDB tree, for -O0 -g.
[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 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-12 16:04:21 UTC --- > --- Comment #5 from Eric Botcazou 2012-12-11 > 08:32:07 UTC --- > Does this still occur? I had done some further investigate at that time and found that this happened when the machine didn't have /usr/bin/jar installed, so instead of using libjava/scripts/jar, an installed version of fastjar (from gcc 4.1) was used. This seems to lead to a version of tools.zip that causes jc1 to ICE as reported. I haven't investigated in more detail since, though. Rainer
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-12 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #16 from Martin Jambor 2012-12-12 16:24:37 UTC --- OK, I'll add the condition to type_internals_preclude_sra_p.
[Bug debug/55665] [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-12 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2012-12-12 16:58:15 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193595 Trying to spot the difference.
[Bug middle-end/46837] induct compiled with -ffast-math -fschedule-insns -fsched-pressure -O3 ~30% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46837 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jack Howarth 2012-12-12 16:58:49 UTC --- This issue doesn't appear to be present for the induct.f90 benchmark in current gcc trunk on x86_64-apple-darwin12. -ffast-math -fschedule-insns -fsched-pressure -O3 -m64 = 11.92867 sec -ffast-math -O3 -m64 = 12.26822 sec
[Bug debug/55665] [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek 2012-12-12 17:47:28 UTC --- Created attachment 28937 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28937 gcc48-pr55665.patch Untested fix.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #158 from Teresa Johnson 2012-12-12 18:59:56 UTC --- On Wed, Dec 12, 2012 at 3:43 AM, markus at trippelsdorf dot de wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 > > --- Comment #157 from Markus Trippelsdorf > 2012-12-12 11:43:27 UTC --- > With revision 193740 libxul's size is ~34MB, which is OK. > > (Unfortunately this new ICE happens with yesterdays gcc when linking libxul: > > /var/tmp/mozilla-central/content/base/src/nsDocument.cpp: In member function > ‘CreateRange’: > /var/tmp/mozilla-central/content/base/src/nsDocument.cpp:4999:0: internal > compiler error: in cgraph_mark_address_taken_node, at cgraph.c:1409 > > I will open a new PR for this later.) > > Here are the requested files: > > (I don't know which of the ~3000 gcda files you need, so I've uploaded them > all) > http://www.trippelsdorf.de/gcda_before.tar.bz2 (4MB) > http://www.trippelsdorf.de/gcda_after.tar.bz2 (4MB) Sorry, I should have clarified that any one of them would do (as long as it corresponded to an object file included in the LTO link for the main executable), since the info I need is in the program summary section for the executable, which is duplicated in each of them. > > (-fdump-ipa-inline output) > http://www.trippelsdorf.de/libxul_before.inline.tar.bz2 (100MB) > http://www.trippelsdorf.de/libxul_after.inline.tar.bz2 (68MB, everything > 'till > the ICE hit) With the old heuristics, the hot bb cutoff was: profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION)) In this case, sum_max is 103439951 and HOT_BB_COUNT_FRACTION was 1, so the cutoff count was 10343. From the working set computed from the histogram, the 99.9% cutoff count is 320. See the end of this email for the full set of histograms and working sets, but here are the top few working sets: ... hal/Hal.gcda: 96.72%: num counts=30069, min counter=16389 hal/Hal.gcda: 97.50%: num counts=35296, min counter=10241 hal/Hal.gcda: 98.28%: num counts=43669, min counter=6145 hal/Hal.gcda: 99.06%: num counts=59589, min counter=3072 hal/Hal.gcda: 99.90%: num counts=115840, min counter=320 So it looks like you would want a cutoff of 97.5% to get close to what was there before. (Honza, I just made some changes to enable gcov-dump to optionally compute and dump out the working sets from the histogram. I can send this for upstream review as I have wanted this several times.) The much smaller cutoff count is why there are fewer calls marked unlikely and more inlining: $ grep "call is unlikely" before/libxul.so.wpa.049i.inline | wc 442342 4944522 42560600 $ grep "call is unlikely" after/libxul.so.wpa.049i.inline | wc 392683 4349335 37477001 $ grep Inlined before/libxul.so.wpa.049i.inline | grep eliminated Inlined 60432 calls, eliminated 30986 functions $ grep Inlined after/libxul.so.wpa.049i.inline | grep eliminated Inlined 89573 calls, eliminated 28921 functions On thing that is interesting in the above info, and may be contributing to the larger size now, is that there are more inlines, but fewer functions are being eliminated. I'm not sure why that is offhand. It's possible (probable) that inlining heuristics need some retuning to make optimal use of the new cutoffs. We also see additional inlines in some of our large internal apps with the change, but not much increase in binary size, and it sometimes leads to better performance - although we are not as much affected because the google branches were using a much larger HOT_BB_COUNT_FRACTION of 60K already, in order to get more inlining. In this case, it looks like you are getting more inlines but it is apparently performance-neutral? Looking at a graph of the working set data, the number of counters starts increasing super-exponentially as the percentages approach 100%. I've been thinking that it may be useful to find the "knee" of the curve to determine the appropriate cutoff percentage. I'll see if I can make some progress on that. Full histogram/working set data: hal/Hal.gcda: a300: 512:PROGRAM_SUMMARY checksum=0x3aa34521 hal/Hal.gcda: counts=2109045, runs=7, sum_all=9749748271, run_max=97136704, sum_max=103439951 hal/Hal.gcda: counter histogram: hal/Hal.gcda: 0: num counts=1824318, min counter=0, cum_counter=0 hal/Hal.gcda: 1: num counts=30727, min counter=1, cum_counter=30727 hal/Hal.gcda: 2: num counts=11646, min counter=2, cum_counter=23292 hal/Hal.gcda: 3: num counts=5414, min counter=3, cum_counter=16242 hal/Hal.gcda: 4: num counts=5156, min counter=4, cum_counter=20624 hal/Hal.gcda: 5: num counts=3379, min counter=5, cum_counter=16895 hal/Hal.gcda: 6: num counts=3674, min counter=6, cum_counter=22044 hal/Hal.gcda: 7: num counts=2310, min counter=7, cum_counter=16170 hal/Hal.gcda: 8: num counts=4756, min counter=8, cum_counter=40330 hal/Hal.gcda: 9: num counts=4725, min counter=10, cum_counter=49265 hal/Hal.gcda: 10: num counts=4256, min
[Bug target/55666] New: Use scratch register to avoid save/restore of callee saved register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55666
Bug #: 55666
Summary: Use scratch register to avoid save/restore of callee
saved register
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Compile the attached source code with options: -march=armv7-a -mthumb -O2
I get the following instructions
YUY2ToUVRow_NEON:
@ args = 4, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
push{r4}
ldrr4, [sp, #4]
#APP
@ 5 "tx.i" 1
adds r1, r0, r1
.p2align 2
1:
vld4.8 {d0, d1, d2, d3}, [r0]!
vld4.8 {d4, d5, d6, d7}, [r1]!
vrhadd.u8 d1, d1, d5
vrhadd.u8 d3, d3, d7
vst1.u8{d1}, [r2]!
vst1.u8{d3}, [r3]!
subs r4, r4, #16
bgt1b
@ 0 "" 2
.thumb
ldrr4, [sp], #4
bxlr
If we replace all usage of r4 with a scratch register r12, then we can avoid
the save/restore of r4.
[Bug target/55666] Use scratch register to avoid save/restore of callee saved register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55666 --- Comment #1 from Carrot 2012-12-12 19:48:30 UTC --- Created attachment 28938 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28938 testcase
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #159 from Jan Hubicka 2012-12-12 20:35:37 UTC --- > hal/Hal.gcda: 96.72%: num counts=30069, min counter=16389 > hal/Hal.gcda: 97.50%: num counts=35296, min counter=10241 > hal/Hal.gcda: 98.28%: num counts=43669, min counter=6145 > hal/Hal.gcda: 99.06%: num counts=59589, min counter=3072 > hal/Hal.gcda: 99.90%: num counts=115840, min counter=320 > > So it looks like you would want a cutoff of 97.5% to get close to what > was there before. Setting the default cutoff to something like 95% would sound fine to me. I see i asked to reduce the parameter but suggested 990. Markus, can you try setting HOT_BB_COUNT_WS_PERMILLE to 950? Honza
[Bug rtl-optimization/55667] New: [regression] -O1 enables frame pointer push to move around on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55667 Bug #: 55667 Summary: [regression] -O1 enables frame pointer push to move around on x86_64 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dfla...@nist.gov Target: x86_64-intel-linux-gnu Created attachment 28939 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28939 preprocessed test program On x86_64 linux, with -fno-omit-frame-pointer and -O1, gcc 4.7.x (verified for 4.7.0 and 4.7.2) allow the frame pointer (rbp) push instruction to wander away from the beginning of a function. As a result, profiling tools including perf and OProfile determine incorrect call chains, and subsequent calculations of call graphs and total time are wrong. The problem does not occur if any of the following are true: -O0 instead of -O1 -m32 instead of -m64 gcc 4.6.3 instead of 4.7.x The preprocessed source of a small program to demonstrate the problem is attached. Example output from the profiling tools and various versions of gcc, as well as the original small program, was sent to the oprofile-list at 2012-12-12 13:45 EST, but the list archive is presently unreachable, so email me for a copy if needed.
[Bug rtl-optimization/55667] [regression] -O1 enables frame pointer push to move around on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55667 --- Comment #1 from David Flater 2012-12-12 20:45:01 UTC --- Created attachment 28940 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28940 log of build of test program
[Bug rtl-optimization/55667] [4.7 regression] -O1 enables frame pointer push to move around on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55667 --- Comment #2 from David Flater 2012-12-12 21:25:27 UTC --- N.B., in the test program, the problem occurs in fn2 but not fn1.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #21 from Jakub Jelinek 2012-12-12 22:09:59 UTC --- Created attachment 28941 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28941 sparc hack I think on SPARC that is partly the fault of the sparc.md part of http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01423.html The old insn pattern was much closer to what the insn actually does, so now neither cselib nor var-tracking has any clue on what the insn is doing, doesn't consider it as a a fp_setter among other things. If the looked the way it did before, and even better also described what it does with the o0-o5 registers too, then no hacks like var-tracking.c HAVE_window_save code would be needed, cselib would just understand it. That said, another alternative is another hack when we already have some, treat window_save insn as fp_setter_insn (or could derive it from some of the CFA flags). Still I think that earlier when discussing UNSPEC_VOLATILE we were talking that UNSPEC_VOLATILE is mainly about being a scheduling barrier and that it shouldn't e.g. modify registers that it doesn't say that are modified. Haven't measured how much this patch improves the compile time, but not enough in a x86_64-linux -> sparc-solaris cross. So I'm going to attach other patches too, to be tried separately and/or together with this.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #22 from Jakub Jelinek 2012-12-12 22:21:57 UTC --- Created attachment 28942 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28942 --param max-vartrack-reverse-op-size patch Another patch, to avoid adding reverse ops to VALUEs that already have lots of locs, assuming for such locs it is unlikely going to be useful. With the default of 50 (+ the previous sparc hack) in x86_64 -> sparc-solaris cross the go1 testcase compiled in about 1.5 minutes, with 10 instead in 50 seconds or so, with 100 in 3 minutes, etc. I've performed x86_64-linux and i686-linux bootstraps with the patch defaulting to 50 (as here) as well as 1000 and the .debug_info and .debug_loc sizes of cc1plus, libstdc++.so.6 and go1 were identical, thus I hope it won't affect debug info quality too much with the default of 50. Alex, what do you think about this? Or should we count just some locations, like the same rtx code as reverse_op would create?
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 Jakub Jelinek changed: What|Removed |Added Attachment #28563|0 |1 is obsolete|| --- Comment #23 from Jakub Jelinek 2012-12-12 22:29:47 UTC --- Created attachment 28943 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28943 updated #c9 patch And last, a non-working updated version of the #c9 patch. The find_base_term* part of it probably would work, it is just a forward port of the earlier patch to new vec C++ish stuff, but without the --param patch the go1 testcase was still very slow, spending too much time in get_addr (again, walking many thousands long locs list of a few VALUEs all the time), this another cache helped that to get within 10 minutes of compile time, but it didn't pass bootstrap, many compilations during bootstrap got stuck for many minutes. So, I'm providing this just for completeness.
[Bug libstdc++/55631] [4.7/4.8 Regression] Several ext/ headers can not be #included on their own
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55631 --- Comment #5 from Jonathan Wakely 2012-12-12 23:01:51 UTC --- Author: redi Date: Wed Dec 12 23:01:40 2012 New Revision: 194457 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194457 Log: PR libstdc++/55631 * include/ext/alloc_traits.h: Include missing header. * include/ext/pointer.h: Likewise. * include/ext/string_conversions.h: Require C++11. * libsupc++/initializer_list: Reindent. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/ext/alloc_traits.h branches/gcc-4_7-branch/libstdc++-v3/include/ext/pointer.h branches/gcc-4_7-branch/libstdc++-v3/include/ext/string_conversions.h branches/gcc-4_7-branch/libstdc++-v3/libsupc++/initializer_list
[Bug sanitizer/55508] many test cases fail using -fsanitize=address with internal compiler error: in expand_call_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55508 --- Comment #4 from Jakub Jelinek 2012-12-12 23:05:27 UTC --- Author: jakub Date: Wed Dec 12 23:05:23 2012 New Revision: 194459 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194459 Log: PR sanitizer/55508 * builtin-attrs.def (ATTR_TMPURE_NOTHROW_LEAF_LIST, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): New. * asan.c (ATTR_TMPURE_NOTHROW_LEAF_LIST, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): Define. * sanitizer.def: Make __asan_report_* and __asan_handle_no_return builtins tm pure. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/builtin-attrs.def trunk/gcc/sanitizer.def
[Bug debug/55665] [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 --- Comment #4 from Jakub Jelinek 2012-12-12 23:19:38 UTC --- Author: jakub Date: Wed Dec 12 23:19:32 2012 New Revision: 194461 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194461 Log: PR debug/55665 * tree-inline.c (remap_decls): Change nonlocalized_list to pointer to pointer to vector from pointer to vector. (remap_block): Pass address of BLOCK_NONLOCALIZED_VARS. * g++.dg/guality/pr55665.C: New test. Added: trunk/gcc/testsuite/g++.dg/guality/pr55665.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug debug/55665] [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-12-12 23:20:51 UTC --- Fixed.
[Bug c++/55668] New: Incorrect lookup for template member of dependent template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55668
Bug #: 55668
Summary: Incorrect lookup for template member of dependent
template
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tud...@fb.com
The following correct program gives an error; it appears that "a.template
foo<0>" looks up foo in global scope and fails because it believes that foo
takes a class first template argument instead of an int.
// The bug is not triggered if the template below is missing,
// or if it is a class or function or global variable instead of
// a template.
template class foo;
template struct A {
template void foo(int val) { }
};
template struct B {
// The bug is not triggered if "bar" is named "foo"
void bar() {
a.template foo<0>(42);
}
// This has to depend on N; A<0> doesn't trigger the bug
A a;
};
The error I get:
d.cpp: In member function `void B::bar()`:
d.cpp:13:21: error: type/value mismatch at argument 1 in template parameter
list for `template class foo`
d.cpp:13:21: error: expected a type, got `0`
Broken in 4.1.2, 4.6.2, 4.7.1 (the three versions I have access to).
(The bug was minimized from actual code, in which the method in question was
named "set" and collided with std::set, as we had "using std::set")
[Bug c++/55668] Incorrect lookup for template member of dependent template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55668 --- Comment #1 from Andrew Pinski 2012-12-13 01:24:35 UTC --- I think there is a dup of this bug somewhere. Related to how sometimes we don't need to use template in some cases.
[Bug c++/55668] Incorrect lookup for template member of dependent template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55668 --- Comment #2 from Tudor Bosman 2012-12-13 01:28:05 UTC --- It's hard to believe that I'm the first one to hit this problem, but my 10 minutes of searching haven't found any duplicates; perhaps my search-fu isn't up to par :)
