[Bug c++/25647] New: Large automaticallty generated code (unrolled loop) crashes the compiler
Large automatically generated code (unrolled bubble sort) on std::vectorint crashes the compiler. If there are 1000 elements in the vector, the compiler crashes with the message: g++ ur1000.cc -o ur1000.exe ur1000.cc: In function `int main(int, char**)': ur1000.cc:99799: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Large automaticallty generated code (unrolled loop) crashes the compiler Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jonas dot mellin at his dot se GCC host triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25647
[Bug c++/25647] Large automaticallty generated code (unrolled loop) crashes the compiler
--- Comment #1 from jonas dot mellin at his dot se 2006-01-03 08:03 --- Created an attachment (id=10577) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10577action=view) The code generating the erroneous code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25647
[Bug tree-optimization/23455] tree load PRE is not working properly
--- Comment #8 from bonzini at gnu dot org 2006-01-03 08:04 --- Ehm, wouldn't unsigned char * alias everything? GCSE doesn't do load PRE for me on the original test case, either. Yes, I was checking if load PRE removes the redundant load of t3 if flush_outbuf is not called. See comment #4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
[Bug c++/25637] [3.4/4.0/4.1/4.2 regression] Member definition in wrong scope accepted
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-03 08:38 --- Subject: Bug 25637 Author: mmitchel Date: Tue Jan 3 08:38:22 2006 New Revision: 109268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109268 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25637
[Bug c++/25638] [4.0/4.1/4.2 regression] ICE on templated destructor as friend
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-03 08:38 --- Subject: Bug 25638 Author: mmitchel Date: Tue Jan 3 08:38:22 2006 New Revision: 109268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109268 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25638
[Bug c++/25633] [3.4/4.0/4.1/4.2 regression] ICE on invalid initializer in constructor
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-03 08:38 --- Subject: Bug 25633 Author: mmitchel Date: Tue Jan 3 08:38:22 2006 New Revision: 109268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109268 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25633
[Bug c++/25634] [3.4/4.0/4.1/4.2 regression] Multiple template parameter lists accepted
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-03 08:38 --- Subject: Bug 25634 Author: mmitchel Date: Tue Jan 3 08:38:22 2006 New Revision: 109268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109268 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25634
[Bug c++/25635] [4.0/4.1/4.2 regression] Bogus cruft in error message for invalid operator declaration
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-03 08:38 --- Subject: Bug 25635 Author: mmitchel Date: Tue Jan 3 08:38:22 2006 New Revision: 109268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109268 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25635
[Bug c++/25638] [4.0/4.1/4.2 regression] ICE on templated destructor as friend
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-03 08:40 --- Subject: Bug 25638 Author: mmitchel Date: Tue Jan 3 08:40:18 2006 New Revision: 109269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109269 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25638
[Bug c++/25635] [4.0/4.1/4.2 regression] Bogus cruft in error message for invalid operator declaration
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-03 08:40 --- Subject: Bug 25635 Author: mmitchel Date: Tue Jan 3 08:40:18 2006 New Revision: 109269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109269 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25635
[Bug c++/25633] [3.4/4.0/4.1/4.2 regression] ICE on invalid initializer in constructor
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-03 08:40 --- Subject: Bug 25633 Author: mmitchel Date: Tue Jan 3 08:40:18 2006 New Revision: 109269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109269 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25633
[Bug c++/25634] [3.4/4.0/4.1/4.2 regression] Multiple template parameter lists accepted
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-03 08:40 --- Subject: Bug 25634 Author: mmitchel Date: Tue Jan 3 08:40:18 2006 New Revision: 109269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109269 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25634
[Bug c++/25637] [3.4/4.0/4.1/4.2 regression] Member definition in wrong scope accepted
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-03 08:40 --- Subject: Bug 25637 Author: mmitchel Date: Tue Jan 3 08:40:18 2006 New Revision: 109269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109269 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * decl.c (grokdeclarator): Refine check for invalid declarations/definitions of member functions outside of their own class. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/ctor3.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/error29.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/operator6.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/class3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25637
[Bug c++/25635] [4.0/4.1/4.2 regression] Bogus cruft in error message for invalid operator declaration
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-03 08:41 --- Subject: Bug 25635 Author: mmitchel Date: Tue Jan 3 08:41:21 2006 New Revision: 109270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109270 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * cp-tree.h (do_friend): Adjust prototype. * decl.c (grokfndecl): Make funcdef_flag a bool, not an int. (grokdeclarator): Likewise. Refine check for invalid declarations/definitions of member functions outside of their own class. * friend.c (do_friend): Make funcdef_flag a bool, not an int. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_template_parameter_list): Call begin_template_parm_list and end_template_parm_list here. (cp_parser_type_parameter): Not here. (cp_parser_template_declaration_after_export): Or here. (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. * tree.c (build_target_expr_with_type): Use force_target_expr. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/ctor3.C trunk/gcc/testsuite/g++.dg/parse/dtor6.C trunk/gcc/testsuite/g++.dg/parse/error29.C trunk/gcc/testsuite/g++.dg/parse/operator6.C trunk/gcc/testsuite/g++.dg/template/class3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/friend.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25635
[Bug c++/25638] [4.0/4.1/4.2 regression] ICE on templated destructor as friend
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-03 08:41 --- Subject: Bug 25638 Author: mmitchel Date: Tue Jan 3 08:41:21 2006 New Revision: 109270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109270 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * cp-tree.h (do_friend): Adjust prototype. * decl.c (grokfndecl): Make funcdef_flag a bool, not an int. (grokdeclarator): Likewise. Refine check for invalid declarations/definitions of member functions outside of their own class. * friend.c (do_friend): Make funcdef_flag a bool, not an int. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_template_parameter_list): Call begin_template_parm_list and end_template_parm_list here. (cp_parser_type_parameter): Not here. (cp_parser_template_declaration_after_export): Or here. (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. * tree.c (build_target_expr_with_type): Use force_target_expr. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/ctor3.C trunk/gcc/testsuite/g++.dg/parse/dtor6.C trunk/gcc/testsuite/g++.dg/parse/error29.C trunk/gcc/testsuite/g++.dg/parse/operator6.C trunk/gcc/testsuite/g++.dg/template/class3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/friend.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25638
[Bug c++/25637] [3.4/4.0/4.1/4.2 regression] Member definition in wrong scope accepted
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-03 08:41 --- Subject: Bug 25637 Author: mmitchel Date: Tue Jan 3 08:41:21 2006 New Revision: 109270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109270 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * cp-tree.h (do_friend): Adjust prototype. * decl.c (grokfndecl): Make funcdef_flag a bool, not an int. (grokdeclarator): Likewise. Refine check for invalid declarations/definitions of member functions outside of their own class. * friend.c (do_friend): Make funcdef_flag a bool, not an int. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_template_parameter_list): Call begin_template_parm_list and end_template_parm_list here. (cp_parser_type_parameter): Not here. (cp_parser_template_declaration_after_export): Or here. (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. * tree.c (build_target_expr_with_type): Use force_target_expr. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/ctor3.C trunk/gcc/testsuite/g++.dg/parse/dtor6.C trunk/gcc/testsuite/g++.dg/parse/error29.C trunk/gcc/testsuite/g++.dg/parse/operator6.C trunk/gcc/testsuite/g++.dg/template/class3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/friend.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25637
[Bug c++/25634] [3.4/4.0/4.1/4.2 regression] Multiple template parameter lists accepted
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-03 08:41 --- Subject: Bug 25634 Author: mmitchel Date: Tue Jan 3 08:41:21 2006 New Revision: 109270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109270 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * cp-tree.h (do_friend): Adjust prototype. * decl.c (grokfndecl): Make funcdef_flag a bool, not an int. (grokdeclarator): Likewise. Refine check for invalid declarations/definitions of member functions outside of their own class. * friend.c (do_friend): Make funcdef_flag a bool, not an int. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_template_parameter_list): Call begin_template_parm_list and end_template_parm_list here. (cp_parser_type_parameter): Not here. (cp_parser_template_declaration_after_export): Or here. (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. * tree.c (build_target_expr_with_type): Use force_target_expr. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/ctor3.C trunk/gcc/testsuite/g++.dg/parse/dtor6.C trunk/gcc/testsuite/g++.dg/parse/error29.C trunk/gcc/testsuite/g++.dg/parse/operator6.C trunk/gcc/testsuite/g++.dg/template/class3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/friend.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25634
[Bug c++/25633] [3.4/4.0/4.1/4.2 regression] ICE on invalid initializer in constructor
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-03 08:41 --- Subject: Bug 25633 Author: mmitchel Date: Tue Jan 3 08:41:21 2006 New Revision: 109270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109270 Log: PR c++/25635 * class.c (add_method): Set TYPE_HAS_CONVERSION for classes with a conversion operator. * decl.c (grokdeclarator): Do not set TYPE_HAS_CONVERSION here. PR c++/25638 * class.c (add_method): Never associate more than one destructor with a single class. PR c++/25637 * cp-tree.h (do_friend): Adjust prototype. * decl.c (grokfndecl): Make funcdef_flag a bool, not an int. (grokdeclarator): Likewise. Refine check for invalid declarations/definitions of member functions outside of their own class. * friend.c (do_friend): Make funcdef_flag a bool, not an int. PR c++/25633 * parser.c (cp_parser_mem_initializer_list): Check result of cp_parser_mem_initializer against error_mark_node, not NULL_TREE. (cp_parser_mem_initializer): Return error_mark_node for failure. PR c++/25634 * parser.c (cp_parser_template_parameter_list): Call begin_template_parm_list and end_template_parm_list here. (cp_parser_type_parameter): Not here. (cp_parser_template_declaration_after_export): Or here. (cp_parser_elaborated_type_specifier): Call cp_parser_check_template_parameters. * tree.c (build_target_expr_with_type): Use force_target_expr. PR c++/25635 * g++.dg/parse/operator6.C: New test. PR c++/25637 * g++.dg/parse/error29.C: New test. PR c++/25638 * g++.dg/parse/dtor6.C: New test. PR c++/25633 * g++.dg/parse/ctor3.C: New test. PR c++/25634 * g++.dg/template/class3.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/ctor3.C trunk/gcc/testsuite/g++.dg/parse/dtor6.C trunk/gcc/testsuite/g++.dg/parse/error29.C trunk/gcc/testsuite/g++.dg/parse/operator6.C trunk/gcc/testsuite/g++.dg/template/class3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/friend.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25633
[Bug c++/25635] [4.0/4.1/4.2 regression] Bogus cruft in error message for invalid operator declaration
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-03 08:46 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25635
[Bug c++/25637] [3.4 regression] Member definition in wrong scope accepted
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-03 08:47 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[3.4/4.0/4.1/4.2 regression]|[3.4 regression] Member |Member definition in wrong |definition in wrong scope |scope accepted |accepted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25637
[Bug c++/25638] [4.0/4.1/4.2 regression] ICE on templated destructor as friend
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-03 08:48 --- The ICE is fixed in 4.0.3. Volker, if you consider the diagnostic issue sufficiently important, please open a new PR for that. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25638
[Bug c++/25634] [3.4/ regression] Multiple template parameter lists accepted
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-03 08:48 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[3.4/4.0/4.1/4.2 regression]|[3.4/ regression] Multiple |Multiple template parameter |template parameter lists |lists accepted |accepted Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25634
[Bug c++/25633] [3.4 regression] ICE on invalid initializer in constructor
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-03 08:50 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[3.4/4.0/4.1/4.2 regression]|[3.4 regression] ICE on |ICE on invalid initializer |invalid initializer in |in constructor |constructor Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25633
[Bug c++/25625] [4.0/4.1/4.2 Regression] Fails to compile C++ code when -frepo is specified.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625
[Bug c++/25648] New: Spurious 'might be used uninitialized' warnings in STL headers with -O2
+++ This bug was initially created as a clone of Bug #22207 +++
The following reduced test case causes spurious -Wuninitialized warnings, but
only with -O2:
-
#include vector
#include string
class OptionSet
{
public:
OptionSet ();
std::vectorstd::string const nonOptions() const;
private:
std::vectorstd::string nonoptions;
};
OptionSet::OptionSet()
{
nonoptions = std::vectorstd::string ();
}
std::vectorstd::string const
OptionSet::nonOptions() const
{
return nonoptions;
}
-
$ g++ -Wuninitialized -O2 -c spurious_uninitialized_testcase.cc
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_vector.h: In member
function `std::vector_Tp, _Alloc std::vector_Tp, _Alloc::operator=(const
std::vector_Tp, _Alloc) [with _Tp = std::string, _Alloc =
std::allocatorstd::string]':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_vector.h:715: warning:
'__result' might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82:
warning: '__cur' might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82:
warning: '__cur' might be used uninitialized in this function
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x
--enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization
--enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
-
The warnings only occur at -O2 and seem to have something to do with inlining.
This causes our build that uses -Wall -Werror to die whereas it had no
problem
with this warning in gcc-3.3.
I'm sensitive to the fact that it's impossible for the compiler to get this
warning correct every time, and the reason for the use of might be in the
warning text. It's acceptible to emit warnings about things that may not
actually be the case, and normally I would just modify the build environment to
disable that warning or lose -Werror. But in this case, the code in question
is
in the STL and is completely out of the hands of the user, and I don't think
it's unreasonable to expect to be able to compile STL-based code with -Werror
-Wall.
This warnings also occur on HP/UX.
gcc -v
Reading specs from
/opt/hp-gcc/3.4.4/ilp32/lib/gcc/hppa1.1-hp-hpux11.11/3.4.4/specs
Configured with: /proj/oscp/nightly/gcc/gcc_3_4_4_release/gcc/configure
--enable-languages=c,c++ --enable-threads=posix --with-ld=/usr/ccs/bin/ld
--without-gnu-ld --build=hppa1.1-hp-hpux11.11 --host=hppa1.1-hp-hpux11.11
--target=hppa1.1-hp-hpux11.11 --prefix=/opt/hp-gcc/3.4.4/ilp32
--with-as=/proj/oscp/nightly/gcc/gcc_3_4_4_release/HP-UX/hppa//opt/hp-gcc/3.4.4/ilp32/bin/as
Thread model: posix
gcc version 3.4.4
Oliver
--
Summary: Spurious 'might be used uninitialized' warnings in STL
headers with -O2
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver dot kowalke at gmx dot de
GCC target triplet: hppa*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25648
[Bug c/25183] [4.0/4.1/4.2 Regression] internal compiler error triggered by overflow in constant expression
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-01-03 09:15 --- Subject: Bug 25183 Author: rguenth Date: Tue Jan 3 09:15:08 2006 New Revision: 109272 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109272 Log: 2006-01-03 Richard Guenther [EMAIL PROTECTED] PR c/25183 * stmt.c (add_case_node): Make sure to clear overflow flags from ranges. * gcc.dg/torture/pr25183.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr25183.c Modified: trunk/gcc/ChangeLog trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug c/25183] [4.0/4.1/4.2 Regression] internal compiler error triggered by overflow in constant expression
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-01-03 09:25 --- Subject: Bug 25183 Author: rguenth Date: Tue Jan 3 09:25:29 2006 New Revision: 109273 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109273 Log: 2006-01-03 Richard Guenther [EMAIL PROTECTED] PR c/25183 * stmt.c (add_case_node): Make sure to clear overflow flags from ranges. * gcc.dg/torture/pr25183.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr25183.c - copied unchanged from r109272, trunk/gcc/testsuite/gcc.dg/torture/pr25183.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug c++/25649] New: [g++, regression?] Bogus uninitialized warning
When compiling the code below with current mainline, I get a warning that was
not emitted a few days ago.
#include iostream
using namespace std;
int main()
{
int x;
cin x;
cout x endl;
}
[EMAIL PROTECTED]:~/tmp g++ -v -Wuninitialized -O bla.cc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/martin/software/gcc/configure --quiet
--prefix=/home/martin/software/ugcc --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.2.0 20060102 (experimental)
/home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1plus
-quiet -v -D_GNU_SOURCE bla.cc -quiet -dumpbase bla.cc -mtune=k8 -auxbase bla
-O -Wuninitialized -version -o /tmp/ccSrl6e0.s
ignoring nonexistent directory
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../include/c++/4.2.0
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../include/c++/4.2.0/x86_64-unknown-linux-gnu
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../include/c++/4.2.0/backward
/usr/local/include
/home/martin/software/ugcc/include
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include
/usr/include
End of search list.
GNU C++ version 4.2.0 20060102 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0 20060102 (experimental).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127998
Compiler executable checksum: daaafcb7365564947efcbce06b4e70bb
bla.cc: In function int main():
bla.cc:7: warning: x may be used uninitialized in this function
as -V -Qy -o /tmp/ccbnSz84.o /tmp/ccSrl6e0.s
GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD version
2.16.91.0.2 20050720 (SuSE Linux)
/home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o
-L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0
-L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../..
/tmp/ccbnSz84.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o
/usr/lib/../lib64/crtn.o
This warning is not emitted by the current gomp branch, 4.1 branch and 4.0
branch
Is this intended behavior?
--
Summary: [g++, regression?] Bogus uninitialized warning
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25649
[Bug c/25183] [4.0/4.1/4.2 Regression] internal compiler error triggered by overflow in constant expression
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-01-03 09:30 --- Subject: Bug 25183 Author: rguenth Date: Tue Jan 3 09:30:18 2006 New Revision: 109274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109274 Log: 2006-01-03 Richard Guenther [EMAIL PROTECTED] PR c/25183 * stmt.c (add_case_node): Make sure to clear overflow flags from ranges. * gcc.dg/torture/pr25183.c: New testcase. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/torture/pr25183.c - copied unchanged from r109272, trunk/gcc/testsuite/gcc.dg/torture/pr25183.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/stmt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug c/25183] [4.0/4.1/4.2 Regression] internal compiler error triggered by overflow in constant expression
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-01-03 09:30 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug tree-optimization/23282] [4.0 Regression] wrong results at -O on x86
--- Comment #13 from jv244 at cam dot ac dot uk 2006-01-03 09:36 --- Still causing trouble with gcc version 4.0.3 20060103 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23282
[Bug target/25218] [4.0 Regression] ICE : in compensate_edge, at reg-stack.c:2795
--- Comment #3 from jv244 at cam dot ac dot uk 2006-01-03 09:42 --- (In reply to comment #2) I really mean, -O3 -m32 -fno-unswitch-loops -fno-tree-dominator-opts fails in 4.0.3 but passes in 4.1.0 or 4.2.0. Still getting: /scratch/vondele/gcc_40_branch/build/bin/gcc -O3 -m32 -fno-unswitch-loops -fno-tree-dominator-opts -c test_25218.c test_25218.c: In function drotmg: test_25218.c:20: internal compiler error: in compensate_edge, at reg-stack.c:2795 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. with gcc (GCC) 4.0.3 20060103 (prerelease) I notice now, on an opteron, that the -m32 switch is needed to trigger the bug. There is no crash if I use just '-O3' whereas this happened on a pentium IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
[Bug c++/25492] [4.0/4.1/4.2 Regression] friend class nested in derived class problem
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25492
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-01-03 11:31 --- Adding unshare_expr to constant_value_1 fixes the problem, but causes bootstrap failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug target/25602] internal compiler error while bootstraping (while compiling libobjc/sendmsg.c)
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-03 11:59:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25602
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #46 from ebotcazou at gcc dot gnu dot org 2006-01-03 12:38 --- Mark's change for PR 23171 has eliminated the ICE on PowerPC/Darwin. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug c++/25649] [g++, regression?] Bogus uninitialized warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-03 12:53 --- It works in 20051231. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25649
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #4 from charlet at gcc dot gnu dot org 2006-01-03 13:28 --- The bug is that the following line in s-osinte-linux-hppa.ads is wrong: for atomic_lock_t'Alignment use 8 * 16; The alignment clause takes *bytes*, not *bits*, so you need to use instead: for atomic_lock_t'Alignment use 16; The inconsistency between new and free for objects aligned more than Standard'Maximum_Alignment is indeed a known latent issue that is being worked on and is not trivial to fix, but should not affect the Ada run-time itself (except when a wrong clause is defined as was the case here). Change suggested above pre-approved. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-03 14:12 --- Caused by either: 2005-10-16 Mark Mitchell [EMAIL PROTECTED] PR c++/24389 * decl2.c (mark_used): Use uses_template_parms instead of dependent_type_p. * init.c (constant_value_1): Handle uninstantiated templates specially. * pt.c (instantiate_decl): Add sanity check. or 2005-10-11 Mark Mitchell [EMAIL PROTECTED] PR c++/21089 * call.c (convert_like_real): Use decl_constant_value, not integral_constant_value. * init.c (constant_value_1): New function. (integral_constant_value): Use it. (decl_constant_value): Likewise. * typeck.c (decay_conversion): Use decl_constant_value, not integral_constant_value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug middle-end/23181] [4.1/4.2 Regression] Slowdown of the bresenham line drawing by roughly 20%
--- Comment #19 from dje at gcc dot gnu dot org 2006-01-03 14:54 --- Is this still a regression in 4.2? The code generated for PowerPC now looks better, possibly due to the new reassociation pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
[Bug rtl-optimization/25578] [4.2 Regression] gfortran version 4.2.0 20051227 - 144 new testsuite failures since 2005121
--- Comment #7 from bonzini at gnu dot org 2006-01-03 14:58 --- Subject: Bug 25578 Author: bonzini Date: Tue Jan 3 14:58:05 2006 New Revision: 109281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109281 Log: gcc: 2006-01-03 Paolo Bonzini [EMAIL PROTECTED] PR rtl-optimization/25578 * combine.c (combine_simplify_rtx, force_to_mode): Don't pass a parameter to simplify_shift_const if changing ASHIFTRT to LSHIFTRT. gcc/testsuite: 2006-01-03 Paolo Bonzini [EMAIL PROTECTED] PR rtl-optimization/25578 * gcc.c-torture/execute/20060102-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20060102-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
Re: [Bug tree-optimization/24169] Address (full struct) escapes even though the called function does not cause it to escape
On Sun, 2006-01-01 at 00:41 +, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 00:41 --- Just a clarification here, I just want the SFT for k.j to be considered call clobbered for this testcase. This is not anywhere near as easy as you think it is. In fact, we used to only call clobber k.j. Because our standards experts tell us that doing pointer arithmetic magic to get back to k.i is legal, we could only consider this function to clobber *just* k.j if the pointer doesn't escape from f, *and* f does not do any pointer arithmetic on it's arguments. This is usually *not* the case, making this testcase more or less not interesting at all.
[Bug tree-optimization/24169] Address (full struct) escapes even though the called function does not cause it to escape
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-01-03 14:58 --- Subject: Re: Address (full struct) escapes even though the called function does not cause it to escape On Sun, 2006-01-01 at 00:41 +, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 00:41 --- Just a clarification here, I just want the SFT for k.j to be considered call clobbered for this testcase. This is not anywhere near as easy as you think it is. In fact, we used to only call clobber k.j. Because our standards experts tell us that doing pointer arithmetic magic to get back to k.i is legal, we could only consider this function to clobber *just* k.j if the pointer doesn't escape from f, *and* f does not do any pointer arithmetic on it's arguments. This is usually *not* the case, making this testcase more or less not interesting at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24169
[Bug rtl-optimization/25578] [4.2 Regression] gfortran version 4.2.0 20051227 - 144 new testsuite failures since 2005121
--- Comment #8 from bonzini at gnu dot org 2006-01-03 14:58 --- patch committed -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03 15:03 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** The alignment clause takes *bytes*, not *bits*, so you need to use instead: for atomic_lock_t'Alignment use 16; The inconsistency between new and free for objects aligned more than Standard'Maximum_Alignment is indeed a known latent issue that is being worked on and is not trivial to fix, but should not affect the Ada run-time itself (except when a wrong clause is defined as was the case here). Change suggested above pre-approved. This has been done 2005-12-28 John David Anglin [EMAIL PROTECTED] * s-osinte-linux-hppa.ads: Correct alignment of atomic_lock_t. and it doesn't fix the invalid tcb pointers being passed to free(). Reducing the alignment to 8, fixes the pointer problem. This will work from a locking standpoint, but it's not correct from a struct layout standpoint. However, it might be ok depending on how ada uses atomic_lock_t objects. If ada is going to align malloc'd pointers, then it should keep track of the adjustment or the original pointer so that the memory can be freed using the original pointer. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #6 from charlet at adacore dot com 2006-01-03 15:10 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** and it doesn't fix the invalid tcb pointers being passed to free(). Reducing the alignment to 8, fixes the pointer problem. This will work from a locking standpoint, but it's not correct from a struct layout standpoint. However, it might be ok depending on how ada uses atomic_lock_t objects. Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Is it really the case that the C headers mandate an alignment of 16 for this type which is not guaranteed by malloc ? These alignment issues are very tricky, and GCC also has several notions of maximum alignments, so this are is definitely of that is causing many troubles with Ada when using GCC 3.x or 4.x Ada does not do anything with these directly, so things should be OK, except that it's easy to get a subtle alignment issue/discrepency. If ada is going to align malloc'd pointers, then it should keep track of the adjustment or the original pointer so that the memory can be freed using the original pointer. Right, and this is a non trivial task, hence my previous comment. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug tree-optimization/24123] [4.1/4.2 Regression] Massive performance regression for -ffast-math due to the recip tree pass
--- Comment #22 from dje at gcc dot gnu dot org 2006-01-03 15:22 --- Is it possible for backends to inquire how many reciprocals were discovered? PowerPC and IA-64 have reciprocal instructions and could benefit by choosing to generate reciprocal earlier with additional information about the number of divides calculated. For PowerPC, it is effective to use the instruction if there are multiple divides, such as the three divisions mentioned above. The IBM XLC compiler propagates the reciprocal and numerator pair through its equivalent to RTL. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123
[Bug tree-optimization/24123] [4.1/4.2 Regression] Massive performance regression for -ffast-math due to the recip tree pass
--- Comment #23 from bonzini at gnu dot org 2006-01-03 15:30 --- For PowerPC, it is effective to use the instruction if there are multiple divides, such as the three divisions mentioned above. The IBM XLC compiler propagates the reciprocal and numerator pair through its equivalent to RTL. I am not sure I follow you. I see two questions, but it could be that you asked neither: 1) You want to use the reciprocal instruction instead of a FP divide. This could be done in the expander, or with a new RECIP_EXPR tree code. I'd rather do the former. 2) Multiplying by the result of the reciprocal instruction always provides the exact result of the division, so you want to enable the pass always. It could be possible to parameterize the recip pass on a separate -fdivide-by-reciprocals flag, turned on by -funsafe-math-optimization, but also always turned on in config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123
[Bug other/25035] [4.1/4.2 regression] Building an avr cross compiler fails (libssp)
--- Comment #3 from bjoern dot m dot haase at web dot de 2006-01-03 15:33 --- A patch for this issue is posted at the gcc-patches list and waits for review. The difficulty is that libssp silently assumes that unix-style stdio is available :-( which is not the case for embedded targets. Bjoern -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03 15:49 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Unfortunately, yes. The fundamental issue is that ldcw is the only atomic memory operation available in PA 1.x, and it requires a 16-byte alignment. In PA 2.0, this is relaxed to 4-byte alignment when the operation is coherent. The linux folks weren't willing to to throw out their PA 1.1 hardware, so we have this 16-byte alignment... Is it really the case that the C headers mandate an alignment of 16 for this type which is not guaranteed by malloc ? These alignment issues are very tricky, and GCC also has several notions of maximum alignments, so this are is definitely of that is causing many troubles with Ada when using GCC 3.x or 4.x Agreed. Because of these issues, I came up with the scheme to make the size of the atomic_lock_t type 16 bytes. The pthread code dynamically picks the aligned 4-byte integer for the ldcw. Thus, the atomic_lock_t type now only needs 4-byte alignment. However, the 16-byte alignment attribute was retained for compatibility. There are some limitations to this scheme and I think the TLS thread implementation will do locking with a light-weight syscall rather than ldcw. This might reduce the alignment requirement to 4 bytes. Ada does not do anything with these directly, so things should be OK, except that it's easy to get a subtle alignment issue/discrepency. If ada is going to align malloc'd pointers, then it should keep track of the adjustment or the original pointer so that the memory can be freed using the original pointer. Right, and this is a non trivial task, hence my previous comment. Ok, then I think the alignment should be reduced to 4 or 8. I've done a number of builds using an alignment of 8. There's only one fail in 4.0.3: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00025.html RUN cxg1005 ,.,. CXG1005 ACATS 2.5 06-01-01 01:38:37 CXG1005 Check that the subprograms defined in the package Generic_Complex_Elementary_Functions provide correct results. * CXG1005 Non-imaginary result from Function Log with a minus one input value. * CXG1005 Non-real result from Function Arcsin with a minus one input value. * CXG1005 Non-real result from Function Arccos with a minus one input value. CXG1005 FAILED . FAIL: cxg1005 I checked the first issue in C and clog(-1.0) seems ok. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug tree-optimization/24123] [4.1/4.2 Regression] Massive performance regression for -ffast-math due to the recip tree pass
--- Comment #24 from dje at gcc dot gnu dot org 2006-01-03 15:50 --- Comment #21 mentions three divisions for the optimization to be more profitable, but that information is lost by the time GCC reaches the expanders. Minimally, it would be helpful to know that the reciprocal optimization found more than three divides. If the backend knew that it were calculating a reciprocal instead of 1./x division and that the reciprocal only occurs when more than two divides are present, it could produce better code. For both PowerPC and IA-64, it would be helpful to have RECIP_EXPR and the pair that completes division because both archtectures could then explicitly use their reciprocal instructions and fully schedule the Newton-Raphson or power-series expansion for the closure instead of generating the 1./x reciprocal as a full divide and the lower accuracy, isolated numerator multiplication separately. If the backends had more complete information, the reciprocal optimization could be extended beyond -ffast-math for some targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123
[Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-03 15:54 --- 4.2.0 produces good code on x86 also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.0 3.4.0 |4.0.0 3.4.0 4.2.0 Summary|[4.1/4.2 Regression]|[4.1 Regression] Slowdown of |Slowdown of the bresenham |the bresenham line drawing |line drawing by roughly 20% |by roughly 20% http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
charlet at adacore dot com wrote: Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Yes, the latter is 8, computed from GCC's BIGGEST_ALIGNMENT. Is it really the case that the C headers mandate an alignment of 16 for this type which is not guaranteed by malloc ? IIUC, it asks for a 16 bytes alignment consciously knowing that it likely won't get it in terms of objects' _addresses_. Now the request will still impact component _offsets_ within records (make them multiple of 16), as Dave points out, and not matching it in Ada might indeed cause various troubles. The big difference between Ada and C here is that the alignment must also be obeyed for objects addresses in Ada, which is why the allocator return address is rounded up (together with the size argument). If ada is going to align malloc'd pointers, then it should keep track of the adjustment or the original pointer so that the memory can be freed using the original pointer. Right, and this is a non trivial task, hence my previous comment. Right. Preliminary attempts at fixing this a while ago made it necessary to touch expand_expr and is_alignin_offset, fairly deep in the back end. Will look it up again.
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #8 from hainque at adacore dot com 2006-01-03 16:25 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** charlet at adacore dot com wrote: Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Yes, the latter is 8, computed from GCC's BIGGEST_ALIGNMENT. Is it really the case that the C headers mandate an alignment of 16 for this type which is not guaranteed by malloc ? IIUC, it asks for a 16 bytes alignment consciously knowing that it likely won't get it in terms of objects' _addresses_. Now the request will still impact component _offsets_ within records (make them multiple of 16), as Dave points out, and not matching it in Ada might indeed cause various troubles. The big difference between Ada and C here is that the alignment must also be obeyed for objects addresses in Ada, which is why the allocator return address is rounded up (together with the size argument). If ada is going to align malloc'd pointers, then it should keep track of the adjustment or the original pointer so that the memory can be freed using the original pointer. Right, and this is a non trivial task, hence my previous comment. Right. Preliminary attempts at fixing this a while ago made it necessary to touch expand_expr and is_alignin_offset, fairly deep in the back end. Will look it up again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug fortran/25252] ICE on invalid code
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-03 16:25 --- Not powerpc-specific. -- dje at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-03 16:27 --- Not powerpc-specific. -- dje at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/24878] subroutine getting called illegally as a function
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-03 16:29 --- Not powerpc-specific. -- dje at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
[Bug boehm-gc/25652] New: Java support for amd64-pc-freebsd
Hello, Java is not supported for the amd64--freebsd targets, essentially because of lacking support in boehm-gc. I created a simple patch to do so : - no credits to me: most of this is directly inspired by the official freebsd-port of boehm-gc - tested for over 6 months on a non-graphical application with long-lasting scientific calculations (mixing C++, Fortran and Java code) Concerning the patch : - the boehm-gc/include/gc_cpp.h-diff is only to quiet the compiler, - the GC_parallel-diff in boehm-gc/pthread_support.c is not amd64--freebsd specific, but I did not test without it. Thanx for your great work. -- Summary: Java support for amd64-pc-freebsd Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arno at heho dot snv dot jussieu dot fr GCC target triplet: amd64-pc-freebsd[56] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
[Bug boehm-gc/25652] Java support for amd64-pc-freebsd
--- Comment #1 from arno at heho dot snv dot jussieu dot fr 2006-01-03 16:43 --- Created an attachment (id=10578) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10578action=view) Add support for amd64--freebsd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
[Bug fortran/24886] another runtime error goes undetected
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-03 16:59 --- Not PPC specific. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug fortran/24759] Unclear error message for a syntax error
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 17:04 --- Not PPC specific. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc-apple-darwin8.3.0 | GCC host triplet|powerpc-apple-darwin8.3.0 | GCC target triplet|powerpc-apple-darwin8.3.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24759
[Bug fortran/24646] accepting invalid label
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 17:06 --- Not PPC specific. Also fixed in 4.1.0 and above: In file t.f90:3 19 real :: a=5 1 Error: Too many digits in statement label at (1) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24646
[Bug fortran/24866] internal compiler error
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 17:07 --- Not PPC specific. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | Last reconfirmed|2005-11-15 04:21:39 |2006-01-03 17:07:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24866
[Bug fortran/24640] [4.1] ice with invalid label
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-03 17:09 --- Not PPC specific. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24640
[Bug tree-optimization/23455] tree load PRE is not working properly
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-01-03 18:29 --- Load PRE on globals is going to take a while, because we do some stupid things in hashing (like hashing tcc_declaration's by pointer, instead of DECL_UID). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
[Bug fortran/19777] -fbounds-check catches non-existent bounds violation
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-03 18:36 ---
Here is a newer patch which fixes it:
Index: trans-array.c
===
--- trans-array.c (revision 109225)
+++ trans-array.c (working copy)
@@ -1942,7 +1942,7 @@ gfc_conv_array_ref (gfc_se * se, gfc_arr
gfc_conv_expr_type (indexse, ar-start[n], gfc_array_index_type);
gfc_add_block_to_block (se-pre, indexse.pre);
- if (flag_bounds_check)
+ if (flag_bounds_check ar-as-type != AS_ASSUMED_SIZE)
{
/* Check array bounds. */
tree cond;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19777
[Bug tree-optimization/24001] Simple redundancy not eliminated
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-01-03 18:39 --- You are confused about what load PRE does. It will not lift these load because it is not partially redundant. You are looking for some sort of generic code hoister. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24001
[Bug fortran/22210] gfc_conv_array_initializer weirdness
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-03 18:45 --- Steven, I am assigning this from your suse account (one which does exist any more) to your @gcc.gnu.org account, if you don't have the time to look into this again, can you assign it to me as I was looking into it and semi saw what was wrong but I did not know if you had a patch or not to fix this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|stevenb at suse dot de |steven at gcc dot gnu dot ||org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
[Bug c++/25294] [4.0 Regression] Bogus unterminated comment error from #pragma comment
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-03 18:49 --- Of course this is not fixed in 4.0.x yet so reopening. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail|4.0.0 4.1.0 4.2.0 |4.0.0 Known to work|3.4.0 |3.4.0 4.1.0 4.2.0 Resolution|FIXED | Summary|[4.0/4.1/4.2 Regression]|[4.0 Regression] Bogus |Bogus unterminated comment|unterminated comment error |error from #pragma comment |from #pragma comment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25294
[Bug libstdc++/25653] New: Documentation bug in ext/stdio_filebuf.h
Using libstdc++, I've got code like this: __gnu_cxx::stdio_filebufchar fdbuf(fd, std::ios::in); The doxygen docs for this fd ctor say The file descriptor will be automatically closed when the stdio_filebuf is closed/destroyed., but I appear to be leaking fds due to making the assumption I was passing ownership of the fd to this streambuf, and not closing it by hand. Is this a documentation bug? I've checked ext/stdio_filebuf.h, and I can't see any referece to close(). The docs for the FILE* ctor say The FILE* will **not** be automatically closed when the stdio_filebuf is closed/destroyed., so it looks like the docs are wrong in this case. If this is true, just adding not should fix it: --- stdio_filebuf.h.old 2006-01-03 18:49:58.653951737 + +++ stdio_filebuf.h 2006-01-03 18:50:31.536432330 + @@ -72,7 +72,7 @@ * @param size Optimal or preferred size of internal buffer, in chars.* * This constructor associates a file stream buffer with an open - * POSIX file descriptor. The file descriptor will be automatically + * POSIX file descriptor. The file descriptor will not be automatically * closed when the stdio_filebuf is closed/destroyed. */ stdio_filebuf(int __fd, std::ios_base::openmode __mode, Regards, Roger -- Summary: Documentation bug in ext/stdio_filebuf.h Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rleigh at debian dot org GCC build triplet: powerpc-linux-gnu GCC host triplet: powerpc-linux-gnu GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 --- For most (if not all) s-osinte*.ads C type redeclarations, I believe it should be sufficient to use a record containing a System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an alignement clause (I don't know if C or GNU C allows to retrieve the alignment of a struct like sizeof for size). Arnaud, do you remember non opaque C types in s-osinte? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug c/25645] gcc search for header files in /usr/local/include before command-line specified directories
--- Comment #1 from palladia at yahoo dot com 2006-01-03 19:25 --- $which gcc /home/gfleming/local/bin/gcc $gcc -v Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.0.2/configure --prefix=/home/gfleming/local --enable-language=c,c++,java Thread model: posix gcc version 4.0.2 $pwd /home/gfleming/xemacs-21.5.24/src $gcc -E -I/home/gfleming/local/include -I. glyphs-eimage.c | grep png.h # 1 /usr/local/include/png.h 1 3 # 211 /usr/local/include/png.h 3 # 212 /usr/local/include/png.h 2 3 # 215 /usr/local/include/png.h 2 3 ... $gcc -E -I. glyphs-eimage.c | grep png.h # 1 /usr/local/include/png.h 1 3 # 211 /usr/local/include/png.h 3 # 212 /usr/local/include/png.h 2 3 # 215 /usr/local/include/png.h 2 3 ... $gcc -E -B/home/gfleming/local -I. glyphs-eimage.c | grep png.h # 1 /home/gfleming/local/include/png.h 1 3 4 # 359 /home/gfleming/local/include/png.h 3 4 # 360 /home/gfleming/local/include/png.h 2 3 4 # 364 /home/gfleming/local/include/png.h 2 3 4 ... $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25645
[Bug fortran/24430] internal compiler error: in convert_move, at expr.c:362
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-03 19:29 --- Closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24430
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 --- For most (if not all) s-osinte*.ads C type redeclarations, I believe it should be sufficient to use a record containing a System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an alignement clause (I don't know if C or GNU C allows to retrieve the alignment of a struct like sizeof for size). GNU C does, __alignof__ (struct a). -- Pinski
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-03 19:31 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** --- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 --- For most (if not all) s-osinte*.ads C type redeclarations, I believe it should be sufficient to use a record containing a System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an alignement clause (I don't know if C or GNU C allows to retrieve the alignment of a struct like sizeof for size). GNU C does, __alignof__ (struct a). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #11 from laurent at guerby dot net 2006-01-03 19:36 --- (In reply to comment #7) There's only one fail in 4.0.3: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00025.html RUN cxg1005 ,.,. CXG1005 ACATS 2.5 06-01-01 01:38:37 CXG1005 Check that the subprograms defined in the package Generic_Complex_Elementary_Functions provide correct results. * CXG1005 Non-imaginary result from Function Log with a minus one input value. * CXG1005 Non-real result from Function Arcsin with a minus one input value. * CXG1005 Non-real result from Function Arccos with a minus one input value. CXG1005 FAILED . FAIL: cxg1005 I checked the first issue in C and clog(-1.0) seems ok. Dave This is PR20754 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754 I'm adding some comments there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/20754] ACATS cxg1005 fails at runtime on hppa-linux
--- Comment #1 from laurent at guerby dot net 2006-01-03 19:44 --- The Ada runtime does not use C complex primitives. In this case, the culprit in all three case is likely to be the following code in ada/a-ngelfu.adb -- Arctan -- -- Natural cycle function Arctan (Y: Float_Type'Base; X: Float_Type'Base := 1.0) return Float_Type'Base is begin if X = 0.0 and then Y = 0.0 then raise Argument_Error; elsif Y = 0.0 then if X 0.0 then return 0.0; else -- X 0.0 return Pi * Float_Type'Copy_Sign (1.0, Y); end if; elsif X = 0.0 then if Y 0.0 then return Half_Pi; else -- Y 0.0 return -Half_Pi; end if; else return Local_Atan (Y, X); end if; end Arctan; In all three failing case (log, cos,, we end up calling Log(-1.0) which calls Arctan (Y = 0.0, X = -1.0) which ends up in the return Pi * Float_Type'Copy_Sign (1.0, Y); case, so I assume 'Copy_Sign is broken in this case, Dave could you try the following small program with your hppa-linux 4.0.x GCC: [EMAIL PROTECTED]:~/tmp/pr20754 cat p.adb with ada.text_io; use ada.text_io; procedure p is begin put_line(long_float'copy_sign(1.0,0.0)'img); end p; [EMAIL PROTECTED]:~/tmp/pr20754 gnatmake p gcc -c p.adb gnatbind -x p.ali gnatlink p.ali [EMAIL PROTECTED]:~/tmp/pr20754 ./p 1.00E+00 Laurent -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
[Bug tree-optimization/25644] Not vectorizing F90 array expressions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-03 20:02 --- Actually this turns out to be the same as PR 18527. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||18527 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25644
[Bug ada/20754] ACATS cxg1005 fails at runtime on hppa-linux
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-03 20:27 --- [EMAIL PROTECTED]:~/gcc_test$ ./p 1.00E+00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
[Bug ada/20754] ACATS cxg1005 fails at runtime on hppa-linux
--- Comment #3 from danglin at gcc dot gnu dot org 2006-01-03 20:29 --- That was with 4.0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
[Bug target/25602] internal compiler error while bootstraping (while compiling libobjc/sendmsg.c)
--- Comment #3 from alex at milivojevic dot org 2006-01-03 20:30 ---
Created an attachment (id=10579)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10579action=view)
one more example of sigsegv
Trivial example where 64-bit gcc binary segfaults.
The code in question is old-style hello world:
#include iostream.h
int main()
{
cout Hello World\n;
}
When attempting to compile:
$ g++ -v -save-temps hello-old.cc
Using built-in specs.
Target: sparc64-sun-solaris2.9
Configured with: ../configure sparc64-sun-solaris2.9 --prefix=/opt/pbl
--with-local-prefix=/opt/pbl --with-cpu=ultrasparc --with-tune=ultrasparc
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.2
/opt/pbl/libexec/gcc/sparc64-sun-solaris2.9/4.0.2/cc1plus -E -quiet -v
-D__arch64__ -D__sparcv9 hello-old.cc -mcpu=ultrasparc -mtune=ultrasparc
-fpch-preprocess -o hello-old.ii
ignoring nonexistent directory
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../sparc64-sun-solaris2.9/include
#include ... search starts here:
#include ... search starts here:
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/sparc64-sun-solaris2.9
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/backward
/opt/pbl/include
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/include
/usr/include
End of search list.
In file included from built-in:0:
built-in:0: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Interestingly, the new style hello world compiles just fine:
#include iostream
using namespace std;
int main()
{
cout Hello World\n;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25602
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 20:37 --- This is related to PR 18527 but not fixed with -funsafe-loop-optimizations. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||18527 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug libstdc++/25653] Documentation bug in ext/stdio_filebuf.h
--- Comment #1 from rleigh at debian dot org 2006-01-03 20:52 --- On further investigation, it looks like when a stdio_filebuf is destroyed, this will ultimately invoke __basic_filechar::close(). This calls fclose(). If an fd is used, fdopen() is called to create a __c_file*. If this is correct, then both file descriptors and FILE * objects will be automatically closed, in which case this patch is needed: --- stdio_filebuf.h.old 2006-01-03 18:49:58.653951737 + +++ stdio_filebuf.h 2006-01-03 20:51:22.146153499 + @@ -85,7 +85,7 @@ *Defaults to system's @c BUFSIZ. * * This constructor associates a file stream buffer with an open - * C @c FILE*. The @c FILE* will not be automatically closed when the + * C @c FILE*. The @c FILE* will be automatically closed when the * stdio_filebuf is closed/destroyed. */ stdio_filebuf(std::__c_file* __f, std::ios_base::openmode __mode, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653
[Bug middle-end/24462] [4.1/4.2 Regression] packed-aligned structures are laid out differently
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-01-03 21:00 --- Is this still a problem? Not anymore, the 4.0 vs 4.1 compat testsuite is now clean both in 32-bit and 64-bit mode. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
[Bug ada/20754] ACATS cxg1005 fails at runtime on hppa-linux
--- Comment #4 from laurent at guerby dot net 2006-01-03 21:19 --- May be this one? [EMAIL PROTECTED]:~/tmp/pr20754 cat p2.adb with Ada.Numerics.Elementary_Functions; with Ada.Numerics.Complex_Types; with Ada.Numerics.Complex_Elementary_Functions; with Ada.Text_IO; procedure P2 is use Ada.Numerics.Elementary_Functions; use Ada.Numerics.Complex_Types; use Ada.Numerics.Complex_Elementary_Functions; use Ada.Text_IO; procedure Put (C : in Complex) is begin Put_Line (( Float'Image (Re (C)) , Float'Image (Im (C)) )); end Put; C0 : constant Complex := (-1.0, 0.0); C1 : Constant Complex := Log (C0); begin Put (C0); Put (C1); Put_Line (Float'Image (Arctan (Y = 0.0, X = -1.0))); end P2; [EMAIL PROTECTED]:~/tmp/pr20754 gnatmake p2 gcc -c p2.adb gnatbind -x p2.ali gnatlink p2.ali [EMAIL PROTECTED]:~/tmp/pr20754 ./p2 (-1.0E+00, 0.0E+00) ( 0.0E+00, 3.14159E+00) 3.14159E+00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
[Bug fortran/25101] Zero stride allowed in FORALL:s
--- Comment #4 from kargl at gcc dot gnu dot org 2006-01-03 22:01 --- Subject: Bug 25101 Author: kargl Date: Tue Jan 3 22:01:10 2006 New Revision: 109288 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109288 Log: 2006-01-03 Steven G. Kargl [EMAIL PROTECTED] PR fortran/25101 * resolve.c (resolve_forall_iterators): Check for scalar variables; Check stride is nonzero. * gfortran.dg/forall_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/forall_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25101
[Bug fortran/25101] [4.1] Zero stride allowed in FORALL:s
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-03 22:02 --- Fixed on trunk. I'll commit to 4.1 in a day or two. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Summary|Zero stride allowed in |[4.1] Zero stride allowed in |FORALL:s|FORALL:s http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25101
[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-03 22:37 --- Subject: Bug 25130 Author: steven Date: Tue Jan 3 22:37:46 2006 New Revision: 109292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109292 Log: 2006-01-03 Steven Bosscher [EMAIL PROTECTED] * fold-const.c (operand_equal_p): Accept a NULL operand 0 for COMPONENT_REFs. * emit-rtl.c (mem_attrs_htab_eq): Use iterative_hash_expr for hashing trees instead of a pointer hash. (mem_attrs_htab_eq): Do a deep compare instead of a pointer compare for MEM_EXPR. PR rtl-optimization/25130 * cse.c (exp_equiv_p): Compare MEM_ATTRS instead of * MEM_ALIAS_SET when comparing MEMs for GCSE Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cse.c branches/gcc-4_1-branch/gcc/emit-rtl.c branches/gcc-4_1-branch/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE
--- Comment #20 from steven at gcc dot gnu dot org 2006-01-03 22:39 --- One part of the problem is fixed, and the test cases now pass. There is still the RTL alias analysis bug mentioned in the thread on gcc@ starting here: http://gcc.gnu.org/ml/gcc/2006-01/msg8.html. But that is an issue that deserves its own PR. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-01-03 22:40 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00136.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00136.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug libstdc++/25653] Documentation bug in ext/stdio_filebuf.h
--- Comment #2 from pcarlini at suse dot de 2006-01-03 22:42 --- (In reply to comment #1) On further investigation, it looks like when a stdio_filebuf is destroyed, this will ultimately invoke __basic_filechar::close(). This calls fclose(). I think this is not true for the constructor at issue, taking a FILE, because _M_cfile_created is set to false by the corresponding __basic_file::sys_open and in this case __basic_file::close() does not call fclose: please, have another look to basic_file_stdio.cc. In other terms, I think the documentation is correct as-is. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653
[Bug boehm-gc/25652] Java support for amd64-pc-freebsd
--- Comment #2 from arno at heho dot snv dot jussieu dot fr 2006-01-03 22:54 --- I forgot to mention : correct libjava testsuite results : === libjava Summary === # of expected passes3964 # of unexpected failures24 # of expected failures 10 # of untested testcases 26 FAIL: cxxtest.cc compilation FAIL: PR16923.c compilation Running /files/home/scito/.scito/tools/gcc41-branch/gcc/libjava/testsuite/libjav a.lang/lang.exp ... FAIL: PR18699 execution - gij test FAIL: PR18699 execution - gij test WARNING: program timed out. FAIL: Process_1 execution - gij test WARNING: program timed out. FAIL: Process_1 execution - gij test WARNING: program timed out. FAIL: Process_2 execution - gij test WARNING: program timed out. FAIL: Process_2 execution - gij test WARNING: program timed out. FAIL: Process_3 execution - gij test WARNING: program timed out. FAIL: Process_3 execution - gij test WARNING: program timed out. FAIL: Process_4 execution - gij test WARNING: program timed out. FAIL: Process_5 execution - gij test WARNING: program timed out. FAIL: Process_6 execution - gij test WARNING: program timed out. FAIL: Process_6 execution - gij test FAIL: Thread_Interrupt output - gij test FAIL: Thread_Interrupt output - gij test FAIL: Thread_Wait_Interrupt output - bytecode-native test FAIL: Thread_Wait_Interrupt -O3 output - source compiled test FAIL: Throw_2 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 execution - bytecode-native test FAIL: Throw_2 -O3 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 -O3 execution - bytecode-native test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
[Bug libgcj/9715] Not all required character encodings are supported
--- Comment #4 from tromey at gcc dot gnu dot org 2006-01-03 22:58 --- Subject: Bug 9715 Author: tromey Date: Tue Jan 3 22:58:31 2006 New Revision: 109294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109294 Log: PR libgcj/9715, PR libgcj/19132: * java/nio/charset/Charset.java (charsetForName): Try default provider first. (availableCharsets): Re-merged. (providers2): Likewise. (defaultCharset): Likewise. * sources.am, Makefile.in: Rebuilt. * gnu/java/nio/charset/Provider.java: Removed. * java/io/OutputStreamWriter.java (OutputStreamWriter(OutputStream,Charset)): New constructor. (OutputStreamWriter(OutputStream,CharsetEncoder)): Likewise. * java/io/InputStreamReader.java (InputStreamReader(InputStream,CharsetDecoder)): New constructor. (InputStreamReader(InputStream,Charset)): Likewise. * gnu/gcj/convert/BytesToUnicode.java (getDecoder): Try a BytesToCharsetAdaptor. * gnu/gcj/convert/UnicodeToBytes.java (getEncoder): Try a CharsetToBytesAdaptor. * gnu/gcj/convert/CharsetToBytesAdaptor.java: New file. * gnu/gcj/convert/BytesToCharsetAdaptor.java: New file. * mauve-libgcj: Remove getEncoding exclusion. Added: trunk/libjava/gnu/gcj/convert/BytesToCharsetAdaptor.java trunk/libjava/gnu/gcj/convert/CharsetToBytesAdaptor.java Removed: trunk/libjava/gnu/java/nio/charset/Provider.java Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/gnu/gcj/convert/BytesToUnicode.java trunk/libjava/gnu/gcj/convert/UnicodeToBytes.java trunk/libjava/java/io/InputStreamReader.java trunk/libjava/java/io/OutputStreamWriter.java trunk/libjava/java/nio/charset/Charset.java trunk/libjava/mauve-libgcj trunk/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9715
[Bug libgcj/19132] InputStreamReader constructor missing
--- Comment #3 from tromey at gcc dot gnu dot org 2006-01-03 22:58 --- Subject: Bug 19132 Author: tromey Date: Tue Jan 3 22:58:31 2006 New Revision: 109294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109294 Log: PR libgcj/9715, PR libgcj/19132: * java/nio/charset/Charset.java (charsetForName): Try default provider first. (availableCharsets): Re-merged. (providers2): Likewise. (defaultCharset): Likewise. * sources.am, Makefile.in: Rebuilt. * gnu/java/nio/charset/Provider.java: Removed. * java/io/OutputStreamWriter.java (OutputStreamWriter(OutputStream,Charset)): New constructor. (OutputStreamWriter(OutputStream,CharsetEncoder)): Likewise. * java/io/InputStreamReader.java (InputStreamReader(InputStream,CharsetDecoder)): New constructor. (InputStreamReader(InputStream,Charset)): Likewise. * gnu/gcj/convert/BytesToUnicode.java (getDecoder): Try a BytesToCharsetAdaptor. * gnu/gcj/convert/UnicodeToBytes.java (getEncoder): Try a CharsetToBytesAdaptor. * gnu/gcj/convert/CharsetToBytesAdaptor.java: New file. * gnu/gcj/convert/BytesToCharsetAdaptor.java: New file. * mauve-libgcj: Remove getEncoding exclusion. Added: trunk/libjava/gnu/gcj/convert/BytesToCharsetAdaptor.java trunk/libjava/gnu/gcj/convert/CharsetToBytesAdaptor.java Removed: trunk/libjava/gnu/java/nio/charset/Provider.java Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/gnu/gcj/convert/BytesToUnicode.java trunk/libjava/gnu/gcj/convert/UnicodeToBytes.java trunk/libjava/java/io/InputStreamReader.java trunk/libjava/java/io/OutputStreamWriter.java trunk/libjava/java/nio/charset/Charset.java trunk/libjava/mauve-libgcj trunk/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19132
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #7 from mark at codesourcery dot com 2006-01-03 23:01 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions rakdver at gcc dot gnu dot org wrote: --- Comment #6 from rakdver at gcc dot gnu dot org 2006-01-03 22:40 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00136.html This patch is not OK, but it's close. We should not call unshare_expr on DECL_INITIAL until after the mark_used call, as static data members in templates will not have proper initializers until after that point. Also, there's no need to unshare *before* calling fold_non_dependent_expr. In fact, there's no need to unshare before the return statement at the end of the function. That will avoid creating trees that will only be thrown away later. So, why not just do: return unshare_expr (decl); at the end of the function? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug rtl-optimization/25654] New: [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
In the following C code, the order of loads and stores is messed up, leading to
wrong code:
extern void abort (void) __attribute__((noreturn));
union setconflict
{
short a[20];
int b[10];
};
int
main ()
{
int sum = 0;
{
union setconflict a;
short *c;
c = a.a;
asm (: =r (c):0 (c));
*c = 0;
asm (: =r (c):0 (c));
sum += *c;
}
{
union setconflict a;
int *c;
c = a.b;
asm (: =r (c):0 (c));
*c = 1;
asm (: =r (c):0 (c));
sum += *c;
}
printf (%d\n,sum);
if (sum != 1)
abort();
return 0;
}
.file t.c
# GNU C version 4.2.0 20060101 (experimental) (x86_64-unknown-linux-gnu)
# compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed: -iprefix -isystem -m32 -march=pentiumpro -auxbase -O2
# -fdump-tree-vars -fomit-frame-pointer -fverbose-asm
# options enabled: -falign-loops -fargument-alias -fbranch-count-reg
# -fcaller-saves -fcommon -fcprop-registers -fcrossjumping
# -fcse-follow-jumps -fcse-skip-blocks -fdefer-pop
# -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse
# -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion
# -fif-conversion2 -finline-functions-called-once -fipa-pure-const
# -fipa-reference -fipa-type-escape -fivopts -fkeep-static-consts
# -fleading-underscore -floop-optimize -floop-optimize2 -fmath-errno
# -fmerge-constants -fomit-frame-pointer -foptimize-register-move
# -foptimize-sibling-calls -fpcc-struct-return -fpeephole -fpeephole2
# -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop
# -frerun-loop-opt -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column
# -fsplit-ivs-in-unroller -fstrength-reduce -fstrict-aliasing
# -fthread-jumps -ftrapping-math -ftree-ccp -ftree-ch -ftree-copy-prop
# -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre
# -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs
# -ftree-pre -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp
# -ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp
# -funit-at-a-time -fverbose-asm -fzero-initialized-in-bss -m32 -m80387
# -m96bit-long-double -maccumulate-outgoing-args -malign-stringops
# -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mno-red-zone -mpush-args
# -mtls-direct-seg-refs
# Compiler executable checksum: 6d90f1c30ff8027bc6976ab2dbfe2320
.section.rodata.str1.1,aMS,@progbits,1
.LC0:
.string %d\n
.text
.p2align 4,,15
.globl main
.type main, @function
main:
leal4(%esp), %ecx #,
andl$-16, %esp #,
pushl -4(%ecx)#
subl$76, %esp #,
leal28(%esp), %eax #, tmp64
movl%ecx, 68(%esp) #,
movl%eax, %edx # tmp64, c
movl%ebx, 72(%esp) #,
movw$0, (%edx) #,* c
movl$1, (%eax) #,* c
movswl (%edx),%ebx #* c, sum
movl(%eax), %edx#* c,
movl$.LC0, (%esp) #,
addl%edx, %ebx #, sum
movl%ebx, 4(%esp) # sum,
callprintf #
decl%ebx# sum
jne .L6 #,
movl68(%esp), %ecx #,
xorl%eax, %eax # result
movl72(%esp), %ebx #,
addl$76, %esp #,
leal-4(%ecx), %esp #,
ret
.L6:
callabort #
.size main, .-main
.ident GCC: (GNU) 4.2.0 20060101 (experimental)
.section.note.GNU-stack,,@progbits
See also the thread on the gcc@ mailing list starting here:
http://gcc.gnu.org/ml/gcc/2006-01/msg8.html.
--
Summary: [4.0/4.1/4.2 Regression] RTL alias analysis unprepared
to handle stack slot sharing
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-03 23:23 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |critical Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.3 4.1.0 4.2.0 Known to work||3.4.4 Last reconfirmed|-00-00 00:00:00 |2006-01-03 23:23:36 date|| Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-01-03 23:24 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two
different functions
--- Comment #7 from mark at codesourcery dot com 2006-01-03 23:01 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied
into two different functions
rakdver at gcc dot gnu dot org wrote:
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-01-03 22:40
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00136.html
This patch is not OK, but it's close.
We should not call unshare_expr on DECL_INITIAL until after the
mark_used call, as static data members in templates will not have proper
initializers until after that point. Also, there's no need to unshare
*before* calling fold_non_dependent_expr.
In fact, there's no need to unshare before the return statement at the
end of the function. That will avoid creating trees that will only be
thrown away later.
So, why not just do:
return unshare_expr (decl);
at the end of the function?
because that causes bootstrap failure --
fold_decl_constant_value does
tree const_expr = expr;
do
{
expr = fold_non_dependent_expr (const_expr);
const_expr = integral_constant_value (expr);
}
while (expr != const_expr);
and if constant_value_1 (called by integral_constant_value) unshares the
expression unconditionally (not only when it processes DECL_INITIAL),
this loop never ends.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-01-03 23:29 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions rakdver at gcc dot gnu dot org wrote: --- Comment #6 from rakdver at gcc dot gnu dot org 2006-01-03 22:40 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00136.html This patch is not OK, but it's close. We should not call unshare_expr on DECL_INITIAL until after the mark_used call, as static data members in templates will not have proper initializers until after that point. Also, there's no need to unshare *before* calling fold_non_dependent_expr. In fact, there's no need to unshare before the return statement at the end of the function. That will avoid creating trees that will only be thrown away later. what about this patch, then (assuming it passes testing)? Index: cp/init.c === *** cp/init.c (revision 109271) --- cp/init.c (working copy) *** constant_value_1 (tree decl, bool integr *** 1503,1508 --- 1503,1510 mark_used (decl); init = DECL_INITIAL (decl); } + init = unshare_expr (init); + if (!(init || init == error_mark_node) || !TREE_TYPE (init) || (integral_p -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug libgcj/25655] New: Implement signal chaining
We should implement something like Sun's signal chaining library for use with libgcj. This may be required when working with native libraries installing their own signal handlers... http://java.sun.com/j2se/1.4.2/docs/guide/vm/signal-chaining.html -- Summary: Implement signal chaining Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25655
