[Bug c++/26266] [4.0/4.1/4.2 regression] Trouble with static const data members in template classes
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-02-18 08:36 --- Subject: Bug 26266 Author: mmitchel Date: Sat Feb 18 08:36:11 2006 New Revision: 111229 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111229 Log: PR c++/26266 * cp-tree.h (cp_finish_decl): Adjust declaration. (grokbitfield): Likewise. (finish_static_data_member_decl): Likewise. * init.c (constant_value_1): Ensure processing_template_decl when folding non-dependent initializers for static data members of dependent types. Return error_mark_node for erroneous initailizers. * class.c (get_vtable_decl): Use finish_decl, not cp_finish_decl. * decl.c (cp_make_fname_decl): Adjust call to cp_finish_decl. (cp_finish_decl): Add init_const_expr_p parameter. Set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (finish_decl): Adjust call to cp_finish_decl. (compute_array_index_type): Robustify. (start_method): Use finish_decl, not cp_finish_decl. * rtti.c (emit_tinfo_decl): Likewise. * except.c (initialize_handler_parm): Adjust call to cp_finish_decl. (expand_start_catch_block): Likewise. * cvt.c (build_up_reference): Adjust call to cp_finish_decl. * pt.c (instantiate_class_template): Adjust call to finish_static_data_member_decl. (tsubst_expr): Use finish_decl, not cp_finish_decl. (instantiate_decl): Adjust call to cp_finish_decl. * name-lookup.c (pushdecl_top_level_1): Use finish_decl, not cp_finish_decl. * decl2.c (finish_static_data_member_decl): Add init_const_expr_p parameter. (grokfield): Likewise. * parser.c (cp_parser_condition): Check for constant initializers. (cp_parser_init_declarator): Adjust calls to grokfield and cp_finish_decl. Don't set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (cp_parser_member_declaration): Likewise. (cp_parser_objc_class_ivars): Likewise. PR c++/26266 * g++.dg/template/static22.C: New test. * g++.dg/template/static23.C: New test. * g++.dg/template/static24.C: New test. * g++.dg/template/non-dependent13.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/non-dependent13.C trunk/gcc/testsuite/g++.dg/template/static22.C trunk/gcc/testsuite/g++.dg/template/static23.C trunk/gcc/testsuite/g++.dg/template/static24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cvt.c trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/except.c trunk/gcc/cp/init.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/rtti.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/26266] [4.0/4.1/4.2 regression] Trouble with static const data members in template classes
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-02-18 08:37 --- Subject: Bug 26266 Author: mmitchel Date: Sat Feb 18 08:37:11 2006 New Revision: 111230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111230 Log: PR c++/26266 * g++.dg/template/static22.C: New test. * g++.dg/template/static23.C: New test. * g++.dg/template/static24.C: New test. * g++.dg/template/non-dependent13.C: New test. * g++.dg/init/member1.C: Tweak error markers. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/init/member1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|normal |critical Summary|Ada gnatlib a-textio.o ICE |ICE compiling a-textio.adb |because of too much RAM,|at -O1 -ftree-vrp |tree-vrp? | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug c++/26266] [4.0/4.1/4.2 regression] Trouble with static const data members in template classes
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-02-18 08:37 --- Subject: Bug 26266 Author: mmitchel Date: Sat Feb 18 08:37:34 2006 New Revision: 111231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111231 Log: PR c++/26266 * cp-tree.h (cp_finish_decl): Adjust declaration. (grokbitfield): Likewise. (finish_static_data_member_decl): Likewise. * init.c (constant_value_1): Ensure processing_template_decl when folding non-dependent initializers for static data members of dependent types. Return error_mark_node for erroneous initailizers. * class.c (get_vtable_decl): Use finish_decl, not cp_finish_decl. * decl.c (cp_make_fname_decl): Adjust call to cp_finish_decl. (cp_finish_decl): Add init_const_expr_p parameter. Set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (finish_decl): Adjust call to cp_finish_decl. (compute_array_index_type): Robustify. (start_method): Use finish_decl, not cp_finish_decl. * rtti.c (emit_tinfo_decl): Likewise. * except.c (initialize_handler_parm): Adjust call to cp_finish_decl. (expand_start_catch_block): Likewise. * cvt.c (build_up_reference): Adjust call to cp_finish_decl. * pt.c (instantiate_class_template): Adjust call to finish_static_data_member_decl. (tsubst_expr): Use finish_decl, not cp_finish_decl. (instantiate_decl): Adjust call to cp_finish_decl. * name-lookup.c (pushdecl_top_level_1): Use finish_decl, not cp_finish_decl. * decl2.c (finish_static_data_member_decl): Add init_const_expr_p parameter. (grokfield): Likewise. * parser.c (cp_parser_condition): Check for constant initializers. (cp_parser_init_declarator): Adjust calls to grokfield and cp_finish_decl. Don't set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (cp_parser_member_declaration): Likewise. (cp_parser_objc_class_ivars): Likewise. PR c++/26266 * g++.dg/template/static22.C: New test. * g++.dg/template/static23.C: New test. * g++.dg/template/static24.C: New test. * g++.dg/template/non-dependent13.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/non-dependent13.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/static22.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/static23.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/static24.C Modified: branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/cp-tree.h branches/gcc-4_1-branch/gcc/cp/cvt.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/decl2.c branches/gcc-4_1-branch/gcc/cp/except.c branches/gcc-4_1-branch/gcc/cp/init.c branches/gcc-4_1-branch/gcc/cp/name-lookup.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/cp/rtti.c branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/member1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/26266] [4.0/4.1/4.2 regression] Trouble with static const data members in template classes
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-02-18 09:40 --- Subject: Bug 26266 Author: mmitchel Date: Sat Feb 18 09:40:03 2006 New Revision: 111233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111233 Log: PR c++/26266 * cp-tree.h (cp_finish_decl): Adjust declaration. (grokbitfield): Likewise. (finish_static_data_member_decl): Likewise. * init.c (constant_value_1): Ensure processing_template_decl when folding non-dependent initializers for static data members of dependent types. Return error_mark_node for erroneous initailizers. * class.c (get_vtable_decl): Use finish_decl, not cp_finish_decl. * decl.c (cp_make_fname_decl): Adjust call to cp_finish_decl. (cp_finish_decl): Add init_const_expr_p parameter. Set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (finish_decl): Adjust call to cp_finish_decl. (compute_array_index_type): Robustify. (start_method): Use finish_decl, not cp_finish_decl. * rtti.c (emit_tinfo_decl): Likewise. * except.c (initialize_handler_parm): Adjust call to cp_finish_decl. (expand_start_catch_block): Likewise. * cvt.c (build_up_reference): Adjust call to cp_finish_decl. * pt.c (instantiate_class_template): Adjust call to finish_static_data_member_decl. (tsubst_expr): Use finish_decl, not cp_finish_decl. (instantiate_decl): Adjust call to cp_finish_decl. * name-lookup.c (pushdecl_top_level_1): Use finish_decl, not cp_finish_decl. * decl2.c (finish_static_data_member_decl): Add init_const_expr_p parameter. (grokfield): Likewise. * parser.c (cp_parser_condition): Check for constant initializers. (cp_parser_init_declarator): Adjust calls to grokfield and cp_finish_decl. Don't set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (cp_parser_member_declaration): Likewise. (cp_parser_objc_class_ivars): Likewise. PR c++/26266 * g++.dg/template/static22.C: New test. * g++.dg/template/static23.C: New test. * g++.dg/template/static24.C: New test. * g++.dg/template/non-dependent13.C: New test. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/26266] [4.0/4.1/4.2 regression] Trouble with static const data members in template classes
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-02-18 09:41 --- Subject: Bug 26266 Author: mmitchel Date: Sat Feb 18 09:41:18 2006 New Revision: 111234 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111234 Log: PR c++/26266 * cp-tree.h (cp_finish_decl): Adjust declaration. (grokbitfield): Likewise. (finish_static_data_member_decl): Likewise. * init.c (constant_value_1): Ensure processing_template_decl when folding non-dependent initializers for static data members of dependent types. Return error_mark_node for erroneous initailizers. * class.c (get_vtable_decl): Use finish_decl, not cp_finish_decl. * decl.c (cp_make_fname_decl): Adjust call to cp_finish_decl. (cp_finish_decl): Add init_const_expr_p parameter. Set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (finish_decl): Adjust call to cp_finish_decl. (compute_array_index_type): Robustify. (start_method): Use finish_decl, not cp_finish_decl. * rtti.c (emit_tinfo_decl): Likewise. * except.c (initialize_handler_parm): Adjust call to cp_finish_decl. (expand_start_catch_block): Likewise. * cvt.c (build_up_reference): Adjust call to cp_finish_decl. * pt.c (instantiate_class_template): Adjust call to finish_static_data_member_decl. (tsubst_expr): Use finish_decl, not cp_finish_decl. (instantiate_decl): Adjust call to cp_finish_decl. * name-lookup.c (pushdecl_top_level_1): Use finish_decl, not cp_finish_decl. * decl2.c (finish_static_data_member_decl): Add init_const_expr_p parameter. (grokfield): Likewise. * parser.c (cp_parser_condition): Check for constant initializers. (cp_parser_init_declarator): Adjust calls to grokfield and cp_finish_decl. Don't set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P here. (cp_parser_member_declaration): Likewise. (cp_parser_objc_class_ivars): Likewise. PR c++/26266 * g++.dg/template/static22.C: New test. * g++.dg/template/static23.C: New test. * g++.dg/template/static24.C: New test. * g++.dg/template/non-dependent13.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/non-dependent13.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/static22.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/static23.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/static24.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/cp-tree.h branches/gcc-4_0-branch/gcc/cp/cvt.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/decl2.c branches/gcc-4_0-branch/gcc/cp/except.c branches/gcc-4_0-branch/gcc/cp/init.c branches/gcc-4_0-branch/gcc/cp/name-lookup.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/cp/rtti.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/member1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/26266] [4.0/4.1/4.2 regression] Trouble with static const data members in template classes
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-02-18 09:41 --- Only the accepts-invalid in Comment #7 remains. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code, rejects- | |valid | Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/26122] [4.0/4.1/4.2 regression] Pure specifiers for templates causing trouble
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-02-18 09:51 --- The reason that the first and last examples are accepted is that, were there dependent base classes, we would have no way of knowing whether or not those base classes might declare a virtual function for which this function was an override. We will detect the problem at template instantiation time. So, diagnosing those examples is almost a feature request, rather than a bug fix. I am testing a patch for the ICE. -- 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=26122
[Bug c++/26295] [4.0/4.1/4.2 Regression] Invalid namespace pointer seg fault
-- 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=26295
[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #1 from schwab at suse dot de 2006-02-18 11:09 --- Also seen on ia64, 2GB is not enough to compile this file. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-18 11:09:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug target/24837] move dynamic linker names out of LINK_SPEC and into new DYNAMIC_LINKER
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-02-18 11:12 --- Subject: Bug 24837 Author: jsm28 Date: Sat Feb 18 11:12:51 2006 New Revision: 111235 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111235 Log: PR target/24837 * config.gcc: Define UCLIBC_DEFAULT to 0 or 1. * opth-gen.awk: Handle Var and InverseMask together. * config/linux.opt (muclibc, mglibc): Use Var(linux_uclibc). * config/linux.h: Use #if not #ifdef for testing UCLIBC_DEFAULT. (TARGET_C99_FUNCTIONS): Test OPTION_GLIBC not TARGET_GLIBC. (CHOOSE_DYNAMIC_LINKER): Give an error for -mglibc and -muclibc used together. (UCLIBC_DYNAMIC_LINKER32, UCLIBC_DYNAMIC_LINKER64, LINUX_DYNAMIC_LINKER32, LINUX_DYNAMIC_LINKER64): Define. * config/alpha/linux-elf.h (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER): Define. (ELF_DYNAMIC_LINKER): Define to LINUX_DYNAMIC_LINKER. * config/alpha/linux.h (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * config/cris/linux.h (GLIBC_DYNAMIC_LINKER): Define. (CRIS_LINK_SUBTARGET_SPEC): Pass a -dynamic-linker option. * config/frv/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. (TARGET_C99_FUNCTIONS): Don't define. * config/i386/linux.h (DYNAMIC_LINKER): Rename to GLIBC_DYNAMIC_LINKER. (SUBTARGET_EXTRA_SPECS): Use LINUX_DYNAMIC_LINKER. * config/i386/linux64.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER32 and LINUX_DYNAMIC_LINKER64. * config/ia64/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * config/m32r/linux.h (GLIBC_DYNAMIC_LINKE): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * config/m68k/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * config/mips/linux64.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64, GLIBC_DYNAMIC_LINKERN32, UCLIBC_DYNAMIC_LINKERN32, LINUX_DYNAMIC_LINKERN32): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKERN32, LINUX_DYNAMIC_LINKER64 and LINUX_DYNAMIC_LINKER32. * config/mn10300/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * config/pa/pa-linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * config/rs6000/linux.h (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * config/rs6000/linux64.h (TARGET_C99_FUNCTIONS): Likewise. (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64, UCLIBC_DYNAMIC_LINKER32, UCLIBC_DYNAMIC_LINKER64, CHOOSE_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER32, LINUX_DYNAMIC_LINKER64): Define. (LINK_OS_LINUX_SPEC32): Use LINUX_DYNAMIC_LINKER32. (LINK_OS_LINUX_SPEC64): Use LINUX_DYNAMIC_LINKER64. * config/rs6000/sysv4.h (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER): Define. (LINK_OS_LINUX_SPEC): Use LINUX_DYNAMIC_LINKE. * config/s390/linux.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER32 and LINUX_DYNAMIC_LINKER64. * config/sh/linux.h (GLIBC_DYNAMIC_LINKER): Define. (SUBTARGET_LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * config/sparc/linux.h (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * config/sparc/linux64.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64, UCLIBC_DYNAMIC_LINKER32, UCLIBC_DYNAMIC_LINKER64, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER32, LINUX_DYNAMIC_LINKER64): Define. (LINK_ARCH32_SPEC): Use LINUX_DYNAMIC_LINKER32. (LINK_ARCH64_SPEC, LINK_SPEC): Use LINUX_DYNAMIC_LINKER64. (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * config/xtensa/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * doc/invoke.texi (-muclibc): Remove caveat about supported targets. testsuite: * gcc.dg/glibc-uclibc-1.c, gcc.dg/glibc-uclibc-2.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/glibc-uclibc-1.c trunk/gcc/testsuite/gcc.dg/glibc-uclibc-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/alpha/linux-elf.h trunk/gcc/config/alpha/linux.h trunk/gcc/config/cris/linux.h trunk/gcc/config/frv/linux.h trunk/gcc/config/i386/linux.h trunk/gcc/config/i386/linux64.h trunk/gcc/config/ia64/linux.h trunk/gcc/config/linux.h trunk/gcc/config/linux.opt
[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #2 from laurent at guerby dot net 2006-02-18 11:15 --- Jeff mentionned ping pong between passes, I believe it's an infinite ping-pong loop between two things with memory usage increasing linearly (either leak or data structures) until the system kills the process. gdb traces do not show backtrace grow. My amd64 machine with 2GB RAM and 6GB swap failed on it too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug target/24837] move dynamic linker names out of LINK_SPEC and into new DYNAMIC_LINKER
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-02-18 11:17 --- Subject: Bug 24837 Author: jsm28 Date: Sat Feb 18 11:17:08 2006 New Revision: 111236 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111236 Log: PR target/24837 * gcc/config.gcc: Define UCLIBC_DEFAULT to 0 or 1. * gcc/opth-gen.awk: Handle Var and InverseMask together. * gcc/config/linux.opt (muclibc, mglibc): Use Var(linux_uclibc). * gcc/config/linux.h: Use #if not #ifdef for testing UCLIBC_DEFAULT. (TARGET_C99_FUNCTIONS): Test OPTION_GLIBC not TARGET_GLIBC. (CHOOSE_DYNAMIC_LINKER): Give an error for -mglibc and -muclibc used together. (UCLIBC_DYNAMIC_LINKER32, UCLIBC_DYNAMIC_LINKER64, LINUX_DYNAMIC_LINKER32, LINUX_DYNAMIC_LINKER64): Define. * gcc/config/alpha/linux-elf.h (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER): Define. (ELF_DYNAMIC_LINKER): Define to LINUX_DYNAMIC_LINKER. * gcc/config/alpha/linux.h (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * gcc/config/cris/linux.h (GLIBC_DYNAMIC_LINKER): Define. (CRIS_LINK_SUBTARGET_SPEC): Pass a -dynamic-linker option. * gcc/config/frv/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. (TARGET_C99_FUNCTIONS): Don't define. * gcc/config/i386/linux.h (DYNAMIC_LINKER): Rename to GLIBC_DYNAMIC_LINKER. (SUBTARGET_EXTRA_SPECS): Use LINUX_DYNAMIC_LINKER. * gcc/config/i386/linux64.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER32 and LINUX_DYNAMIC_LINKER64. * gcc/config/ia64/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * gcc/config/m32r/linux.h (GLIBC_DYNAMIC_LINKE): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * gcc/config/m68k/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * gcc/config/mips/linux64.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64, GLIBC_DYNAMIC_LINKERN32, UCLIBC_DYNAMIC_LINKERN32, LINUX_DYNAMIC_LINKERN32): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKERN32, LINUX_DYNAMIC_LINKER64 and LINUX_DYNAMIC_LINKER32. * gcc/config/mn10300/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * gcc/config/pa/pa-linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * gcc/config/rs6000/linux.h (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * gcc/config/rs6000/linux64.h (TARGET_C99_FUNCTIONS): Likewise. (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64, UCLIBC_DYNAMIC_LINKER32, UCLIBC_DYNAMIC_LINKER64, CHOOSE_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER32, LINUX_DYNAMIC_LINKER64): Define. (LINK_OS_LINUX_SPEC32): Use LINUX_DYNAMIC_LINKER32. (LINK_OS_LINUX_SPEC64): Use LINUX_DYNAMIC_LINKER64. * gcc/config/rs6000/sysv4.h (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER): Define. (LINK_OS_LINUX_SPEC): Use LINUX_DYNAMIC_LINKE. * gcc/config/s390/linux.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER32 and LINUX_DYNAMIC_LINKER64. * gcc/config/sh/linux.h (GLIBC_DYNAMIC_LINKER): Define. (SUBTARGET_LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * gcc/config/sparc/linux.h (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * gcc/config/sparc/linux64.h (GLIBC_DYNAMIC_LINKER32, GLIBC_DYNAMIC_LINKER64, UCLIBC_DYNAMIC_LINKER32, UCLIBC_DYNAMIC_LINKER64, CHOOSE_DYNAMIC_LINKER, LINUX_DYNAMIC_LINKER32, LINUX_DYNAMIC_LINKER64): Define. (LINK_ARCH32_SPEC): Use LINUX_DYNAMIC_LINKER32. (LINK_ARCH64_SPEC, LINK_SPEC): Use LINUX_DYNAMIC_LINKER64. (TARGET_C99_FUNCTIONS): Define to TARGET_GLIBC. * gcc/config/xtensa/linux.h (GLIBC_DYNAMIC_LINKER): Define. (LINK_SPEC): Use LINUX_DYNAMIC_LINKER. * gcc/doc/invoke.texi (-muclibc): Remove caveat about supported targets. * gcc/testsuite/gcc.dg/glibc-uclibc-1.c, gcc/testsuite/gcc.dg/glibc-uclibc-2.c: New tests. Added: branches/csl/sourcerygxx-4_1/gcc/testsuite/gcc.dg/glibc-uclibc-1.c - copied unchanged from r111235, trunk/gcc/testsuite/gcc.dg/glibc-uclibc-1.c branches/csl/sourcerygxx-4_1/gcc/testsuite/gcc.dg/glibc-uclibc-2.c - copied unchanged from r111235, trunk/gcc/testsuite/gcc.dg/glibc-uclibc-2.c Modified:
[Bug target/24837] move dynamic linker names out of LINK_SPEC and into new DYNAMIC_LINKER
--- Comment #7 from jsm28 at gcc dot gnu dot org 2006-02-18 11:20 --- Fixed for 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24837
[Bug target/26349] New: config/i386/i386.h: typo in comment?
config/i386/i386.h suggests a value to force a 486, but the value would force a pentium. Matthias /* configure can arrange to make this 2, to force a 486. */ #ifndef TARGET_CPU_DEFAULT #define TARGET_CPU_DEFAULT TARGET_CPU_DEFAULT_generic #endif [...] #define TARGET_CPU_DEFAULT_i386 0 #define TARGET_CPU_DEFAULT_i486 1 #define TARGET_CPU_DEFAULT_pentium 2 --- gcc/config/i386/i386.h.~1~ 2006-02-18 11:50:58.015111488 +0100 +++ gcc/config/i386/i386.h 2006-02-18 12:21:55.953661896 +0100 @@ -90,7 +90,7 @@ /* Macros used in the machine description to test the flags. */ -/* configure can arrange to make this 2, to force a 486. */ +/* configure can arrange to make this 1, to force a 486. */ #ifndef TARGET_CPU_DEFAULT #define TARGET_CPU_DEFAULT TARGET_CPU_DEFAULT_generic -- Summary: config/i386/i386.h: typo in comment? Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC host triplet: i386-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26349
[Bug c/8268] no compile time array index checking
--- Comment #19 from dcb314 at hotmail dot com 2006-02-18 12:09 --- (In reply to comment #17) Created an attachment (id=10869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10869action=view) [edit] patch I'm currently testing this patch. I tried out the suggested patch on gcc version 4.2, snapshot 20060211, and tried to build the compiler. It said ../../src/gcc-4.2-20060211/libiberty/cp-demangle.c: In function 'd_demangle': ../../src/gcc-4.2-20060211/libiberty/cp-demangle.c:3899: internal compiler error: tree check: expected catch_expr, have try_finally in array_offset_warning, at c-common.c:5893 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The source code line causing problems is array_offset_warning (CATCH_BODY (t)); Also, there seems to be some dead code after the break statement: + case EH_FILTER_EXPR: + array_offset_warning (EH_FILTER_FAILURE (t)); + break; + array_offset_warning (TREE_OPERAND (t, 0)); + array_offset_warning (TREE_OPERAND (t, 1)); Possibly a missing case ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-02-18 12:28
---
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s-str[42];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #21 from mueller at gcc dot gnu dot org 2006-02-18 12:39 --- hmm, thanks. it should have looked like this: + case TRY_FINALLY_EXPR: + case TRY_CATCH_EXPR: +array_offset_warning (TREE_OPERAND (t, 0)); +array_offset_warning (TREE_OPERAND (t, 1)); +break; + case CATCH_EXPR: + array_offset_warning (CATCH_BODY (t)); + break; Anyway, I agree that the SSA pass after all const folding has happened is a much better approach than my quick hack, as long as it isn't significantly slower (compile time). I'm currently trying Falk's patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #22 from mueller at gcc dot gnu dot org 2006-02-18 12:42
---
Richard: Under which assumption? because the array size is = sizeof(int) ?
Why not suppressing the warning by changing the code to:
typedef struct {
int len;
char str[0];
} String;
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #23 from falk at debian dot org 2006-02-18 12:58 ---
(In reply to comment #21)
hmm, thanks. it should have looked like this:
+ case TRY_FINALLY_EXPR:
+ case TRY_CATCH_EXPR:
+array_offset_warning (TREE_OPERAND (t, 0));
+array_offset_warning (TREE_OPERAND (t, 1));
+break;
+ case CATCH_EXPR:
+ array_offset_warning (CATCH_BODY (t));
+ break;
Anyway, I agree that the SSA pass after all const folding has happened is a
much better approach than my quick hack, as long as it isn't significantly
slower (compile time). I'm currently trying Falk's patch.
The problem it had was with inlining: code like
static inline int f(int a[], int b) {
return a[b]; // line 2
}
int g(void) {
int a[2] = {1, 2};
return f(a, 2); // line 7
}
To really be helpful, the warning should say something like array access
out of bound in line 2 after inlining in line 7, but I don't know how
to achieve that. The uninitialized warning has the same problem by running
so late; it punts and just says a used uninitialized in g, which seems
kinda lame.
Anyway, the warning is probably still useful if this is not resolved...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug target/26350] New: ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
We ICE building hercules for powerpc32. Reduced testcase, build with
-O2 -fPIC -mlong-double-128:
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
typedef struct REGS REGS;
typedef union { uint32_t F; } FW;
typedef union { struct { FW L; } F; } DW;
typedef struct _PSW {
DW ia;
} PSW;
struct REGS {
PSW psw;
DW cr[16];
};
struct ebfp {
long double v;
};
void ( s390_convert_fix32_to_bfp_ext_reg) (REGS *regs)
{
struct ebfp op1;
int32_t op2;
((regs))-psw.ia.F.L.F += (4);
if(!((regs)-cr[(0)].F.L.F 0x0004))
op1.v = (long double)op2;
put_ebfp(op1);
}
--
Summary: ICE in extract_insn, at recog.c:2084, -fPIC -mlong-
double-128
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: ppc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug c/8268] no compile time array index checking
--- Comment #24 from rguenth at gcc dot gnu dot org 2006-02-18 13:15 --- (In reply to comment #22) We need to allow offsetting beyond the declared array size if this array is the last member of a structure. This is refered to as malloc trick to allocate variable sized structures with a flexible array member. Due to compilers lacking support for the correct char str[] declaration you will find all of char str[0] (GNU extension) char str[] char str[1] char str[4] (or whatever number) so in this case we need to allow all accesses, or with a separate warning flag only warn if the decl was not one of [0], [] or [1]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #25 from falk at debian dot org 2006-02-18 13:25 --- (In reply to comment #24) We need to allow offsetting beyond the declared array size if this array is the last member of a structure. This is refered to as malloc trick to allocate variable sized structures with a flexible array member. Due to compilers lacking support for the correct char str[] declaration you will find all of char str[0] (GNU extension) char str[] char str[1] char str[4] (or whatever number) so in this case we need to allow all accesses, or with a separate warning flag only warn if the decl was not one of [0], [] or [1]. I tried to handle this by never warning for any size-0 or size-1 array. Is there some way to check that this array is in fact the last member of a struct? That would clearly be better. I'd still consider warning for sizes 1, because it's probably rare enough to not justify the false negatives we get otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug libgcj/26351] New: Native Momory Leak in ResourceBundle
Invoking java.util.ResourceBundle.getBundle(String) leaks some native memory.
A small sample program is attached. If you run it, you will see that the
process' virual memory size keeps growing while Java heap consumption stays at
a same level after some iteration.
The problem is in gnu.gcj.runtime.StackTrace.fillInStackTrace (a native code)
invoked through gnu.gcj.runtime.StackTrace.classAt through
java.lang.Class.forName through java.util.ResourceBundle.tryBundle. When the
native method fillInStackTrace is invoked by a method other than its
constructor, a native memory allocated through _Jv_Malloc and stored in addrs
is discarded without _Jv_Free'ed.
I exprerienced this problem on Windows (MinGW) but I belive it is common to
other platforms.
A suggested fix is attached:
--- libjava/gnu/gcj/runtime/natStackTrace.orig.cc 2003-10-02
16:10:34.0 +0900
+++ libjava/gnu/gcj/runtime/natStackTrace.cc2006-02-17 00:01:52.529572700
+0900
@@ -85,6 +85,8 @@
else
frame = NULL;
+ if (addrs != NULL)
+_Jv_Free (addrs);
addrs = reinterpret_castgnu::gcj::RawData * (frame);
#else // HAVE_BACKTRACE
(void)maxlen;
---
A sample program to reproduce the problem follows:
import java.util.ResourceBundle;
import java.util.MissingResourceException;
public class Leak {
public static void main(String[] args) {
final Runtime r = Runtime.getRuntime();
for (;;) {
for (int i = 0; i 1; i++) {
try {
ResourceBundle.getBundle(nothing);
} catch (MissingResourceException e) {
}
}
System.out.println(r.freeMemory() + / + r.totalMemory());
}
}
}
--
Summary: Native Momory Leak in ResourceBundle
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fexx at fexx dot org
GCC build triplet: mingw32
GCC host triplet: mingw32
GCC target triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26351
[Bug c/8268] no compile time array index checking
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-02-18 13:44 --- I agree that the false positives would be acceptable. One could even warn for [0] and [1] arrays if std=c99 (I believe flexible array members were not in c89, but i didn't check). For a way to check if an array access can possibly cross structure extent you can look at tree-dfa.c:get_ref_base_and_extent which also accounts for flexible array members. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-18 14:32 --- For the record, AMD64 (usr-)timings: GCC 4.0 GCC 4.1 0m5.412s0m4.400s 0m5.388s0m4.404s 0m5.408s0m4.404s So for AMD64 we in fact booked significant progress in GCC 4.1 wrt. GCC 4.0. This is with: xgcc (GCC) 4.0.3 20060211 (prerelease) xgcc (GCC) 4.1.0 20060211 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug c/8268] no compile time array index checking
--- Comment #27 from dcb314 at hotmail dot com 2006-02-18 14:33 --- (In reply to comment #21) hmm, thanks. it should have looked like this: I tried your second patch, and the compile of the compiler got as far as the following /home/dcb/gnu/42-20060211/working/./prev-gcc/xgcc -B/home/dcb/gnu/42-20060211/working/./prev-gcc/ -B/home/dcb/gnu/42-20060211/results/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc-4.2-20060211/gcc -I../../src/gcc-4.2-20060211/gcc/. -I../../src/gcc-4.2-20060211/gcc/../include -I../../src/gcc-4.2-20060211/gcc/../libcpp/include -I../../src/gcc-4.2-20060211/gcc/../libdecnumber -I../libdecnumber ../../src/gcc-4.2-20060211/gcc/real.c -o real.o../../src/gcc-4.2-20060211/gcc/real.c: In function 'real_to_integer2': ../../src/gcc-4.2-20060211/gcc/real.c:1385: error: array reference -1 below range min (0) ../../src/gcc-4.2-20060211/gcc/real.c: In function 'real_from_integer': ../../src/gcc-4.2-20060211/gcc/real.c:2050: error: array reference -1 below range min (0) ../../src/gcc-4.2-20060211/gcc/real.c: In function 'encode_ieee_quad': ../../src/gcc-4.2-20060211/gcc/real.c:3564: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c:3615: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c: In function 'decode_ieee_quad': ../../src/gcc-4.2-20060211/gcc/real.c:3693: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c:3719: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c:3745: error: array reference 3 above range max (2) It seems that a combination of the new warning and the Werror flag prevents compilation. On the other point about using arrayName[ 4] for the end of struct hack, I'd be entirely happy with false positives. Folks who want that hack can just say arrayName[ 1] to avoid the new warning anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-18 14:36 --- Timings with the same compilers on the same machine, but with -m32 -march=pentium4 (but still with -O2): GCC 4.0 GCC 4.1 0m4.148s0m8.817s 0m4.140s0m8.785s 0m4.164s0m8.761s So: 1) We produce _faster_ code with GCC 4.0 -m32 than with -m64 2) GCC 4.1 -m32 produces code that is twice as slow as GCC 4.0 -m32, as reported. Both points are odd (and no, I did not by accident swap the results somwhere ;-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-02-15 10:58:11 |2006-02-18 14:36:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-18 14:39 --- Loop body with GCC 4.1: L0:; j = i + 1; if (cnt j) goto L12; else goto L8; L12:; ivtmp.49 = (int *) ivtmp.54; j.56 = j; L1:; D.2857 = (int *) j; D.2751 = MEM[base: lst, index: D.2857, step: 4B, offset: 4294967292B]; D.2851 = (int *) ivtmp.49; D.2756 = MEM[base: D.2851, offset: 4B]; if (D.2751 D.2756) goto L2; else goto L3; L2:; MEM[base: lst, index: D.2857, step: 4B, offset: 4294967292B] = D.2756; MEM[base: D.2851, offset: 4B] = D.2751; L3:; j.56 = j.56 + 1; ivtmp.49 = ivtmp.49 + 4B; if (cnt j.56) goto L1; else goto L8; L8:; ivtmp.54 = ivtmp.54 + 4B; i = j; L6:; if (i pretmp.39) goto L0; else goto L7; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-18 14:39 --- Loop body with GCC 4.0: L0:; j = i + 1; if (cnt j) goto L12; else goto L8; L12:; ivtmp.22 = (int *) ivtmp.31; ivtmp.19 = 0; L1:; D.2609 = *((int *) ivtmp.31 + 4294967292B); D.2657 = (int *) ivtmp.22; D.2614 = *D.2657; if (D.2609 D.2614) goto L2; else goto L3; L2:; *((int *) ivtmp.31 + 4294967292B) = D.2614; *D.2657 = D.2609; L3:; ivtmp.19 = ivtmp.19 + 1; ivtmp.22 = ivtmp.22 + 4B; if (ivtmp.19 != (unsigned int) cnt - (unsigned int) j) goto L1; else goto L8; L8:; ivtmp.31 = ivtmp.31 + 4B; i = j; L6:; if (i pretmp.14) goto L0; else goto L7; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #3 from law at redhat dot com 2006-02-18 14:47 --- Subject: Re: ICE compiling a-textio.adb at -O1 -ftree-vrp On Sat, 2006-02-18 at 11:15 +, laurent at guerby dot net wrote: --- Comment #2 from laurent at guerby dot net 2006-02-18 11:15 --- Jeff mentionned ping pong between passes, I believe it's an infinite ping-pong loop between two things with memory usage increasing linearly (either leak or data structures) until the system kills the process. gdb traces do not show backtrace grow. My amd64 machine with 2GB RAM and 6GB swap failed on it too. The only way the ping-pong would lead to this behavior woudl be if you had a self-referring (ie recursive) expression. ie, a PLUS_EXPR where one of the operands is the PLUS_EXPR itself. More likely it's something wonky elsewhere. That's been the pattern so far. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug c/8268] no compile time array index checking
--- Comment #28 from giovannibajo at libero dot it 2006-02-18 14:48 --- Jakub, you have provided some infrastructure to compute object size and provide warnings for unsafe use of builtins. Do you believe that infrastructure could be reused/enhanced for this bug? -- giovannibajo at libero dot it changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 14:56 --- Would have been nice if you put the error message in the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-18 15:03 --- This works in 4.2.0 20060218. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-18 15:08 --- Error message is ieee.min2.i:25: error: unrecognizable insn: (insn 64 63 30 1 (set (reg:DF 8 8) (mem/u/c/i:DF (symbol_ref/u:SI (*.LC3) [flags 0x2]) [12 S8 A64])) -1 (nil) (nil)) ieee.min2.i:25: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.suse.de/feedback for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 15:19 --- The difference between 4.1 and 4.2 come in the schedule1 pass. 4.1 does something while it looks like 4.2 does not. -fno-schedule-insns on 4.1 fixes the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug c/8268] no compile time array index checking
--- Comment #29 from jakub at gcc dot gnu dot org 2006-02-18 15:24 --- Yes, fairly easily. Just add another pass, probably into tree-object-size.c, where you: init_object_sizes (); and for each ARRAY_REF compute objsz = compute_builtin_object_size (TREE_OPERAND (array_ref, 0), 0) and if (objsz != (unsigned HOST_WIDE_INT) -1 compare_tree_int (TREE_OPERAND (array_ref, 1), objsz)) = 0) warning (...); When done with the pass, call fini_object_sizes ();. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c++/26352] New: ICE
-- Summary: ICE Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug c++/26352] ICE
--- Comment #1 from igodard at pacbell dot net 2006-02-18 15:48 --- Created an attachment (id=10873) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10873action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug c++/26352] ICE
--- Comment #2 from igodard at pacbell dot net 2006-02-18 15:48 --- Created an attachment (id=10874) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10874action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug target/26189] Bug in vendor /usr/include/net/if.h needs fixincluding on HPUX
--- Comment #3 from sje at gcc dot gnu dot org 2006-02-18 15:58 --- Subject: Bug 26189 Author: sje Date: Sat Feb 18 15:58:06 2006 New Revision: 111237 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111237 Log: PR target/26189 * inclhack.def (hpux_spu_info): New. * fixincl.x: Regenerate Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189
[Bug target/26189] Bug in vendor /usr/include/net/if.h needs fixincluding on HPUX
--- Comment #4 from sje at gcc dot gnu dot org 2006-02-18 16:00 --- Subject: Bug 26189 Author: sje Date: Sat Feb 18 15:59:57 2006 New Revision: 111238 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111238 Log: PR target/26189 * inclhack.def (hpux_spu_info): New. * fixincl.x: Regenerate Modified: branches/gcc-4_1-branch/fixincludes/ChangeLog branches/gcc-4_1-branch/fixincludes/fixincl.x branches/gcc-4_1-branch/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189
[Bug libfortran/26346] FAIL: gfortran.dg/secnds.f -O0 execution test
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-18 16:00 --- Subject: Re: FAIL: gfortran.dg/secnds.f -O0 execution test This test can sometimes fail if you have a lot of background tasks running. I believe that the only taks running were those associated with the check and the standard set of system processes. Check the tolerance on the timing accuracy and see if increasing that allows the test to pass. I have seen it do this before. Or is the failure more distinct then that? At this time, I don't know. Will retest this weekend. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26346
[Bug c++/26352] ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 16:07 --- g++: Internal error: Killed (program cc1plus) means memory was over used. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug c/26353] New: [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on Nocona
I saw 9% regression in SPEC CPU 2K 175.vpr -O2 number on Nocona between gcc 3.4.4 and gcc 4.2. Gcc 4.1 and 4.0 have similar regression. -- Summary: [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on Nocona Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org 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=26353
[Bug ada/13408] [4.1/4.2 Regression] acats numeric tests cxg* fail on pa/hpux
--- Comment #13 from danglin at gcc dot gnu dot org 2006-02-18 16:12 --- Subject: Bug 13408 Author: danglin Date: Sat Feb 18 16:12:20 2006 New Revision: 111240 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111240 Log: PR ada/13408 * pa.h (WIDEST_HARDWARE_FP_SIZE): Define. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/pa/pa.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13408
[Bug c++/26291] [3.4/4.0/4.1/4.2 regression] Invalid ellipsis in operator not diagnosed
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
[Bug ada/13408] [4.1/4.2 Regression] acats numeric tests cxg* fail on pa/hpux
--- Comment #14 from danglin at gcc dot gnu dot org 2006-02-18 16:15 --- Subject: Bug 13408 Author: danglin Date: Sat Feb 18 16:15:07 2006 New Revision: 111241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111241 Log: PR ada/13408 * pa.h (WIDEST_HARDWARE_FP_SIZE): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13408
[Bug target/26353] [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on Nocona
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 16:16 --- What is the issue here except for the fact vrp regressed? There is not enough information even start to look into this bug until there is a testcase which people who don't have access to SPEC (me) to start looking into this issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
[Bug fortran/20938] Dependency checking fails for equivalences
--- Comment #2 from pault at gcc dot gnu dot org 2006-02-18 16:16 --- A patch is on its way - it's regtesting right now. This fixes the problem with where_19.f90 as well. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20938
[Bug ada/13408] [4.1/4.2 Regression] acats numeric tests cxg* fail on pa/hpux
--- Comment #15 from danglin at gcc dot gnu dot org 2006-02-18 16:17 --- Subject: Bug 13408 Author: danglin Date: Sat Feb 18 16:17:46 2006 New Revision: 111242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111242 Log: PR ada/13408 * pa.h (WIDEST_HARDWARE_FP_SIZE): Define. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/pa/pa.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13408
[Bug ada/13408] [4.1/4.2 Regression] acats numeric tests cxg* fail on pa/hpux
--- Comment #16 from danglin at gcc dot gnu dot org 2006-02-18 16:21 --- Subject: Bug 13408 Author: danglin Date: Sat Feb 18 16:21:06 2006 New Revision: 111243 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111243 Log: PR ada/13408 * pa.h (WIDEST_HARDWARE_FP_SIZE): Define. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/config/pa/pa.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13408
[Bug c++/26352] ICE
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 16:22 --- I cannot reproduce this at all in 4.0.2, 4.0.0, or 4.0.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug ada/13408] [4.1/4.2 Regression] acats numeric tests cxg* fail on pa/hpux
--- Comment #17 from danglin at gcc dot gnu dot org 2006-02-18 16:27 --- Fixed by patch. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13408
[Bug target/26353] [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on Nocona
--- Comment #2 from hjl at lucon dot org 2006-02-18 16:37 --- From http://people.redhat.com/dnovillo/spec2000.em64t/gcc/log/20060118/CINT2000.759.asc 175.vpr 1400 315 444* 1400 317 442* From http://people.redhat.com/dnovillo/spec2000.em64t/baseline-gcc342/log/20050514/CINT2000.543.asc 175.vpr 1400 312 448 1400 293 478* The difference is about 7.5%. We are working on a small testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
[Bug target/26353] [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on Nocona
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 16:38 --- I would not trust Diego's numbers with my life. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #4 from danglin at gcc dot gnu dot org 2006-02-18 16:41 --- Also seen on hppa-unknown-linux-gnu: /home/dave/gnu/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc- 4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/inclu de -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -c -g -O2 -f PIC -DELF=1 -DLINUX=1 -W -Wall -gnatpg a-textio.adb -o a-textio.o virtual memory exhausted: Cannot allocate memory -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #5 from dje at gcc dot gnu dot org 2006-02-18 16:47 --- This appears to be related to -fpic. The SYMBOL_REF is considered small data and rs6000_legitimate_small_data_p() includes !flag_pic. What is generating this when -fpic? -- dje at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot |dje at gcc dot gnu dot org |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 --- Saw it too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|ICE compiling a-textio.adb |[4.2 Regression] ICE |at -O1 -ftree-vrp |compiling a-textio.adb at - ||O1 -ftree-vrp Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug rtl-optimization/25600] unsigned31?-1:0 should be optimized to int31
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 17:13 --- Confirmed fixed. Thanks Roger. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25600
[Bug target/26353] [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on Nocona
--- Comment #4 from hjl at lucon dot org 2006-02-18 17:14 --- I have seen 9% myself. We are trying to isolate the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 17:22 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-18 17:22:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug libobjc/26309] [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX V4.0F
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 17:22 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-18 17:22:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26309
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #7 from dje at gcc dot gnu dot org 2006-02-18 17:24 --- Reload is creating the symbol_ref from the extenddftf2 splitter, which is trying to load 0.0. I think this is a case where we need to expand legitimize_reload_address(). Darwin uses that to fix up these insns, but it currently is disabled for SVR4 flag_pic. #if TARGET_MACHO DEFAULT_ABI == ABI_DARWIN (flag_pic || MACHO_DYNAMIC_NO_PIC_P) #else DEFAULT_ABI == ABI_V4 !flag_pic #endif -- dje at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-02-18 17:22:09 |2006-02-18 17:24:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug middle-end/18908] Missed folding opportunities with bools
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-18 17:32 --- Acutally f3 is not fixed but I don't understand how not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
[Bug fortran/24519] gfortran slow because of incomplete dependency checking
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-18 17:52 --- A patch is on its way for the immediate problem; however, the more complicated cases of loop reversal and of dependecy involving expressions will have to wait. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24519
[Bug middle-end/26334] [4.1 Regression] ICE in lhd_set_decl_assembler_name
--- Comment #6 from jakub at gcc dot gnu dot org 2006-02-18 18:58 --- Subject: Bug 26334 Author: jakub Date: Sat Feb 18 18:58:42 2006 New Revision: 111247 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111247 Log: PR middle-end/26334 * stmt.c (decl_overlaps_hard_reg_set_p): Use DECL_HARD_REGISTER instead of DECL_REGISTER. * gcc.c-torture/compile/20060217-1.c: New test. * gcc.dg/20060218-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20060217-1.c trunk/gcc/testsuite/gcc.dg/20060218-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26334
[Bug middle-end/26334] [4.1 Regression] ICE in lhd_set_decl_assembler_name
--- Comment #7 from jakub at gcc dot gnu dot org 2006-02-18 19:04 --- Subject: Bug 26334 Author: jakub Date: Sat Feb 18 19:04:08 2006 New Revision: 111248 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111248 Log: PR middle-end/26334 * gcc.dg/20060218-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20060218-1.c Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26334
[Bug fortran/26201] [4.1/4.2 regression] __convert_i4_i8 written to a module.
--- Comment #7 from eedelman at gcc dot gnu dot org 2006-02-18 19:52 --- Here's a small one-liner patch that I think fixes the bug. I'll post it to the mailing list later tonight if/when it passes regression testing. Index: gcc/fortran/intrinsic.c === --- gcc/fortran/intrinsic.c (revision 111236) +++ gcc/fortran/intrinsic.c (working copy) @@ -3428,6 +3428,7 @@ gfc_convert_type_warn (gfc_expr * expr, new-symtree-n.sym-attr.elemental = 1; new-symtree-n.sym-attr.pure = 1; new-symtree-n.sym-attr.referenced = 1; + gfc_intrinsic_symbol(new-symtree-n.sym); gfc_commit_symbol (new-symtree-n.sym); *expr = *new; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug middle-end/26334] [4.1 Regression] ICE in lhd_set_decl_assembler_name
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-18 19:58 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26334
[Bug middle-end/25912] Problem compiling Asterisk 1.2.2 with Debian 3.1 (Sarge) gcc (3.3.5 (Debian 1:3.3.5-13))
--- Comment #4 from julius at zgod dot cjb dot net 2006-02-18 20:37 --- On another system with Debian Sarge, I can compile it without problems. It is then compiled for i686 though instead of i586. Could it be that only compiling i586 is a problem? Should I try compiling it for i486 or i386 on my older comp? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25912
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #8 from dje at gcc dot gnu dot org 2006-02-18 20:43 --- Created an attachment (id=10875) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10875action=view) patch to place constant 0.0 in MEM and validize to create GOT reference -- dje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug tree-optimization/25680] Store CCP does not understand REALPART_EXPR COMPLEX_CST
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 21:09 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25680
[Bug tree-optimization/25680] Store CCP does not understand REALPART_EXPR COMPLEX_CST
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-18 21:09 --- Subject: Bug 25680 Author: pinskia Date: Sat Feb 18 21:09:35 2006 New Revision: 111251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111251 Log: 2006-02-18 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/25680 * tree-ssa-ccp.c (ccp_fold): Handle store CCP of REALPART_EXPR and IMAGPART_EXPR. 2006-02-18 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/25680 * testsuite/gcc.dg/tree-ssa/complex-3.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/complex-3.c trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25680
[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #6 from law at redhat dot com 2006-02-18 21:36 --- Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 --- Saw it too. Basically we're simulating a set of 6 statements over and over for reasons unknown. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #7 from law at redhat dot com 2006-02-18 21:49 --- Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 --- Saw it too. I think I know what's going on here. Probably can't get a good fix in until tues/wed. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
[Bug tree-optimization/17106] Opportunity to eliminate loads from TOC.
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-02-18 22:07 --- Subject: Bug 17106 Author: rsandifo Date: Sat Feb 18 22:06:53 2006 New Revision: 111254 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111254 Log: * cselib.c (cselib_init): Change RTX_SIZE to RTX_CODE_SIZE. * emit-rtl.c (copy_rtx_if_shared_1): Use shallow_copy_rtx. (copy_insn_1): Likewise. Don't copy each field individually. Reindent. * read-rtl.c (apply_macro_to_rtx): Use RTX_CODE_SIZE instead of RTX_SIZE. * reload1.c (eliminate_regs): Use shallow_copy_rtx. * rtl.c (rtx_size): Rename variable to... (rtx_code_size): ...this. (rtx_size): New function. (rtx_alloc_stat): Use RTX_CODE_SIZE instead of RTX_SIZE. (copy_rtx): Use shallow_copy_rtx. Don't copy each field individually. Reindent. (shallow_copy_rtx_stat): Use rtx_size instead of RTX_SIZE. * rtl.h (rtx_code_size): New variable. (rtx_size): Change from a variable to a function. (RTX_SIZE): Rename to... (RTX_CODE_SIZE): ...this. PR target/9703 PR tree-optimization/17106 * doc/tm.texi (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Document. (Anchored Addresses): New section. * doc/invoke.texi (-fsection-anchors): Document. * doc/rtl.texi (SYMBOL_REF_IN_BLOCK_P, SYMBOL_FLAG_IN_BLOCK): Likewise. (SYMBOL_REF_ANCHOR_P, SYMBOL_FLAG_ANCHOR): Likewise. (SYMBOL_REF_BLOCK, SYMBOL_REF_BLOCK_OFFSET): Likewise. * hooks.c (hook_bool_mode_rtx_false): New function. * hooks.h (hook_bool_mode_rtx_false): Declare. * gengtype.c (create_optional_field): New function. (adjust_field_rtx_def): Add the block_sym field for SYMBOL_REFs when SYMBOL_REF_IN_BLOCK_P is true. * target.h (output_anchor, use_blocks_for_constant_p): New hooks. (min_anchor_offset, max_anchor_offset): Likewise. (use_anchors_for_symbol_p): New hook. * toplev.c (compile_file): Call output_object_blocks. (target_supports_section_anchors_p): New function. (process_options): Check that -fsection-anchors is only used on targets that support it and when -funit-at-a-time is in effect. * tree-ssa-loop-ivopts.c (prepare_decl_rtl): Only create DECL_RTL if the decl doesn't have one. * dwarf2out.c: Remove instantiations of VEC(rtx,gc). * expr.c (emit_move_multi_word, emit_move_insn): Pass the result of force_const_mem through use_anchored_address. (expand_expr_constant): New function. (expand_expr_addr_expr_1): Call it. Use the same modifier when calling expand_expr for INDIRECT_REF. (expand_expr_real_1): Pass DECL_RTL through use_anchored_address for all modifiers except EXPAND_INITIALIZER. Use expand_expr_constant. * expr.h (use_anchored_address): Declare. * loop-unroll.c: Don't declare rtx vectors here. * explow.c: Include output.h. (validize_mem): Call use_anchored_address. (use_anchored_address): New function. * common.opt (-fsection-anchors): New switch. * varasm.c (object_block_htab, anchor_labelno): New variables. (hash_section, object_block_entry_eq, object_block_entry_hash) (use_object_blocks_p, get_block_for_section, create_block_symbol) (use_blocks_for_decl_p, change_symbol_section): New functions. (get_variable_section): New function, split out from assemble_variable. (make_decl_rtl): Create a block symbol if use_object_blocks_p and use_blocks_for_decl_p say so. Use change_symbol_section if the symbol has already been created. (assemble_variable_contents): New function, split out from... (assemble_variable): ...here. Don't output any code for block symbols; just pass them to place_block_symbol. Use get_variable_section and assemble_variable_contents. (get_constant_alignment, get_constant_section, get_constant_size): New functions, split from output_constant_def_contents. (build_constant_desc): Create a block symbol if use_object_blocks_p says so. Or into SYMBOL_REF_FLAGS. (assemble_constant_contents): New function, split from... (output_constant_def_contents): ...here. Don't output any code for block symbols; just pass them to place_section_symbol. Use get_constant_section and get_constant_alignment. (force_const_mem): Create a block symbol if use_object_blocks_p and use_blocks_for_constant_p say so. Or into SYMBOL_REF_FLAGS. (output_constant_pool_1): Add an explicit alignment argument. Don't switch sections here. (output_constant_pool): Adjust call to output_constant_pool_1. Switch sections here instead. Don't output anything for block symbols; just pass them to
[Bug target/9703] [arm] Accessing data through constant pool more times could be solved in less instructions
--- Comment #8 from rsandifo at gcc dot gnu dot org 2006-02-18 22:07 --- Subject: Bug 9703 Author: rsandifo Date: Sat Feb 18 22:06:53 2006 New Revision: 111254 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111254 Log: * cselib.c (cselib_init): Change RTX_SIZE to RTX_CODE_SIZE. * emit-rtl.c (copy_rtx_if_shared_1): Use shallow_copy_rtx. (copy_insn_1): Likewise. Don't copy each field individually. Reindent. * read-rtl.c (apply_macro_to_rtx): Use RTX_CODE_SIZE instead of RTX_SIZE. * reload1.c (eliminate_regs): Use shallow_copy_rtx. * rtl.c (rtx_size): Rename variable to... (rtx_code_size): ...this. (rtx_size): New function. (rtx_alloc_stat): Use RTX_CODE_SIZE instead of RTX_SIZE. (copy_rtx): Use shallow_copy_rtx. Don't copy each field individually. Reindent. (shallow_copy_rtx_stat): Use rtx_size instead of RTX_SIZE. * rtl.h (rtx_code_size): New variable. (rtx_size): Change from a variable to a function. (RTX_SIZE): Rename to... (RTX_CODE_SIZE): ...this. PR target/9703 PR tree-optimization/17106 * doc/tm.texi (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Document. (Anchored Addresses): New section. * doc/invoke.texi (-fsection-anchors): Document. * doc/rtl.texi (SYMBOL_REF_IN_BLOCK_P, SYMBOL_FLAG_IN_BLOCK): Likewise. (SYMBOL_REF_ANCHOR_P, SYMBOL_FLAG_ANCHOR): Likewise. (SYMBOL_REF_BLOCK, SYMBOL_REF_BLOCK_OFFSET): Likewise. * hooks.c (hook_bool_mode_rtx_false): New function. * hooks.h (hook_bool_mode_rtx_false): Declare. * gengtype.c (create_optional_field): New function. (adjust_field_rtx_def): Add the block_sym field for SYMBOL_REFs when SYMBOL_REF_IN_BLOCK_P is true. * target.h (output_anchor, use_blocks_for_constant_p): New hooks. (min_anchor_offset, max_anchor_offset): Likewise. (use_anchors_for_symbol_p): New hook. * toplev.c (compile_file): Call output_object_blocks. (target_supports_section_anchors_p): New function. (process_options): Check that -fsection-anchors is only used on targets that support it and when -funit-at-a-time is in effect. * tree-ssa-loop-ivopts.c (prepare_decl_rtl): Only create DECL_RTL if the decl doesn't have one. * dwarf2out.c: Remove instantiations of VEC(rtx,gc). * expr.c (emit_move_multi_word, emit_move_insn): Pass the result of force_const_mem through use_anchored_address. (expand_expr_constant): New function. (expand_expr_addr_expr_1): Call it. Use the same modifier when calling expand_expr for INDIRECT_REF. (expand_expr_real_1): Pass DECL_RTL through use_anchored_address for all modifiers except EXPAND_INITIALIZER. Use expand_expr_constant. * expr.h (use_anchored_address): Declare. * loop-unroll.c: Don't declare rtx vectors here. * explow.c: Include output.h. (validize_mem): Call use_anchored_address. (use_anchored_address): New function. * common.opt (-fsection-anchors): New switch. * varasm.c (object_block_htab, anchor_labelno): New variables. (hash_section, object_block_entry_eq, object_block_entry_hash) (use_object_blocks_p, get_block_for_section, create_block_symbol) (use_blocks_for_decl_p, change_symbol_section): New functions. (get_variable_section): New function, split out from assemble_variable. (make_decl_rtl): Create a block symbol if use_object_blocks_p and use_blocks_for_decl_p say so. Use change_symbol_section if the symbol has already been created. (assemble_variable_contents): New function, split out from... (assemble_variable): ...here. Don't output any code for block symbols; just pass them to place_block_symbol. Use get_variable_section and assemble_variable_contents. (get_constant_alignment, get_constant_section, get_constant_size): New functions, split from output_constant_def_contents. (build_constant_desc): Create a block symbol if use_object_blocks_p says so. Or into SYMBOL_REF_FLAGS. (assemble_constant_contents): New function, split from... (output_constant_def_contents): ...here. Don't output any code for block symbols; just pass them to place_section_symbol. Use get_constant_section and get_constant_alignment. (force_const_mem): Create a block symbol if use_object_blocks_p and use_blocks_for_constant_p say so. Or into SYMBOL_REF_FLAGS. (output_constant_pool_1): Add an explicit alignment argument. Don't switch sections here. (output_constant_pool): Adjust call to output_constant_pool_1. Switch sections here instead. Don't output anything for block symbols; just pass them to place_block_symbol.
[Bug regression/26355] New: defining static members of specialized template classes doesn't work
I'm not 100% sure if this is a compiler bug or a bug in my code but I think
that what I'm trying to do should be valid according to 14.7.5/4 of the C++
Standard. Please consider the following example:
% cat stsp.cpp
enum V { V1, V2, V3 };
template V v struct Data { static int Value; };
int DataV1::Value;
extern int GetIt() { return DataV1::Value; }
Compiling this with g++ 4.0 or 4.1 doesn't work:
% g++-4.0 -c -Wall stsp.cpp
stsp.cpp:5: error: too few template-parameter-lists
% g++-4.1 -c -Wall stsp.cpp
stsp.cpp:5: error: too few template-parameter-lists
While it works with all the previous versions (down to 2.95!).
g++4 does accept the explicit specialization of the static member if you
prepend template to DataV1::Value line which, IMHO, wrong too. But it
doesn't define the symbol in the object file in this case.
If this is really not allowed then it would be nice to make the error message
more clear.
--
Summary: defining static members of specialized template classes
doesn't work
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
[Bug target/9703] [arm] Accessing data through constant pool more times could be solved in less instructions
--- Comment #9 from rsandifo at gcc dot gnu dot org 2006-02-18 22:22 --- The patch I committed should provide the general infrastructure, but an ARM patch will be needed to make use of it. ARM code would also benefit if we tried to reuse addresses that the function had to calculate anyway, rather than use arbitrary anchors for everything. (I wrote a message about this that I was supposed to send to [EMAIL PROTECTED] However, it isn't in either the web archives or gmane, so I suspect I sent it privately by accident.) I'm not intending to do the ARM bits myself right now, so I'll return this PR to unassigned. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rsandifo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9703
[Bug tree-optimization/17106] Opportunity to eliminate loads from TOC.
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-02-18 22:25 --- With the patch that I just committed, you should be able to get the desired behaviour using -fsection-anchors. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17106
[Bug c++/22095] static template class member definition doesn't compile
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 22:26 --- *** Bug 26355 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vz-gcc at zeitlins dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22095
[Bug regression/26355] defining static members of specialized template classes doesn't work
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 22:26 --- This is invalid code. This is a dup of bug 22095. The diagnostic issue is filed under PR 20118. *** This bug has been marked as a duplicate of 22095 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
[Bug regression/26355] defining static members of specialized template classes doesn't work
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-18 22:28 --- Also see PR 11930 for more help with the issue adding template does not emit the variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
[Bug regression/26355] defining static members of specialized template classes doesn't work
--- Comment #3 from vz-gcc at zeitlins dot org 2006-02-18 22:47 ---
First, thanks a lot Andrew for your lightning fast reply, this is really
amazing -- and incredibly helpful!
Second, really sorry, rereading the explicit specialization section once again
I see that I was indeed wrong and that template is really needed.
Third, unfortunately PR 11930 does not help with my test case:
% cat -n stsp.cpp
1 enum V { V1, V2, V3 };
2
3 template V v struct Data { static int Value; };
4
5 template struct DataV1;
6
7 template int DataV1::Value;
8
9 int main() { return DataV1::Value; }
% g++-4.0 -o stsp -Wall stsp.cpp
/tmp/ccywXRfg.o: In function `main':stsp.cpp:(.text+0x1d): undefined reference
to `Data(V)0::Value'
collect2: ld returned 1 exit status
It looks like the compiler interprets the line 7 as declaration and not
definition? If I add an initializer (i.e. change the line to end with Value =
17 or Value(17)) then it works just fine. Unfortunately in the real code the
static member is a class and, worse, a class with only default ctor so I can't
use Value() (which would be parsed as a function declaration) to force
recognizing it such.
Sorry in advance if I'm missing something again but it doesn't seem normal that
no definition is emitted for the example above, does it?
Thanks again for your help!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
[Bug libstdc++/26297] boostrap fails with invalid cast compiling libstdc++ with --disable-nls on AIX
--- Comment #8 from multix at gmail dot com 2006-02-18 23:04 --- this happens on 3.3.6 too, but I read http://gcc.gnu.org/ml/gcc/2003-10/msg00110.html who was able to build 3.3.1 on an even older system. Differences are that he disabled multilib and shared libraries. I don't see how that could affect me though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26297
[Bug libstdc++/26297] boostrap fails with invalid cast compiling libstdc++ with --disable-nls on AIX
--- Comment #9 from dje at gcc dot gnu dot org 2006-02-18 23:16 --- libstdc++ configuration may have detected that the particular feature causing problems was not present or the header may not have defined the function at all, causing libstdc++ to provide its own implementation. The usual problem is that a system claims it supports some feature, but does not implement it correctly or does not declare the standard function correctly. Providing something wrong generally is worse than not providing it. GCC does have some functionality to go back and fix up headers, but GCC probably does not know about this particular problem. The problem appears to be that AIX 4.2 declares strtof() in /usr/include/stdlib.h as extern floatstrtof(char *, char **); instead of extern floatstrtof(const char *, char **); In other words, missing the const. You could manually fix the header during the build process between building the compiler and building the libraries, by changing the copy of the stdlib.h header in the gcc/include subdirectory of the build. GCC uses its copy of the header if present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26297
[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128
--- Comment #9 from dje at gcc dot gnu dot org 2006-02-18 23:19 --- Subject: Bug 26350 Author: dje Date: Sat Feb 18 23:19:02 2006 New Revision: 111255 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111255 Log: PR target/26350 * config/rs6000/rs6000.md (extenddftf2): Force 0.0 to validized MEM for ABI_V4 pic. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
[Bug fortran/26201] [4.1/4.2 regression] __convert_i4_i8 written to a module.
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2006-02-18 23:54 --- Subject: Re: [4.1/4.2 regression] __convert_i4_i8 written to a module. On Sat, Feb 18, 2006 at 07:52:27PM -, eedelman at gcc dot gnu dot org wrote: Index: gcc/fortran/intrinsic.c === --- gcc/fortran/intrinsic.c (revision 111236) +++ gcc/fortran/intrinsic.c (working copy) @@ -3428,6 +3428,7 @@ gfc_convert_type_warn (gfc_expr * expr, new-symtree-n.sym-attr.elemental = 1; new-symtree-n.sym-attr.pure = 1; new-symtree-n.sym-attr.referenced = 1; + gfc_intrinsic_symbol(new-symtree-n.sym); gfc_commit_symbol (new-symtree-n.sym); *expr = *new; This fixes the problem of compiling MUMPS on amd64-*-freebsd. OK to commit to trunk. You'll need approval from markm to commit to 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug other/26356] New: contrib.texi contributors lists need merging
Currently gcc/doc/contrib.texi has four lists: - main gcc contributors. - gnats contributors - libgcj/classpath contributors - testers They should be merged. -- Summary: contrib.texi contributors lists need merging Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26356
[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #8 from law at redhat dot com 2006-02-19 00:16 ---
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02
---
Saw it too.
Ignore my last post about an initial theory. It looks like
some code, somewhere is goofing up types in a very unpleasant
way. If I had to point a finger, I'd have to guess it's
somewhere in the Ada front-end and an Ada person is going to have
to look at this. It's highly unlikely with my total lack of
knowledge about the Ada front-end that have any chance of fixing
it.
Our little odyssey starts with visiting this PHI node:
[ The first visit is uninteresting, ignore it. I'm starting my
analysis with the second visit. ]
lastD.2483_148 = PHI lastD.2483_60(28), lastD.2483_15(14);
Only the edge from block #14 is executable, so the result of the
PHI will be equivalent to the current range for last_15. The
range we record is [0, 0x7fff].
We then proceed to the uses of last_148. One of which is:
lastD.2483_86 = lastD.2483_148 + 1;
Now for the first oddity. If we look at the underlying type
for last we have a type natural___XDLU_0__2147483647. What's
interesting about it is that it has a 32bit type precision, but
the min/max values only specify 31 bits. ie, the min/max values
are 0, 0x7fff.
So anyway, we proceed to add the current range for last_148
[0, 0x7fff] to the constant 1.This results in
[1, 0x8000]. Second oddity. This is clearly outside the
type's min/max values, but because the value is inside the
type's precision, no overflow is signaled and no bits are
zero'd out.
We then encounter this statement:
lastD.2483_60 = lastD.2483_86;
So we copy the current range for last_86 to last_60. [1, 0x8000]
which I'll note again is outside the min/max values associated with
last's type.
We now return to the PHI node:
lastD.2483_148 = PHI lastD.2483_60(28), lastD.2483_15(14);
We still only have one edge (from block #14) marked executable,
so nothing interesting happens yet.
We then visit the PHI node a 4th time. This time both edges are
marked as executable. So we're going to have to meet the ranges
for last_60 [0x1, 0x8000] and last_15 [0x0, 0x7fff].
Now with the range for last_60 being outside the type's min/max values
I don't think we can meaningfully merge these ranges. We've clearly
gone off the reservation already, but just for fun let's see what
happens.
The min value is computed as 0x0, which is exactly what we would
expect. Nothing fun or interesting here.
What's fun is meeting the max values of 0x800 and 0x7fff.
vrp_meet returns 0x8000 as the meet value. OK, that's plausible,
I don't think vrp_meet tries to clamp values at min/max for the type.
We then fallinto this hunk of code:
3995 if (lhs_vr-type == VR_RANGE vr_result.type == VR_RANGE)
3996{
3997 if (!POINTER_TYPE_P (TREE_TYPE (lhs)))
3998{
3999 int cmp_min = compare_values (lhs_vr-min,
vr_result.min);
4000 int cmp_max = compare_values (lhs_vr-max,
vr_result.max);
4001
4002 /* If the new minimum is smaller or larger than the
previous
4003 one, go all the way to -INF. In the first case, to
avoid
4004 iterating millions of times to reach -INF, and in
the
(gdb)
4005 other case to avoid infinite bouncing between
different
4006 minimums. */
4007 if (cmp_min 0 || cmp_min 0)
4008vr_result.min = TYPE_MIN_VALUE (TREE_TYPE
(vr_result.min));
4009
4010 /* Similarly, if the new maximum is smaller or larger
than
4011 the previous one, go all the way to +INF. */
4012 if (cmp_max 0 || cmp_max 0)
4013vr_result.max = TYPE_MAX_VALUE (TREE_TYPE
(vr_result.max));
4014
(gdb)
4015 /* If we ended up with a (-INF, +INF) range, set it to
4016 VARYING. */
4017 if (vr_result.min == TYPE_MIN_VALUE (TREE_TYPE
(vr_result.min))
4018 vr_result.max == TYPE_MAX_VALUE (TREE_TYPE
(vr_result.max)))
4019goto varying;
lhs_vr-max is 0x7fff and vr_result-max is 0x8000, so cmp_max
is -1. Which indicates we should set a new maximum to be the maximum
for the type. The maximum for the type is 0x7fff. But just as
important, this ends up changing the underlying type for vr_result.max,
instead of being natural___XDLU_0__2147483647 it's a more generic
integer type. Ugh! Now we go to update the range for the result
using update_value_range. We determine the range is new, even though
the underlying values are unchanged because we're using pointer
equality for all our tests (this is bad).
So we consider the PHI node's result as being new, so we re-simulate
the uses of the
[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
--- Comment #9 from laurent at guerby dot net 2006-02-19 00:23 --- May be Richard Kenner could help here? -- laurent at guerby dot net changed: What|Removed |Added CC||kenner at vlsi1 dot ultra ||dot nyu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
Re: [Bug c/8268] no compile time array index checking
rguenth at gcc dot gnu dot org wrote:-
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s-str[42];
}
That definitely deserves a warning.
Neil.
[Bug c/8268] no compile time array index checking
--- Comment #30 from neil at daikokuya dot co dot uk 2006-02-19 00:52
---
Subject: Re: no compile time array index checking
rguenth at gcc dot gnu dot org wrote:-
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s-str[42];
}
That definitely deserves a warning.
Neil.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug libfortran/26357] New: Unformated input doesn't work
One of the SPEC CPU 2006 benchmark uses unformatted input and it failed at the rune time. -- Summary: Unformated input doesn't work Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
[Bug libfortran/26357] Unformated input doesn't work
--- Comment #1 from hjl at lucon dot org 2006-02-19 01:15 --- Created an attachment (id=10876) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10876action=view) A testcase I got [EMAIL PROTECTED] unformated]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -o foo foo.f90 -Wl,-rpath,/export/build/gnu/gcc/build-x86_64-linux/gcc/../x86_64-unknown-linux-gnu/libgfortran/.libs ./foo make: *** [all] Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
[Bug libgomp/26328] Timouts in libgomp tests with --with-long-double-128
--- Comment #2 from lucier at math dot purdue dot edu 2006-02-19 01:16 --- Subject: Re: Timouts in libgomp tests with --with-long-double-128 On Feb 16, 2006, at 2:41 PM, pinskia at gcc dot gnu dot org wrote: First --with-long-double-128 does nothing on Darwin. Does it do nothing on darwin because long double is already 128bits on Darwin? Some of the messages on the lists imply that there are 64- bit long doubles as well as 128-bit long doubles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26328
[Bug libfortran/26357] Unformated input doesn't work
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-19 01:19 --- unformated input is not portable at all and should be baned from SPEC unless the test is also writting out the unformated data. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
[Bug libfortran/26357] Unformated input doesn't work
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-19 01:20 --- I am tempting at closing this as invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
[Bug libfortran/26357] Unformated input doesn't work
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-19 01:30 --- http://gcc.gnu.org/onlinedocs/gcc-3.0.1/g77_20.html#SEC662 Says they are not portable. Why are they trying to use unformatted input? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
