[Bug tree-optimization/55260] New: [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260 Bug #: 55260 Summary: [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28650 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28650 reduced testcase Compiler output: $ gcc -O2 -std=gnu++0x -fno-inline -fipa-cp-clone testcase.C testcase.C:20:1: internal compiler error: in ipa_get_parm_lattices, at ipa-cp.c:263 } ^ 0x59033c ipa_get_parm_lattices /mnt/svn/gcc-trunk/gcc/ipa-cp.c:263 0x129c1e5 ipa_get_parm_lattices /mnt/svn/gcc-trunk/gcc/ipa-cp.c:2908 0x129c1e5 cgraph_edge_brings_all_agg_vals_for_node /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3082 0x129c1e5 perhaps_add_new_callers /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3134 0x129c1e5 decide_about_value /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3207 0x129dfd0 decide_whether_version_node /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3315 0x129dfd0 ipcp_decision_stage /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3441 0x129dfd0 ipcp_driver /mnt/svn/gcc-trunk/gcc/ipa-cp.c:3483 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r193368 - fail 4.7 r191640 - OK
[Bug target/55258] SSE register isn't used for 16byte copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55258 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 08:52:22 UTC --- Created attachment 28651 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28651 Something like this
[Bug c++/55261] New: [C++0x] ICE (SIGSEGV) when inheriting implicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55261 Bug #: 55261 Summary: [C++0x] ICE (SIGSEGV) when inheriting implicit constructor Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28652 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28652 reduced testcase I don't know if the code is valid. Compiler output: $ gcc testcase.C -std=c++11 testcase.C:4:8: internal compiler error: Segmentation fault struct B : A ^ 0xbc2e9f crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:333 0x6579f9 vec_ttree_node*::operator[](unsigned int) /mnt/svn/gcc-trunk/gcc/vec.h:487 0x6579f9 add_implicitly_declared_members /mnt/svn/gcc-trunk/gcc/cp/class.c:3016 0x65e2b4 check_bases_and_members /mnt/svn/gcc-trunk/gcc/cp/class.c:5343 0x663321 finish_struct_1(tree_node*) /mnt/svn/gcc-trunk/gcc/cp/class.c:6237 0x66558c finish_struct(tree_node*, tree_node*) /mnt/svn/gcc-trunk/gcc/cp/class.c:6545 0x69413e cp_parser_class_specifier_1 /mnt/svn/gcc-trunk/gcc/cp/parser.c:18231 0x69413e cp_parser_class_specifier /mnt/svn/gcc-trunk/gcc/cp/parser.c:18440 0x69413e cp_parser_type_specifier /mnt/svn/gcc-trunk/gcc/cp/parser.c:13568 0x6ab3cd cp_parser_decl_specifier_seq /mnt/svn/gcc-trunk/gcc/cp/parser.c:10893 0x6aee09 cp_parser_simple_declaration /mnt/svn/gcc-trunk/gcc/cp/parser.c:10492 0x6b0e57 cp_parser_block_declaration /mnt/svn/gcc-trunk/gcc/cp/parser.c:10441 0x6ba23b cp_parser_declaration /mnt/svn/gcc-trunk/gcc/cp/parser.c:10338 0x6b886d cp_parser_declaration_seq_opt /mnt/svn/gcc-trunk/gcc/cp/parser.c:10224 0x6b8b62 cp_parser_translation_unit /mnt/svn/gcc-trunk/gcc/cp/parser.c:3796 0x6b8b62 c_parse_file() /mnt/svn/gcc-trunk/gcc/cp/parser.c:28144 0x7bdbe4 c_common_parse_file() /mnt/svn/gcc-trunk/gcc/c-family/c-opts.c:1007 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 09:15:32 UTC --- (In reply to comment #2) (define_insn *movti_internal_rex64 [(set (match_operand:TI 0 nonimmediate_operand =!r ,!o ,x,x ,m) (match_operand:TI 1 general_operand riFo,riF,C,xm,x))] TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1])) Uros, is this change ok for you? If it is ok I can commit the patch only on Wednesday (I'll be away for a few days). Yes, the change looks correct to me. I'll take care of the patch.
[Bug c++/55262] New: [C++0x] g++.dg/cpp0x/inh-ctor10.C ICEs with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55262
Bug #: 55262
Summary: [C++0x] g++.dg/cpp0x/inh-ctor10.C ICEs with -g
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Created attachment 28653
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28653
preprocessed source
Compiler output:
$ gcc inh-ctor10.ii -std=c++11 -g
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor10.C: In constructor
'B::B(Ts ...) [with Ts = {int}]':
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor10.C:10:12: internal
compiler error: Segmentation fault
using A::A;
^
0xbc2e9f crash_signal
/mnt/svn/gcc-trunk/gcc/toplev.c:333
0x5eb3bb function_parameter_expanded_from_pack_p(tree_node*, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:2869
0x8c826d gen_formal_parameter_pack_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:17119
0x8c826d gen_subprogram_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:17943
0x8ce15c gen_decl_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19990
0x8cbe34 dwarf2out_abstract_function
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:17429
0x8ce148 gen_decl_die
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19947
0x8cf6f8 dwarf2out_function_decl
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:20380
0x94416c rest_of_handle_final
/mnt/svn/gcc-trunk/gcc/final.c:4324
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-193368-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-193368-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.8.0 20121109 (experimental) (GCC)
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 09:22:03 UTC --- (In reply to comment #3) There are 2 issues here: 1. Should we use movdqu(%eax), %xmm0# 19*movti_internal_rex64/4[length = 5] movdqa%xmm0, (%rsp)# 29*movti_internal_rex64/5[length = 5] to copy 16 bytes? Yes, and this is the intention of all these ! marks. 2. Should we split *movti_internal_rex64 if -mno-sse is used? Movti is used for TARGET_64BIT only. Please keep in mind that *_doubleword instructions operate on TImode values, so we rely completely on register allocator to NOT allocate XMM register moves in this case. According to the documentation, ! means that alternative is OK if no reloading is needed, so this fits our purpose to use SSE moves unless we move value directly to TImode arithmetic operation (*_doubleword patterns).
[Bug middle-end/55263] New: [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263 Bug #: 55263 Summary: [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28654 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28654 autoreduced testcase The ICE at the same place as PR54385, but that one is FIXED now. Compiler output: $ gcc -O -fgcse-after-reload -fnon-call-exceptions testcase.C testcase.C: In function 'void foo()': testcase.C:65:1: internal compiler error: in pre_and_rev_post_order_compute, at cfganal.c:875 } ^ 0x827274 pre_and_rev_post_order_compute(int*, int*, bool) /mnt/svn/gcc-trunk/gcc/cfganal.c:875 0x7e19b9 init_alias_analysis() /mnt/svn/gcc-trunk/gcc/alias.c:2852 0xaddc9a gcse_after_reload_main /mnt/svn/gcc-trunk/gcc/postreload-gcse.c:1274 0xaddc9a rest_of_handle_gcse2 /mnt/svn/gcc-trunk/gcc/postreload-gcse.c:1321 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r193368 - crash 4.7 r191640 - OK
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #9 from uros at gcc dot gnu.org 2012-11-10 11:28:17 UTC --- Author: uros Date: Sat Nov 10 11:28:12 2012 New Revision: 193388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193388 Log: PR target/55247 * config/i386/i386.md (*movti_internal_rex64): Add ! to riF-o alternative. testsuite/ChangeLog: PR target/55247 * gcc.target/i386/pr55247.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55247.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-10 Component|rtl-optimization|middle-end Ever Confirmed|0 |1 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 11:47:05 UTC --- Recategorizing due to middle-end issue, see comment #5 and #6.
[Bug middle-end/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 11:55:55 UTC --- ~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c results in following sequence: movdqu (%eax), %xmm0 movdqa %xmm0, (%rsp) movq(%rsp), %rax movq8(%rsp), %rdx movq%rax, 16(%rsp) movq%rdx, 24(%rsp) while -maddress=mode=short produces expected code: movq8(%eax), %rdx movq(%eax), %rax movq%rdx, 8(%esp) movq%rax, (%esp)
[Bug target/15184] [4.6/4.7/4.8 Regression] Direct access to byte inside word not working with -march=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 --- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 12:15:14 UTC --- (In reply to comment #20) Please can the RMs have a new look at this. This is tuning decision, and I see Intel folks in the CC. I see no problem in changing these defaults, if they are supported by some benchmark results.
[Bug target/54716] Select best typed instruction for bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Marc Glisse glisse at gcc dot gnu.org 2012-11-10 12:55:43 UTC --- It looks like Jakub's patch fixed this completely. I now see -mavx: vorpd, vorpd, vorps -mavx2: vorpd, vorpd, vpor so closing.
[Bug target/15184] [4.6/4.7/4.8 Regression] Direct access to byte inside word not working with -march=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 --- Comment #22 from Mikael Pettersson mikpe at it dot uu.se 2012-11-10 13:36:46 UTC --- Created attachment 28655 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28655 another test case I'm using a construct similar to the 'f1' function of the initial test case to set the low 8 or 16 bits of a 32-bit register in a CPU emulator of mine, and the code generated by gcc 4.6/4.7/4.8 for this on x86_64 is appalling. In the attached test case, the setb1 and setw1 functions use bit and/or operations, while the setb2 and setw2 functions assign the sub-field directly via a union. gcc compiles each set*2 function to a single mov (+ ret), while each set*1 function becomes 5 instructions (+ ret).
[Bug tree-optimization/55264] New: [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Bug #: 55264 Summary: [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28656 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28656 preprocessed source (g++.dg/tree-ssa/pr45453.C) Compiler output: $ gcc -O2 -fno-early-inlining -fno-weak pr45453.ii /mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr45453.C:16:1: internal compiler error: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 } ^ 0xa220d7 ipa_make_edge_direct_to_target(cgraph_edge*, tree_node*) /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2141 0xa29cec try_make_edge_direct_virtual_call /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2245 0xa29cec update_indirect_edges_after_inlining /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2316 0xa29cec propagate_info_to_inlined_callees /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2356 0xa29c2e propagate_info_to_inlined_callees /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2360 0xa29f08 ipa_propagate_indirect_call_infos(cgraph_edge*, vec_tcgraph_edge***) /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2386 0x12a7864 inline_call(cgraph_edge*, bool, vec_tcgraph_edge***, int*, bool) /mnt/svn/gcc-trunk/gcc/ipa-inline-transform.c:259 0x12a6932 inline_small_functions /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1609 0x12a6932 ipa_inline /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1791 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r193387 - crash 4.7 r191640 - crash 4.6 r191640 - crash 4.5 r191640 - OK
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #26 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-10 14:38:03 UTC --- Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate.
[Bug middle-end/55266] New: vector expansion: 36 movs for 4 adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
Bug #: 55266
Summary: vector expansion: 36 movs for 4 adds
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
I already mentioned this example, but I don't think it is in any PR:
typedef double vec __attribute__((vector_size(4*sizeof(double;
void f(vec*x){
*x+=*x+*x;
}
compiled with -S -O3 -msse4, produces 4 add insns (normal), and 36 mov insns,
which is a bit much... For comparison, this should be equivalent to the
following code, which generates only 6 mov insn:
typedef double vec __attribute__((vector_size(2*sizeof(double;
void f(vec*x){
x[0]+=x[0]+x[0];
x[1]+=x[1]+x[1];
}
One minor enhancement would be to have fold_ternary handle BIT_FIELD_REF of
CONSTRUCTOR of vectors (I think it is already tracked elsewhere, though I
couldn't find it).
But the main issue is with copying these fake vectors. Their fake registers
are in memory, and copying between those (4 times 2 movs going through rax in
DImode, I assume it is faster than going through xmm registers?) isn't
optimized away. In this example, the content of *x is first copied to a fake
register. Then V2DF parts are extracted, added, and put in memory. That fake
register is now copied to a new fake register. V2DF are taken from it, added to
the V2DF that were still there, and stored to memory. And that is finally
copied to the memory location x.
I don't know how that should be improved. Maybe the vector lowering pass should
go even further, turn the first program into the second one, and not leave any
extra long vectors for the back-end to handle? It doesn't seem easy to optimize
in the back-end, too late. Or maybe something can be done at expansion time?
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-10 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-10 17:07:57 UTC --- With current trunk (r193391) I see a different ICE: /mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/tree-ssa/pr45453.C:16:1: internal compiler error: in inline_call, at ipa-inline-transform.c:269 0xec0114 inline_call(cgraph_edge*, bool, vec_tcgraph_edge***, int*, bool) /home/polacek/src/gcc/gcc/ipa-inline-transform.c:269 0xebefb8 inline_small_functions /home/polacek/src/gcc/gcc/ipa-inline.c:1553 0xebf492 ipa_inline /home/polacek/src/gcc/gcc/ipa-inline.c:1735 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/55267] New: double operation giving different results depending on context and optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55267
Bug #: 55267
Summary: double operation giving different results depending on
context and optimization level
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jkuittinen293...@gmail.com
/*
* the following code outputs :o on 4.7.2 when compiled with -O0
* and :) when compiled with -O1
*
*/
#include iostream
class Plap
{
public:
double value;
Plap(int a, int b)
{
value = (double)a / (double)b;
}
};
int main()
{
int i = 1;
int j = 3;
Plap plap(i, j);
if (plap.value != ((double)i / (double)j))
std::cout :o std::endl;
else
std::cout :) std::endl;
return 0;
}
[Bug c++/55267] double operation giving different results depending on context and optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55267 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10 17:49:20 UTC --- I bet this is a dup of bug 323.
[Bug middle-end/55263] [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-10 CC||mpolacek at gcc dot ||gnu.org, steven at gcc dot ||gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-10 18:24:15 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=190602
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10 18:32:27 UTC --- Author: pinskia Date: Sat Nov 10 18:32:23 2012 New Revision: 193393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193393 Log: 2012-11-10 Andrew Pinski apin...@cavium.com PR bootstrap/55202 * configure.ac: Set PLUGIN_LD_SUFFIX to just ld if it was ld-new or collect-ld. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10 18:32:51 UTC --- Fixed.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |UNCONFIRMED Component|middle-end |rtl-optimization Depends on||55259 Ever Confirmed|1 |0 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 19:02:04 UTC --- (In reply to comment #11) ~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c results in following sequence: movdqu (%eax), %xmm0 movdqa %xmm0, (%rsp) movq(%rsp), %rax movq8(%rsp), %rdx movq%rax, 16(%rsp) movq%rdx, 24(%rsp) while -maddress=mode=short produces expected code: movq8(%eax), %rdx movq(%eax), %rax movq%rdx, 8(%esp) movq%rax, (%esp) This is related to PR 55259. This patch: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00799.html fixes it.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 19:11:03 UTC --- (In reply to comment #12) (In reply to comment #11) ~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c results in following sequence: movdqu (%eax), %xmm0 movdqa %xmm0, (%rsp) movq(%rsp), %rax movq8(%rsp), %rdx movq%rax, 16(%rsp) movq%rdx, 24(%rsp) while -maddress=mode=short produces expected code: movq8(%eax), %rdx movq(%eax), %rax movq%rdx, 8(%esp) movq%rax, (%esp) This is related to PR 55259. This patch: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00799.html fixes it. With this fix, we don't need to change *movti_internal_rex64 since it generates redundant load/store.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #14 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 19:41:31 UTC --- (In reply to comment #13) With this fix, we don't need to change *movti_internal_rex64 since it generates redundant load/store. True, IIRC this was the reason for asymmetry in alternatives. Please revert the *movti_internal_rex64 change when the middle-end patch goes in.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #27 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-10 20:21:41 UTC --- (In reply to comment #26) Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate. IMHO the correct fix is to not seek and/or truncate the file unless the Fortran semantics require it; that way libgfortran does not need to care whether the file is special or not. As explained in #c23, special files are special in different ways (also different on different OS'es), and trying to enumerate all the ways in which they are special is bound to fail. I think Tobias comment #c24 pinpoints the place which needs to be fixed, but unfortunately I haven't had time to look into it.
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-10 22:58:16 UTC --- Hum, I am not sure why the macro unwinder avoids unwinding if the macro comes from a system-header. If a warning message comes from a system-header, then it should have been suppressed earlier and never reach the macro unwinder. Otherwise, we already have emitted the diagnostic, so the macro unwinder just provides more context.
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-10 23:10:32 UTC --- On the other hand, let's consider: pr55252.c: #define bar 256 #include pr55252.h pr55252.h: #pragma GCC system_header signed char foo = bar; In this case, I would expect the warning to be suppressed (as it is with -ftrack-macro-expansion=0). However, since the warning is actually given in the C file, it is emitted. I am getting more and more convinced that expanding to spelling point might not be the best (I think Paolo Bonzini raised this issue at the time...). On the other hand, this is a very contrived testcase. I wouldn't expect in normal code that the expansion point to be in a system-header and the spelling point in a non-system-header. Dodji, what do you think?
[Bug tree-optimization/55200] RubyLang complex.c Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200 Chris Lundquist clundquist at bluebox dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Chris Lundquist clundquist at bluebox dot net 2012-11-10 23:11:04 UTC --- Fixed in latest release. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/lto-wrapper Target: x86_64-apple-darwin12 Configured with: ../gcc-4.8-20121104/configure --prefix=/opt/local --build=x86_64-apple-darwin12 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8-20121104_0' Thread model: posix gcc version 4.8.0 20121104 (experimental) (MacPorts gcc48 4.8-20121104_0)
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-10
23:20:36 UTC ---
(In reply to comment #4)
On the other hand, this is a very contrived testcase. I
wouldn't expect in normal code that the expansion point to be in a
system-header and the spelling point in a non-system-header.
It's not that contrived, here's a more realistic example:
#define fixed 1
#include iostream
int main() { }
This gives a very unhelpful error:
t.cc:1:15: error: expected unqualified-id before numeric constant
#define fixed 1
^
t.cc:1:15: error: expected unqualified-id before numeric constant
#define fixed 1
^
t.cc:1:15: error: expected initializer before numeric constant
[Bug middle-end/55263] [4.8 Regression] ICE: pre_and_rev_post_order_compute, at cfganal.c:875 with -O -fgcse-after-reload -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|steven at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-11-10 23:59:39 UTC --- Index: postreload.c === --- postreload.c(revision 193396) +++ postreload.c(working copy) @@ -2289,8 +2289,9 @@ rest_of_handle_postreload (void) reload_cse_regs (get_insns ()); /* Reload_cse_regs can eliminate potentially-trapping MEMs. Remove any EH edges associated with them. */ - if (cfun-can_throw_non_call_exceptions) -purge_all_dead_edges (); + if (cfun-can_throw_non_call_exceptions + purge_all_dead_edges ()) +cleanup_cfg (0); return 0; }
[Bug target/55268] New: gcc4.8 mingw-w64 Wrong stdcall import symbols generated after rev 193204
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55268 Bug #: 55268 Summary: gcc4.8 mingw-w64 Wrong stdcall import symbols generated after rev 193204 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: squall...@gmail.com Warning: resolving __imp__GetModuleHandleA by linking to __imp__GetModuleHandleA@4 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving __imp__VirtualProtect by linking to __imp__VirtualProtect@16 Warning: resolving __imp__Sleep by linking to __imp__Sleep@4 Warning: resolving __imp__GetLastError by linking to __imp__GetLastError@0 Warning: resolving __imp__TlsGetValue by linking to __imp__TlsGetValue@4 Warning: resolving __imp__GetCurrentThreadId by linking to __imp__GetCurrentThreadId@0 Warning: resolving __imp__VirtualQuery by linking to __imp__VirtualQuery@12 E:/msys/src/gcc/trunk/build/gcc/crtbegin.o:cygming-crtbegin.c:(.text+0x35): undefined reference to `_imp__GetProcAddress' gthr-win32_s.o: In function `_gthr_win32_key_create': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:105: undefined reference to `_imp__TlsAlloc' gthr-win32_s.o: In function `_gthr_win32_key_delete': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:123: undefined reference to `_imp__TlsFree' gthr-win32_s.o: In function `_gthr_win32_getspecific': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:133: undefined reference to `_imp__SetLastError' gthr-win32_s.o: In function `_gthr_win32_setspecific': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:140: undefined reference to `_imp__TlsSetValue' gthr-win32_s.o: In function `_gthr_win32_mutex_init_function': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:150: undefined reference to `_imp__CreateSemaphoreA' gthr-win32_s.o: In function `_gthr_win32_mutex_destroy': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:156: undefined reference to `_imp__CloseHandle' gthr-win32_s.o: In function `_gthr_win32_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:163: undefined reference to `_imp__WaitForSingleObject' gthr-win32_s.o: In function `_gthr_win32_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:187: undefined reference to `_imp__ReleaseSemaphore' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_init_function': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:198: undefined reference to `_imp__CreateSemaphoreA' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:215: undefined reference to `_imp__WaitForSingleObject' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:256: undefined reference to `_imp__ReleaseSemaphore' gthr-win32_s.o: In function `_gthr_win32_recursive_mutex_destroy': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/../../../libgcc/config/i386/gthr-win32.c:265: undefined reference to `_imp__CloseHandle' unwind-dw2-fde_s.o: In function `_gthread_mutex_init_function': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:638: undefined reference to `_imp__CreateSemaphoreA' unwind-dw2-fde_s.o: In function `_gthread_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:655: undefined reference to `_imp__WaitForSingleObject' unwind-dw2-fde_s.o: In function `_gthread_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:689: undefined reference to `_imp__ReleaseSemaphore' unwind-dw2-fde_s.o: In function `_gthread_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:655: undefined reference to `_imp__WaitForSingleObject' unwind-dw2-fde_s.o: In function `_gthread_mutex_unlock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:689: undefined reference to `_imp__ReleaseSemaphore' E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:689: undefined reference to `_imp__ReleaseSemaphore' unwind-dw2-fde_s.o: In function `_gthread_mutex_lock': E:\msys\src\gcc\trunk\build\i686-w64-mingw32\libgcc/./gthr-default.h:655: undefined reference to `_imp__WaitForSingleObject' unwind-dw2-fde_s.o: In function
[Bug treelang/55269] New: Rename tree_node complex field to avoid conflict with C99 complex type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55269 Bug #: 55269 Summary: Rename tree_node complex field to avoid conflict with C99 complex type Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: treelang AssignedTo: unassig...@gcc.gnu.org ReportedBy: pe...@colberg.org Dear GCC developers, The identifier of the union field tree_complex complex of union tree_node in tree.h potentially conflicts with the macro #define complex _Complex defined in C99 complex.h. I stumbled over this issue while writing a plugin for GCC using the foreign function interface of LuaJIT. LuaJIT predefines C99 complex types, both _Complex and complex. Therefore LuaJIT rejects tree_complex complex of tree_node as a declaration with an invalid declaration. Could the tree_complex field be renamed, e.g., to complex_cst? (The suggestion stems from the name of the macro COMPLEX_CST_CHECK.) Regards, Peter
[Bug treelang/55269] Rename tree_node complex field to avoid conflict with C99 complex type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55269 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-11 06:21:55 UTC --- In 4.8, GCC is now written in C++ rather than C, so I don't think it matter anymore as there is no macro define in C++ for complex.
[Bug target/55014] ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC|mikpe at it dot uu.se | --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2012-11-11 07:55:49 UTC --- Fixed by r193052, aka PR54957. However, testing is now made more difficult due to r193032, aka PR52015 -- apparently one now needs bleeding edge mingw-w64 headers to build gcc-4.8 for x86_64-w64-mingw32.
