[Bug tree-optimization/46465] ICE: in calc_dfs_tree, at dominance.c:394 with -Os -fno-rerun-cse-after-loop -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46465 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-03 08:24:00 UTC --- Created attachment 22609 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22609 different testcase This testcase is a bit longer, but it needs simpler flags: $ gcc -O -fgcse -fno-tree-dominator-opts pr46465-2.c -wrapper=gdb,--args gcc: error: unrecognized option '-wrapper=gdb,--args' pr46465-2.c: In function 'foo': pr46465-2.c:15:1: internal compiler error: in calc_dfs_tree, at dominance.c:395 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Backtrace is the same as for the first testcase (and even as for PR46755): (gdb) bt #0 fancy_abort (file=0x10f5ca8 /mnt/svn/gcc-trunk/gcc/dominance.c, line=395, function=0x10f5d65 calc_dfs_tree) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x00634a93 in calc_dfs_tree (di=0x7fffd7b0, reverse=0 '\000') at /mnt/svn/gcc-trunk/gcc/dominance.c:395 #2 0x00636370 in calculate_dominance_info (dir=CDI_DOMINATORS) at /mnt/svn/gcc-trunk/gcc/dominance.c:656 #3 0x005ed4ad in flow_loops_find (loops=0x167d000) at /mnt/svn/gcc-trunk/gcc/cfgloop.c:386 #4 0x0077f674 in ira (f=value optimized out) at /mnt/svn/gcc-trunk/gcc/ira.c:3168 #5 0x00781580 in rest_of_handle_ira () at /mnt/svn/gcc-trunk/gcc/ira.c:3346 #6 0x007eb69f in execute_one_pass (pass=0x1631ce0) at /mnt/svn/gcc-trunk/gcc/passes.c:1553 #7 0x007eb965 in execute_pass_list (pass=0x1631ce0) at /mnt/svn/gcc-trunk/gcc/passes.c:1608 #8 0x007eb977 in execute_pass_list (pass=0x1632200) at /mnt/svn/gcc-trunk/gcc/passes.c:1609 #9 0x0092bb86 in tree_rest_of_compilation (fndecl=0x75cdf000) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #10 0x00af13c2 in cgraph_expand_function (node=0x75ce4000) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508 #11 0x00af399a in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1567 #12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1827 #13 0x00af3f1a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031 #14 0x00508b8c in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9844 #15 0x008d5580 in compile_file (argc=15, argv=0x7fffdc48) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #16 do_compile (argc=15, argv=0x7fffdc48) at /mnt/svn/gcc-trunk/gcc/toplev.c:1874 #17 toplev_main (argc=15, argv=0x7fffdc48) at /mnt/svn/gcc-trunk/gcc/toplev.c:1937 #18 0x76586bbd in __libc_start_main () from /lib/libc.so.6 #19 0x004ef5f1 in _start ()
[Bug rtl-optimization/46755] ICE: in calc_dfs_tree, at dominance.c:395 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46755 --- Comment #3 from Zdenek Sojka zsojka at seznam dot cz 2010-12-03 08:25:50 UTC --- PR46465 might be related, it has the same backtrace and uses computed gotos as well.
[Bug fortran/46625] libquadmath: Mangle internal symbols; rename __float128 - string functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46625 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-03 08:44:26 UTC --- While MinGW64 now mangles the symbols, I think MinGW.org does not. As I was told, the issue also affects the 32bit MinGW.
[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #9 from Iain Sandoe iains at gcc dot gnu.org 2010-12-03 08:58:25
UTC ---
(In reply to comment #8)
Please add a comment with a testcase that fails to work. I tried the obvious
one, and when .f is added to darwin9.h, it worked.
Indeed, between my comment #6 and yours the (suffix) problem has been resolved
(5 days can be a long time in gcc, it seems ;) ).
(probably fixed by r167292)
so placing:
.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|.f95|.f03|.f77|.for|.F|.F90|.F95|.F03:
in config/darwin{,9}.h is now functional - I've tried a variety of
representative command lines without fail - so it looks like the underlying
issue has been resolved.
Of course, residual issues [spurious warnings] with dsymutil are outside our
control (other than wrapping the utility in some way).
However, other than resolving this, we could enable for Fortran.
To resolve the spurious warnings, we will either
(a) Have to wrap dsymutil in some script to suppress the spurious messages ..
(I made a script referenced in comment #4)
.. or
(b) Go through the test-suite and put in prune lines in the cases that will
now fail on excess errors.
--
(a) is somewhat hacky - but does have the advantage that it is a fix in one
place rather than distributing stuff around the test-suite.
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.03 09:32:03
Ever Confirmed|0 |1
--- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03
09:32:03 UTC ---
Even something as simple as this brings the compiler down.
struct A
{
A(int);
operator void*() const;
};
templateint void foo(const A x)
{ 0 ? x : 0; }
Here's a backtrace from gdb if that helps.
0 fancy_abort (file=0xe5e0ed ../../combined/gcc/cp/tree.c, line=287,
function=0xe60260 build_target_expr) at ../../combined/gcc/diagnostic.c:892
#1 0x005e7c68 in build_target_expr (decl=0x2ac80b326280,
value=0x2ac80b42f678) at ../../combined/gcc/cp/tree.c:284
#2 0x005eceeb in build_cplus_new (type=0x2ac80b43ff18, init=value
optimized out) at ../../combined/gcc/cp/tree.c:450
#3 0x0049c742 in convert_like_real (convs=0x70ca550,
expr=0x2ac80b42f678, fn=0x0, argnum=0, inner=value optimized out,
issue_conversion_warnings=value optimized out, c_cast_p=0 '\0', complain=3)
at ../../combined/gcc/cp/call.c:5300
#4 0x0049e0c9 in build_conditional_expr (arg1=0x2ac80b3128d0,
arg2=0x2ac80b3128a0, arg3=0x2ac80b302f50, complain=3) at
../../combined/gcc/cp/call.c:3965
#5 0x0058a840 in build_x_conditional_expr (ifexp=0x2ac80b302f50,
op1=0x2ac80b3128a0, op2=0xe60260, complain=3) at
../../combined/gcc/cp/typeck.c:5478
#6 0x0056d43e in cp_parser_assignment_expression
(parser=0x2ac80b44d000, cast_p=value optimized out, pidk=0x0) at
../../combined/gcc/cp/parser.c:6972
#7 0x0056d6b0 in cp_parser_expression (parser=0xe5e0ed, cast_p=value
optimized out, pidk=0xe60260) at ../../combined/gcc/cp/parser.c:7149
#8 0x0056da50 in cp_parser_expression_statement
(parser=0x2ac80b44d000, in_statement_expr=0x0) at
../../combined/gcc/cp/parser.c:8264
#9 0x0057a496 in cp_parser_statement (parser=0x2ac80b44d000,
in_statement_expr=0x0, in_compound=1 '\001', if_p=0x0) at
../../combined/gcc/cp/parser.c:8129
#10 0x0057b4d6 in cp_parser_statement_seq_opt (parser=0x2ac80b44d000,
in_statement_expr=0x0) at ../../combined/gcc/cp/parser.c:8378
#11 0x0057b614 in cp_parser_compound_statement (parser=0x2ac80b44d000,
in_statement_expr=0x0, in_try=value optimized out) at
../../combined/gcc/cp/parser.c:8332
#12 0x0057d8de in cp_parser_ctor_initializer_opt_and_function_body
(parser=0x2ac80b44d000) at ../../combined/gcc/cp/parser.c:16319
#13 0x0057dc17 in cp_parser_function_definition_after_declarator
(parser=0x2ac80b44d000, inline_p=0 '\0') at
../../combined/gcc/cp/parser.c:19747
#14 0x0057eb6c in cp_parser_init_declarator (parser=0x2ac80b44d000,
decl_specifiers=0x7fff9f7fc170, checks=0x0, function_definition_allowed_p=1
'\001', member_p=0 '\0', declares_class_or_enum=value optimized out,
function_definition_p=0x7fff9f7fc1df \001) at
../../combined/gcc/cp/parser.c:19677
#15 0x0057eebb in cp_parser_single_declaration (parser=0x2ac80b44d000,
checks=0x0, member_p=0 '\0', explicit_specialization_p=0 '\0',
friend_p=0x7fff9f7fc247 ) at ../../combined/gcc/cp/parser.c:20002
#16 0x0057f0cb in cp_parser_template_declaration_after_export
(parser=0x2ac80b44d000, member_p=96 '`') at
../../combined/gcc/cp/parser.c:19852
#17 0x005840e2 in cp_parser_declaration (parser=0x2ac80b44d000) at
../../combined/gcc/cp/parser.c:9415
#18 0x00582405 in cp_parser_declaration_seq_opt (parser=0x2ac80b44d000)
at ../../combined/gcc/cp/parser.c:9337
#19 0x0058271b in c_parse_file () at
../../combined/gcc/cp/parser.c:3454
#20 0x0065ceed in c_common_parse_file () at
../../combined/gcc/c-family/c-opts.c:1071
#21 0x00940017 in toplev_main (argc=3, argv=0x7fff9f7fc4a8) at
../../combined/gcc/toplev.c:579
#22 0x00350401d974 in __libc_start_main () from /lib64/libc.so.6
#23 0x0048a669 in _start ()
[Bug rtl-optimization/46777] New: [4.5/4.6 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2164 with -O -fgcse -fno-tree-dominator-opts -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46777 Summary: [4.5/4.6 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2164 with -O -fgcse -fno-tree-dominator-opts -funroll-loops Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22610 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22610 reduced testcase The ICE message looks similiar to PR46440 and PR46493, but this one fails in trunk as well. $ gcc -fgcse -O -fno-tree-dominator-opts -funroll-loops pr46777.c pr46777.c: In function 'little2_prologTok': pr46777.c:39:1: error: verify_flow_info: Incorrect fallthru 67-68 pr46777.c:39:1: error: wrong insn in the fallthru edge (barrier 585 579 594) pr46777.c:39:1: internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2164 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Backtrace: (gdb) bt #0 error (gmsgid=0x10ef838 verify_flow_info: Incorrect fallthru %i-%i) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:747 #1 0x005f6997 in rtl_verify_flow_info () at /mnt/svn/gcc-trunk/gcc/cfgrtl.c:2162 #2 0x005e6cd4 in verify_flow_info () at /mnt/svn/gcc-trunk/gcc/cfghooks.c:257 #3 0x005ebffa in outof_cfg_layout_mode () at /mnt/svn/gcc-trunk/gcc/cfglayout.c:362 #4 0x007eb69f in execute_one_pass (pass=0x1630b00) at /mnt/svn/gcc-trunk/gcc/passes.c:1553 #5 0x007eb965 in execute_pass_list (pass=0x1630b00) at /mnt/svn/gcc-trunk/gcc/passes.c:1608 #6 0x007eb977 in execute_pass_list (pass=0x1632200) at /mnt/svn/gcc-trunk/gcc/passes.c:1609 #7 0x0092bb86 in tree_rest_of_compilation (fndecl=0x75ce3000) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #8 0x00af13c2 in cgraph_expand_function (node=0x75ce2160) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508 #9 0x00af399a in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1567 #10 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1827 #11 0x00af3f1a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031 #12 0x00508b8c in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9844 #13 0x008d5580 in compile_file (argc=16, argv=0x7fffdc38) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #14 do_compile (argc=16, argv=0x7fffdc38) at /mnt/svn/gcc-trunk/gcc/toplev.c:1874 #15 toplev_main (argc=16, argv=0x7fffdc38) at /mnt/svn/gcc-trunk/gcc/toplev.c:1937 #16 0x76586bbd in __libc_start_main () from /lib/libc.so.6 #17 0x004ef5f1 in _start () Tested revisions: r167383 - crash 4.5 r166509 - crash 4.4 r166509 - OK
[Bug c++/46715] template constructor - Compiler Bus error under -O2/-Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46715 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 09:33:59 UTC --- What happens if you try something later in the 4.4 branch ? Ramana
[Bug target/46693] incorrect code generation with -O2 optimization enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46693 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 09:42:32 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 09:42:32 UTC --- Confirmed.
[Bug target/46631] Change operands order so we can use 16bit and instead of 32bit in thumb2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46631 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 09:55:09 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 09:55:09 UTC --- Confirmed.
[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 09:56:53 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 09:56:53 UTC --- I see this on trunk even today.
[Bug target/46483] Built-in memcpy() does not handle unaligned int for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46483 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 10:02:39 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #13 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 10:02:39 UTC --- Trunk appears to be fixed but very conservatively as Richi says but 4.5 probably exhibits the issue from Mikael's last comment.
[Bug libffi/46508] [4.6 regression] Add ARM VFP ABI support to libffi broke build for armv5tel-linux-gnueabi with binutils-2.20.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46508 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 10:04:41 Ever Confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 10:04:41 UTC --- A patch was submitted here. Does this fix your problem ? http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02878.html
[Bug libffi/46508] [4.6 regression] Add ARM VFP ABI support to libffi broke build for armv5tel-linux-gnueabi with binutils-2.20.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46508 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2010-12-03 10:20:59 UTC --- (In reply to comment #1) A patch was submitted here. Does this fix your problem ? http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02878.html I'm currently doing a 4.6 bootstrap and testsuite run with this patch applied. It should be finished in a couple of hours.
[Bug target/45885] ICE in arm_dbx_register_number, at config/arm/arm.c:22071
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45885 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 10:22:45 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 10:22:45 UTC --- As I've said in the past, the arm-none-linux-gnu target really hasn't been validated for neon support and thus it is likely that there are parts which are just broken. Thus expecting that this will *work* is probably not correct. This configuration is strictly in maintenance mode only and I would encourage you to move on to linux-gnueabi . Ramana
[Bug target/45937] unnecessary add/sub sp to reserve stack memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45937 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 10:29:19 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/45252] unnecessary register move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45252 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 10:34:54 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug fortran/45159] Unnecessary temporaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159 --- Comment #23 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-03 10:35:16 UTC --- Author: tkoenig Date: Fri Dec 3 10:35:12 2010 New Revision: 167413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167413 Log: 2010-12-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * dependency.c (check_section_vs_section): Pre-calculate the relationship between the strides and the relationship between the start values. Use an integer constant one for that purpose. Forward dependencies for positive strides apply for where the lhs start = rhs start and lhs stride = rhs stride and vice versa for negative stride. No need to compare end expressions in either case (assume no bounds violation). 2010-12-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * gfortran.dg/dependency_38.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_38.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #25 from rguenther at suse dot de rguenther at suse dot de 2010-12-03 10:47:49 UTC --- On Fri, 3 Dec 2010, mrs at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #24 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2010-12-03 00:26:37 UTC --- The lto people need to engineer a design in which the debug information is left around in .o files, and those files are read at the very last step in a link, to collect the debug information from them and persist that information into the filesystem. They are removing .o files before the end of the final link. To the extent those files have debug information in them, this can't work. I could not find the last invocation of gcc that fails. If someone could point that out, I might be able to suggest a work around that just disappears debug information until such time as the first bug is fixed. Essentially, you can remove -g* from that line and disappear the collection of the debug information. Another solution would be to not have any .c, .cc, .C, .cpp, .cp, .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line. I didn't manage to prove the following theory but it's the only that makes sense. What I think happens is the following: User says gcc -o t t.c -flto We now do the usual compile ./cc1 -c -o /tmp/xyz.o t.c -flto and now execute the link-spec which matches the symtool thing (but on the wrong object file!). So, we now link. Which will do collect2 ... which executes lto-wrapper which executes gcc -c -x lto -o /tmp/abc.o /tmp/xyz.o -flto and then collect2 continues and links collect2-ld ... -o t /tmp/abc.o only _now_ dsymutil is invoked (from the first link-spec!) and on /tmp/xyz.o, which isn't the correct object file either. But somehow that intermediate file has disappeared at this point (I have yet to see who is responsible for cleaning up that one and when it does so). Thus, the setup is broken anyhow, even if we manage to retain the object file for long enough. The darwin people have to design a more robust way to run dsymutil. Richard.
[Bug c++/46715] template constructor - Compiler Bus error under -O2/-Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46715 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 10:49:30 UTC --- I don't see a problem with trunk FWIW. using arm-eabi on a x86_64 linux host. Don't have access to i386-apple-darwin8.11.1 host Ramana
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #26 from rguenther at suse dot de rguenther at suse dot de 2010-12-03 10:51:06 UTC --- On Fri, 3 Dec 2010, rguenther at suse dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #25 from rguenther at suse dot de rguenther at suse dot de 2010-12-03 10:47:49 UTC --- On Fri, 3 Dec 2010, mrs at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #24 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2010-12-03 00:26:37 UTC --- The lto people need to engineer a design in which the debug information is left around in .o files, and those files are read at the very last step in a link, to collect the debug information from them and persist that information into the filesystem. They are removing .o files before the end of the final link. To the extent those files have debug information in them, this can't work. I could not find the last invocation of gcc that fails. If someone could point that out, I might be able to suggest a work around that just disappears debug information until such time as the first bug is fixed. Essentially, you can remove -g* from that line and disappear the collection of the debug information. Another solution would be to not have any .c, .cc, .C, .cpp, .cp, .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line. I didn't manage to prove the following theory but it's the only that makes sense. What I think happens is the following: User says gcc -o t t.c -flto We now do the usual compile ./cc1 -c -o /tmp/xyz.o t.c -flto and now execute the link-spec which matches the symtool thing (but on the wrong object file!). So, we now link. Which will do collect2 ... which executes lto-wrapper which executes gcc -c -x lto -o /tmp/abc.o /tmp/xyz.o -flto and then collect2 continues and links collect2-ld ... -o t /tmp/abc.o only _now_ dsymutil is invoked (from the first link-spec!) and on /tmp/xyz.o, which isn't the correct object file either. But somehow that intermediate file has disappeared at this point (I have yet to see who is responsible for cleaning up that one and when it does so). Thus, the setup is broken anyhow, even if we manage to retain the object file for long enough. The darwin people have to design a more robust way to run dsymutil. Btw, I would have tried to dig deeper but darwin lacks basic tools such as strace which I am familiar with, so I was lost (fortunately for you I now do have access to a darwin x86 machine). So if you can hint me at what's the equivalent of strace -f -e unlink,execve -o log ./xgcc ... on darwin that would help. Richard.
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for soft-float on arm-*-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org Known to fail|| --- Comment #16 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 11:04:06 UTC --- Isn't this now fixed ? Ramana
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added CC||mkuvyrkov at gcc dot ||gnu.org --- Comment #5 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-03 11:14:05 UTC --- (In reply to comment #4) On x86_64-apple-darwin10 at r167400, we are still failing... FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq at -m64. IIUC, this only occurs on x86_64-darwin10 target. Jack, If you are interested in fixing this, could you post before and after assembler dumps for x86_64-darwin10 compiler for the testcase. Thank you.
[Bug c++/46778] New: More SFINAE issues?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46778
Summary: More SFINAE issues?
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com
I'm working on updating std::is_constructible and I see behavior I don't
understand for the current implementation. Shouldn't the below just compile???
(a more refined version of the code using std::declval_Args1(), etc, as in
type_traits doesn't change anything)
templatetypename _Tp, typename... _Args
class is_constructible_mini
{
typedef char __one;
typedef struct { char __arr[2]; } __two;
templatetypename _Tp1, typename... _Args1
static decltype(_Tp1(_Args1()...), __one())
__test(int);
templatetypename, typename...
static __two __test(...);
public:
static const bool value = sizeof(__test_Tp, _Args...(0)) == 1;
};
int t1[is_constructible_miniint::value ? -1 : 1];
int t2[is_constructible_miniconst int::value ? -1 : 1];
int t3[is_constructible_miniint, int, int::value ? -1 : 1]; // Ok
int t4[is_constructible_miniconst int, int, int::value ? -1 : 1];
[Bug c++/46778] More SFINAE issues?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46778 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-03 11:19:52 UTC --- I'm adding Jason in CC.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #27 from Iain Sandoe iains at gcc dot gnu.org 2010-12-03 11:29:59 UTC --- (In reply to comment #26) On Fri, 3 Dec 2010, rguenther at suse dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #25 from rguenther at suse dot de rguenther at suse dot de 2010-12-03 10:47:49 UTC --- On Fri, 3 Dec 2010, mrs at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #24 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2010-12-03 00:26:37 UTC --- The lto people need to engineer a design in which the debug information is left around in .o files, and those files are read at the very last step in a link, to collect the debug information from them and persist that information into the filesystem. They are removing .o files before the end of the final link. To the extent those files have debug information in them, this can't work. I could not find the last invocation of gcc that fails. If someone could point that out, I might be able to suggest a work around that just disappears debug information until such time as the first bug is fixed. Essentially, you can remove -g* from that line and disappear the collection of the debug information. Another solution would be to not have any .c, .cc, .C, .cpp, .cp, .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line. r167292 has fixed the problem with the suffix recognition. (I suspect that the bug you fixed predates the inclusion of the spec, thus the spec has never worked 100% on trunk) I didn't manage to prove the following theory but it's the only that makes sense. What I think happens is the following: User says gcc -o t t.c -flto We now do the usual compile ./cc1 -c -o /tmp/xyz.o t.c -flto and now execute the link-spec which matches the symtool thing (but on the wrong object file!). So, we now link. Which will do collect2 ... which executes lto-wrapper which executes gcc -c -x lto -o /tmp/abc.o /tmp/xyz.o -flto and then collect2 continues and links collect2-ld ... -o t /tmp/abc.o only _now_ dsymutil is invoked (from the first link-spec!) and on /tmp/xyz.o, which isn't the correct object file either. But somehow that intermediate file has disappeared at this point (I have yet to see who is responsible for cleaning up that one and when it does so). my understanding is that dsymutil only takes the linked executable as its command line argument - and looks up the objects from the tables therein. The debug is then extracted from those objects, linked and placed into the .dSYM and then the objects are unlinked. Therefore, somehow I assume that the linked exec is referring to an object which has gone away. (if it's actually the wrong object, then that's a potentially more serious issue). Thus, the setup is broken anyhow, even if we manage to retain the object file for long enough. The darwin people have to design a more robust way to run dsymutil. AFAIK dsymutil requires only (a) the linked exec. and (b) that the objects used to link it are still available. It's not obvious to me how we (within the FSF community) can simplify that or make it more robust. Btw, I would have tried to dig deeper but darwin lacks basic tools such as strace which I am familiar with, so I was lost (fortunately for you I now do have access to a darwin x86 machine). So if you can hint me at what's the equivalent of strace -f -e unlink,execve -o log ./xgcc ... on darwin that would help. sudo dtruss -f -t syscall ./xgcc... log might be helpful, cheers, Iain
[Bug fortran/44352] ICE in string_to_single_character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-03 11:29:59 UTC --- The test case recurses infinitely with -fdump-fortran-original: Namespace: A-H: (REAL 8) I-N: (INTEGER 4) O-Z: (REAL 8) procedure name = MAIN__ symtree: 'MAIN__' || symbol: 'MAIN__' type spec : (UNKNOWN 0) attributes: (PROGRAM PUBLIC SUBROUTINE) symtree: 'ddname' || symbol: 'ddname' type spec : (CHARACTER 32) attributes: (VARIABLE ) symtree: 'dname' || symbol: 'dname' type spec : (CHARACTER 32) attributes: (PROCEDURE STATEMENT-PROC FUNCTION) value: 'h810 e=0.01 ' result: dname Formal arglist: x Formal namespace Namespace: A-H: (REAL 8) I-N: (INTEGER 4) O-Z: (REAL 8) procedure name = MAIN__ ... and so on.
[Bug c/46779] New: wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779
Summary: wrong code generation for array access
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mschu...@ivs.cs.ovgu.de
CC: mschu...@ivs.cs.ovgu.de
Target: avr-*-*
Created attachment 22611
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22611
example program for reproducing the wrong code generation
The gcc versions 4.4.0-4.4.5 generates wrong code for an array access if some
thing come together and it was very difficult to produce a nearly minimal test
case. It seems to be that the generation of the code goes wrong if using size
optimization, inline assembler and nested loops. Maybe the optimizer runs out
of usable registers, because some registers are globbered by the inline
assembler. The inline assembler is not from my self, because I used a macro
from the avr-libc (version 1.6.8) for filling up a boot page for later writing
this into the flash. The relevant code look as follows (in the code I expanded
the macro directly):
uint8_t array[256]={'A','B'};
int main(void) {
uint8_t *buf=array;
uint32_t page=0;
uint16_t w;
uint8_t y;
uint16_t i;
for (y=0;y100;++y) {
page=((uint16_t)y)8;
for (i=0; i10; i+=2) {
w = (buf[i+1]);
w=8;
w|= buf[i];
__asm__ __volatile__
(
movw r0, %4\n\t
movw r30, %A3\n\t
sts %1, %C3\n\t
sts %0, %2\n\t
spm\n\t
clr r1\n\t
:
:
i (_SFR_MEM_ADDR(__SPM_REG)),
i (_SFR_MEM_ADDR(RAMPZ)),
r ((uint8_t)__BOOT_PAGE_FILL),
r ((uint32_t)(page+i)),
r ((uint16_t)w)
: r0, r30, r31
);
}
}
return 0;
}
To reproduce the bug, compile the provided attachment with:
avr-gcc -Os main.cc -mmcu=atmega128
This generates, showing only the inner loop:
ea: 60 e0 ldi r22, 0x00 ; 0
ec: eb 01 movwr28, r22
ee: 6c 91 ld r22, X
f0: 70 e0 ldi r23, 0x00 ; 0
f2: 6c 2b or r22, r28
f4: 7d 2b or r23, r29
f6: 0b 01 movwr0, r22
f8: f9 01 movwr30, r18
fa: 40 93 5b 00 sts 0x005B, r20
fe: 10 93 68 00 sts 0x0068, r17
102: e8 95 spm
104: 11 24 eor r1, r1
106: 12 96 adiwr26, 0x02 ; 2
108: 2e 5f subir18, 0xFE ; 254
10a: 3f 4f sbcir19, 0xFF ; 255
10c: 4f 4f sbcir20, 0xFF ; 255
10e: 5f 4f sbcir21, 0xFF ; 255
110: 71 e0 ldi r23, 0x01 ; 1
112: aa 30 cpi r26, 0x0A ; 10
114: b7 07 cpc r27, r23
116: 49 f7 brne.-46; 0xea main+0x1c
and you see at 0xee the RAM is read, but only at this position, however, in the
C-source we have two reads.
This example compiled with gcc version 4.4.x generates wrong code, instead
using gcc version 4.5.x it works as it should. However, I am not sure if this
is fixed there or is this bug there also latently contained. Maybe, it is bug
in the optimizer, which only needs another example to show up there too.
Some information to the used compiler:
avr-gcc -v
Using built-in specs.
Target: avr
Configured with: /tmp/cross-build/gcc-4.4.0/configure --target=avr
--prefix=/localapp/cross-gcc/builds/2.20.1-4.4.0-7.1/avr --program-prefix=avr-
--with-gnu-ld --with-gnu-as --enable-languages=c,c++
Thread model: single
gcc version 4.4.0 (GCC)
The other compiler version are compiled with same configure flags.
[Bug c++/46778] More SFINAE issues?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46778
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-03
11:32:00 UTC ---
the test looks valid to me, this simpler version is also rejected
templatetypename _Tp
class is_constructible_mini2
{
typedef char __one;
typedef struct { char __arr[2]; } __two;
templatetypename _Tp1
static decltype(_Tp1(), __one())
__test(int);
templatetypename
static __two __test(...);
public:
static const bool value = sizeof(__test_Tp(0)) == 1;
};
int t1[is_constructible_mini2int::value ? -1 : 1];
int t2[is_constructible_mini2const int::value ? -1 : 1];
[Bug rtl-optimization/45354] [4.6 regression] ICE with -fselective-scheduling and -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45354 --- Comment #10 from Alexander Monakov amonakov at gcc dot gnu.org 2010-12-03 12:04:22 UTC --- Author: amonakov Date: Fri Dec 3 12:04:16 2010 New Revision: 167415 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167415 Log: PR rtl-optimization/45354 * sel-sched-ir.c (jump_leads_only_to_bb_p): Rename to ... (bb_has_removable_jump_to_p): This. Update all callers. Make static. Allow BBs ending with a conditional jump. Forbid EDGE_CROSSING jumps. * sel-sched-ir.h (jump_leads_only_to_bb_p): Delete prototype. testsuite: * gcc.dg/tree-prof/pr45354.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-prof/pr45354.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/sel-sched-ir.h trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/45354] [4.6 regression] ICE with -fselective-scheduling and -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45354 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Alexander Monakov amonakov at gcc dot gnu.org 2010-12-03 12:05:50 UTC --- Fixed.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #28 from Iain Sandoe iains at gcc dot gnu.org 2010-12-03 12:10:42 UTC --- another thing that might help is to hack gcc/spec to put dsymutil --symtab that causes dsymutil to dump what it found in the exec and exit without doing the debug-link.
[Bug tree-optimization/46780] New: -fgraphite-identity ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1081
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46780
Summary: -fgraphite-identity ICE in refs_may_alias_p_1, at
tree-ssa-alias.c:1081
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wouter.vermae...@scarlet.be
cat bug.ii
extern C { double cos(double x); }
static int outbuf[8][8];
int main() {
double buf1[9];
double* buf1_1 = buf1[1];
for (int i = 0; i 8; ++i) {
buf1_1[i] *= cos(i);
}
int buf2[64];
for (int i = 0; i 8; ++i) {
int* buf2_i = buf2[i];
for (int j = 0; j 8; ++j) {
outbuf[i][j] = buf2_i[8 * j];
}
}
}
g++ -O2 -fgraphite-identity bug.ii
bug.ii: In function ‘int main()’:
bug.ii:19:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:1081
I'm using SVN revision tr...@167414 on linux x86_64.
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED Known to fail|| --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org 2010-12-03 12:23:00 UTC --- The reported issue was fixed for 4.4.x and there are no plans for backporting this fix to 4.3.x branch. I'll close this bug. I admit that we could think about to allow for prototypes only, that a dllimport attribute remains for following non-dllimport marked prototypes. On the other hand, it seems to be an extension.
[Bug fortran/44352] ICE in string_to_single_character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-03 12:23:14 UTC --- Author: tkoenig Date: Fri Dec 3 12:23:11 2010 New Revision: 167416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167416 Log: 2010-12-03 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/44352 * dump-parse-tree.c (show_symbol): Don't show formal namespace for statement functions in order to avoid infinite recursion. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c
[Bug target/45885] ICE in arm_dbx_register_number, at config/arm/arm.c:22071
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45885 --- Comment #3 from Ryan Mansfield rmansfield at qnx dot com 2010-12-03 12:25:04 UTC --- (In reply to comment #2) As I've said in the past, the arm-none-linux-gnu target really hasn't been validated for neon support and thus it is likely that there are parts which are just broken. Thus expecting that this will *work* is probably not correct. This configuration is strictly in maintenance mode only and I would encourage you to move on to linux-gnueabi . This bug, as are the other ones I filed are not strictly limited to arm-none-linux-gnu. I am simply using a using arm-none-linux-gnu toolchain to reproduce and report the issue. These likely effect all apcs-gnu toolchains, and looking at config.gcc, there are more configurations that follow that than gnueabi configurations. So basically you're saying that NEON is only supported in arm-none-linux-gnueabi configurations because it's only been tested there. As for the expecting it to work, ICE are always bugs so until support for these configurations are removed these are valid bugs. Whether bugs get closed, as fixed or wontfix, doesn't make them less of a bug.
[Bug fortran/44352] ICE in string_to_single_character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-03 12:26:21 UTC --- The infinite recursion is fixed, the original problem remains.
[Bug tree-optimization/46781] New: [4.6 Regression] Missing optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46781 Summary: [4.6 Regression] Missing optimization Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 22612 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22612 Code produced by GCC 4.6.0 Compiled with -O2
[Bug tree-optimization/46781] [4.6 Regression] Missing optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46781 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2010-12-03 12:38:03 UTC --- Created attachment 22613 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22613 Code produced by GCC 4.5.2 C source is in attachment 19980.
[Bug fortran/46772] libquadmath: Build failure - strtod: static declaration of 'strtod' follows non-static declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46772 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 12:38:27 CC||ktietz at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2010-12-03 12:38:27 UTC --- Fix looks reasonable to me. That mingw.org defines this function static is more a bug on their side.
[Bug target/45693] [4.6 regression] All Tru64 UNIX C++ EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 --- Comment #12 from Rainer Orth ro at gcc dot gnu.org 2010-12-03 12:46:15 UTC --- Author: ro Date: Fri Dec 3 12:46:12 2010 New Revision: 167422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167422 Log: Backport from mainline: 2010-11-02 Rainer Orth r...@cebitec.uni-bielefeld.de PR target/45693 * configure.host (osf*): Set os_include_dir to os/generic. Add -lpthread to OPT_LDFLAGS. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/configure.host
[Bug fortran/44352] ICE in string_to_single_character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-03 12:50:24 UTC --- Reduced test case, not that there was a lot to reduce: character*2 ddname,dname dname(x)= 'x' ddname=dname(0.0) END (the test succeeds with character*1).
[Bug target/45885] ICE in arm_dbx_register_number, at config/arm/arm.c:22071
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45885 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-03 13:21:48 UTC --- (In reply to comment #0) $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnu Configured with: ../configure --target=arm-unknown-linux-gnu --prefix=/home/ryan/x-tools/arm-unknown-linux-gnu --with-headers=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include --with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.6.0 20101004 (experimental) [trunk revision 164952] (GCC) $ ./xgcc -B. -c -O3 -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=neon -g ~/ice.i What happens if you do a -mcpu=cortex-a8 ?
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug lto/46769] LTO failed to build gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.03 13:29:21 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 13:29:21 UTC --- Testcase?
[Bug rtl-optimization/46777] [4.5/4.6 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2164 with -O -fgcse -fno-tree-dominator-opts -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46777 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.2
[Bug c/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 13:37:46 UTC --- at least I see r1 use in the asm but no clobber for it, instead it clobbers the seemingly unused r31.
[Bug tree-optimization/45370] [4.6 Regression] gfortran.dg/subref_array_pointer_2.f90 -O2 -fgraphite-identity ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45370 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |tree-optimization Target Milestone|--- |4.6.0 Summary|gfortran.dg/subref_array_po |[4.6 Regression] |inter_2.f90 -O2|gfortran.dg/subref_array_po |-fgraphite-identity ICE|inter_2.f90 -O2 ||-fgraphite-identity ICE
[Bug tree-optimization/46780] -fgraphite-identity ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1081
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46780 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 13:40:11 UTC --- I get with checking enabled: bug.ii: In function 'int main()': bug.ii:5:5: error: invalid first operand of MEM_REF buf1[8] bug.ii:9:21: note: in statement # VUSE .MEM_81 D.2085_90 = buf1[8]; which makes it a dup of PR45370. *** This bug has been marked as a duplicate of bug 45370 ***
[Bug tree-optimization/45370] [4.6 Regression] gfortran.dg/subref_array_pointer_2.f90 -O2 -fgraphite-identity ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45370 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||wouter.vermaelen at scarlet ||dot be --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 13:40:11 UTC --- *** Bug 46780 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/46781] [4.6 Regression] Missing optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46781
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.03 13:55:38
Target Milestone|--- |4.6.0
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03
13:55:38 UTC ---
Confirmed. GCC 4.5 tree DSE removes the first store to p:
fun (void * * q)
{
void * r;
void * * p.1;
bb 2:
p.1_1 = p;
p = 0B;
r_3 = *q_2(D);
p = p.1_1;
return r_3;
and then PRE figures out the redundant store.
4.6 correctly preserves the store to p as the read from *q aliases it
(4.5 type-based aliasing concludes that void * doesn't alias void **,
something that people regularly get wrong thus I dumbed down TBAA).
Where did you get this testcase from?
To illustrate the difference, the following testcase is not optimized
by GCC 4.5 either (and that's required):
extern void **p;
void **fun (void ***q)
{
void **t;
void **r;
t = p;
p = 0;
r = *q;
p = t;
return r;
}
The observed change is caused by:
2010-08-25 Richard Guenther rguent...@suse.de
* alias.c (get_alias_set): Assign a single alias-set to all pointers.
* gimple.c (gimple_get_alias_set): Remove special handling
for pointers.
[Bug c/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 --- Comment #2 from Michael Schulze mschulze at ivs dot cs.ovgu.de 2010-12-03 13:58:40 UTC --- (In reply to comment #1) at least I see r1 use in the asm but no clobber for it, instead it clobbers the seemingly unused r31. Yes correct, r1 is not clobbered, however, I tested it with clobbering this one too. But this does not change the code generation, leading to the same erroneous code. In case of r31, I think you are wrong because it is used in movw r30, %A3\n\t. Are you agree this is a bug or not?
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |target Version|4.4.0 |4.4.5 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 14:05:42 UTC --- (In reply to comment #2) (In reply to comment #1) at least I see r1 use in the asm but no clobber for it, instead it clobbers the seemingly unused r31. Yes correct, r1 is not clobbered, however, I tested it with clobbering this one too. But this does not change the code generation, leading to the same erroneous code. In case of r31, I think you are wrong because it is used in movw r30, %A3\n\t. Are you agree this is a bug or not? I don't know anything about AVR, so I can't say that (I just noticed the r1 issue).
[Bug debug/46782] New: -fcompare-debug failure (length) with -fvar-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46782 Summary: -fcompare-debug failure (length) with -fvar-tracking Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22614 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22614 reduced testcase Compiler output: $ gcc -fvar-tracking -fcompare-debug pr46782.c pr46782.c:1:0: warning: variable tracking requested, but useless unless producing debug info [enabled by default] gcc: error: pr46782.c: -fcompare-debug failure (length) Fail with -g as well. Tested revisions: r167356 - fail r153685 - fail 4.5 r166509 - fail
[Bug fortran/46783] New: [OOP] TRANSFER with polymorphic MOLD=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46783 Summary: [OOP] TRANSFER with polymorphic MOLD= Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Cf. http://j3-fortran.org/pipermail/j3/2010-December/004026.html Currently, the declared type is used for MOLD= in TRANSFER. It seems as if the effective type should be used instead. This is a tracker bug as the standard is a bit ambiguous about it; I assume that there will be an IR (interpretation request) about it. Currently, F2008 just has: MOLD shall be a scalar or array of any type. If it is a variable, it need not be defined. Result Characteristics. The result is of the same type and type parameters as MOLD.
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 --- Comment #4 from Michael Schulze mschulze at ivs dot cs.ovgu.de 2010-12-03 14:16:30 UTC --- I don't know anything about AVR, so I can't say that (I just noticed the r1 issue). Ok due to the compiler abi for the avr, r0,r1 are fixed registers that are never allocated by gcc for local data, but often used for fixed purposes. r0 is a temporary register that may be globbered by any C-code. r1 is assumed to be always zero in any C-code. This is the reason, why it is cleared at the end of the inline assembler.
[Bug preprocessor/46784] New: Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46784 Summary: Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges' Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@hotmail.com During a compilation of Cairo 1.10 I got the following error: make[3]: Entering directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0/src' CC cairo-analysis-surface.lo CC cairo-arc.lo CC cairo-array.lo CC cairo-atomic.lo CC cairo-base64-stream.lo CC cairo-base85-stream.lo CC cairo-bentley-ottmann.lo cairo-bentley-ottmann.c: In function `_cairo_bo_sweep_line_compare_edges': cairo-bentley-ottmann.c:424: internal compiler error: in expand_mult, at expmed.c:2653 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [cairo-bentley-ottmann.lo] Error 1 make[3]: Leaving directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0' make: *** [all] Error 2 so as good boy I open a bug report !! SunOS mrtg 5.10 Generic_142909-17 on Sparc T-5120 with LDOM 1.3 pkg-config 0.25 fontconfig-2.4.2 pixman 0.21.2 cairo 1.10 gcc: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 Cairo config.sh option: ./configure --prefix=$INSTALL_DIR --enable-xlib=no --enable-xlib-render=no --enable-win32=no CFLAGS=-O3 -fPIC -D_POSIX_PTHREAD_SEMANTICS I have no more clue what I suppose to give you in this case !
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2010-12-03 14:34:35 UTC --- (In reply to comment #4) On x86_64-apple-darwin10 at r167400, we are still failing... FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq at -m64. Works for me with a x86_64-apple-darwin10 cross compiler with revision 167416: .globl _test _test: LFB516: movq%rdi, %xmm0 ret LFE516: .section __TEXT,__eh_frame,coale
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for soft-float on arm-*-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501 --- Comment #17 from Martin Guy martinwguy at gmail dot com 2010-12-03 14:46:28 UTC --- Sort of. The cause of the bug was never found, and the workaround is to disable an instruction. It might be worth trying enabling movsfcc in current GCC and re-running the tests, since the conditional execution stuff in the middle end was rewritten between 4.3 and 4.4 if I remember correctly, so the actual bug in the middle end may have gone away with that rewrite.
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03 14:49:40 UTC --- Created attachment 22615 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22615 assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10 at r167372 Generated with... /Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/ /Users/howarth/gcc/gcc/testsuite/gcc.target/i386/sse2-init-v2di-2.c -O2 -msse4 -march=core2 -S -m64 -o sse2-init-v2di-2.s
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03 14:50:21 UTC --- Created attachment 22616 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22616 assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10 at r167375
[Bug tree-optimization/46785] New: Doesn't vectorize reduction x += y*y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46785
Summary: Doesn't vectorize reduction x += y*y
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: i...@gcc.gnu.org
When looking at why GCC is so slow with the himeno benchmark in the usual
Phoronix testing I noticed that we do not vectorize the reduction in
float x[1024];
float
test (void)
{
int i;
float gosa = 0.0;
for (i = 0; i 1024; ++i)
{
float tem = x[i];
gosa += tem * tem;
}
return gosa;
}
because at analysis time we have
D.3171_6 = __builtin_powf (tem_5, 2.0e+0);
as the def for the addition which doesn't satisfy is_gimple_assign
nor any of the vinfo tests:
$3 = {type = undef_vec_info_type, live = 0 '\000', in_pattern_p = 0 '\000',
read_write_dep = 0 '\000', stmt = 0x77edc908, loop_vinfo = 0x18f77e0,
vectype = 0x0, vectorized_stmt = 0x0, data_ref_info = 0x0,
dr_base_address = 0x0, dr_init = 0x0, dr_offset = 0x0, dr_step = 0x0,
dr_aligned_to = 0x0, related_stmt = 0x0, same_align_refs = 0x18cf7f0,
def_type = vect_internal_def, slp_type = loop_vect, first_dr = 0x0,
next_dr = 0x0, same_dr_stmt = 0x0, size = 0, store_count = 0, gap = 0,
relevant = vect_unused_in_scope, cost = {outside_of_loop = 0,
inside_of_loop = 0}, bb_vinfo = 0x0, vectorizable = 1 '\001'}
As we want to allow internal defs we can also just let calls slip through
here (so we vectorize reductions with veclib vectorized calls as well).
Ira?
[Bug middle-end/46786] New: ICE: verify_stmts failed: statement marked for throw, but doesn't with -fopenmp -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46786 Summary: ICE: verify_stmts failed: statement marked for throw, but doesn't with -fopenmp -fnon-call-exceptions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22617 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22617 reduced testcase (from gcc.dg/gomp/pr25989.c) Compiler output: $ gcc -O -fopenmp -fexceptions -fnon-call-exceptions pr46786.c pr46786.c: In function 'foo._omp_fn.0': pr46786.c:5:9: error: statement marked for throw, but doesn't .omp_data_i__a_lsm.7_9 = D.2714_8; pr46786.c:5:9: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r167383 - crash 4.5 r166509 - crash 4.4 r166509 - crash
[Bug rtl-optimization/46777] [4.5/4.6 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2164 with -O -fgcse -fno-tree-dominator-opts -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46777 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.03 15:03:28 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-12-03 15:03:28 UTC --- It was introduced by revision 146848: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01491.html
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2010-12-03 15:06:31 UTC --- (In reply to comment #8) Created attachment 22616 [details] assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10 at r167375 It was fixed by revision 167398. Why do you use r167375?
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03 15:21:12 UTC --- (In reply to comment #9) (In reply to comment #8) Created attachment 22616 [details] [details] assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10 at r167375 It was fixed by revision 167398. Why do you use r167375? Since it still occurs in r167400 on darwin, the difference between r167372 and r167375 should capture the assembly changes with the absent movq in sse2-init-v2di-2.s on x86_64-apple-darwin10.
[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2010-12-03 15:21:51 UTC --- Jan, your patch has broken bootstrap on two platforms for a week now, and there's not even an indication that you're looking at the problem. Please fix or revert ASAP. Rainer
[Bug preprocessor/46784] Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46784 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2010-12-03 15:26:32 UTC --- gcc-3.4.6 is no longer supported upstream. Please upgrade to gcc-4.4 or gcc-4.5.
[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.03 15:27:13
CC||amonakov at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org 2010-12-03
15:27:13 UTC ---
In this particular example, the problem is in scan_tree_for_params_int:
int v = int_cst_value (cst);
mpz_init (val);
mpz_set_si (val, 0);
/* Necessary to not get -1 = 2^n - 1. */
if (v 0)
mpz_sub_ui (val, val, -v);
else
mpz_add_ui (val, val, v);
(gdb) p cst
$8 = (tree) 0x75a4e848
(gdb) pt
integer_cst 0x75a4e848 type integer_type 0x77ed0738 long long int
constant -8589934593
(gdb) p v
$9 = -1
(gdb)
There are multiple places where graphite uses int_cst_value. Note that the
problem may be more severe on 32-bit hosts as there the tree may hold a 64-bit
constant but mpz_*_{u,s}i accepts 'long's.
[Bug tree-optimization/46787] New: Does not vectorize loop with load from scalar variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46787
Summary: Does not vectorize loop with load from scalar variable
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: i...@gcc.gnu.org
When looking at why GCC is so slow with the himeno benchmark in the usual
Phoronix testing I noticed that we do not vectorize
float *x;
float parm;
float
test (int start, int end)
{
int i;
for (i = start; i end; ++i)
{
float tem = x[i];
x[i] = parm * tem;
}
}
because there is a scalar non-varying load of parm that, when the loop
rolls just a single time is aliased by the store to x[i].
We are though vectorizing with at least a vectorization factor of two,
which means that x cannot validly point to parm (and a vector store
would exceed the scalar variables size, something that after vectorization
alias-analysis would use to disambiguate the vector store and the load).
Thus we can treat loads of scalar decls as if they were done outside of
the loop and vectorize it as
D.1234_3 = tem;
vec_tmp_4 = { D.1234_3, D.1234_3 };
thus, as if D.1234_3 were a vect_external_def and mark the statement
itself as not relevant.
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2010-12-03 15:34:10 UTC --- (In reply to comment #10) (In reply to comment #9) (In reply to comment #8) Created attachment 22616 [details] [details] [details] assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10 at r167375 It was fixed by revision 167398. Why do you use r167375? Since it still occurs in r167400 on darwin, the difference between r167372 and r167375 should capture the assembly changes with the absent movq in sse2-init-v2di-2.s on x86_64-apple-darwin10. I don't need to see the assembly code to know revision 167375 is bad. Please show the output from revision 167398 or above.
[Bug tree-optimization/46787] Does not vectorize loop with load from scalar variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46787
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03
15:37:16 UTC ---
To fix:
/* FIXME -- data dependence analysis does not work correctly for objects
with invariant addresses in loop nests. Let us fail here until the
problem is fixed. */
if (dr_address_invariant_p (dr) nest)
{
free_data_ref (dr);
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, \tFAILED as dr address is invariant\n);
ret = false;
break;
}
for this to work and be a real improvement we need to pass down the
minimum iterations of the loop (thus, the minimum vectorization factor
in case of the vectorizer).
We can also fix it up locally in the vectorizer when
compute_data_dependences_for_loop would not re-scan the loop
for data references (but we'd do it in the vectorizer and remove
the scalar loads).
We can also avoid computing data dependences until
vect_analyze_data_ref_dependences then and save some compile-time for
non-vectorized loops.
[Bug c/46788] New: unsigned int possible treated as signed in a union/struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46788
Summary: unsigned int possible treated as signed in a
union/struct
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tinokra...@web.de
Created attachment 22618
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22618
a module
When compiling the attached file the compiler does not warn, but the assambler
gives the following error:
C:\DOKUME~1\tkr\LOKALE~1\Temp\ccqr1SmQ.s: Assembler messages:
C:\DOKUME~1\tkr\LOKALE~1\Temp\ccqr1SmQ.s:522: Error: immediate value out of
range -- `movt r3,-32768'
The line dwCalcVal.u_16_values.u_16_value_1=0x8000u; causes the error.
It looks to me like a singned-unsigned fault and in fact it is so. reducing the
constant to a value 0x till 0x7FFF will compile without error.
The problem appears also only when:
- the value is at the stack (local)
- the second value in struct is used (u_16_value_0 works fine).
GCC v 4.3.3 also works fine on the same code.
Configuarion:
-
PC Windows XP with Codesourcery, Target STM32F103 ARM-Controller
arm-none-eabi-gcc.exe -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc.exe
COLLECT_LTO_WRAPPER=c:/temp/codesourcery/bin/../libexec/gcc/arm-none-eabi/4.5.1/lto-wrapper.exe
Target: arm-none-eabi
Configured with:
/scratch/julian/2010q3-release-eabi-lite/src/gcc-4.5-2010.09/configure
--build=i686-pc-linux-gnu --host=i686-mingw32 --target=arm-none-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2010
-D__CS_SOURCERYGXX_MIN__=9 -D__CS_SOURCERYGXX_REV__=51
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
--enable-languages=c,c++ --disable-s
hared --enable-lto --with-newlib --with-pkgversion='Sourcery G++ Lite
2010.09-51' --with-bugurl=https://support.codesourcery.com/GNUToolchain/
--disable-nls --prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-none-eabi
--with-build-sysroot=/scratch/julian/2010q3-release-eabi-lite/install/host-i686-mingw32/arm-none-eabi
--with-libiconv-prefix=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-gmp=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-mpfr=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-mpc=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-ppl=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lst dc++,-Bdynamic -lm'
--with-cloog=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-libelf=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/julian/2010q3-release-eabi-lite/obj/tools-i686-pc-linux-gnu-2010.09-51-arm-none-eabi-i686-mingw32/arm-none-eabi/bin
--with-build-time-tools=/scratch/julian/2010q3-release-eabi-lite/obj/tools-i686-pc-linux-gnu-2010.09-51-arm-none-eabi-i686-mingw32/arm-none-eabi/bin
Thread model: single
gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51)
Call-Parameters:
COLLECT_GCC_OPTIONS='-c' '-mcpu=cortex-m3' '-mthumb' '-mtune=cortex-m3'
'-mfix-cortex-m3-ldrd' '-mlong-calls' '-pedantic' '-mfpu=vfp'
'-mfloat-abi=soft' '-nostdinc' '-Os' '-DLITTLE_ENDIAN' '-v' '-gdwarf-2'
'-fmessage-length=0' '-mlittle-endian' '-fshort-enums' '-mno-thumb-interwork'
'-mstructure-size-boundary=8' '-fno-builtin' '-funsigned-bitfields'
'-Wcast-align' '-Wreturn-type' '-Wimplicit' '-Wunused' '-Wswitch'
'-Wuninitialized' '-o' 'E:\workspace_tkr\FSD-ELMA\trunk\out/SA1/ALGAac1.o'
'-D__CS_SOURCERYGXX_MAJ__=2010' '-D__CS_SOURCERYGXX_MIN__=9'
'-D__CS_SOURCERYGXX_REV__=51'
e:/toolhome/arm/codesourcery/v_4_5_1/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/as.exe
-v -EL -mcpu=cortex-m3 -mfloat-abi=soft -mfpu=vfp -meabi=5 -alhcdn -o
E:\workspace_tkr\FSD-ELMA\trunk\out/SA1/ALGAac1.o
C:\DOKUME~1\tkr\LOKALE~1\Temp\ccqr1SmQ.s
GNU assembler version 2.20.51 (arm-none-eabi) using BFD version (Sourcery G++
Lite 2010.09-51) 2.20.51.20100809
[Bug libstdc++/45133] [c++0x] std::future will crash with NULL deref if get() is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |ASSIGNED --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-03 15:38:53 UTC --- The latest draft still says this is undefined behaviour, but has a note encouraging implementations to detect this case and throw. I am suitably encouraged. I'll start by doing that conditionally when _GLIBCXX_DEBUG is defined...
[Bug tree-optimization/46781] [4.6 Regression] Missing optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46781 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Attachment #22612|application/octet-stream|text/plain mime type|| --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2010-12-03 15:39:16 UTC --- Comment on attachment 22612 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22612 Code produced by GCC 4.6.0 (In reply to comment #2) Where did you get this testcase from? May I know why do you ask? IIRC, it was distilled from some large program. There was a difference when compiling it with and without LTO, and I reported it as a bug 43201.
[Bug tree-optimization/46785] Doesn't vectorize reduction x += y*y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46785 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 15:39:49 UTC --- Btw, I wonder why we bother to check the defs at all and not just do def1 flow_bb_inside_loop_p (loop, gimple_bb (def1)) we should be able to handle all vectorizable reduction operands, and their vectorizability will be determined anyway.
[Bug lto/46769] LTO failed to build gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-12-03 15:42:47 UTC --- From http://www.kernel.org/pub/linux/devel/gcc/lto/ld-new.ltrans1.o.bz2 [...@gnu-6 gold]$ /usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto1 -quiet -dumpdir ./ -dumpbase ld-new.ltrans1 -mtune=generic -march=x86-64 -auxbase-strip ld-new.ltrans1.ltrans.o -g -O2 -Wextra -Wall -Werror -version -frandom-seed=ld-new -fuse-linker-plugin -frandom-seed=1 -fltrans ld-new.ltrans1.o -o ld-new.ltrans1.s GNU GIMPLE (GCC) version 4.6.0 20101202 (experimental) [trunk revision 167368] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101202 (experimental) [trunk revision 167368], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 4.6.0 20101202 (experimental) [trunk revision 167368] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101202 (experimental) [trunk revision 167368], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 In file included from /export/gnu/import/git/binutils/gold/options.h:7421:0, from :6349: /export/gnu/import/git/binutils/gold/icf.h: In member function \u2018__base_dtor \u2019: /export/gnu/import/git/binutils/gold/icf.h:62:0: internal compiler error: in force_type_die, at dwarf2out.c:20704 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-6 gold]$
[Bug other/46789] New: go configuration with --prefix=/usr pollutes the /usr/lib namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46789 Summary: go configuration with --prefix=/usr pollutes the /usr/lib namespace Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@ubuntu.com [go/libgo components missing in the bug tracker] with --prefix=/usr libgo pollutes /usr/lib ? is there a recommended way to install the runtime into something like /usr/lib/go? or /usr/lib/go-version - the .gox files maybe should go to /usr/lib/go or /usr/lib/go-version, so that you can have parallel installations of different GCC versions with the same prefix. libjava is doing this too. - libgobegin.a maybe should installed into gcc_lib_dir?
[Bug fortran/44352] ICE in string_to_single_character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-03 15:55:42 UTC --- This works: character*2 ddname,dname dname(x)= 'x ' ddname=dname(0.0) END We fail to pad the string for this case.
[Bug middle-end/46745] [4.6 Regression] '#'mem_ref' not supported by dump_expr#expression error'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46745 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 16:10:43 UTC --- Author: rguenth Date: Fri Dec 3 16:10:36 2010 New Revision: 167433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167433 Log: 2010-12-03 Richard Guenther rguent...@suse.de PR c/46745 * c-pretty-print.c (pp_c_postfix_expression): Handle MEM_REF. (pp_c_unary_expression): Likewise. (pp_c_expression): Likewise. cp/ * error.c (dump_expr): Handle MEM_REF. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03 16:20:12 UTC --- Created attachment 22619 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22619 assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10 at r167430
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03 16:20:59 UTC --- Created attachment 22620 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22620 assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10 at r167430 with darwin core2 patch
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #14 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03 16:22:05 UTC --- Created attachment 22621 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22621 darwin core2 patch
[Bug middle-end/46745] [4.6 Regression] '#'mem_ref' not supported by dump_expr#expression error'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46745 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 16:23:00 UTC --- Fixed.
[Bug lto/46769] LTO failed to build gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 16:24:25 UTC --- Can you use partial linking and reduce the set of object files (best when reproducing with -flto-partition=none) and then attach preprocessed sources of them? LTO object code testcases are not very useful. Thanks, Richard.
[Bug c/46788] unsigned int possible treated as signed in a union/struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46788 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 16:25:40 UTC --- Please report to CodeSourcery or use a FSF version.
[Bug preprocessor/46784] Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46784 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.03 16:27:51 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-03 16:27:51 UTC --- Also you need to provide preprocessed source for cairo-bentley-ottmann.c and the output of appending -v to the gcc command-line that causes the internal compiler error.
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768
--- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03
16:27:52 UTC ---
I understand the issue now. Stock r167430 is fine but the addition of the
approved patch to fix the md files and default i386 darwin to -mtune=core2
causes the failure in...
FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq
Apparently the darwin core2 patch will also need to correct the
sse2-init-v2di-2.c testcase with...
Index: gcc.target/i386/sse2-init-v2di-2.c
===
--- gcc.target/i386/sse2-init-v2di-2.c(revision 167430)
+++ gcc.target/i386/sse2-init-v2di-2.c(working copy)
@@ -10,4 +10,4 @@
return _mm_cvtsi64_si128 (b);
}
-/* { dg-final { scan-assembler movq } } */
+/* { dg-final { scan-assembler movd } } */
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-03 16:29:31 UTC --- Note the original i386 darwin patch with the rational for the movq to movd assembly changes can be found at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01024.html.
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768
--- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2010-12-03 16:40:25
UTC ---
(In reply to comment #15)
I understand the issue now. Stock r167430 is fine but the addition of the
approved patch to fix the md files and default i386 darwin to -mtune=core2
causes the failure in...
FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq
Apparently the darwin core2 patch will also need to correct the
sse2-init-v2di-2.c testcase with...
Index: gcc.target/i386/sse2-init-v2di-2.c
===
--- gcc.target/i386/sse2-init-v2di-2.c(revision 167430)
+++ gcc.target/i386/sse2-init-v2di-2.c(working copy)
@@ -10,4 +10,4 @@
return _mm_cvtsi64_si128 (b);
}
-/* { dg-final { scan-assembler movq } } */
+/* { dg-final { scan-assembler movd } } */
That is incorrect. I will fix it properly after Dwarn patch is checked in.
[Bug middle-end/46761] [4.6 Regression] -fgraphite-identity produces wrong code for array initialization arr[i] = i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46761 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov amonakov at gcc dot gnu.org 2010-12-03 16:54:26 UTC --- Sometimes graphite generates wrong guards for regions. The following patch fixes the attached testcase for me, but I have not tested it any further. diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c index 9a90ef7..8a80033 100644 --- a/gcc/graphite-clast-to-gimple.c +++ b/gcc/graphite-clast-to-gimple.c @@ -986,7 +986,7 @@ graphite_create_new_loop_guard (sese region, edge entry_edge, : PLUS_EXPR, type, ub, one); /* When ub + 1 wraps around, use lb = ub. */ - if (integer_zerop (ub_one)) + if (TREE_OVERFLOW_P (ub_one)) cond_expr = fold_build2 (LE_EXPR, boolean_type_node, lb, ub); else cond_expr = fold_build2 (LT_EXPR, boolean_type_node, lb, ub_one);
[Bug lto/45638] No rule to make target `check-lto', needed by `check'. Stop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45638 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-12-03 16:54:24 UTC --- Fixed, as far as I can see.
[Bug c++/46058] [4.5/4.6 Regression] gcc crashes with lvalue error on the following Code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46058 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2010-12-03 16:56:42 UTC --- Author: jason Date: Fri Dec 3 16:56:37 2010 New Revision: 167435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167435 Log: PR c++/46058 * tree.c (lvalue_kind) [SCOPE_REF]: Handle non-dependent case. Added: trunk/gcc/testsuite/g++.dg/template/scope4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46123 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2010-12-03 16:56:59 UTC --- Author: jason Date: Fri Dec 3 16:56:53 2010 New Revision: 167436 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167436 Log: PR debug/46123 * dwarf2out.c (gen_tagged_type_die): Don't put local types in a declaration DIE. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr46123.C trunk/gcc/testsuite/g++.dg/debug/pr46123.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671 --- Comment #6 from dave at hiauly1 dot hia.nrc.ca 2010-12-03 17:22:07 UTC --- On Fri, 03 Dec 2010, ro at CeBiTec dot Uni-Bielefeld.DE wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2010-12-03 15:21:51 UTC --- Jan, your patch has broken bootstrap on two platforms for a week now, and there's not even an indication that you're looking at the problem. Please fix or revert ASAP. The implementation of default_function_section in the change is elf specific. As a result, all targets that don't use elf sections are broken by the change. Even if I define TARGET_ASM_FUNCTION_SECTION, this will still leave the other targets that don't use elf sections broken. Elf sections were never the default before. The change was applied during stage3 and it wasn't a bug fix. So, the commit was questionable. Dave
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888 --- Comment #21 from Anh Vo anhvofrcaus at gmail dot com 2010-12-03 17:45:58 UTC --- Executing command 'file gcc/doc/tm.texi' yields ../gcc-4.6-20101113/gcc/doc/tm.texi: ASCII English text, with CRLF line terminators. However, executing command 'file gcc/tm.texi' in the build directory outputs gcc/tm.texi: ASCII English text, with very long lines. Obviously, the results are not the same.
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888 --- Comment #22 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-03 17:57:22 UTC --- (In reply to comment #21) Executing command 'file gcc/doc/tm.texi' yields ../gcc-4.6-20101113/gcc/doc/tm.texi: ASCII English text, with CRLF line terminators. So, does your source come from untarring a snapshot?
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888 --- Comment #23 from Anh Vo anhvofrcaus at gmail dot com 2010-12-03 18:08:27 UTC --- Yes, it is. In fact, I downloaded it from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101113/. The exact name of the snapshot is gcc-4.6-20101113.tar.bz2.
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #24 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-03 18:15:18 UTC --- (In reply to comment #23) Yes, it is. In fact, I downloaded it from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101113/. The exact name of the snapshot is gcc-4.6-20101113.tar.bz2. So the problem is that when building from an untarred snapshot / release, CRLF translation might have been applied - unlike with svn, where you see wxactly what is in the repository. I suppose we should make a copy of $(srcdir)/doc/tm.texi with \r removed as well, so that the comparison can succeed no matter if \r has been inserted or not.
[Bug lto/46769] LTO failed to build gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2010-12-03 18:28:58 UTC --- Created attachment 22622 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22622 A testcase /usr/gcc-4.6/bin/g++ -r -W -Wall -flto-partition=none -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=ld-new -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -o ld-new i386.ii -nostdlib In file included from :867:0: /export/gnu/import/git/binutils/gold/icf.h: In member function ‘__base_dtor ’: /export/gnu/import/git/binutils/gold/icf.h:62:5: internal compiler error: in force_type_die, at dwarf2out.c:20704 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /usr/gcc-4.6/bin/g++ returned 1 exit status
[Bug middle-end/46790] New: [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 Summary: [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: hubi...@gcc.gnu.org Target: x86_64-unknown-linux-gnu Starting with r167085, test runs on gcc10.fsffrance.org have had a bunch of failures in the libstdc++ testsuite; the testcases fail with calls to terminate() because exceptions are not handled properly. This seems to be due to .gcc_except_table being thrown away by --gc-sections, which in turn seems to be due to the change in the name of text subsections; .text.startup.main no longer matches .gcc_except_table.main, so the heuristic that ld 2.18 uses to keep .gcc_except_table hunks breaks. One test that fails is 18_support/uncaught_exception/14026.cc.
