[Bug middle-end/56167] ICE with invalid __attribute__ arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56167 --- Comment #4 from Jakub Jelinek 2013-02-05 08:08:33 UTC --- Author: jakub Date: Tue Feb 5 08:08:27 2013 New Revision: 195748 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195748 Log: PR middle-end/56167 * c-common.c (handle_error_attribute): Fix condition. * gcc.dg/pr56167.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56167.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56167] ICE with invalid __attribute__ arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56167 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2013-02-05 08:10:39 UTC --- Fixed.
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #23 from Eric Botcazou 2013-02-05 09:08:19 UTC --- Author: ebotcazou Date: Tue Feb 5 09:08:09 2013 New Revision: 195749 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195749 Log: PR sanitizer/55374 * config/gnu-user.h (LIBASAN_EARLY_SPEC): Add missing guard. Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h
[Bug fortran/55789] [4.6/4.7/4.8 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 --- Comment #7 from Jan Hubicka 2013-02-05 09:13:59 UTC --- Author: hubicka Date: Tue Feb 5 09:13:48 2013 New Revision: 195751 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195751 Log: PR tree-optimization/55789 * g++.dg/tree-ssa/inline-1.C: Update max-inliner-iterations. * g++.dg/tree-ssa/inline-2.C: Update max-inliner-iterations. * g++.dg/tree-ssa/inline-3.C: Update max-inliner-iterations. * g++.dg/ipa/inline-1.C: New testcase. * g++.dg/ipa/inline-2.C: New testcase. * g++.dg/ipa/inline-3.C: New testcase. * params.def (PARAM_EARLY_INLINER_MAX_ITERATIONS): Drop to 1. Added: trunk/gcc/testsuite/g++.dg/ipa/inline-1.C trunk/gcc/testsuite/g++.dg/ipa/inline-2.C trunk/gcc/testsuite/g++.dg/ipa/inline-3.C Modified: trunk/gcc/ChangeLog trunk/gcc/params.def trunk/gcc/testsuite/g++.dg/tree-ssa/inline-1.C trunk/gcc/testsuite/g++.dg/tree-ssa/inline-2.C trunk/gcc/testsuite/g++.dg/tree-ssa/inline-3.C
[Bug tree-optimization/56210] invalid -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56210
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||missed-optimization
Last reconfirmed||2013-02-05
Component|middle-end |tree-optimization
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Richard Biener 2013-02-05
09:14:35 UTC ---
We warn for MEM[(void *)";" + 3B]:
f ()
{
static char key[4] = "abc";
int _5;
:
_5 = strncmp (";", &key, 3);
if (_5 == 0)
goto ;
else
goto ;
:
__builtin_puts (&MEM[(void *)";" + 3B]);
:
return;
which is of course in an unexecuted block (";" is not equal to "abc").
Which points to a missed folding of the strncmp, respectively of a missed
promotion of 'key' to const.
We are cleverly optimizing away the loop as we can see it executes at
most once. CCP3 figures this out but fails to fold strncmp because
ipa-reference does not figure it is constant - it seems to not handle
builtin calls very well (puts makes it consider all vars are written to).
Also points-to computes
# PT =
p_3 = ";";
# PT = nonlocal escaped
p_9 = p_1 + 3;
# PT = nonlocal escaped
# USE = nonlocal escaped
p_7 = __builtin_strchr (p_1, 59);
# PT = nonlocal escaped
p_8 = p_7 + 1;
# PT = nonlocal escaped
# p_1 = PHI <";"(2), p_8(6)>
because strchr is not handled.
Let me have a look.
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug testsuite/56206] [4.7 Regression] "dg-require-effective-target arm_hard_vfp_ok" triggers many test suite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56206 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.7.3 Summary|[4.7.3 regression] |[4.7 Regression] |"dg-require-effective-targe |"dg-require-effective-targe |t arm_hard_vfp_ok" triggers |t arm_hard_vfp_ok" triggers |many test suite errors |many test suite errors
[Bug target/56200] queens benchmark is faster with -O0 than with any other optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-05 Ever Confirmed|0 |1 --- Comment #3 from Richard Biener 2013-02-05 09:21:59 UTC --- Confirmed. Huh. Using -O1 -fwhole-program gives the best numbers for me.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #6 from Kostya Serebryany 2013-02-05 09:21:59 UTC --- I am slightly confused. Are we discussing compile time or test-run-time? I've just built SPEC 2006 with -fsanitize=address -O2 gcc: r195706 clang: r174324 Measured on Intel(R) Xeon(R) CPU W3690 @ 3.47GHz clang gcc 400.perlbench, 1209.00,-1.00,-0.00 401.bzip2, 885.00, 1187.00, 1.34 403.gcc, 739.00, 756.00, 1.02 429.mcf, 602.00, 612.00, 1.02 445.gobmk, 840.00, 1191.00, 1.42 456.hmmer, 1304.00, 1838.00, 1.41 458.sjeng, 923.00, 1326.00, 1.44 462.libquantum, 543.00, 481.00, 0.89 464.h264ref, 1271.00,-1.00,-0.00 471.omnetpp, 631.00, 624.00, 0.99 473.astar, 672.00, 765.00, 1.14 483.xalancbmk, 500.00, 521.00, 1.04 433.milc, 710.00, 629.00, 0.89 444.namd, 637.00, 539.00, 0.85 447.dealII, 650.00, 714.00, 1.10 450.soplex, 389.00, 419.00, 1.08 453.povray, 459.00, 432.00, 0.94 470.lbm, 388.00, 409.00, 1.05 482.sphinx3, 998.00, 1335.00, 1.34 400.perlbench fails with a real asan-ish warning (clang can use a blacklist file and disables instrumentation for the buggy function. See https://code.google.com/p/address-sanitizer/wiki/FoundBugs#Spec_CPU_2006 and https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Turning_off_instrumentation) 464.h264ref with gcc loops forever, I did not investigate why. So, on average clang+asan is faster than gcc-asan (up to 40%!), but in some cases (mostly, FP code) gcc is faster (up to 15%)
[Bug tree-optimization/56205] [4.8 Regression] stdarg pass confused by jump threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56205 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-05 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-02-05 09:22:29 UTC --- stdarg, ick.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #7 from Kostya Serebryany 2013-02-05 09:43:11 UTC --- If we are talking about compile time, I observe 2x difference in favor of clang: building 483.xalancbmk gcc+asan+O2: 564 seconds clang+asan+O2: 243 second gcc is built with default options clang is built with -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON
[Bug target/56200] queens benchmark is faster with -O0 than with any other optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200 Alexander Monakov changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||ubizjak at gmail dot com --- Comment #4 from Alexander Monakov 2013-02-05 09:46:13 UTC --- The need for the first alignment is clear: it aligns the loop to a 16-byte boundary, and gcc does set that alignment at -O2. Uros, H.J., any idea why separating the first conditional jump from the rest by additional alignment is crucial for performance in this case? Is there anything that can be improved in GCC here?
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #6 from Paolo Carlini 2013-02-05 09:50:11 UTC --- Thanks Daniel. Next, we have to figure out which commit broke such lookups. I can work on that today (if nobody beats me)
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #8 from Jakub Jelinek 2013-02-05 09:56:17 UTC --- "464.h264ref with gcc loops forever, I did not investigate why." is PR53073 , you can use -fno-aggressive-loop-optimizations to workaround the invalid code in SPEC. As for runtime performance of gcc -fsanitize=address code, it would be interesting to try also with Dodji's patchset, how that improves things. And, for compile time, you want to be testing with --enable-checking=release built gcc, that is what people will actually use if they aren't developing gcc.
[Bug tree-optimization/56210] invalid -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56210 --- Comment #3 from Richard Biener 2013-02-05 10:04:53 UTC --- I have a fix for the points-to analysis, but the IPA reference bug is hard to fix as puts may recurse back into the current unit and it may use/clobber all global vars (of which key is one). So I fear no folding is possible here easily.
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #5 from Rainer Orth 2013-02-05 10:24:28 UTC --- Created attachment 29353 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29353 proposed patch I've now looked a bit closer and came up with the attached patch: it restricts the test to 32-bit x86. Checking the difference between Linux/x86 and Solaris/x86, it turns out that Linux uses .cfi* directives, while Solaris does not. To account for this, I'm adding -fno-dwarf2-cfi-asm (enforcing -fdwarf2-cfi-asm didn't work) and update the match count. The resulting patch was tested on i386-pc-solaris2.11, i686-pc-unknown-linux-gnu and x86_64-unknown-linux-gnu. Ok for mainline? Rainer
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-05 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug tree-optimization/56210] invalid -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56210 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2013-02-05 10:28:01 UTC --- If key is never changing, why don't you just make it const in the source?
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #9 from Kostya Serebryany 2013-02-05 10:30:16 UTC --- > And, for compile time, you want to be testing with --enable-checking=release Thanks! With --enable-checking=release gcc's compile time drops to 374 seconds. That's much better, but still 50% slower than clang (built with asserts)
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #10 from Kostya Serebryany 2013-02-05 10:41:20 UTC --- (In reply to comment #8) > "464.h264ref with gcc loops forever, I did not investigate why." > is PR53073 , you can use -fno-aggressive-loop-optimizations to workaround the > invalid code in SPEC. Thanks. But then again we hit another bug in 464.h264ref. So, if we want to run h264ref and perbmk w/o changing sources under gcc+asan we need to have the blacklist functionality. (see the same links as above). ==8720== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff625736a0 at pc 0x4e2a98 bp 0x7fff62573600 sp 0x7fff625735f8 READ of size 4 at 0x7fff625736a0 thread T0 #0 0x4e2a97 in SATD (benchspec/CPU2006/464.h264ref/run/run_base_ref_z./h264ref_base.z+0x4e2a97) #1 0x4e47c0 in SubPelBlockMotionSearch (benchspec/CPU2006/464.h264ref/run/run_base_ref_z./h264ref_base.z+0x4e47c0) ... Address 0x7fff625736a0 is located at offset 96 in frame of T0's stack: This frame has 1 object(s): [32, 96) 'd'
[Bug tree-optimization/56205] [4.8 Regression] stdarg pass confused by jump threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56205 --- Comment #2 from Jakub Jelinek 2013-02-05 10:42:34 UTC --- Created attachment 29354 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29354 gcc48-pr56205.patch Untested fix.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #11 from Jakub Jelinek 2013-02-05 10:54:46 UTC --- I really don't like the blacklist hack, such changes belong to the source, not outside of it. If you want to disable instrumentation of SATD, I think modification of the source is preferrable, or I guess you can use echo > buggy-spec-workarounds.h <<\EOF extern int SATD (int *, int) __attribute__((__no_address_safety_analysis__)); EOF and use -include .../buggy-spec-workarounds.h, though of course if it is a real bug in SPEC, it would be much better to just report it to SPEC and hope they fix it up. Though given http://www.spec.org/cpu2006/Docs/faq.html#Run.05 I don't have much hope they will (when they even don't see it as C89 violation).
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #12 from Markus Trippelsdorf 2013-02-05 11:17:42 UTC --- (In reply to comment #9) > > And, for compile time, you want to be testing with --enable-checking=release > Thanks! > With --enable-checking=release gcc's compile time drops to 374 seconds. > That's much better, but still 50% slower than clang (built with asserts) Hmm, that means gcc is 35% slower (374 vs. 243). That is exactly the slowdown that I see in all my tests. (So switching to clang is like moving from a 4-core to a 6-core machine from a compile time perspective.)
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #13 from Jakub Jelinek 2013-02-05 11:24:23 UTC --- Please, let's not make this PR into a general gcc vs. clang compile time comparison (see e.g. Vlad Makarov's mails on this topic, if you care more about compile time than runtime, supposedly e.g. -O1 might be better than -O2), for this particular PR I think it matters what relative slowdown -fsanitize=address causes on compile time and runtime for both compilers, and whether with Dodji's changes help here. If not, it is time to look at testcases and figure out what is going on. Without Dodji's patch we know what's going on and what could make the difference.
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #7 from Paolo Carlini 2013-02-05 11:25:46 UTC --- Narrowed to r190095 - r190842 so far.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #14 from Jakub Jelinek 2013-02-05 11:26:05 UTC --- (In reply to comment #11) > bug in SPEC, it would be much better to just report it to SPEC and hope they > fix it up. Though given http://www.spec.org/cpu2006/Docs/faq.html#Run.05 I > don't have much hope they will (when they even don't see it as C89 violation). Ah, in this case it is actually the same bug.
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #8 from Jakub Jelinek 2013-02-05 11:35:35 UTC --- http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190664
[Bug target/56211] gnulib yesno compiled incorrectly with -02 on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56211 Allan McRae changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Allan McRae 2013-02-05 12:04:33 UTC --- You are correct. More searching shows yesno declared as returning bool in one place and int in the other.
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|matz at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener 2013-02-05 12:12:20 UTC --- Created attachment 29355 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29355 patch I was thinking of sth as simple as the attached. (TODO: simplify and localize vect_check_strided_load) We need a runtime testcase that verifies PR53185 is vectorized correctly.
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #2 from Marek Polacek 2013-02-05
12:16:08 UTC ---
So, what happens here is that tracer performs tail-duplication. That is per se
of course fine, but when we're re-scanning bodies in fix_loop_structure, we
correctly mark BBs in the loop 1, then the loop 3, but then when processing the
loop 2, in flow_loop_nodes_find, we mark tail-duplicated BB as belonging into
the loop 2, because
FOR_EACH_EDGE (latch, latch_ei, loop->header->preds)
{
if (latch->src->loop_father == loop
|| !dominated_by_p (CDI_DOMINATORS, latch->src, loop->header))
continue;
doesn't notice that the BB is in fact outside of the loop. Which is bad - we
then process predecessors of that BB and mark the BBs in loop 3 as belonging
into loop 2. Oops.
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181 --- Comment #3 from Marek Polacek 2013-02-05 12:22:28 UTC --- Hopefully it'll be somewhat clearer with a picture: http://people.redhat.com/mpolacek/src/pr56181.png the BB 4 is the one that is first marked as residing in loop 2 (because it is dominated by BB 5 and its loop_father is 1, while the loop we're processing is loop 2).
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #15 from Kostya Serebryany 2013-02-05 12:22:56 UTC --- Well, I of course can change the SPEC code 464.h264ref, 1271.00,1879.00,1.47 As for Dodji's patch: can someone attach it here? Let me benchmark it too, although if that's just optimizing within one BB I don't expect more than 5% difference (based on my experiments in llvm). Dodji, what are your numbers?
[Bug middle-end/56212] New: Does not fold unsigned (b - a) + a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56212
Bug #: 56212
Summary: Does not fold unsigned (b - a) + a
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
unsigned foo (unsigned a, unsigned b)
{
return (b - a) + a;
}
should be simplified to return b. Later GIMPLE reassoc and forwprop do that
job.
[Bug target/25967] Add attribute naked for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 --- Comment #10 from Alexander Kobets 2013-02-05 12:51:00 UTC --- (In reply to comment #1) > A quick question here. Why not use a .s file instead? Quick answer. CC optimizes code better, especialy for instruction sheduling.
[Bug tree-optimization/54767] [4.7 Regression] Incorrect code generated with "-O2 -fcheck=bounds"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 --- Comment #13 from Richard Biener 2013-02-05 12:54:17 UTC --- Author: rguenth Date: Tue Feb 5 12:54:12 2013 New Revision: 195754 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195754 Log: 2013-02-05 Richard Biener PR tree-optimization/54767 * tree-vrp.c (vrp_visit_phi_node): For PHI arguments coming via backedges drop all symbolical range information. (execute_vrp): Compute backedges. * gfortran.fortran-torture/execute/pr54767.f90: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr54767.f90 Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vrp.c
[Bug tree-optimization/54767] [4.7 Regression] Incorrect code generated with "-O2 -fcheck=bounds"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Richard Biener 2013-02-05 12:54:41 UTC --- Fixed.
[Bug tree-optimization/55107] [4.7 Regression] GCC in an infinite loop in PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107 --- Comment #6 from Richard Biener 2013-02-05 12:56:56 UTC --- Author: rguenth Date: Tue Feb 5 12:56:51 2013 New Revision: 195755 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195755 Log: 2013-02-05 Richard Biener Backport from mainline 2012-12-10 Richard Biener PR tree-optimization/55107 * tree-ssa-pre.c (struct pre_stats): Remove constified field. (bitmap_set_replace_value): Add gcc_unreachable. (do_regular_insertion): Re-write all_same handling. Insert an assignment instead of a PHI in this case. (execute_pre): Do not record constified events. * gcc.dg/torture/pr55107.c: New testcase. * gcc.dg/tree-ssa/ssa-pre-5.c: Adjust. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55107.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-5.c branches/gcc-4_7-branch/gcc/tree-ssa-pre.c
[Bug tree-optimization/55107] [4.7 Regression] GCC in an infinite loop in PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Known to fail||4.7.2 --- Comment #7 from Richard Biener 2013-02-05 12:57:26 UTC --- Fixed.
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #17 from Jakub Jelinek 2013-02-05 13:01:25 UTC --- Ah, since PR53383 you can actually use -mno-sse -mpreferred-stack-boundary=3 on x86_64, but only with -mno-sse. Of course it is an ABI incompatible change, so you need to rebuild everything with that option.
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Richard Biener changed: What|Removed |Added Attachment #29355|0 |1 is obsolete|| --- Comment #10 from Richard Biener 2013-02-05 13:07:51 UTC --- Created attachment 29356 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29356 patch This is what I am testing now. Of course nothing tells us (yet) if that fixes this bug - the slowdown of rnflow.f90 - which might be caused by us vectorizing this loop at all (as far as I understand before the change we did not vectorize it).
[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 mgretton at gcc dot gnu.org changed: What|Removed |Added CC||mgretton at gcc dot gnu.org --- Comment #1 from mgretton at gcc dot gnu.org 2013-02-05 13:08:48 UTC --- I can reproduce this is in a compiler targeted for arm-none-eabi (and without needing libraries built) as follows: Compiler configured with: /work/sources/gcc-fsf/master/configure --target=arm-none-eabi --prefix=/work/builds/gcc-fsf-master/tools --without-headers --with-newlib --disable-shared --disable-threads --disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic --without-libquadmath --disable-libquadmath --enable-languages=c,c++ ./cc1plus -fpreprocessed test.ii -mthumb -march=armv7-a -mfpu=neon -mfloat-abi=softfp -mtune=cortex-a9 -O2 -o /tmp/tmp.s RTL dumps of 208r.ira and 208r.reload are attached from running the above command. The assert producing the ICE is: int regno = REGNO (out); gcc_assert (regno < FIRST_PSEUDO_REGISTER || reg_renumber[regno] >= 0 || reg_equiv_constant (regno) == NULL_RTX); out: (reg:DI 358 [315]) regno: 358 reg_renumber[regno] = -1 reg_equiv_constant (regno) = ? (Can't get GDB to print the value)
[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 --- Comment #2 from mgretton at gcc dot gnu.org 2013-02-05 13:11:33 UTC --- Created attachment 29357 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29357 RTL dump from IRA phase
[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 --- Comment #3 from mgretton at gcc dot gnu.org 2013-02-05 13:12:18 UTC --- Created attachment 29358 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29358 RTL dump from reload phase
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 --- Comment #11 from Dominique d'Humieres 2013-02-05 13:35:51 UTC --- After an incremental update of r195753 with the patch in comment #10, compiling rnflow.f90 with '-O3 -ffast-math -funroll-loops' gives an executable which segfault. 0: 0: 0.135 -> Read sequence 0: 0:42.259 -> extract extrema 0: 0:42.361 -> Generate raw transitions counts 0: 0:42.566 -> Compute Markov matrix 0: 0:42.595 -> Calculate theoretical rainflow ==6222== Invalid read of size 4 ==6222==at 0x10001E9FF: evlrnf_ (rnflow.f90:2703) ==6222==by 0xFF15: ??? ==6222==by 0x10166D0CB: __strtodg (in /usr/lib/libSystem.B.dylib) ==6222==by 0xE4: ??? ==6222== Address 0x507d4c030 is not stack'd, malloc'd or (recently) free'd ==6222== ==6222== ==6222== Process terminating with default action of signal 11 (SIGSEGV) ==6222== General Protection Fault ==6222==at 0x10170EFC1: dyld_stub_binder (in /usr/lib/libSystem.B.dylib) ==6222==by 0x1015AC02F: ??? (in /opt/gcc/gcc4.8w/lib/libgfortran.3.dylib) ==6222==by 0xE64: ??? ==6222==by 0x10149AE8A: _gfortrani_st_vprintf (in /opt/gcc/gcc4.8w/lib/libgfortran.3.dylib) If needed, I'll do a clean bootstrap later this afternoon.
[Bug libgomp/51376] libgomp taskwait failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51376 --- Comment #6 from Alan Modra 2013-02-05 13:40:35 UTC --- Author: amodra Date: Tue Feb 5 13:40:25 2013 New Revision: 195756 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195756 Log: PR libgomp/51376 PR libgomp/56073 * task.c (GOMP_task): Revert 2011-12-09 change. (GOMP_taskwait): Likewise. Instead use atomic load with acquire barrier to read task->children.. (gomp_barrier_handle_tasks): ..and matching atomic store with release barrier here when setting parent->children to NULL. Modified: branches/gcc-4_7-branch/libgomp/ChangeLog branches/gcc-4_7-branch/libgomp/task.c
[Bug libgomp/56073] SPEComp2012 376.kdtree fails to complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073 --- Comment #3 from Alan Modra 2013-02-05 13:40:39 UTC --- Author: amodra Date: Tue Feb 5 13:40:25 2013 New Revision: 195756 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195756 Log: PR libgomp/51376 PR libgomp/56073 * task.c (GOMP_task): Revert 2011-12-09 change. (GOMP_taskwait): Likewise. Instead use atomic load with acquire barrier to read task->children.. (gomp_barrier_handle_tasks): ..and matching atomic store with release barrier here when setting parent->children to NULL. Modified: branches/gcc-4_7-branch/libgomp/ChangeLog branches/gcc-4_7-branch/libgomp/task.c
[Bug libgomp/56073] SPEComp2012 376.kdtree fails to complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alan Modra 2013-02-05 13:43:51 UTC --- Fixed
[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 Ulrich Weigand changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #4 from Ulrich Weigand 2013-02-05 13:51:24 UTC --- This is weird; I cannot reproduce the behaviour even with the exact configure and command lines you specify. I've been using SVN rev. 195717; which revision do you see the problem with? In the generated test.ii.208r.ira file I get, I see different register uses even before IRA, compared to your version. Would you mind sending me (offline) a full set of the dump files so I can see where my compile run starts to diverge from yours?
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Richard Biener changed: What|Removed |Added Attachment #29356|0 |1 is obsolete|| --- Comment #12 from Richard Biener 2013-02-05 13:52:16 UTC --- Created attachment 29359 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29359 updated patch Updated patch that does not miscompile rnflow. Simplified as well... 0: 0:17.264 -> Completed program execution with patch, 0: 0:19.462 -> Completed program execution with strided load vectorization disabled, 0: 0:17.929 -> Completed program execution without patch. -Ofast -funroll-loops with generic on an old iCore (fam 6, model 30) Not sure what the original regression was against (certainly not against enabling strided load vectorization?)
[Bug tree-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195
--- Comment #2 from Jakub Jelinek 2013-02-05
13:56:56 UTC ---
Seems this is heavily related to the uninitialized uses, in
(insn 90 87 91 22 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 118 [ D.1797 ])
(mem:SI (reg/v/f:DI 59 [ q ]) [2 *q_1+0 S4 A32]))) pr56195.c:17 7
{*cmpsi_1}
(nil))
both SI 118 and DI 59 pseudos are preinitialized to const0_rtx because both the
address to read from and the other value are uninitialized. Guess LRA figures
out that both operands are equal to const0_rtx, just doesn't handle the
different modes properly (it can be cmpl (%rdi), %edi ).
[Bug tree-optimization/56213] New: strided load vectorization is unnecessarily restricted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56213 Bug #: 56213 Summary: strided load vectorization is unnecessarily restricted Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Blocks: 53947 In vect_check_strided_load we constrain the form of DR_REF for no good reason now that, after PR53342 fix, we always generate the usual pointer dereference form.
[Bug fortran/55789] [4.6/4.7/4.8 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 --- Comment #8 from Jan Hubicka 2013-02-05 15:24:03 UTC --- Author: hubicka Date: Tue Feb 5 15:23:56 2013 New Revision: 195758 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195758 Log: PR tree-optimization/55789 * g++.dg/tree-ssa/inline-1.C: Update max-inliner-iterations. * g++.dg/tree-ssa/inline-2.C: Update max-inliner-iterations. * g++.dg/tree-ssa/inline-3.C: Update max-inliner-iterations. * g++.dg/ipa/inline-1.C: New testcase. * g++.dg/ipa/inline-2.C: New testcase. * g++.dg/ipa/inline-3.C: New testcase. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ipa/inline-1.C trunk/gcc/testsuite/g++.dg/tree-ssa/inline-3.C
[Bug tree-optimization/53185] [4.8 Regression] segmentation fault in vectorizable_load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185 --- Comment #9 from Richard Biener 2013-02-05 15:33:48 UTC --- Author: rguenth Date: Tue Feb 5 15:33:35 2013 New Revision: 195759 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195759 Log: 2013-02-05 Richard Biener PR tree-optimization/53342 PR tree-optimization/53185 * tree-vectorizer.h (vect_check_strided_load): Remove. * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Do not disallow peeling for vectorized strided loads. (vect_check_strided_load): Make static and simplify. (vect_analyze_data_refs): Adjust. * tree-vect-stmts.c (vectorizable_load): Handle peeled loops correctly when vectorizing strided loads. * gcc.dg/vect/pr53185-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr53185-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 --- Comment #13 from Richard Biener 2013-02-05 15:33:51 UTC --- Author: rguenth Date: Tue Feb 5 15:33:35 2013 New Revision: 195759 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195759 Log: 2013-02-05 Richard Biener PR tree-optimization/53342 PR tree-optimization/53185 * tree-vectorizer.h (vect_check_strided_load): Remove. * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Do not disallow peeling for vectorized strided loads. (vect_check_strided_load): Make static and simplify. (vect_analyze_data_refs): Adjust. * tree-vect-stmts.c (vectorizable_load): Handle peeled loops correctly when vectorizing strided loads. * gcc.dg/vect/pr53185-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr53185-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #71 from simon at pushface dot org 2013-02-05 15:33:52 UTC ---
Created attachment 29360
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29360
Patch to suppress register swap on Darwin >= 12
(In reply to comment #69)
> OK, thanks, so the bug has apparently been fixed in Darwin 12. The last thing
> to do is to devise a _run time_ test to be added to
> __gnat_adjust_context_for_raise that will disable the code if the Darwin
> version is 12 or above. Essentially anything that works is acceptable. Any
> Darwin expert out there?
This patch works here in Darwin 12.2.1:
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
=== gnat Summary ===
# of expected passes1158
# of expected failures 17
# of unsupported tests 5
/Users/simon/tmp/gcc-build-195682-patched/gcc/gnatmake version 4.8.0 20130202
(experimental) [trunk revision 195682]
It uses sysctl(3) and strtol(3), which might seem heavy but as Eric has pointed
out it'll only be called when we're already in the middle of handling a signal.
Especially considering that, I may have gone OTT in caching the determined
version and/or separating the version determination into a new function.
I haven't checked the returned values of the sysctl(3) calls or the length of
the buffer required; what's policy? and what could be done if there was an
error?
As an aside, what's the recommended technique for rebuilding and reinstalling
just the RTS? ('cd gcc; make gnatlib' leaves the build in a state where 'make
install' doesn't work).
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Richard Biener 2013-02-05 15:36:14 UTC --- I suppose fixed. Not a regression to 4.7.x anyway(?)
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181 --- Comment #4 from Marek Polacek 2013-02-05 15:53:44 UTC --- Or maybe tracer shouldn't duplicate BB between headers, i.e. BB whose successor and predecessor is a header. Testing a patch for that...
[Bug tree-optimization/56205] [4.8 Regression] stdarg pass confused by jump threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56205 --- Comment #3 from Jakub Jelinek 2013-02-05 15:54:49 UTC --- Author: jakub Date: Tue Feb 5 15:54:39 2013 New Revision: 195760 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195760 Log: PR tree-optimization/56205 * tree-stdarg.c (check_all_va_list_escapes): Return true if there are any PHI nodes that set non-va_list_escape_vars SSA_NAME and some va_list_escape_vars SSA_NAME appears in some PHI argument. * gcc.dg/tree-ssa/stdarg-6.c: New test. * gcc.c-torture/execute/pr56205.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr56205.c trunk/gcc/testsuite/gcc.dg/tree-ssa/stdarg-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-stdarg.c
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #24 from Jakub Jelinek 2013-02-05 15:55:41 UTC --- Author: jakub Date: Tue Feb 5 15:55:31 2013 New Revision: 195761 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195761 Log: PR sanitizer/55374 * config/gnu-user.h (LIBTSAN_EARLY_SPEC): Define. (STATIC_LIBTSAN_LIBS): Likewise. * gcc.c (ADD_STATIC_LIBTSAN_LIBS, LIBTSAN_EARLY_SPEC): Define. (LIBTSAN_SPEC): Add ADD_STATIC_LIBTSAN_LIBS, if LIBTSAN_EARLY_SPEC is defined, don't add anything else beyond that. (SANITIZER_EARLY_SPEC, SANITIZER_SPEC): Define. (LINK_COMMAND_SPEC): Use them. Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h trunk/gcc/gcc.c
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #5 from Aldy Hernandez 2013-02-05 15:57:55 UTC --- I'll take a peek.
[Bug tree-optimization/56205] [4.8 Regression] stdarg pass confused by jump threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56205 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2013-02-05 15:58:32 UTC --- Should be fixed now.
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181 --- Comment #5 from Richard Biener 2013-02-05 15:58:32 UTC --- (In reply to comment #4) > Or maybe tracer shouldn't duplicate BB between headers, i.e. BB whose > successor > and predecessor is a header. Testing a patch for that... Not sure what's so special about such block ... apart from making the 2nd loop not have a simple preheader.
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #6 from Dominique d'Humieres 2013-02-05 16:00:21 UTC --- > I'll take a peek. Great!-)
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #7 from Tobias Grosser 2013-02-05 16:10:21 UTC --- (In reply to comment #5) > I'll take a peek. Wonderful, feel free to CC me if you have any questions!
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 I M changed: What|Removed |Added CC||infinity.probability at ||gmail dot com --- Comment #40 from I M 2013-02-05 16:33:13 UTC --- With version 4.7.2 this bug still exists. Is there any timeline to fix it?
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #6 from Marek Polacek 2013-02-05
16:33:45 UTC ---
Hmm, maybe I should have put it this way: we don't want to duplicate a BB,
which may be a preheader. Does it sound sane? Thus, something like
--- a/gcc/tracer.c
+++ b/gcc/tracer.c
@@ -217,6 +217,21 @@ find_trace (basic_block bb, basic_block *trace)
return i;
}
+/* Return true if basic block BB may be a preheader. */
+
+static bool
+maybe_preheader_p (basic_block bb)
+{
+ edge e;
+ edge_iterator ei;
+
+ FOR_EACH_EDGE (e, ei, bb->succs)
+if (e->dest->loop_father->header == e->dest)
+ return true;
+
+ return false;
+}
+
/* Look for basic blocks in frequency order, construct traces and tail
duplicate
if profitable. */
@@ -310,7 +325,8 @@ tail_duplicate (void)
not profitable and it might create a loop with multiple
entries or at least rotate the loop. */
&& (!current_loops
- || bb2->loop_father->header != bb2))
+ || bb2->loop_father->header != bb2)
+ && !maybe_preheader_p (bb2))
{
edge e;
basic_block copy;
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #41 from I M 2013-02-05 16:36:41 UTC --- With version 4.7.2 this bug still exists. Is there any timeline to fix it? The following code module thing implicit none character(len=:), allocatable :: array_of_chars(:) contains subroutine allocatestuff() implicit none integer :: length_names = 15 integer :: number_arrays = 5 allocate(character(15) :: array_of_chars(number_arrays)) !allocate(character(length_names) :: array_of_chars(number_arrays)) end subroutine allocatestuff end module thing program test1 implicit none call allocatestuff() end program test1 Both allocates triggers the bug. If the same code is in the main program and not in a module the first allocate works, but the second doesn't.
[Bug tree-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195 --- Comment #3 from Jakub Jelinek 2013-02-05 16:40:17 UTC --- I'd say the bug is in get_reload_reg. Changing pseudo 118 in operand 0 of insn 90 on equiv 0 Changing address in insn 90 r59:DI -- no change Changing pseudo 59 in address of insn 90 on equiv 0 Creating newreg=137, assigning class GENERAL_REGS to address r137 Choosing alt 1 in insn 90: (0) r (1) rm Reuse r137 for reload 0, change to class INDEX_REGS for r137 90: flags:CCGC=cmp(r137:DI,[r137:DI]) Inserting insn reload before: 256: r137:DI=0 3065 if (get_reload_reg (type, mode, old, goal_alt[i], "", &new_reg) 3066 && type != OP_OUT) calls it with type=OP_IN, mode=SImode, original=const0_rtx, rclass=GENERAL_REGS but returns new_reg = (reg:DI 137). That is because: if (rtx_equal_p (curr_insn_input_reloads[i].input, original) && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class)) doesn't check any mode if original (and curr_insn_input_reloads[i].input) are VOIDmode as in this case. So, either this can be fixed by doing: if (rtx_equal_p (curr_insn_input_reloads[i].input, original) - && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class)) + && in_class_p (curr_insn_input_reloads[i].reg, rclass, &new_class) + && GET_MODE (curr_insn_input_reloads[i].reg) == mode) , or we could try better, if the GET_MODE (curr_insn_input_reloads[i].reg) is wider than mode, see if we can create a lowpart subreg thereof and return that, and only give up (i.e. continue looping) if creation of the lowpart subreg for some reason failed. Vlad, what do you think?
[Bug tree-optimization/56210] invalid -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56210 --- Comment #5 from jim at meyering dot net 2013-02-05 17:00:47 UTC --- Hi Jakub, Exactly. The lack of const there was a bug, and I fixed that before reporting the gcc behavior that had surprised me.
[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
CC||gingold at adacore dot com
--- Comment #72 from Eric Botcazou 2013-02-05
17:48:16 UTC ---
> This patch works here in Darwin 12.2.1:
>
> === acats Summary ===
> # of expected passes2320
> # of unexpected failures0
>
> === gnat Summary ===
>
> # of expected passes1158
> # of expected failures 17
> # of unsupported tests 5
Great!
> Especially considering that, I may have gone OTT in caching the determined
> version and/or separating the version determination into a new function.
Not at all, it's not forbidden to be clever.
> I haven't checked the returned values of the sysctl(3) calls or the length of
> the buffer required; what's policy? and what could be done if there was an
> error?
We should probably check the return value of sysctl and immediately return 0 if
there is a problem (it would be up to the caller to decide what to do with 0).
Then I don't think that we need to check the length.
Minor points:
1. This should be
static int
__darwin_major_version (void)
2. I think that you can pass NULL to strtol instead of dot_p.
3. Double space before star-slash at the end of comments.
4. No () for functions in comments.
> As an aside, what's the recommended technique for rebuilding and reinstalling
> just the RTS? ('cd gcc; make gnatlib' leaves the build in a state where 'make
> install' doesn't work).
rm $(target)/libada/stamp-libada gcc/stamp-gnatlib*
make all-target-libada
CCing Tristan who knows more about Darwin than me...
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #18 from Alexander Kobets 2013-02-05 18:36:18 UTC --- (In reply to comment #17) Well.
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
--- Comment #9 from Daniel Krügler
2013-02-05 19:09:15 UTC ---
Further data about the root of the problem: It seems actually to be an access
problem, the requirements for reproducing seem to be:
1) Some class B derives *privately* from a base class A
2) B refers to some function template f2 that refers to another dependent
function template f1 both in class scope of A (It doesn't matter whether these
function are actually public in A)
A reduced example is as follows:
//---
struct A {
template
static int f1();
template
static int f2(char(*)[sizeof(f1())]);
};
struct B : private A {
enum { value = sizeof(f2(0)) };
};
//---
"Compilation finished with errors:
source.cpp:10:35: error: no matching function for call to 'B::f2(int)'
enum { value = sizeof(f2(0)) };
^
source.cpp:10:35: note: candidate is:
source.cpp:6:15: note: template static int A::f2(char (*)[sizeof
(f1())])
static int f2(char(*)[sizeof(f1())]);
^
source.cpp:6:15: note: template argument deduction/substitution failed:
source.cpp: In substitution of 'template static int A::f2(char
(*)[sizeof (f1())]) [with T = int]':
source.cpp:10:35: required from here
source.cpp:3:15: error: 'static int A::f1() [with T = int]' is inaccessible
static int f1();
^
source.cpp:6:39: error: within this context
static int f2(char(*)[sizeof(f1())]);
^"
[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185 Daniel Starke changed: What|Removed |Added Known to work||4.6.3 --- Comment #3 from Daniel Starke 2013-02-05 19:43:05 UTC --- Sorry, I forgot to fill out that field. Works fine with: Using built-in specs. COLLECT_GCC=D:\Programme\msys\mingw64\bin\x86_64-w64-mingw32-gcc.exe COLLECT_LTO_WRAPPER=d:/programme/msys/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.3/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../src/gcc-4.6.3/configure --enable-languages=c,c++ --disable-nls --disable-shared --enable-static --enable-lto --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32 --enable-targets=all --with-gmp=/usr/new-cross-gcc/lib/gmp-5.0.2 --with-mpfr=/usr/new-cross-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-cross-gcc/lib/mpc-0.9 --with-ppl=/usr/new-cross-gcc/lib/ppl-0.11.2 --with-cloog=/usr/new-cross-gcc/lib/cloog-parma-0.16.1 --with-host-libstdcxx='-lstdc++ -lsupc++' --enable-cloog-backend=ppl Thread model: win32 gcc version 4.6.3 (GCC) This is a cross compiler, thus I can not bootstrap it. The versions of the used libraries are in the configure string. Or do you need the base of the build system used to create that cross compiler?
[Bug c++/56177] [4.8 Regression] ICE when used forward for 'auto f();'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56177 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #42 from janus at gcc dot gnu.org 2013-02-05 20:22:25 UTC --- (In reply to comment #41) > With version 4.7.2 this bug still exists. Is there any timeline to fix it? > > [...] > > Both allocates triggers the bug. If the same code is in the main program and > not in a module the first allocate works, but the second doesn't. While your test case ICEs with 4.6 and 4.7 (internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158), it works with the current trunk version (if you add "use thing"), so it should also work with the upcoming release 4.8.0. Note that there are still some known bugs, though (cf. comment 39).
[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 --- Comment #33 from Dominique d'Humieres 2013-02-05 20:24:37 UTC --- Anything missing before this PR can be closed?
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 --- Comment #12 from janus at gcc dot gnu.org 2013-02-05 21:25:09 UTC --- Here is a further reduced test case, based on comment 1 and 3 (which are basically identical): program main implicit none integer, pointer :: y(:) y => null() call a4t2(y) contains subroutine a4t2(x) integer, intent(in) :: x(4) end subroutine end It yields valgrind errors with all gfortran versions I tried (trunk, 4.7, 4.6 and 4.3): ==5664== Conditional jump or move depends on uninitialised value(s) ==5664==at 0x4F25F05: _gfortran_internal_pack (in_pack_generic.c:53) ==5664==by 0x40076E: MAIN__ (in /home/jweil/GSoC/PRs/55978/a.out) ==5664==by 0x4007CA: main (in /home/jweil/GSoC/PRs/55978/a.out) So it seems this is not an actual regression?!? class_optional_2.f90 was introduced only in 4.8, and possibly r195125 only uncovered an existing bug (e.g. by adding a call to _gfortran_internal_pack).
[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 --- Comment #34 from Mikael Morin 2013-02-05 21:31:20 UTC --- (In reply to comment #33) > Anything missing before this PR can be closed? Unburying the patch for comment #4, testing it, committing it. :-)
[Bug ada/56178] [4.8 Regression] Miscompilation of Ada front-end with profiled bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56178 --- Comment #4 from Eric Botcazou 2013-02-05 21:41:30 UTC --- ureal.adb:UR_Add is miscompiled with profile feedback and this is yet another instance of the infamous webizer bug: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01259.html but the origin seems to be in fwprop1 this time...
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #2 from ian at gcc dot gnu.org 2013-02-05 22:22:25 UTC --- Author: ian Date: Tue Feb 5 22:22:17 2013 New Revision: 195766 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195766 Log: PR go/56017 libgo: Use DejaGNU when testing a cross-compiler. Modified: trunk/libgo/Makefile.am trunk/libgo/Makefile.in trunk/libgo/configure trunk/libgo/configure.ac trunk/libgo/testsuite/Makefile.in
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Ian Lance Taylor 2013-02-05 22:23:14 UTC --- This should be fixed, or at any rate should fail in some interesting new way.
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 --- Comment #13 from janus at gcc dot gnu.org 2013-02-05 22:26:55 UTC --- (In reply to comment #12) > program main > implicit none > > integer, pointer :: y(:) > > y => null() > call a4t2(y) > > contains > > subroutine a4t2(x) >integer, intent(in) :: x(4) > end subroutine > > end Ok, sorry. This one is actually invalid, which is correctly caught by -fcheck=all: Fortran runtime error: Pointer actual argument 'y' is not associated However, it becomes valid when making 'x' optional (but still gives the valgrind error).
[Bug go/55091] libgo testsuite doesn't support --target_board='unix{-mx32}'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55091
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Comment #2 from Ian Lance Taylor 2013-02-05 22:28:08
UTC ---
If you want to use RUNTESTFLAGS when testing libgo, also use USE_DEJAGNU=yes.
That is:
make USE_DEJAGNU=yes RUNTESTFLAGS="--target_board='unix{-mx32}'"
(But I have not tried this myself).
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #14 from janus at gcc dot gnu.org 2013-02-05 22:31:06 UTC ---
Draft patch:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c(revision 195644)
+++ gcc/fortran/trans-array.c(working copy)
@@ -7164,6 +7164,17 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
fold_convert (TREE_TYPE (se->expr), null_pointer_node));
}
+ if (fsym && fsym->attr.optional && sym && sym->attr.pointer)
+{
+ tmp = build_fold_indirect_ref_loc (input_location, desc);
+ tmp = gfc_conv_array_data (tmp);
+ tmp = fold_build2_loc (input_location, NE_EXPR, boolean_type_node,
+tmp, fold_convert (TREE_TYPE (tmp), null_pointer_node));
+ ptr = build3_loc (input_location, COND_EXPR, TREE_TYPE (se->expr),
+tmp, fold_convert (TREE_TYPE (se->expr), ptr),
+fold_convert (TREE_TYPE (se->expr), null_pointer_node));
+}
+
ptr = gfc_evaluate_now (ptr, &se->pre);
/* Use the packed data for the actual argument, except for contiguous
arrays,
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 --- Comment #5 from ian at gcc dot gnu.org 2013-02-05 22:36:31 UTC --- Author: ian Date: Tue Feb 5 22:36:20 2013 New Revision: 195768 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195768 Log: PR go/55969 * configure.ac: Disable libgo on some systems where it does not work. Modified: trunk/configure trunk/configure.ac
[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
simon at pushface dot org changed:
What|Removed |Added
Attachment #29360|0 |1
is obsolete||
--- Comment #73 from simon at pushface dot org 2013-02-05 22:37:36 UTC ---
Created attachment 29361
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29361
Patch to suppress register swap on Darwin >= 12, v2
(In reply to comment #72)
> We should probably check the return value of sysctl and immediately return 0
> if
> there is a problem (it would be up to the caller to decide what to do with 0).
> Then I don't think that we need to check the length.
Done.
I do wonder when Apple introduced this problem. It was first reported with
Darwin 10, but GCC 4.6 and GNAT GPL 2011, 2012 (both based on GCC 4.5) don't
show the problem, so would we have known? Should the test be 10 <= version <12
> Minor points:
>
> 1. This should be
>
> static int
> __darwin_major_version (void)
>
> 2. I think that you can pass NULL to strtol instead of dot_p.
>
> 3. Double space before star-slash at the end of comments.
>
> 4. No () for functions in comments.
Done.
> > As an aside, what's the recommended technique for rebuilding and
> > reinstalling
> > just the RTS? ('cd gcc; make gnatlib' leaves the build in a state where
> > 'make
> > install' doesn't work).
>
> rm $(target)/libada/stamp-libada gcc/stamp-gnatlib*
> make all-target-libada
and 'make install-target-libada'.
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Ian Lance Taylor 2013-02-05 22:37:42 UTC --- The top level configure script should no longer build libgo on systems like Darwin where it is known to be unsupported. *** This bug has been marked as a duplicate of bug 46986 ***
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 Ian Lance Taylor changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #38 from Ian Lance Taylor 2013-02-05 22:37:42 UTC --- *** Bug 55969 has been marked as a duplicate of this bug. ***
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 --- Comment #15 from Tobias Burnus 2013-02-05 22:46:03 UTC --- (In reply to comment #14) > + if (fsym && fsym->attr.optional && sym && sym->attr.pointer) Shouldn't you use something like gfc_expr_attr(expr).pointer Otherwise, I fear it will fail for var%comp Additionally, one might have to handle - unallocated allocatables - NULL() [= EXPR_NULL] - CLASS(), (pointer|allocatable)? Furthermore, I think one can use: (gfc_option.allow_std & GFC_STD_F2008) != 0 as only since Fortran 2008, NULL pointers and deallocated allocatables count as absent optionals (to nonpointer,nonallocatable actuals).
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 --- Comment #22 from Michael Truog 2013-02-05 23:47:08 UTC --- I believe this bug is resolved and was just a problem with my build setup. I am unable to confirm that this is the solution, just due to changes in versions and software, but I see no reason to not close this bug. Thank you for looking at the problem.
[Bug target/56200] queens benchmark is faster with -O0 than with any other optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200 H.J. Lu changed: What|Removed |Added CC||areg.melikadamyan at gmail ||dot com --- Comment #5 from H.J. Lu 2013-02-05 23:50:35 UTC --- Optimized alignments are enabled for -O2 and above. For -O2, there are: .p2align 4,,10 .p2align 3 .L19: cmplfile(,%rbx,4), %ebp jg .L18 cmpl0(%r13,%rbx,4), %ebp jg .L18 cmpl(%r12), %ebp jle .L22 .p2align 4,,10 .p2align 3 .L18: and generate 400ab6: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1) 400ac0: 3b 2c 9d a0 1a 60 00cmp0x601aa0(,%rbx,4),%ebp 400ac7: 7f 17 jg 400ae0 400ac9: 41 3b 6c 9d 00 cmp0x0(%r13,%rbx,4),%ebp 400ace: 7f 10 jg 400ae0 400ad0: 41 3b 2c 24 cmp(%r12),%ebp 400ad4: 7e 32 jle400b08 400ad6: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1) Branch Predict Unit fetches 32-byte at a time. There are 3 back-to-back fused cmp/jcc instructions in 32-byte window, which causes misprediction. We can add a nop after the first cmp/jcc to avoid back-to-back cmp/jccs.
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-05 Ever Confirmed|0 |1 --- Comment #8 from Aldy Hernandez 2013-02-05 23:52:30 UTC --- Confirmed with cloog 0.18 and isl 0.11, both installed in /build/install, and configuring GCC with: /source/gcc/configure --disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran --with-cloog=/build/install --with-isl=/build/install houston:/build/55022-f90/gcc/pr55022$ ls air_main.f90 botwall.f90 datax.inp datay.inp topwall.f90 houston:/build/55022-f90/gcc/pr55022$ ../xgcc -B../ -O2 -fgraphite-identity air_main.f90 botwall.f90 topwall.f90 -L ../../x86_64-unknown-linux-gnu/libgfortran/.libs/ -lgfortran -lm houston:/build/55022-f90/gcc/pr55022$ ./a.out ... ... 1290.000625547555 0.01001.945421 1440.000674419139 0.01002.198194 1660.000728576510 0.0100 NaN 168 100.000735868323 0.0100 NaN
[Bug go/56172] net FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 --- Comment #3 from ian at gcc dot gnu.org 2013-02-05 23:59:28 UTC --- Author: ian Date: Tue Feb 5 23:59:24 2013 New Revision: 195774 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195774 Log: PR go/56172 runtime: Fix argument passed to forcegchelper. Modified: trunk/libgo/runtime/mheap.c
[Bug middle-end/56214] New: [4.8 Regression] FAIL: gcc.c-torture/execute/20050121-1.c compilation, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56214 Bug #: 56214 Summary: [4.8 Regression] FAIL: gcc.c-torture/execute/20050121-1.c compilation, ICE Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa*-*-* (32-bit) Target: hppa*-*-* (32-bit) Build: hppa*-*-* (32-bit) Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c -fno-diagnostics-show-caret -w -O0 -lm -o /home/dave/gnu/gcc/objdir/gcc/testsuite/gcc/20050121-1.x0(timeout = 300) spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c -fno-diagnostics-show-caret -w -O0 -lm -o /home/dave/gnu/gcc/objdir/gcc/testsuite/gcc/20050121-1.x0 /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c: In function 'foo_char': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33:1: error: unrecognizable insn: (insn 46 25 34 2 (set (reg:SI 20 %r20) (subreg:SI (mem/c:CQI (plus:SI (reg/f:SI 3 %r3) (const_int 22 [0x16])) [0 %sfp+22 S2 A64]) 0)) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33 -1 (nil)) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33:1: internal compiler error: in extract_insn, at recog.c:2150 0x4c0f9f _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:109 0x4c0ff7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:117 0x48f52f extract_insn(rtx_def*) ../../gcc/gcc/recog.c:2150 0x48f5b3 extract_insn_cached(rtx_def*) ../../gcc/gcc/recog.c:2053 0x2d3623 cleanup_subreg_operands(rtx_def*) ../../gcc/gcc/final.c:3008 0x4b85ff reload(rtx_def*, int) ../../gcc/gcc/reload1.c:1240 0x3d2df3 do_reload ../../gcc/gcc/ira.c:4635 0x3d2df3 rest_of_handle_reload ../../gcc/gcc/ira.c:4736 Introduced between 195690 and 195703.
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #5 from Matt Hargett 2013-02-06 01:23:02 UTC --- the latest failure, with current trunk: /work/mhargett/gcc-trunk-obj/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange -floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcc-ar.o -o gcc-ar \ file-find.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0, from :61: ../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view->len) < 0) ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0, from :61: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view->len) < 0) ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy (&ehdr, ehdr_view.data, sizeof ehdr); ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.data' was declared here struct backtrace_view ehdr_view; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/cc68SyuG.ltrans2.ltrans.o] Error 1 make[4]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /u/mhargett/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [gcov-dump] Error 1 make[3]: *** Waiting for unfinished jobs In file included from ../../gcc-trunk/libiberty/cp-demangle.c:877:0, from :73: ../../gcc-trunk/libbacktrace/elf.c: In function 'backtrace_initialize': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view->len) < 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :73: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:877:0, from :73: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view->len) < 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :73: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :73: ../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy
[Bug target/53040] nested functions may trash floating point registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Alan Modra 2013-02-06 02:39:54 UTC --- Fixed. Not a regression so not applying to FSF branches.
[Bug target/53040] nested functions may trash floating point registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040 --- Comment #4 from Alan Modra 2013-02-06 02:46:24 UTC --- Author: amodra Date: Wed Feb 6 02:46:13 2013 New Revision: 195778 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195778 Log: PR target/53040 * config/rs6000/rs6000.c (rs6000_savres_strategy): When using static chain, set REST_INLINE_FPRS too. Modified: branches/ibm/gcc-4_7-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_7-branch/gcc/config/rs6000/rs6000.c
[Bug target/53038] cfi_restore for cr before cr is actually restored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alan Modra 2013-02-06 03:04:58 UTC --- Fixed mainline. Not a regression so not applying to FSF branches.
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work due to access problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #10 from Jason Merrill 2013-02-06 03:33:52 UTC --- Author: jason Date: Wed Feb 6 03:33:45 2013 New Revision: 195779 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195779 Log: PR c++/56208 * pt.c (fn_type_unification): Discard any access checks from substituting explicit args. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae43.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
