[Bug other/50664] GDB rebuilt by i686-w64-mingw32-gcc4.6.2's -Os crashed when debugging, but -O2 is OK.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50664 --- Comment #1 from xunxun xunxun1982 at gmail dot com 2011-10-20 06:39:17 UTC --- gcc-4.6.2-RC-20111019 has not the problem. May be solved.
[Bug other/50664] GDB rebuilt by i686-w64-mingw32-gcc4.6.2's -Os crashed when debugging, but -O2 is OK.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50664 xunxun xunxun1982 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from xunxun xunxun1982 at gmail dot com 2011-10-20 06:39:50 UTC --- gcc-4.6.2-RC-20111019 has not the problem. May be solved.
[Bug libfortran/50016] [4.7 Regression] Drastic I/O performance regression on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50016 --- Comment #18 from xunxun xunxun1982 at gmail dot com 2011-10-20 06:49:19 UTC --- (In reply to comment #17) Author: burnus Date: Wed Oct 19 17:27:03 2011 New Revision: 180199 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180199 Log: 2011-10-19 Janne Blomqvist j...@gcc.gnu.org Kai Tietz kti...@redhat.com Tobias Burnus bur...@net-b.de PR fortran/50016 * io/unix.h (flush_sync): Add new libgfortran-internal * prototype. * io/unix.c (flush_sync): New function, which calls sflush and on MinGW(-w64) also _commit. (flush_all_units, flush_all_units_1): Replace sflush/_commit by flush_sync. * io/file_pos.c (st_flush): Replace sflush/_commit by * flush_sync. * io/intrinsics.c (flush_i4, flush_i8): Ditto. Modified: branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/io/file_pos.c branches/gcc-4_6-branch/libgfortran/io/intrinsics.c branches/gcc-4_6-branch/libgfortran/io/unix.c branches/gcc-4_6-branch/libgfortran/io/unix.h Will the rev 180199 merge into gcc4.6.2 release? Because the first 4.6.2 RC doesn't contain the modify, gcc-4.6.2-RC-20111019 libgfortran build on mingw/mingw64 can cause: libtool: compile: i686-w64-mingw32-gcc -L/mingw/i686-w64-mingw32/lib -L/mingw/mingw/lib -isystem /mingw/i686-w64-mingw32/include -isystem /mingw/mingw/include -DHAVE_CONFIG_H -I. -I../.././libgfortran -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../.././libgfortran/../libquadmath -I../../host-i686-w64-mingw32/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -pipe -O2 -I/mingw/include -MT file_pos.lo -MD -MP -MF .deps/file_pos.Tpo -c ../.././libgfortran/io/file_pos.c -o file_pos.o ../.././libgfortran/io/file_pos.c: In function 'st_flush': ../.././libgfortran/io/file_pos.c:457:20: error: 'stream' has no member named 'fd' I would hope the next 4.6.2 RC or release fix the problem. Thanks.
[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app. -fvisibility=hidden does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-20 07:27:30 UTC --- no side effects for the time being. I've tried only small applications though. I would suggest to rename --disable-visibility --disable-std-visibility or similar as, applied to top level configure, it is not very informative about its semantics
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20 07:36:40 UTC --- For me the trunk with vectorization is certainly faster than 4.3, it is true that 4.6 is slower. 4.3 -O3 -ffast-math 0m0.144s 4.3 -O3 -ffast-math -fno-tree-vectorize 0m0.167s 4.6 -O3 -ffast-math 0m0.194s 4.6 -O3 -ffast-math -fno-tree-vectorize 0m0.195s 4.6 -O3 -ffast-math -mavx 0m0.181s trunk -O3 -ffast-math 0m0.127s trunk -O3 -ffast-math -fno-tree-vectorize 0m0.176s trunk -O3 -ffast-math -mavx 0m0.071s
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855 --- Comment #24 from rguenther at suse dot de rguenther at suse dot de 2011-10-20 07:43:44 UTC --- On Wed, 19 Oct 2011, pinskia at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855 --- Comment #23 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-19 19:10:38 UTC --- The other way to handle this is to allow unswitch loops to handle non inner loops which from what I can tell is a two line patch. Though unswitching is too late for loop invariant motion to work here.
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20 07:57:10 UTC --- BTW, 4.6 numbers can be improved to the trunk numbers by applying http://gcc.gnu.org/viewcvs?root=gccview=revrev=179460 (aka a subset of Eric's r179165 change) - C++ references here prevent the vectorization of one of the loops.
[Bug debug/50806] New: dwarf2out crash: missing GTY?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50806 Bug #: 50806 Summary: dwarf2out crash: missing GTY? Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com Target: x86_64-unknown-linux-gnu Created attachment 25560 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25560 Fix. With custom patched dwarf2out.c I got a crash on memory mangled by the garbage collector. With patched GTY there the crash no longer happened - but I do not have a reproducer anymore, sorry if it is a bogus patch. The memory corrupted later was initially allocated and stored into mem_loc_result-dw_loc_oprnd1.v.val_loc. I do not think there is any other reference to it than that field with no GTY. GIT 33e7b55c2549d655d88ec64c06c51912d0d07527 gcc (GCC) 4.7.0 20111002 (experimental) 11900 mem_loc_result-dw_loc_oprnd1.v.val_loc = op0; (gdb) bt #0 mem_loc_descriptor (rtl=, mode=SImode, mem_mode=VOIDmode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:11900 #1 in loc_descriptor (rtl=, mode=SImode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12790 #2 in loc_descriptor (rtl=, mode=SImode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12614 #3 in dw_loc_list_1 (loc=, varloc=, want_address=2, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12889 #4 in dw_loc_list (loc_list=, decl=, want_address=2) at gcc/dwarf2out.c:13145 #5 in loc_list_from_tree (loc=, want_address=2) at gcc/dwarf2out.c:13538 #6 in add_location_or_const_value_attribute (die=, decl=, cache_p=0 '\000', attr=DW_AT_location) at gcc/dwarf2out.c:15048 #7 in gen_formal_parameter_die (node=, origin=0x0, emit_name_p=1 '\001', context_die=) at gcc/dwarf2out.c:16804 #8 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19632 #9 in gen_subprogram_die (decl=, context_die=) at gcc/dwarf2out.c:17560 #10 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19545 #11 in dwarf2out_decl (decl=) at gcc/dwarf2out.c:19919 #12 in dwarf2out_function_decl (decl=) at gcc/dwarf2out.c:19927 #13 in rest_of_handle_final () at gcc/final.c:4252 #14 in execute_one_pass (pass=0x4dbe120) at gcc/passes.c:2064 #15 in execute_pass_list (pass=0x4dbe120) at gcc/passes.c:2119 #16 in execute_pass_list (pass=0x4dbef00) at gcc/passes.c:2120 #17 in execute_pass_list (pass=0x4dbeea0) at gcc/passes.c:2120 #18 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420 #19 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803 #20 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862 #21 in cgraph_optimize () at gcc/cgraphunit.c:2133 #22 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310 #23 in c_write_global_declarations () at gcc/c-decl.c:9936 #24 in compile_file () at gcc/toplev.c:581 #25 in do_compile () at gcc/toplev.c:1925 #26 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001 #27 in main (argc=101, argv=) at gcc/main.c:36 It was later freed (watchpoint hit) by: (gdb) bt #0 __memset_sse2 () at ../sysdeps/x86_64/memset.S:333 #1 in poison_pages () at gcc/ggc-page.c:1845 #2 in ggc_collect () at gcc/ggc-page.c:1938 #3 in execute_todo (flags=2) at gcc/passes.c:1763 #4 in execute_one_pass (pass=0x4dbce80) at gcc/passes.c:2087 #5 in execute_pass_list (pass=0x4dbce80) at gcc/passes.c:2119 #6 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420 #7 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803 #8 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862 #9 in cgraph_optimize () at gcc/cgraphunit.c:2133 #10 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310 #11 in c_write_global_declarations () at gcc/c-decl.c:9936 #12 in compile_file () at gcc/toplev.c:581 #13 in do_compile () at gcc/toplev.c:1925 #14 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001 #15 in main (argc=101, argv=) at gcc/main.c:36 And later it crashed on the mangled memory.
[Bug bootstrap/50801] macro location tracking patch set breaks bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 --- Comment #3 from dodji at seketeli dot org dodji at seketeli dot org 2011-10-20 08:05:18 UTC --- Patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01821.html
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #8 from Michael Matz matz at gcc dot gnu.org 2011-10-20 08:14:45 UTC --- Andi, the patch you bisected transformed a pre-existing bug into a segfault. Reverting it wouldn't fix anything. You could try the stab-in-the-dark patch from PR50741, but if that doesn't help I don't see how to make progress here without somebody who sees the problem to go into gdb and do a 'p debug_tree(var)' on a cc1 that has enough debuginfo for var to still contain a useful value.
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-20 08:19:28 UTC --- Ah great. Then I wonder if at this point we couldn't even resolve this..
[Bug c++/45385] missing -Wconversion for method calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45385 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-20 08:19:05 UTC --- There is a check in c-common.c:conversion_warning that tests for things generated by the compiler by looking for artificial operands. The implicit *this pointer is probably triggering here. One could test for *this or perhaps there is a better way to check for compiler-generated expressions (if you remove the check, you should trigger a regression in the testsuite).
[Bug bootstrap/50801] macro location tracking patch set breaks bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-10-20 08:21:18 UTC --- I can confirm that this patch fixes the problem I was seeing on SPU as well.
[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app. -fvisibility=hidden does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-20 08:23:01 UTC --- Vincenzo, I agree about the name, yesterday had the same thought. Then we have the usual annoyances with configure options and switches, we normally don't want to just rename in order to not break build systems, scripts, etc. I'll see what we can do, ideally add an alias and deprecate the old one.
[Bug c++/45333] Include macros in instantiation backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333
--- Comment #2 from dodji at seketeli dot org dodji at seketeli dot org
2011-10-20 08:25:20 UTC ---
Yes, it's related. With the infrastructure that is in right now, the
results are not super for template instantiate backtraces though:
$ cat -n test.cc
1#define ZERO(c) c.set(0)
2
3struct S
4{
5 int a;
6 int b;
7};
8
9template class T
10class C
11{
12 T t;
13
14public:
15 void set(int x) { t = x; }
16};
17
18void foo(CS c)
19{
20 ZERO(c);
21}
22
23
24
$
When cc1plus -quiet -ftrack-macro-expansion ./test.cc yields:
test.cc: In instantiation of ‘void CT::set(int) [with T = S]’:
test.cc:1:24: required from here
test.cc:15:21: erreur: no match for ‘operator=’ in ‘((CS*)this)-CS::t = x’
test.cc:15:21: note: candidate is:
test.cc:3:8: note: S S::operator=(const S)
test.cc:3:8: note: no known conversion for argument 1 from ‘int’ to ‘const
S’
So it points to the spelling location (1:24) of the token involved in
the error message, rather than to the expansion point of the macro. I'd
like it to mention both, like it does for the C FE.
Beside fixing the various bootstrap breakages I have introduced, I'll
need to go through the template instantiation error message mechanics to
teach them how to use the new macro token tracking infrastructure, I
guess. :-)
At least we have the infrastructure now.
Thank you for the head-up.
[Bug c++/45385] missing -Wconversion for method calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45385 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-20 08:27:38 UTC --- Thanks a lot. If I understand correctly this is a regression affecting a very sensible warning which we want to fix for 4.7, at least. We should mark it as such.
[Bug c++/45333] Include macros in instantiation backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-20 08:32:40 UTC --- With -ftrack-macro-expansion we get: pr45333.cc: In instantiation of ‘void CT::set(int) [with T = S]’: pr45333.cc:1:24: required from here pr45333.cc:15:21: error: no match for ‘operator=’ in ‘((CS*)this)-CS::t = x’ pr45333.cc:15:21: note: candidate is: pr45333.cc:3:8: note: S S::operator=(const S) pr45333.cc:3:8: note: no known conversion for argument 1 from ‘int’ to ‘const S’ So we can track the origin of the instantation to the macro definition, but then we don't show where the macro is invoked from, which is shown without -ftrack-macro-expansion. I think it should show both, like clang does: pr45333.cc: In instantiation of ‘void CT::set(int) [with T = S]’: pr45333.cc:1:19: instantiated from macro ZERO pr45333.cc:20:3: required from here pr45333.cc:15:21: error: no match for ‘operator=’ in ‘((CS*)this)-CS::t = x’ pr45333.cc:15:21: note: candidate is: pr45333.cc:3:8: note: S S::operator=(const S) pr45333.cc:3:8: note: no known conversion for argument 1 from ‘int’ to ‘const S’ Notice that in my ideal output, I also fixed the location given for the first instantation to point to set (1:19) and not to the end of the line (1:24).
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20 08:42:55 UTC --- Certainly not right now, this isn't a kind of change that should be added in between 4.6.2-RC and 4.6.2. Maybe later.
[Bug target/50781] ICE: in expand_vec_perm_broadcast_1, at config/i386/i386.c:35998 with -mavx and __builtin_shuffle()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50781 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20 08:54:33 UTC --- This ought to be fixed on the current trunk.
[Bug c++/45333] Include macros in instantiation backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333 --- Comment #4 from dodji at seketeli dot org dodji at seketeli dot org 2011-10-20 08:57:06 UTC --- So we can track the origin of the instantation to the macro definition, but then we don't show where the macro is invoked from, which is shown without -ftrack-macro-expansion. I think it should show both, like clang does Agreed. Notice that in my ideal output, I also fixed the location given for the first instantation to point to set (1:19) and not to the end of the line (1:24). Agreed again. I suspect this is related to our (ab)use of the global input_location instead of relying on the precise location of the tokens we are dealing with. So I guess it'll take some iterations to generally get this right, as you know already.
[Bug target/50396] SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 --- Comment #1 from Mathias Gaunard mathias at gaunard dot com 2011-10-20 08:58:19 UTC --- This bug has stayed as unconfirmed for a while. Is there anything that I could do to help?
[Bug testsuite/50803] [4.7 Regression] FAIL: gcc.dg/ipa/inline-5.c scan-ipa-dump-times inline Will be eliminated 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50803 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Component|tree-optimization |testsuite CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 Target Milestone|--- |4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-20 09:00:20 UTC --- Callee-copy thing. Consider XFAILing for your target.
[Bug middle-end/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug debug/50806] dwarf2out crash: missing GTY?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50806 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20 09:03:23 UTC --- Patches should be posted to gcc-patches mailing list.
[Bug tree-optimization/50805] [4.7 Regression] FAIL: gcc.dg/tree-ssa/builtin-expect-[1-4].c scan-tree-dump-times gimple builtin_expect[^\n]*, 0\);\n[^\n]*if 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50805 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-20 09:04:33 UTC --- dup *** This bug has been marked as a duplicate of bug 50795 ***
[Bug middle-end/50795] [4.7 Regression] FAIL: gcc.dg/tree-ssa/builtin-expect-[1234].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50795 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-20 09:04:33 UTC --- *** Bug 50805 has been marked as a duplicate of this bug. ***
[Bug middle-end/50795] [4.7 Regression] FAIL: gcc.dg/tree-ssa/builtin-expect-[1234].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50795 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-20 09:07:36 UTC --- Author: ramana Date: Thu Oct 20 09:07:30 2011 New Revision: 180240 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180240 Log: 2011-10-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/50106 * config/arm/arm.c (thumb_unexpanded_epilogue): Handle return reg size from 1-3. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug bootstrap/50801] macro location tracking patch set breaks bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-20 09:05:20 UTC --- fixed.
[Bug rtl-optimization/50396] SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Component|target |rtl-optimization Version|unknown |4.7.0 Ever Confirmed|0 |1 Known to fail||4.5.2, 4.7.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-20 09:11:06 UTC --- Confirmed. Broken by CSE1 on RTL at -O1.
[Bug c++/45333] Include macros in instantiation backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-20 09:11:42 UTC --- (In reply to comment #4) Agreed again. I suspect this is related to our (ab)use of the global input_location instead of relying on the precise location of the tokens we are dealing with. So I guess it'll take some iterations to generally get this right, as you know already. Indeed. I must say it is superb that the infrastructure is there already, once this is a bit more stable, so many new things are possible. You should put a big item in http://gcc.gnu.org/gcc-4.7/changes.html, and some announcement in News: Diagnostics in C++ have been significantly improved for 4.7: (1) The reasons for overload and lookup failure are now detailed described (thanks to the work of Nathan Froyd) (2) GCC is able to track macro expansions to provide more accurate locations in diagnostics (thanks to the work of Dodji Seketeli), and (3) Several hundreds of bugs related to diagnostics have been fixed for 4.7 (thanks to the work of Paolo Carlini and other contributors).
[Bug rtl-optimization/50396] SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-20
09:13:21 UTC ---
case DIV:
/* Handle floating point and integers separately. */
if (SCALAR_FLOAT_MODE_P (mode))
{
should probably be FLOAT_MODE_P (mode).
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #6 from dodji at seketeli dot org dodji at seketeli dot org 2011-10-20 09:15:31 UTC --- FWIW, this is maybe related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 that got fixed in commit r180239
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-20 09:24:10 UTC --- Author: ramana Date: Thu Oct 20 09:24:06 2011 New Revision: 180241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180241 Log: Backport from mainline fix for PR target/50106. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.c
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-20 09:25:10 UTC --- Fixed now I think.
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #7 from dodji at seketeli dot org dodji at seketeli dot org 2011-10-20 09:26:31 UTC --- I can give you access to my (slowww) G5 if you mail me your ssh key. Thank you for giving me access to the box.
[Bug target/49485] [4.6 Regression] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Summary|Performance problem with|[4.6 Regression] |C++ code|Performance problem with ||C++ code Ever Confirmed|0 |1 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-20 09:27:32 UTC --- Of course, assuming you actually mean to backport something. Thanks again.
[Bug target/50807] New: [avr]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50807 Bug #: 50807 Summary: [avr] Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: eric.wedding...@atmel.com Target: avr The following line of code const char __attribute__((progmem)) var = Hallo[0]; compileds with avr-g++ progmem.c -S -Os compiles code that tries to initialize var at run time: .section.text.startup,ax,@progbits .type_GLOBAL__sub_I_progmem.c, @function _GLOBAL__sub_I_progmem.c: ldi r24,lo8(72) sts _ZL3var,r24 ret .size_GLOBAL__sub_I_progmem.c, .-_GLOBAL__sub_I_progmem.c .global __do_global_ctors .section .ctors,a,@progbits .wordgs(_GLOBAL__sub_I_progmem.c) .local_ZL3var .comm_ZL3var,1,1 As var is located in flash and thus cannot be initialized at runtime, there should be an error message like progmem variable var cannot be initialized at load time.
[Bug debug/50806] dwarf2out crash: missing GTY?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50806 --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-10-20 10:15:27 UTC --- OK, thanks, posted: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01850.html
[Bug target/50807] [avr]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50807 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Target Milestone|--- |4.6.2 Ever Confirmed|0 |1 Known to fail||4.6.2, 4.7.0 Severity|normal |minor --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-20 10:16:37 UTC --- Confirmed with 4.6.2 The generated code is a bit different. var is put into the correct section .progmem but there is no error and the constructor will write to RAM: .section.text.startup,ax,@progbits .type_GLOBAL__sub_I_progmem.c, @function _GLOBAL__sub_I_progmem.c: ldi r24,lo8(72) sts _ZL3var,r24 ret .size_GLOBAL__sub_I_progmem.c, .-_GLOBAL__sub_I_progmem.c .global __do_global_ctors .section .ctors,a,@progbits .wordgs(_GLOBAL__sub_I_progmem.c) .section.progmem.data,a,@progbits .type_ZL3var, @object .size_ZL3var, 1 _ZL3var: .skip 1,0
[Bug middle-end/50808] New: Diagnostic output at expansion time should be moved earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50808 Bug #: 50808 Summary: Diagnostic output at expansion time should be moved earlier. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org We output a lot of errors and warnings at exapnsion time, especially when dealing with builtins. This should be moved to after early optimization so it is consistently output with LTO. Some testcases needs fat LTO for this prupose right now: * lib/lto.exp (lto_init): Test slib lto and no-liker-plugin path. * lto/gcc-dg.exp (check_effective_target_lto): Likewise. * lto/c-torture.exp: Likewise. * execute/bultins/strstr-asm.c: Force fat LTO. * gcc.c-torture/compile/sync-1.c: Likewise. * gcc.c-torture/compile/sync-1.c: Likewise. * gcc.c-torture/compile/sync-3.c: Likewise. * gcc.dg/noncompile/invalid_asm.c: Likewise. * gcc.dg/noncompile/920507-1.c: Likewise. * gcc.dg/torture/pr36400.c: Likewise. * g++.dg/torture/pr34850.C: Likewise.
[Bug middle-end/50808] Diagnostic output at expansion time should be moved earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50808 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/50808] Diagnostic output at expansion time should be moved earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50808 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-20 10:24:22 UTC --- All builtin warning related stuff needs to go to check_builtin_function_arguments and friends.
[Bug debug/50806] dwarf2out crash: missing GTY?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50806 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-10-20 10:29:58 UTC --- Rejected by mail and I have no reproducer.
[Bug middle-end/50808] Diagnostic output at expansion time should be moved earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50808 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-20 10:52:49 UTC --- I think we have already in Bugzilla an old PR about a related issue, for a specific warning.
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106
--- Comment #11 from Sebastian Huber sebastian.hu...@embedded-brains.de
2011-10-20 11:07:09 UTC ---
Thank you very much. With this change the GCC 4.6.2-RC-20111019 produces now
correct code in this case.
I know understand why the unused volatile registers are saved and restored.
This is to get rid of the arithmetic stack adjustments.
--- test.Os.GCC-4.5.s 2011-10-20 13:04:15.384638860 +0200
+++ test.Os.GCC-4.6.s 2011-10-20 13:04:15.396639237 +0200
@@ -17,32 +17,29 @@
.thumb_func
.type _GetIDS, %function
_GetIDS:
- push{lr}
- ldr r2, .L4
- sub sp, sp, #12
- ldr r2, [r2]
- mov r3, r0
+ push{r0, r1, r2, lr}
+ ldr r3, .L4
ldr r1, .L4+4
- add r0, sp, #4
- cmp r3, r2
+ ldr r3, [r3]
+ cmp r0, r3
bge .L2
- lsl r3, r3, #1
- add r1, r1, r3
+ lsl r0, r0, #1
+ add r1, r1, r0
.L2:
mov r2, #2
+ add r0, sp, #4
bl memcpy
add r3, sp, #4
ldrbr0, [r3, #1]
ldrbr2, [r3]
lsl r0, r0, #8
- add sp, sp, #12
- orr r0, r0, r2
+ orr r0, r2
@ sp needed for prologue
- pop {pc}
+ pop {r1, r2, r3, pc}
.L5:
.align 2
.L4:
.word _LIST_SIZE
.word _List
.size _GetIDS, .-_GetIDS
- .ident GCC: (GNU) 4.5.4 20111013 (prerelease)
+ .ident GCC: (GNU) 4.6.2 20111019 (prerelease)
[Bug middle-end/50808] Diagnostic output at expansion time should be moved earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50808 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20 11:41:44 UTC --- E.g. for warning/error attribute it is very much intentional it is reported as late as possible.
[Bug other/50759] [4.7 Regression] @table ended by @end quotation at line 595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50759 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-20 Ever Confirmed|0 |1
[Bug bootstrap/50709] [4.7 Regression] stage3 bootstrap comparison failure with --disable-checking config option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50709 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-20 11:46:11 UTC --- Author: hubicka Date: Thu Oct 20 11:46:08 2011 New Revision: 180247 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180247 Log: PR bootstrap/50709 * ipa-inline.c (inline_small_functions): Fix checking code to not make effect on fibheap stability. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug other/50759] [4.7 Regression] @table ended by @end quotation at line 595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50759
--- Comment #2 from dodji at seketeli dot org dodji at seketeli dot org
2011-10-20 11:48:24 UTC ---
It looks like support for @quotation/@end quotation pairs needs adding to
texi2pod.pl.
That, or I could just use @smallexample/@end smallexample as in the
other places of the documentation.
I am about to commit the below to trunk as obvious.
Use @smallexample instead of @quotation in cppopts.texi
gcc/
* doc/cppopts.texi: Use @smallexample/@end smallexample in
documentation for -fdebug-cpp instead of @quotation/@end quotation
that is not supported by contrib/texi2pod.pl.
diff --git a/gcc/doc/cppopts.texi b/gcc/doc/cppopts.texi
index ef3a0b2..6c70a0a 100644
--- a/gcc/doc/cppopts.texi
+++ b/gcc/doc/cppopts.texi
@@ -590,9 +590,9 @@ This option is only useful for debugging GCC. When used
with
token in the output is preceded by the dump of the map its location
belongs to. The dump of the map holding the location of a token would
be:
-@quotation
+@smallexample
@{@samp{P}:@file{/file/path};@samp{F}:@file{/includer/path};@samp{L}:@var{line_num};@samp{C}:@var{col_num};@samp{S}:@var{system_header_p};@samp{M}:@var{map_address};@samp{E}:@var{macro_expansion_p},@samp{loc}:@var{location}@}
-@end quotation
+@end smallexample
When used without @option{-E}, this option has no effect.
[Bug fortran/50659] [4.4/4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 --- Comment #17 from Dodji Seketeli dodji at gcc dot gnu.org 2011-10-20 12:37:02 UTC --- Author: dodji Date: Thu Oct 20 12:36:55 2011 New Revision: 180250 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180250 Log: Use @smallexample instead of @quotation in cppopts.texi gcc/ PR other/50659 * doc/cppopts.texi: Use @smallexample/@end smallexample in documentation for -fdebug-cpp instead of @quotation/@end quotation that is not supported by contrib/texi2pod.pl. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/cppopts.texi
[Bug other/50759] [4.7 Regression] @table ended by @end quotation at line 595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50759 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dodji Seketeli dodji at gcc dot gnu.org 2011-10-20 13:18:17 UTC --- Fixed by commit r180101
[Bug target/50809] New: driver-arm.c:55:11: error: anonymous type with no linkage used to declare variable 'anonymous struct vendors []' with linkage [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50809 Bug #: 50809 Summary: driver-arm.c:55:11: error: anonymous type with no linkage used to declare variable 'anonymous struct vendors []' with linkage [-Werror] Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: armv5tejl-unknown-linux-gnueabi Target: armv5tejl-unknown-linux-gnueabi Build: armv5tejl-unknown-linux-gnueabi /home/dave/gnu/gcc/objdir/./prev-gcc/g++ -B/home/dave/gnu/gcc/objdir/./prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.7/armv5tejl-unknown-linux-gnueabi/bin/ -nostdinc ++ -B/home/dave/gnu/gcc/objdir/prev-armv5tejl-unknown-linux-gnueabi/libstdc++-v3 /src/.libs -B/home/dave/gnu/gcc/objdir/prev-armv5tejl-unknown-linux-gnueabi/libs tdc++-v3/libsupc++/.libs -I/home/dave/gnu/gcc/objdir/prev-armv5tejl-unknown-linu x-gnueabi/libstdc++-v3/include/armv5tejl-unknown-linux-gnueabi -I/home/dave/gnu/ gcc/objdir/prev-armv5tejl-unknown-linux-gnueabi/libstdc++-v3/include -I/home/dav e/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/home/dave/gnu/gcc/objdir/prev-armv5tejl- unknown-linux-gnueabi/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/prev-ar mv5tejl-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/dave/opt/gnu/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/dave/opt/gnu/include -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/dave/opt/gnu/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/config/arm/driver-arm.c ../../gcc/gcc/config/arm/driver-arm.c:55:11: error: anonymous type with no linkage used to declare variable 'anonymous struct vendors []' with linkage [-Werror] cc1plus: all warnings being treated as errors -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: armv5tejl-unknown-linux-gnueabi Configured with: ../gcc/configure --enable-languages=c,c++,fortran,objc,obj-c++ --enable-checking=release --enable-shared --enable-threads --disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch --prefix=/home/dave/opt/gnu/gcc/gcc-4.7 --with-gmp=/home/dave/opt/gnu --with-as=/home/dave/opt/gnu/bin/as --with-ld=/home/dave/opt/gnu/bin/ld Thread model: posix gcc version 4.7.0 20111019 (experimental) [trunk revision 180200] (GCC)
[Bug c++/50810] New: c++0x-compat does not warn about narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50810
Bug #: 50810
Summary: c++0x-compat does not warn about narrowing conversions
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following program is rejected by g++ in -std=c++0x mode (assuming 'char' is
signed) but does not raise any warnings when compiled with -Wc++0x-compat:
int main() {
char data[] = { 0xff };
char value = 0xff;
}
This is significantly the largest source of compatibility errors in our
code-base today (95% of our known issues), so it would be very useful if the
warning caught these.
[Bug c++/50810] c++0x-compat does not warn about narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50810 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-20 13:55:02 UTC --- (In reply to comment #0) This is significantly the largest source of compatibility errors in our code-base today yep, same here
[Bug target/50719] segmentation fault when attempting to build libav with gcc trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50719 Sean McGovern gseanmcg at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Sean McGovern gseanmcg at gmail dot com 2011-10-20 13:56:44 UTC --- Closing as INVALID, this issue was likely fallout from other problems on this target.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-20 14:05:49 UTC --- Previously the builds produced working code. Now they just segfault. If I revert the patches (plus the ones depending on it) I get working code again. In my book that's a fix. I don't know what the bug was, but it can't be worth ICEing instead.
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #8 from Iain Sandoe iains at gcc dot gnu.org 2011-10-20 14:29:12 UTC --- Unfortunately, as of r180241, I still have the bootstrap fail in building libgfortran (Java untested) and the ICEs in struct-layout-1.
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #5 from Eric Weddington eric.weddington at atmel dot com 2011-10-20 14:36:01 UTC --- Hi Johann, I would prefer if the name of the address space for program memory be named __flash so that way it is the same name as what the IAR compiler uses. Using the same name as the IAR compiler assists users who wish to migrate from the IAR to the GCC toolchains. Like so: + c_register_addr_space (__flash, ADDR_SPACE_PGM);
[Bug c++/50811] New: G++ rejects class-virt-specifier if class-head-name includes nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
Bug #: 50811
Summary: G++ rejects class-virt-specifier if class-head-name
includes nested-name-specifier
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
namespace B {
struct C;
};
struct B::C final { };
f.C:5:13: error: variable 'B::C final' has initializer but incomplete type
[Bug target/47989] -mrecip causes 482.sphinx3, 464.h264ref and 481.wrf to miscompare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47989 --- Comment #4 from uros at gcc dot gnu.org 2011-10-20 15:13:39 UTC --- Author: uros Date: Thu Oct 20 15:13:30 2011 New Revision: 180256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180256 Log: PR target/47989 * config/i386/i386.h (RECIP_MASK_DEFAULT): New define. * config/i386/i386.op (recip_mask): Initialize with RECIP_MASK_DEFAULT. * doc/invoke.texi (ix86 Options, -mrecip): Document that GCC implements vectorized single float division and vectorized sqrtf(x) with reciprocal sequence with additional Newton-Raphson step with -ffast-math. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.opt trunk/gcc/doc/invoke.texi
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-20 15:18:51 UTC --- (In reply to comment #5) Hi Johann, I would prefer if the name of the address space for program memory be named __flash so that way it is the same name as what the IAR compiler uses. Using the same name as the IAR compiler assists users who wish to migrate from the IAR to the GCC toolchains. Like so: + c_register_addr_space (__flash, ADDR_SPACE_PGM); I chose __pgm because it is different to __flash. Even though I know nothing about IAR's __flash I can hardly imagine that __pgm does 100% the same. It's implementation defined and using the same identifier would give rise to the incorrect assumption that both imlementations behave exactly the same, which most probably is not the case. Moreover, the problem of 64k flash is not yet addressed. As far as I can see, there are three approches: 1. Don't do anything about it. 2. Implement bunch of ASes like __pgm1, __pgm2 for each 64k chunk. This is easiest to implement and has least side effects on avr back end. These AVRs are segmented architecture and at some points an implementation cannot hide that to the user. This would require changes in default ld script or user would have to supply his own ld script to locate the 64k chunks/sections. 3. Implement thing like __pgmx that is attached to 24 bit address. This is way more complicated because a new machine mode PSI must be supported or else the AS has to hitchhike SImode. When crossing section boundaries ELPM Z+ changes RAMPZ, leading to messy code in the general case. Notice that it is not possible to split additions in the AVR BE because there is still cc0. And there is *no* address register that can hold pointers 16 bits. X cannot because Y might be FP, Y cannot because it might be PF, Z cannot because there is no register R32 whouch would then be RAMPZ. Dunno if treating RAMPZ as GPR instead of as SFR is doable and sane.
[Bug bootstrap/50812] New: libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 Bug #: 50812 Summary: libbid build fails with ICE on bid128_div.c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: fxcoud...@gcc.gnu.org Host: x86_64-apple-darwin11 Target: i586-pc-mingw32 Build: x86_64-apple-darwin11 Created attachment 25561 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25561 Preprocessed source triggering the ICE Building a cross-compiler to i586-pc-mingw32 fails with an ICE while compiling libgcc, or more precisely, libbid's bid128_div.c: ../../../../gcc/trunk/libgcc/config/libbid/bid128_div.c:1851:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1407 The cross-compiler is configured with: ../../gcc/trunk/configure --prefix=/Users/fx/devel/mingw/cross --target=i586-pc-mingw32 --disable-werror --with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 --enable-languages=c,fortran The backtrace of the ICE is: #0 fancy_abort (file=0x100aae258 ../../../gcc/trunk/gcc/ipa-inline.c, line=1407, function=0x100aae9a0 inline_small_functions) at diagnostic.c:897 #1 0x00010056dd1a in ipa_inline () at ipa-inline.c:1407 #2 0x000100617f17 in execute_one_pass (pass=0x100aae258) at passes.c:2064 #3 0x000100618a7c in execute_ipa_pass_list (pass=0x100aae258) at passes.c:2431 #4 0x00010035f89c in ipa_passes [inlined] () at /Users/fx/devel/gcc/trunk/gcc/cgraphunit.c:2061 #5 0x00010035f89c in cgraph_optimize () at cgraphunit.c:2116 #6 0x00010036099f in cgraph_finalize_compilation_unit () at cgraphunit.c:1312 #7 0x0001000157d8 in c_write_global_declarations () at c-decl.c:9940 #8 0x0001006db701 in do_compile [inlined] () at /Users/fx/devel/gcc/trunk/gcc/toplev.c:581 I attach the preprocessed source. The bug is triggered consistently at -O1 and higher optimization. It can be reproduced simply with cc1 -O bid128_div.i
[Bug bootstrap/50812] libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-10-20 15:25:20 UTC --- I should have added that I am using trunk revision 180247.
[Bug target/47989] -mrecip causes 482.sphinx3, 464.h264ref and 481.wrf to miscompare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47989 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg01825.htm ||l Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-10-20 15:29:51 UTC --- We now use reciprocals for vectorized operators by default, see threads at [1], [2] and [3] for the discussion. [1] http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02550.html [2] http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00212.html [3] http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01825.html So, fixed.
[Bug bootstrap/50812] libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-20 15:30:34 UTC --- There is numerous bootstrap failures between revisions 180241 (OK) and 180248 with this ICE (see http://gcc.gnu.org/ml/gcc-regression/2011-10/) .
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #10 from Michael Matz matz at gcc dot gnu.org 2011-10-20 16:15:36 UTC --- Why is it so difficult to just fire up gdb? This all could be solved in a couple of minutes.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #11 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-20 16:30:27 UTC --- I did fire gdb up of course, the output is in the initial report. I also tracked it down to exactly your commit.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20 16:39:15 UTC --- It doesn't contain enough info though. In particular, it would be nice to see p debug_tree (*(tree *)0x2b11d2f00c00) (the first argument for the innermost walk_tree_1) and possibly for the outer one too and maybe track through conditional breakpoint on ggc-page.c ggc_alloc_stat return stmt where the VAR_DECL in it has been created.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #13 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-20 16:44:42 UTC --- I only have a core file. It's really hard to catch the correct lto1 in gdb in a complex LTO build. The only sane way I found to at least get some gdb information is to use -dH and use the corefile. But then calling debug_tree doesn't work of course.
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 --- Comment #1 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-10-20 16:46:29 UTC --- On it. FWIW, I don't get these failures with rev 180136, with or without the patch, and I can't trigger them at 180194 either. Can you get more info on what the failure is (say, debug dumps, asm output, whatever) so I can try to blind-debug it? TIA,
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #14 from kargl at gcc dot gnu.org 2011-10-20 17:10:00 UTC --- Fixed on trunk at revision 180261. Forgot to include PR number in ChangeLog, so commit message won't show up in audit trail.
[Bug fortran/50524] *** glibc detected *** invalid free() pointer on illegal code (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50524 --- Comment #2 from kargl at gcc dot gnu.org 2011-10-20 17:15:23 UTC --- Author: kargl Date: Thu Oct 20 17:15:06 2011 New Revision: 180262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180262 Log: 2011-10-15 Steven G. Kargl ka...@gcc.gcu.org PR fortran/50524 * resolve.c (resolve_ref): Check return value of resolve_substring(). 2011-10-15 Steven G. Kargl ka...@gcc.gcu.org PR fortran/50524 * gfortran.dg/substring_integer_index.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/substring_integer_index.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50524] *** glibc detected *** invalid free() pointer on illegal code (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50524 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from kargl at gcc dot gnu.org 2011-10-20 17:28:19 UTC --- Fixed on trunk. Thanks for the report.
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-10-20 17:30:07 UTC --- I saw them on Fedora 15 with gdb-7.3-43.fc15.x86_64.
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #9 from Iain Sandoe iains at gcc dot gnu.org 2011-10-20 17:44:56 UTC --- This might be the easier one to debug: Running /GCC/gcc-live-trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp ... FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_main_tst.o compile, (internal compiler error) FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o compile, (internal compiler error) FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_y_tst.o compile, (internal compiler error) seems (possibly) to be failing in parsing a system header
[Bug fortran/50514] gfortran should check ISHFT ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from kargl at gcc dot gnu.org 2011-10-20 18:11:33 UTC --- Fixed on trunk for static checking. Runtime checking is not going to happen due to the overhead.
[Bug target/50694] SH Target: SH2A little endian does not actually work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694 --- Comment #7 from Oleg Endo oleg.e...@t-online.de 2011-10-20 18:44:32 UTC --- (In reply to comment #6) (In reply to comment #5) I'll send in a patch with a couple of other cosmetic changes later, OK? Please go for it. ..or maybe just leave it as it is :T The change I was suggesting opens up another problem with multilib and endian config / selection. I think instead of adding / implementing the endian restrictions it would be more useful to expand little endian support in binutils and drop the endian restrictions in gcc altogether once binutils fully support it. What do you think? Would that make more sense in the end?
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-10-20 18:48:13 UTC --- I'm on BLAG 140k/x86_64 (=~ Fedora 14). The fact that the same compiler code works on a similar platform suggests to me that the problem is not in the compiler, but rather in the linker or the debugger. I'm confused as to your report. You wrote Linux/ia32, but it's a GDB for x86_64, which suggests a 64-x-32 build or a 32-bit bootstrap starting with a 64-bit -m32 compiler, or maybe a 32-bit bootstrap compiler on a x86_64 platform. Anyhow, I tried all but the last of these options, to no avail, so I'll leave this alone unless I get more evidence that this is indeed a problem in the compiler, rather than some bug elsewhere that the patch happened to expose. For the record, I've used: gcc-4.5.1-4.fc14.x86_64 (with -m32) glibc-2.14-4.i686 binutils-2.20.51.0.7-8.fc14.x86_64 gdb-7.2-51.fc14.x86_64 and ld.bfd is the linker used by the bootstrap and the built compilers.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #15 from Uros Bizjak ubizjak at gmail dot com 2011-10-20 18:53:12 UTC --- (In reply to comment #14) Fixed on trunk at revision 180261. Forgot to include PR number in ChangeLog, so commit message won't show up in audit trail. This can be solved by copying commit message from gcc-cvs@ ML by hand. Like ... this: Author: kargl Date: Thu Oct 20 17:04:53 2011 New Revision: 180261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180261 Log: 2011-10-16 Steven G. Karglka...@gcc.gnu.org * io.c (match_dt_format): Match a user-defined operator or a kind type prefixed string. 2011-10-16 Steven G. Karglka...@gcc.gnu.org * gfortran.dg/format_string.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/format_string.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug c++/41449] Partial aggregate initialization not cleaned up on exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41449 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/41449] Partial aggregate initialization not cleaned up on exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41449 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-10-20 19:13:54 UTC --- Author: jason Date: Thu Oct 20 19:13:51 2011 New Revision: 180267 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180267 Log: PR c++/41449 * typeck2.c (split_nonconstant_init_1): Handle EH cleanup of initialized subobjects. Added: trunk/gcc/testsuite/g++.dg/eh/partial1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 --- Comment #4 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-10-20 19:15:51 UTC --- Just tried with ld.gold instead, still no failure.
[Bug c++/41449] Partial aggregate initialization not cleaned up on exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41449 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-10-20 19:18:56 UTC --- Fixed for 4.7.
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-10-20 19:24:55 UTC --- You should try gdb 7.3 to see if it makes a difference.
[Bug target/50572] unstable performance on Atom due to loop alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50572 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-10-20 19:29:57 UTC --- Author: hjl Date: Thu Oct 20 19:29:52 2011 New Revision: 180268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180268 Log: Change Atom align_loops_max_skip to 15. 2011-10-20 Sergey Ostanevich sergos@gmail.com PR target/50572 * config/i386/i386.c (processor_target_table): Change Atom align_loops_max_skip to 15. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/50813] New: gcc.dg/torture/vshuf-{v4di,v8si}.c fail on AVX target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50813
Bug #: 50813
Summary: gcc.dg/torture/vshuf-{v4di,v8si}.c fail on AVX target
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
CC: ja...@gcc.gnu.org, r...@gcc.gnu.org
Target: x86-avx
Recent failure on AVX targets [1].
These two testcases try to generate avx2_permv2ti insn, which is disabled on
non-AVX2 targets:
(define_insn avx2_permv2ti
[(set (match_operand:V4DI 0 register_operand =x)
(unspec:V4DI
[(match_operand:V4DI 1 register_operand x)
(match_operand:V4DI 2 nonimmediate_operand xm)
(match_operand:SI 3 const_0_to_255_operand n)]
UNSPEC_VPERMTI))]
TARGET_AVX2
vperm2i128\t{%3, %2, %1, %0|%0, %1, %2, %3}
[(set_attr type sselog)
(set_attr prefix vex)
(set_attr mode OI)])
The pattern is generated through ix86_vectorize_builtin_vec_perm_ok via:
Breakpoint 1, gen_avx2_permv2ti (operand0=0x715862e0,
operand1=0x715862a0, operand2=0x715862c0, operand3=0x71997670)
at insn-emit.c:14480
14480{
(gdb) bt
#0 gen_avx2_permv2ti (operand0=0x715862e0, operand1=0x715862a0,
operand2=0x715862c0, operand3=0x71997670) at insn-emit.c:14480
#1 0x00adca70 in expand_vec_perm_even_odd_1 (d=0x7fffdda0, odd=0)
at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:36132
#2 0x00adcdda in expand_vec_perm_even_odd (d=0x7fffdda0)
at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:36201
#3 0x00add743 in ix86_expand_vec_perm_builtin_1 (d=0x7fffdda0)
at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:36456
#4 0x00adecdc in ix86_vectorize_builtin_vec_perm_ok (
vec_type=0x71ac65e8, mask=0x71b132a0)
at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:36776
#5 0x007c89a3 in can_vec_perm_expr_p (type=0x71ac65e8,
sel=0x71b132a0) at /home/uros/gcc-svn/trunk/gcc/optabs.c:6717
[1] http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg02319.html
[Bug target/50813] gcc.dg/torture/vshuf-{v4di,v8si}.c fail on AVX target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50813 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-10-20 19:45:44 UTC --- The failure manifests as: In file included from vshuf-v4di.c:14:0: vshuf-main.inc: In function ‘test_16’: vshuf-main.inc:28:1: error: unrecognizable insn: (insn 36 39 37 3 (set (reg:V4DI 99) (unspec:V4DI [ (reg:V4DI 66 [ a.8 ]) (reg:V4DI 98) (const_int 32 [0x20]) ] UNSPEC_VPERMTI)) vshuf-main.inc:28 -1 (nil)) vshuf-main.inc:28:1: internal compiler error: in extract_insn, at recog.c:2137 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -O2 -mavx
[Bug target/50813] gcc.dg/torture/vshuf-{v4di,v8si}.c fail on AVX target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50813
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-20
19:52:45 UTC ---
Strange, wonder how I've missed this.
I guess easiest would be probably just to
if (!TARGET_AVX2)
{
struct expand_vec_perm_d d_copy = *d;
d_copy.target = gen_lowpart (V{4DF,8SF}mode, d-target);
d_copy.op0 = gen_lowpart (V{4DF,8SF}mode, d-op0);
d_copy.op1 = gen_lowpart (V{4DF,8SF}mode, d-op1);
return expand_vec_perm_even_odd_1 (d_copy);
}
for V{4DI,8SI}mode. Or if (!TARGET_AVX2) return false;.
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 --- Comment #6 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-10-20 19:57:41 UTC --- What kind of error are you getting from gdb 7.3? Since 7.2 is getting the correct info, that's the bug report that ought to be submitted to GDB.
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #3 from Mathias Gaunard mathias at gaunard dot com 2011-10-20 20:07:24 UTC --- Created attachment 25562 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25562 Reduced testcase Original testcase reduced using automated delta tools
[Bug bootstrap/50812] libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||jh at suse dot cz --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-10-20 20:25:44 UTC --- So it's not mingw-specific, it's a full i686/x86_64 bootstrap failure. This seems due to either of these two patches: 2011-10-19 Jan Hubicka j...@suse.cz * ipa-inline.c (inline_small_functions): Always update all calles after inlining. 2011-10-19 Jan Hubicka j...@suse.cz PR bootstrap/50709 * ipa-inline.c (inline_small_functions): Fix checking code to not make effect on fibheap stability.
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 --- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-10-20 20:37:37 UTC --- Author: hjl Date: Thu Oct 20 20:37:32 2011 New Revision: 180271 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180271 Log: Fix operands order in BMI2 patterns. gcc/ 2011-10-20 Kirill Yukhin kirill.yuk...@intel.com PR target/50766 * config/i386/i386.md (bmi_bextr_mode): Update register/ memory operand order. (bmi2_bzhi_mode3): Ditto. (bmi2_pdep_mode3): Ditto. (bmi2_pext_mode3): Ditto. gcc/testsuite/ 2011-10-20 Kirill Yukhin kirill.yuk...@intel.com PR target/50766 * gcc.target/i386/pr50766.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr50766.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org |
[Bug target/50814] New: SH Target: SHAD / SHLD instructions not used on SH2A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
Bug #: 50814
Summary: SH Target: SHAD / SHLD instructions not used on SH2A
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh2a-*-*
Although there are some insns (e.g. ashlsi3_sh2a) that are supposed to handle
dynamic shifts on SH2A, somehow the dynamic shift instructions SHAD and SHLD
are never generated, no matter what the shift amount is.
int x_shad_right (int y)
{
return y 15;
}
mov.l.L6,r1
sts.lpr,@-r15
jsr@r1
nop
movr4,r0
lds.l @r15+,pr
rts/n
.align 2
.L6:
.long___ashiftrt_r4_15
int x_shad_left (int y)
{
return y 15;
}
movr4,r0
shll8r0
shlrr0
rts
shll8r0
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20111020 (experimental) (GCC)
It is also not clear to me why SH2A seems to require different handling for
dynamic shifts than SH3 or SH4...
[Bug bootstrap/50812] libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-20 20:50:16 UTC --- AFAICT this is now fixed (probably r180249): Author:hubicka Date:Thu Oct 20 12:18:56 2011 UTC (8 hours, 29 minutes ago) Changed paths:2 Log Message: * ipa-inline.c (inline_small_functions): Always update all calles after inlining.
[Bug debug/50799] [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50799 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-10-20 21:04:59 UTC --- (In reply to comment #6) What kind of error are you getting from gdb 7.3? Since 7.2 is getting the correct info, that's the bug report that ought to be submitted to GDB. My understanding is most of guality tests are skipped with older GDB, like # make check-gcc RUNTESTFLAGS=guality.exp=pr43177.c ... # of expected passes20 # of unsupported tests28 Is gcc.dg/guality/pr43177.c tested with GDB 7.2?
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 --- Comment #1 from Steve Ellcey sje at gcc dot gnu.org 2011-10-20 21:26:05 UTC --- Author: sje Date: Thu Oct 20 21:26:01 2011 New Revision: 180277 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180277 Log: 2011-10-20 Steve Ellcey s...@cup.hp.com PR testsuite/50722 * gcc.dg/pr49994-3.c: Skip on HP-UX. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr49994-3.c
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sje at cup dot hp.com Resolution||FIXED --- Comment #2 from Steve Ellcey sje at cup dot hp.com 2011-10-20 21:31:53 UTC --- Fixed by adding do-skip-if to the testcase.
