[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-11 08:27:41 UTC --- Author: jakub Date: Sat Feb 11 08:27:30 2012 New Revision: 184126 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184126 Log: PR debug/52132 * reg-stack.c (subst_stack_regs_in_debug_insn): Don't use get_true_reg. * gcc.dg/pr52132.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr52132.c Modified: trunk/gcc/ChangeLog trunk/gcc/reg-stack.c trunk/gcc/testsuite/ChangeLog
[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-11 08:32:40 UTC --- Fixed.
[Bug c++/51910] [4.7 Regression] -frepo linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910 --- Comment #18 from Jason Merrill jason at gcc dot gnu.org 2012-02-11 08:50:27 UTC --- Author: jason Date: Sat Feb 11 08:50:23 2012 New Revision: 184127 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184127 Log: PR c++/51910 * tlink.c (demangled_hash_entry): Change mangled to a VEC. (demangle_new_symbols): Fill it. (scan_linker_output): Walk it. (start_tweaking): Split out from scan_linker_output. (maybe_tweak): Update sym-chosen. * Makefile.in (COLLECT2_OBJS): Add vec.o and gcc-none.o Added: trunk/gcc/testsuite/g++.dg/template/repo10.C Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/tlink.c
[Bug c++/39055] [DR 1443][4.4/4.5/4.6/4.7 regression] questionable default parameter of a member function accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |NEW Summary|questionable default|[DR 1443][4.4/4.5/4.6/4.7 |parameter of a member |regression] questionable |function accepted |default parameter of a ||member function accepted --- Comment #19 from Jason Merrill jason at gcc dot gnu.org 2012-02-11 08:53:01 UTC --- At the Kona meeting this week, one of the EDG guys pointed out that there is text in 8.3.6 that specifically prohibits this: Similarly, a non-static member shall not be used in a default argument, even if it is not evaluated, unless it appears as the id-expression of a class member access expression (5.2.5) or unless it is used to form a pointer to member (5.3.1).
[Bug rtl-optimization/52175] [4.7 regression] ICE in maybe_record_trace_start after invalid dbr_schedule transformation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52175 --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-02-11 09:00:47 UTC --- Author: rsandifo Date: Sat Feb 11 09:00:42 2012 New Revision: 184128 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184128 Log: gcc/ PR rtl-optimization/52175 * reorg.c (fill_slots_from_thread): Don't apply add/sub optimization to frame-related instructions. gcc/testsuite/ PR rtl-optimization/52175 * gcc.c-torture/compile/pr52175.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52175.c Modified: trunk/gcc/ChangeLog trunk/gcc/reorg.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/52175] [4.7 regression] ICE in maybe_record_trace_start after invalid dbr_schedule transformation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52175 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-02-11 09:16:06 UTC --- Patch applied.
[Bug c++/51910] [4.7 Regression] -frepo linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-11 09:16:32 UTC --- Fixed, thanks.
[Bug middle-end/52209] [4.7 Regression] wrong code at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52209 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-11 09:15:41 UTC --- Created attachment 26640 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26640 gcc47-pr52209.patch I don't think we need REDUCE_BIT_FIELD here, IMHO the old code was just fine for the signed bitfields. Because then op0 will be either 0 or -1, NOT on it turns it into -1 or 0 and REDUCE_BIT_FIELD would do nothing on that. Richard's change was IMHO only needed for unsigned bitfields.
[Bug fortran/38114] unneeded temp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38114 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-11 09:31:08 UTC --- I also think this is not a missed optimization. We need a temporary for the write statement anyway. I vote for closing this. Setting to WAITING, if somebody else concurs please close.
[Bug target/52205] SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-11 10:47:46 UTC --- I see this in both 32-bit and 64-bit mode. If I tweak libgcc/config/sparc/sol2-unwind.h so that sparc_is_sighandler sets *nframes to 3 rather than 2, then the test passes (I only tried this in 32-bit mode, not in 64-bit mode). The cuh_pattern test in sparc_is_sighandler does not match, so presumably it needs to be adjusted for Solaris 2.11. However, I'm not sure how to properly and safely correct it. OK, let's at least try, first in 32-bit mode. What code path is taken exactly in sparc_is_sighandler on Solaris 11?
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-11 10:50:53 UTC --- Did the revert fix any regression that was reported as a bug and has gotten a testcase? If not, then the proper way to address this new regression is to revert the revert especially as it appearantly happened during stage4(?) Yes, the revert fixes a regression (6 ACATS tests + 4 gnat.dg tests) and no, it didn't happen during stage4. Let's try to do something under PR target/52205.
[Bug target/46779] [4.4/4.5/4.6 Regression][avr] wrong code generation for values held in R28/R29
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||dhowells at redhat dot com --- Comment #16 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-11 10:54:54 UTC --- *** Bug 51445 has been marked as a duplicate of this bug. ***
[Bug target/51445] g++ sometimes miscompiles code for the avr target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51445 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org Resolution|FIXED |DUPLICATE --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-11 10:54:54 UTC --- *** This bug has been marked as a duplicate of bug 46779 ***
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-11 11:40:36 UTC --- (In reply to comment #9) We have a problem in v4.6.2 with the following (using the std=f95 flag): There seems to have been a limitation in past versions of gfortran with allocatable components inside derived types. Allocatable components in derived types is not allowed in Fortran 95 - it has only been later added as Technical Report (TR) 15581 and it is part of Fortran 2003. Thus, the flag -std=f95 does not work if you need allocatable components. Hence, you have to choose one of the other options listed as comment #7: Unless you provide me with a time machine [...] The only solutions, I see, which do not require code changes are: - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x - Use GCC 4.6 older than 2010-11-28 - Use a GCC (any version) newer than 2012-02-03 - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) - Use -std=f95 (caveat: Requires that the code compiles without error with -std=f95) I personally would use -fno-realloc-lhs [...] For completeness, also the following code changes are possible; except for the first one, they are not recommended: - Use an array spec for allocatable LHS, e.g. B(:,:,:) = - Don't use allocatables left of = RESHAPE - Make the expression on the RHS more complicated: add + 0 or surround with ( ).
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #12 from steven hirshman sphirshman at yahoo dot com 2012-02-11 12:08:02 UTC --- Thank you for your reply. I'll check with my coworker about that. From: burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: sphirsh...@yahoo.com Sent: Saturday, February 11, 2012 6:40 AM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-11 11:40:36 UTC --- (In reply to comment #9) We have a problem in v4.6.2 with the following (using the std=f95 flag): There seems to have been a limitation in past versions of gfortran with allocatable components inside derived types. Allocatable components in derived types is not allowed in Fortran 95 - it has only been later added as Technical Report (TR) 15581 and it is part of Fortran 2003. Thus, the flag -std=f95 does not work if you need allocatable components. Hence, you have to choose one of the other options listed as comment #7: Unless you provide me with a time machine [...] The only solutions, I see, which do not require code changes are: - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x - Use GCC 4.6 older than 2010-11-28 - Use a GCC (any version) newer than 2012-02-03 - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) - Use -std=f95 (caveat: Requires that the code compiles without error with -std=f95) I personally would use -fno-realloc-lhs [...] For completeness, also the following code changes are possible; except for the first one, they are not recommended: - Use an array spec for allocatable LHS, e.g. B(:,:,:) = - Don't use allocatables left of = RESHAPE - Make the expression on the RHS more complicated: add + 0 or surround with ( ).
[Bug other/52207] License on gcc/doc/include/gcc-common.texi screws up the licenses of many other documents.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52207 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org 2012-02-11 12:18:48 UTC --- This is clearly a matter for the SC. I'd suggest they seek approval from the FSF to (a) put suitable terms directly on gcc-common.texi (maybe GFDL without invariant sections or cover texts, maybe permissive terms); (b) remove cover texts and invariant sections from manuals that are under 400 pages and not published on paper by the FSF, as per the policies at http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Documentation.html that do not require such cover texts and invariant sections in that case.
[Bug rtl-optimization/52203] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7136 with -fsel-sched-pipelining -fselective-scheduling2 and other custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52203 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |abel at gcc dot gnu.org |gnu.org | --- Comment #1 from Andrey Belevantsev abel at gcc dot gnu.org 2012-02-11 12:52:38 UTC --- Thanks, Zdenek and Steven, I'll look at this on Monday. I bet this is caused by yet another insn without a reservation.
[Bug c/52210] New: vect_model_simple_cost: reading uninitialised memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52210 Bug #: 52210 Summary: vect_model_simple_cost: reading uninitialised memory Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 26641 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26641 C source code I just tried to compile the attached code with flag -O3 under valgrind on latest trunk dated 20120211 on an AMD x86_64 box. Valgrind said ==6796== Conditional jump or move depends on uninitialised value(s) ==6796==at 0xAECAC5: vect_model_simple_cost(_stmt_vec_info*, int, vect_def_type*, _slp_tree*) (tree-vect-stmts.c:800) ==6796==by 0xB17569: vect_get_and_check_slp_defs(_loop_vec_info*, _bb_vec_info*, _slp_tree*, gimple_statement_d*, int, bool, VEC_slp_oprnd_info_heap**) (tree-vect-slp.c:327) ==6796==by 0xB18EB0: vect_build_slp_tree(_loop_vec_info*, _bb_vec_info*, _slp_tree**, unsigned int, int*, int*, int, unsigned int*, VEC_int_heap**, VEC_slp_tree_heap**, unsigned int, bool*) (tree-vect-slp.c:868) ==6796==by 0xB199E9: vect_build_slp_tree(_loop_vec_info*, _bb_vec_info*, _slp_tree**, unsigned int, int*, int*, int, unsigned int*, VEC_int_heap**, VEC_slp_tree_heap**, unsigned int, bool*) (tree-vect-slp.c:918) ==6796==by 0xB1C7AD: vect_analyze_slp_instance(_loop_vec_info*, _bb_vec_info*, gimple_statement_d*) (tree-vect-slp.c:1549) ==6796==by 0xB1DDEF: vect_analyze_slp(_loop_vec_info*, _bb_vec_info*) (tree-vect-slp.c:1649) ==6796==by 0xB1E1C0: vect_slp_analyze_bb(basic_block_def*) (tree-vect-slp.c:2056) ==6796==by 0xB1F135: execute_vect_slp() (tree-vectorizer.c:265) ==6796==by 0x885CEC: execute_one_pass(opt_pass*) (passes.c:2081) ==6796==by 0x886266: execute_pass_list(opt_pass*) (passes.c:2136) ==6796==by 0x9C424D: tree_rest_of_compilation(tree_node*) (tree-optimize.c:422) ==6796==by 0x61E63D: cgraph_expand_function(cgraph_node*) (cgraphunit.c:1831) ==6796== Preprocessed source code attached. Flag -O3 required. This bug might be related to #45948
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||bosch at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #51 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-11 14:43:54 UTC --- Geert's proposal at http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00556.html is an interesting track. I'll give it a try.
[Bug translation/52211] New: Typo in translatable string: -fdisble (-fdisable)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52211 Bug #: 52211 Summary: Typo in translatable string: -fdisble (-fdisable) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: sti...@antcom.de See gcc/passes.c, currently line 712: error (unknown pass %s specified in -fdisble, phase_name);
[Bug bootstrap/52172] [4.7 Regression] stage 3 Bootstrap comparison failure on FreeBSD ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52172 --- Comment #8 from Anton Shterenlikht mexas at bristol dot ac.uk 2012-02-11 22:01:52 UTC --- bear with me.. # pwd /usr/ports/lang/gcc47/work/build/stage2-gcc # cat stage2-command /usr/ports/lang/gcc47/work/build/./stage2-gcc/g++ -fcompare-debug -save-temps -B/usr/ports/lang/gcc47/work/build/./stage2-gcc/ -B/usr/local/ia64-portbld-freebsd9.9/bin/ -nostdinc++ -B/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/src/.libs -B/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/libsupc++/.libs -I/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/include/ia64-portbld-freebsd9.9 -I/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/include -I/usr/ports/lang/gcc47/work/gcc-4.7-20120204/libstdc++-v3/libsupc++ -L/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/src/.libs -L/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -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 -I. -I. -I.././../gcc-4.7-20120204/gcc -I.././../gcc-4.7-20120204/gcc/. -I.././../gcc-4.7-20120204/gcc/../include -I.././../gcc-4.7-20120204/gcc/../libcpp/include -I/usr/local/include -I.././../gcc-4.7-20120204/gcc/../libdecnumber -I.././../gcc-4.7-20120204/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include .././../gcc-4.7-20120204/gcc/var-tracking.c -o var-tracking.o # ./stage2-command # cd ../stage3-gcc/ # cat stage3-command /usr/ports/lang/gcc47/work/build/./stage2-gcc/g++ -fcompare-debug -save-temps -B/usr/ports/lang/gcc47/work/build/./stage2-gcc/ -B/usr/local/ia64-portbld-freebsd9.9/bin/ -nostdinc++ -B/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/src/.libs -B/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/libsupc++/.libs -I/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/include/ia64-portbld-freebsd9.9 -I/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/include -I/usr/ports/lang/gcc47/work/gcc-4.7-20120204/libstdc++-v3/libsupc++ -L/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/src/.libs -L/usr/ports/lang/gcc47/work/build/stage2-ia64-portbld-freebsd9.9/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -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 -I. -I. -I.././../gcc-4.7-20120204/gcc -I.././../gcc-4.7-20120204/gcc/. -I.././../gcc-4.7-20120204/gcc/../include -I.././../gcc-4.7-20120204/gcc/../libcpp/include -I/usr/local/include -I.././../gcc-4.7-20120204/gcc/../libdecnumber -I.././../gcc-4.7-20120204/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include .././../gcc-4.7-20120204/gcc/var-tracking.c -o var-tracking.o # ./stage3-command g++: error: .././../gcc-4.7-20120204/gcc/var-tracking.c: -fcompare-debug failure # ls -al var-tracking.* -rw-r--r-- 1 root wheel 17465618 Feb 11 21:51 var-tracking.gk.gkd -rw-r--r-- 1 root wheel 1621224 Feb 11 21:51 var-tracking.gk.ii -rw-r--r-- 1 root wheel 17465618 Feb 11 21:51 var-tracking.gkd -rw-r--r-- 1 root wheel 1621224 Feb 11 21:50 var-tracking.ii -rw-r--r-- 1 root wheel 4186799 Feb 11 21:51 var-tracking.s I uploaded var-tracking.ii at: http://seis.bris.ac.uk/~mexas/var-tracking.ii Or have I misunderstood you?
[Bug target/52205] SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-02-12 Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #3 from Ian Lance Taylor ian at airs dot com 2012-02-12 04:12:07 UTC --- I'm using a system Rainer gave me access to. It's sparc-sun-solaris2.11. uname -a reports SunOS mayon 5.11 11.0 sun4v sparc SUNW,SPARC-Enterprise-T5220 Solaris readelf -V /lib/libc.so.1 shows that the highest version is SUNW_1.22.7. Using mainline as of a couple of February 8, 2012 or so. Looking at libgcc/config/sparc/sol2-unwind.h. This case matches: if(/* Solaris 8+ - multi-threaded __sighndlr:save %sp, -96, %sp __sighndlr+4:mov %i0, %o0 __sighndlr+8:mov %i1, %o1 __sighndlr+12:call %i3 __sighndlr+16:mov %i2, %o2 __sighndlr+20:ret --- PC __sighndlr+24:restore */ pc[-5] == 0x9de3bfa0 pc[-4] == 0x90100018 pc[-3] == 0x92100019 pc[-2] == 0x9fc6c000 pc[-1] == 0x9410001a pc[ 0] == 0x81c7e008 pc[ 1] == 0x81e8) In that condition, cuh_pattern is set to 0x92100019. This doesn't match any of the choices in the code, so it returns 1 with *nframes = 2. In order to work correctly, it needs to return with *nframes = 3. cuh_pattern is an instruction loaded from some code. That code looks like this: 0xff298f48 call_user_handler+876: mov %i1, %o1 0xff298f4c call_user_handler+880: call 0xff2a552c __sighndlr 0xff298f50 call_user_handler+884: mov %i5, %o2 0xff298f54 call_user_handler+888: ld [ %fp + 0x4c ], %i5 0xff298f58 call_user_handler+892: ld [ %fp + 0x44 ], %g5
[Bug tree-optimization/15459] [meta-bug] there should be a tree combiner like the rtl one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15459 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-12 04:28:50 UTC --- tree-ssa-forwprop is becoming one but slowly. In the next few months, I am going to take what is done in fold-const and port them to forwprop. I already posted one of them: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00945.html . I will try to work on the rest and more.
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531
--- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-12
04:35:53 UTC ---
The shortest testcase for the problem function:
int isnegative_optimized_4(unsigned int X) {
int result; // Y is the conditional expression of if-else.
if ((~X) 31) result = 0;
elseresult = 1;
return result;
}
We need to combine the following gimple:
D.2293_3 = ~X_2(D);
D.2294_4 = (int) D.2293_3;
D.2424_9 = D.2294_4 = 0;
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-12 04:37:08 UTC --- Note: D.2424_9 = D.2294_4 = 0; is the same as: D.2424_9 = D.2294_4 0;
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531
--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-12
04:39:01 UTC ---
forwprop already handles:
int f(int a)
{
int b = ~a;
return b0;
}
It just needs to handle:
int f(unsigned a)
{
int b = ~a;
return b0;
}
[Bug tree-optimization/15017] compare with casts (equal) are not removed in forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15017 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #14 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-12 05:25:35 UTC --- Replaced 'as1_3 != bs1_5' with 'as.0_2 != bs.1_4' Fixed now.
[Bug go/47656] libgo.so has writable executable stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47656 --- Comment #4 from Ian Lance Taylor ian at airs dot com 2012-02-12 05:59:42 UTC --- Yes, __builtin_init_heap_trampoline is new for 4.7. Sorry for not answering earlier, I missed the e-mail message somehow.
[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 --- Comment #6 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-02-12 06:00:42 UTC --- Author: ian Date: Sun Feb 12 06:00:34 2012 New Revision: 184137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184137 Log: PR go/51874 * go.test/go-test.exp (go-gc-tests): Don't run nilptr test on SPARC Solaris. Don't run the test at all on systems where it may not work, rather than xfailing it. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/go.test/go-test.exp
[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 --- Comment #7 from Ian Lance Taylor ian at airs dot com 2012-02-12 06:04:42 UTC --- In current mainline I'm not aware of any test failures on Solaris. The SPARC Solaris system I am using is very slow and I do see some timeouts. However, I do not see any more actual failures. I have not tested on Irix. To be honest I am far less interested in Irix than I am in Solaris. Can you still buy a new Irix system? If you agree that Solaris working, can you either close this PR or make it Irix-specific? Thanks.
[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 --- Comment #8 from Ian Lance Taylor ian at airs dot com 2012-02-12 06:05:36 UTC --- Sorry, I should clarify that I don't see any failures on Solaris if I patch the compiler to avoid PR 51921.
[Bug go/52084] go tests fail to link on powerpc-linux-gnu (undefined reference to __sync_add_and_fetch_8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-02-12 06:23:13 UTC --- Author: ian Date: Sun Feb 12 06:23:08 2012 New Revision: 184138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184138 Log: PR go/52084 libgo: Provide more __sync functions if required. Modified: trunk/libgo/config.h.in trunk/libgo/configure trunk/libgo/configure.ac trunk/libgo/runtime/thread.c
[Bug go/52084] go tests fail to link on powerpc-linux-gnu (undefined reference to __sync_add_and_fetch_8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Ian Lance Taylor ian at airs dot com 2012-02-12 06:23:51 UTC --- Should be fixed in mainline. Thanks for reporting it.
[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-12 06:55:18 UTC --- (In reply to comment #7) I have not tested on Irix. To be honest I am far less interested in Irix than I am in Solaris. Can you still buy a new Irix system? Not know I know of. There are some mips64-linux-gnu machines around which run pretty fast though (I can do some runs on an 6 core 1.3GHz MIPS64 Linux if needed).
[Bug c++/52212] New: friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
Bug #: 52212
Summary: friend declaration doesn't see previous friend of same
function
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: igod...@pacbell.net
This code:
class D {
class E{
class F{};
friend void foo1(D::E::F q);
};
friend void foo1(D::E::F q);
};
void foo1(D::E::F q) {}
int main(int argc, char** argv) { return 0; }
gets you:
foo.cc:3:9: error: âclass D::E::Fâ is private
foo.cc:6:26: error: within this context
Note that the same function was earlier made a friend of class E, and so can
see F. If you leave out the second friending, you get:
foo.cc: In function âvoid foo1(D::E::F)â:
foo.cc:2:8: error: âclass D::Eâ is private
foo.cc:9:21: error: within this context
which is correct; foo1 cannot see E without the second friend. But with both
friends foo1 should see everybody.
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #1 from Ivan Godard igodard at pacbell dot net 2012-02-12 07:46:10 UTC --- p.s. FWIW, clang accepts this and Comeau does not.
