[Bug c++/13095] GCC accepts invalid using declaration
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-09 07:27 --- Fixed on mainline by Nathan's patch for PR19497. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13095
[Bug target/21973] Segfault in GTK+ compiled with -march=pentium4 when used through JNI
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21973
[Bug c++/21974] linking error of basic_string
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 07:33 --- 3.3.x is no longer maintained. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21974
[Bug libstdc++/21974] linking error of basic_string
-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21974
[Bug c/21975] New: Segmentation fault while compiling ipw2100
Compiling ipw2100 1.1.0 against linux 2.6.12-rc6 results in an internal compiler error. $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0-20050602/configure --prefix=/usr --libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-arch=pentium2 --enable-shared --disable-multilib --enable-clocale=gnu --enable-threads=posix --enable-__cxa_atexit Thread model: posix gcc version 4.0.1 20050602 (prerelease) $ gcc -Wp,-MD,/usr/src/ipw2100-1.1.0/.ipw2100.o.d -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.0.1/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -fomit-frame-pointer -pipe -msoft-float -mpreferred-stack-boundary=2 -fno-unit-at-a-time -mregparm=3 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -I/usr/src/linux-2.6.12-rc6-paldo1/drivers/net/wireless -g -Wa,-adhlms=/usr/src/ipw2100-1.1.0/ipw2100.o.lst -DCONFIG_PM -DCONFIG_IPW_DEBUG=y -DCONFIG_IPW2100_MONITOR=y -DCONFIG_IEEE80211_DEBUG=y -DCONFIG_IEEE80211_CRYPT=m -DCONFIG_IEEE80211_WPA=m -DCONFIG_IEEE80211_CRYPT_TKIP=m -DCONFIG_IEEE80211_CRYPT_CCMP=m -DMODULE -DKBUILD_BASENAME=ipw2100 -DKBUILD_MODNAME=ipw2100 -c -o /usr/src/ipw2100-1.1.0/ipw2100.o /usr/src/ipw2100-1.1.0/ipw2100.c include/linux/etherdevice.h: In function 'ipw2100_set_address': include/linux/etherdevice.h:84: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions -- Summary: Segmentation fault while compiling ipw2100 Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j at bitron dot ch CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
[Bug tree-optimization/20610] Real by complex multiplications perform unnecessary operations
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-09 07:44 --- Subject: Bug 20610 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-09 07:43:47 Modified files: gcc: ChangeLog gimplify.c integrate.c tree-complex.c tree-gimple.c tree-optimize.c tree-pass.h tree.h Log message: PR tree-opt/20610 * tree.h (DECL_COMPLEX_GIMPLE_REG_P): New. (struct tree_decl): Add gimple_reg_flag. * integrate.c (copy_decl_for_inlining): Copy it. * gimplify.c (internal_get_tmp_var): Set it. (gimplify_bind_expr): Likewise. (gimplify_function_tree): Likewise. (gimplify_modify_expr_complex_part): New. (gimplify_modify_expr): Use it. * tree-gimple.c (is_gimple_reg_type): Allow complex. (is_gimple_reg): Allow complex with DECL_COMPLEX_GIMPLE_REG_P set. * tree-complex.c (complex_lattice_t): New. (complex_lattice_values, complex_variable_components): New. (some_nonzerop, find_lattice_value, is_complex_reg, init_parameter_lattice_values, init_dont_simulate_again, complex_visit_stmt, complex_visit_phi, create_components, update_complex_components, update_parameter_components, update_phi_components, update_all_vops, expand_complex_move): New. (extract_component): Handle INDIRECT_REF, COMPONENT_REF, ARRAY_REF, SSA_NAME. (update_complex_assignment): Use update_complex_components; handle updates of return_expr properly. (expand_complex_addition): Use complex lattice values. (expand_complex_multiplication): Likewise. (expand_complex_division): Likewise. (expand_complex_libcall): Use update_complex_components. (expand_complex_comparison): Use update_stmt. (expand_complex_operations_1): Use expand_complex_move, retrieve lattice values. (tree_lower_complex): Compute lattice values. (tree_lower_complex_O0): Duplicate from tree_lower_complex. (pass_lower_complex_O0): Rename from pass_lower_complex. (pass_lower_complex, gate_no_optimization): New. * tree-optimize.c (init_tree_optimization_passes): Update for complex pass changes. * tree-pass.h (pass_lower_complex_O0): Declare. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9100&r2=2.9101 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.135&r2=2.136 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/integrate.c.diff?cvsroot=gcc&r1=1.279&r2=1.280 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gcc&r1=2.26&r2=2.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-gimple.c.diff?cvsroot=gcc&r1=2.38&r2=2.39 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-optimize.c.diff?cvsroot=gcc&r1=2.105&r2=2.106 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-pass.h.diff?cvsroot=gcc&r1=2.40&r2=2.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.735&r2=1.736 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20610
[Bug c/21975] Segmentation fault while compiling ipw2100
--- Additional Comments From j at bitron dot ch 2005-06-09 07:45 --- Created an attachment (id=9053) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9053&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
[Bug c++/21903] [3.4/4.0 regression] Default argument of template function causes a compile-time error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-09 07:46 --- Subject: Bug 21903 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-06-09 07:46:23 Modified files: gcc/cp : ChangeLog cp-tree.def parser.c pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.oliva: template6.C Added files: gcc/testsuite/g++.dg/parse: local-class1.C defarg9.C gcc/testsuite/g++.dg/template: explicit6.C Log message: cp: PR c++/21903 * cp-tree.def (DEFAULT_ARG): Document TREE_CHAIN use. * parser.c (cp_parser_late_parsing_default_args): Propagate parsed argument to any early instantiations. * pt.c (tsubst_arg_types): Chain early instantiation of default arg. PR c++/19884 * pt.c (check_explicit_specialization): Make sure namespace binding lookup found an overloaded function. (lookup_template_function): Just assert FNS is an overloaded function. testsuite: PR c++/19608 * parser.c (cp_parser_late_parsing_for_member): Use current_function_decl as scope to push to and from. testsuite: PR 21903 * g++.dg/parse/defarg9.C: New. PR c++/19884 * g++.old-deja/g++.oliva/template6.C: Add another case. * g++.dg/template/explicit6.C: New. PR c++/19608 * g++.dg/parse/local-class1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.223&r2=1.3892.2.224 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.def.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.80&r2=1.80.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.56&r2=1.157.2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.54&r2=1.816.2.55 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.403&r2=1.3389.2.404 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/local-class1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.28.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/defarg9.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/explicit6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.28.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.oliva/template6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3&r2=1.3.16.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
[Bug c++/19884] [3.4 regression] ICE on explicit instantiation of a non-template constructor
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-09 07:46 --- Subject: Bug 19884 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-06-09 07:46:23 Modified files: gcc/cp : ChangeLog cp-tree.def parser.c pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.oliva: template6.C Added files: gcc/testsuite/g++.dg/parse: local-class1.C defarg9.C gcc/testsuite/g++.dg/template: explicit6.C Log message: cp: PR c++/21903 * cp-tree.def (DEFAULT_ARG): Document TREE_CHAIN use. * parser.c (cp_parser_late_parsing_default_args): Propagate parsed argument to any early instantiations. * pt.c (tsubst_arg_types): Chain early instantiation of default arg. PR c++/19884 * pt.c (check_explicit_specialization): Make sure namespace binding lookup found an overloaded function. (lookup_template_function): Just assert FNS is an overloaded function. testsuite: PR c++/19608 * parser.c (cp_parser_late_parsing_for_member): Use current_function_decl as scope to push to and from. testsuite: PR 21903 * g++.dg/parse/defarg9.C: New. PR c++/19884 * g++.old-deja/g++.oliva/template6.C: Add another case. * g++.dg/template/explicit6.C: New. PR c++/19608 * g++.dg/parse/local-class1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.223&r2=1.3892.2.224 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.def.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.80&r2=1.80.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.56&r2=1.157.2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.54&r2=1.816.2.55 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.403&r2=1.3389.2.404 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/local-class1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.28.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/defarg9.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/explicit6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.28.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.oliva/template6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3&r2=1.3.16.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19884
[Bug c++/19608] [3.4 Regression] ICE after friend function definition in local class
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-09 07:46 --- Subject: Bug 19608 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-06-09 07:46:23 Modified files: gcc/cp : ChangeLog cp-tree.def parser.c pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.oliva: template6.C Added files: gcc/testsuite/g++.dg/parse: local-class1.C defarg9.C gcc/testsuite/g++.dg/template: explicit6.C Log message: cp: PR c++/21903 * cp-tree.def (DEFAULT_ARG): Document TREE_CHAIN use. * parser.c (cp_parser_late_parsing_default_args): Propagate parsed argument to any early instantiations. * pt.c (tsubst_arg_types): Chain early instantiation of default arg. PR c++/19884 * pt.c (check_explicit_specialization): Make sure namespace binding lookup found an overloaded function. (lookup_template_function): Just assert FNS is an overloaded function. testsuite: PR c++/19608 * parser.c (cp_parser_late_parsing_for_member): Use current_function_decl as scope to push to and from. testsuite: PR 21903 * g++.dg/parse/defarg9.C: New. PR c++/19884 * g++.old-deja/g++.oliva/template6.C: Add another case. * g++.dg/template/explicit6.C: New. PR c++/19608 * g++.dg/parse/local-class1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.223&r2=1.3892.2.224 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.def.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.80&r2=1.80.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.56&r2=1.157.2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.54&r2=1.816.2.55 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.403&r2=1.3389.2.404 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/local-class1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.28.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/defarg9.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/explicit6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.28.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.oliva/template6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3&r2=1.3.16.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19608
[Bug c++/21903] [4.0 regression] Default argument of template function causes a compile-time error
--- Additional Comments From nathan at gcc dot gnu dot org 2005-06-09 07:47 --- Fixed on 3.4 2005-06-08 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/21903 * cp-tree.def (DEFAULT_ARG): Document TREE_CHAIN use. * parser.c (cp_parser_late_parsing_default_args): Propagate parsed argument to any early instantiations. * pt.c (tsubst_arg_types): Chain early instantiation of default arg. -- What|Removed |Added Summary|[3.4/4.0 regression] Default|[4.0 regression] Default |argument of template|argument of template |function causes a compile- |function causes a compile- |time error |time error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
[Bug c++/19884] ICE on explicit instantiation of a non-template constructor
--- Additional Comments From nathan at gcc dot gnu dot org 2005-06-09 07:48 --- Fixed on 3.4 2005-06-08 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/19884 * pt.c (check_explicit_specialization): Make sure namespace binding lookup found an overloaded function. (lookup_template_function): Just assert FNS is an overloaded function. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[3.4 regression] ICE on |ICE on explicit |explicit instantiation of a |instantiation of a non- |non-template constructor|template constructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19884
[Bug c++/19608] ICE after friend function definition in local class
--- Additional Comments From nathan at gcc dot gnu dot org 2005-06-09 07:49 --- Fixed on 3.4 2005-06-08 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/19608 * parser.c (cp_parser_late_parsing_for_member): Use current_function_decl as scope to push to and from. testsuite: -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[3.4 Regression] ICE after |ICE after friend function |friend function definition |definition in local class |in local class | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19608
[Bug tree-optimization/20610] Real by complex multiplications perform unnecessary operations
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-09 08:14 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20610
[Bug tree-optimization/21933] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-06-09 08:45 --- patch: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00850.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21933
[Bug tree-optimization/21884] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-06-09 08:47 --- this patch: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00850.html seems to fix this ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21884
[Bug tree-optimization/21933] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-09 08:51 --- Confirmed by Dorit. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||06/msg00445.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-06-09 08:51:11 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21933
[Bug fortran/19239] gfortran ICE on vector subscript expressions
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-09 09:06 --- This TODO item prevents successful compilation of the following Numerical Recipes: anneal.f90 dftint.f90:39 factln.f90:39 factrl.f90:40 four1_gather.f90:20 fourn_gather.f90:25 pwt.f90:17 savgol.f90:29 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19239
[Bug middle-end/21964] [3.4 Regression] broken tail call at -O2 or more
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-09
09:20 ---
Here is the initial RTL for the call to foo:
(call_insn 44 20 45 (call_placeholder 40 31 22 27 (cond [
(const_string "normal") (sequence [
(insn 40 0 39 (set (reg:SI 63)
(reg/v:SI 58 [ n ])) -1 (nil)
(nil))
(insn 39 40 41 (parallel [
(set (reg/v:SI 58 [ n ])
(plus:SI (reg/v:SI 58 [ n ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 41 39 42 (set (reg:SI 62)
(reg:SI 63)) -1 (nil)
(nil))
(insn 42 41 43 (set (reg:SI 5 di)
(reg:SI 62)) -1 (nil)
(nil))
(call_insn 43 42 0 (call (mem:QI (symbol_ref:DI ("foo") [flags 0x3]
) [0 S1 A8])
(const_int 0 [0x0])) -1 (nil)
(nil)
(expr_list (use (reg:SI 5 di))
(nil)))
])
(const_string "tail_call") (sequence [
(note 31 0 32 NOTE_INSN_DELETED)
(note 32 31 34 NOTE_INSN_DELETED)
(insn 34 32 33 (set (reg:SI 61)
(reg/v:SI 58 [ n ])) -1 (nil)
(nil))
(insn 33 34 35 (parallel [
(set (reg/v:SI 58 [ n ])
(plus:SI (reg/v:SI 58 [ n ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 35 33 36 (set (reg:SI 60)
(reg:SI 61)) -1 (nil)
(nil))
(insn 36 35 37 (set (reg:SI 5 di)
(reg:SI 60)) -1 (nil)
(nil))
(call_insn/j 37 36 38 (call (mem:QI (symbol_ref:DI ("foo") [flags 0x3]
) [0 S1 A8])
(const_int 0 [0x0])) -1 (nil)
(nil)
(expr_list (use (reg:SI 5 di))
(nil)))
(barrier 38 37 0)
])
(const_string "tail_recursion") (sequence [
(note 22 0 23 NOTE_INSN_DELETED)
(note 23 22 25 NOTE_INSN_DELETED)
(insn 25 23 26 (set (reg:SI 59)
(reg/v:SI 58 [ n ])) -1 (nil)
(nil))
(insn 26 25 24 (set (reg/v:SI 58 [ n ])
(reg:SI 59)) -1 (nil)
(nil))
(insn 24 26 28 (parallel [
(set (reg/v:SI 58 [ n ])
(plus:SI (reg/v:SI 58 [ n ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(jump_insn 28 24 29 (set (pc)
(label_ref 27)) -1 (nil)
(nil))
(barrier 29 28 30)
(barrier 30 29 0)
])
])) -1 (nil)
(nil)
(nil))
You have to set debug_call_placeholder_verbose = 1 in print-rtl.c to
see what is going on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug middle-end/21964] [3.4 Regression] broken tail call at -O2 or more
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-09 09:22 --- In this case we obviously take the "tail_recursion" sequence, which is already wrong: (const_string "tail_recursion") (sequence [ (note 22 0 23 NOTE_INSN_DELETED) (note 23 22 25 NOTE_INSN_DELETED) (insn 25 23 26 (set (reg:SI 59) (reg/v:SI 58 [ n ])) -1 (nil) (nil)) (insn 26 25 24 (set (reg/v:SI 58 [ n ]) (reg:SI 59)) -1 (nil) (nil)) (insn 24 26 28 (parallel [ (set (reg/v:SI 58 [ n ]) (plus:SI (reg/v:SI 58 [ n ]) (const_int 1 [0x1]))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) (jump_insn 28 24 29 (set (pc) (label_ref 27)) -1 (nil) (nil)) (barrier 29 28 30) (barrier 30 29 0) ]) Note that the "n++" (insn 24) is before the jump to the tail recursion label at the head of the function (jump_insn 28). So the initial RTL generation is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug c++/21976] New: Incomplete types are not detected at template definition time
Hello,
the following should probably be flagged as an error without requiring an
instantiation of the template:
---
struct A;
template struct B {
void foo(void) { A a; }
};
---
GCC accepts the code without complaining.
--
Summary: Incomplete types are not detected at template definition
time
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giovannibajo at libero dot it
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21976
[Bug c++/21976] Incomplete types are not detected at template definition time
-- What|Removed |Added CC||mw_adtrap at yahoo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21976
[Bug fortran/21905] Not Implemented: Scalarization of non-elemental intrinsic
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-09 09:33 --- Is this a dup of PR17298 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21905
[Bug libstdc++/21974] linking error of basic_string
--- Additional Comments From pcarlini at suse dot de 2005-06-09 09:33 --- This issue is in the FAQ, actually: http://gcc.gnu.org/onlinedocs/libstdc++/21_strings/howto.html#5 Recently, we started supporting such usages as (welcome) extensions. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21974
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-09 09:34 --- Another important code ist blocked by this code: numerical recipes library functions: bessj.f90 sort_radix.f90:13 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-09 09:42 --- *** Bug 21905 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/21905] Not Implemented: Scalarization of non-elemental intrinsic
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-09 09:42 --- Hm, I had searched. *** This bug has been marked as a duplicate of 17298 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21905
[Bug fortran/21977] New: ice-on-valid-code, segmentation fault
The file dawson.f90 from the numerical recipes library produces a segfault, in reduced form: !-- FUNCTION dawson_v(x) use nrutil IMPLICIT NONE REAL(SP), DIMENSION(:), INTENT(IN) :: x REAL(SP), DIMENSION(size(x)) :: dawson_v dawson_v=1.0 CONTAINS !BL FUNCTION dawsonseries_v(xin) IMPLICIT NONE REAL(SP) ::, DIMENSION(:), INTENT(IN) :: xin REAL(SP) ::, DIMENSION(size(xin)) :: dawsonseries_v dawsonseries_v=1.0 END FUNCTION dawsonseries_v END FUNCTION dawson_v !-- > gfortran -v -c testcase_dawson.f90 gcc version 4.1.0 20050608 (experimental) /opt/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 testcase_dawson.f90 -quiet -dumpbase testcase_dawson.f90 -mtune=pentiumpro -auxbase testcase_dawson -version -o /tmp/ccgEwl8x.s GNU F95 version 4.1.0 20050608 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20050606 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 testcase_dawson.f90:2: internal compiler error: Segmentation fault -- Summary: ice-on-valid-code, segmentation fault Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: c dot lemmen at fz-juelich dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21977
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From martin at mpa-garching dot mpg dot de 2005-06-09 10:16 --- > Lots of previously working code (somewhere around December 2004) now > (June 2005) exhibits this bug, it seems that this bug is a side-effect > of something else. Call it a regression ? > > Sorry for not being able to pin down when this regression occurred. If you have a test case that compiled properly in Dec 2004, it should be easy to locate the offending commit via the automated regression hunter, at least for someone familiar with this tool (i.e. not me). This could provide very important information for fixing this bug. Could you please provide a test case and a date when you last saw this testcase compile properly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug AWT/21978] New: GCC 4.0 Awt and Swing problem linux 9.0
hi, i have redhat linux 9.0 installed(everything) in my pc, and i installed
gcc4.0, but when i complied the java program from deitel&deitel it throws
exceptions,
[EMAIL PROTECTED] java test]# ./PopupTest
Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit:
at java.awt.Toolkit.getDefaultToolkit() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at java.awt.EventQueue.invokeLater(java.lang.Runnable)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.SwingUtilities.invokeLater(java.lang.Runnable)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.RepaintManager.addInvalidComponent(javax.swing.JComponent)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JComponent.revalidate() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JComponent.setOpaque(boolean)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JPanel.JPanel(java.awt.LayoutManager, boolean)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JPanel.JPanel() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JRootPane.createGlassPane() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JRootPane.getGlassPane() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JRootPane.JRootPane() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JFrame.createRootPane() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JFrame.getRootPane() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JFrame.frameInit() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at javax.swing.JFrame.JFrame(java.lang.String)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at PopupTest.PopupTest() (/root/java test/PopupTest.java:13)
at PopupTest.main(java.lang.String[]) (/root/java test/PopupTest.java:67)
at gnu.java.lang.MainThread.call_main() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
Caused by: java.lang.ClassNotFoundException:
at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at java.lang.Class.forName(java.lang.String)
(/opt/gcc4.0/lib/libgcj.so.6.0.0)
at java.awt.Toolkit.getDefaultToolkit() (/opt/gcc4.0/lib/libgcj.so.6.0.0)
...18 more
[EMAIL PROTECTED] java test]#
i have installed gcc4.0 in /opt/gcc4.0 directory and i have checked its paths
using $PATH and $LD_LIB_PATH variables, i have previously installed gcc3.2.2 i
dont know what to do, please tell me step by step to resolve it, i dont know
weather any body have executed any swing program on gcc4.0 or not,
Version-Release number of selected component (if applicable):
How reproducible:
here is the java file
// Fig. 13.8: PopupTest.java
// Demonstrating JPopupMenus
import javax.swing.*;
import java.awt.event.*;
import java.awt.*;
public class PopupTest extends JFrame {
private JRadioButtonMenuItem items[];
private Color colorValues[] =
{ Color.blue, Color.yellow, Color.red };
public PopupTest()
{
super( "Using JPopupMenus" );
final JPopupMenu popupMenu = new JPopupMenu();
ItemHandler handler = new ItemHandler();
String colors[] = { "Blue", "Yellow", "Red" };
ButtonGroup colorGroup = new ButtonGroup();
items = new JRadioButtonMenuItem[ 3 ];
// construct each menu item and add to popup menu; also
// enable event handling for each menu item
for ( int i = 0; i < items.length; i++ ) {
items[ i ] = new JRadioButtonMenuItem( colors[ i ] );
popupMenu.add( items[ i ] );
colorGroup.add( items[ i ] );
items[ i ].addActionListener( handler );
}
getContentPane().setBackground( Color.white );
// define a MouseListener for the window that displays
// a JPopupMenu when the popup trigger event occurs
addMouseListener(
new MouseAdapter() {
public void mousePressed( MouseEvent e )
{ checkForTriggerEvent( e ); }
public void mouseReleased( MouseEvent e )
{ checkForTriggerEvent( e ); }
private void checkForTriggerEvent( MouseEvent e )
{
if ( e.isPopupTrigger() )
popupMenu.show( e.getComponent(),
e.getX(), e.getY() );
}
}
);
setSize( 300, 200 );
show();
}
public static void main( String args[] )
{
PopupTest app = new PopupTest();
app.addWindowListener(
new WindowAdapter() {
public void windowClosing( WindowEvent e )
{
System.exit( 0 );
}
}
);
}
private class ItemHandler implements ActionListener {
public void actionPerformed( ActionEvent e )
{
// determine which menu item was selected
for ( int i = 0; i < items.length; i++ )
if ( e.getSource() == items[ i ] ) {
getContentPane().setBackground(
colorValues[ i ] );
repaint();
[Bug middle-end/21964] [3.4 Regression] broken tail call at -O2 or more
--- Additional Comments From giovannibajo at libero dot it 2005-06-09 10:33 --- can you binsearch this on the 3.4 branch? -- What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug driver/21979] New: Preprocessing fortran files has some flaws
Preprocessing fortran files has some flaws (affects mainline and 4.0 branch): 1) Some command line arguments cause hiccups: gfortran -pipe -c test.F90 yields f951: error: unrecognized command line option "-95" gfortran -pipe -c test.f90 works 2) Files not cleaned up: gfortran -c test.F90 leaves an empty .f file in the temp directory. This file is probably unused and shouldn't be generated at all. (This happens twice when building libgfortran.) test.F90 and test.f90 can be arbitary valid fortran files. -- Summary: Preprocessing fortran files has some flaws Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21979
[Bug driver/21979] Preprocessing fortran files has some flaws
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-09 11:06 --- In addition the command gfortran -pipe -c test.F90 generates a file named "-95". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21979
[Bug middle-end/21964] [3.4 Regression] broken tail call at -O2 or more
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-09 11:25 --- Why would you want to binsearch this? GCC 3.0.4 was already broken, according to the "Known to fail" list, while 2.95.3 is "Known to work". And because the sibcall pass was new in GCC 3.0, the odds are that this was broken from the beginning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug middle-end/21964] [3.4 Regression] broken tail call at -O2 or more
--- Additional Comments From giovannibajo at libero dot it 2005-06-09 11:52 --- Ah sorry, for some reason I misread the bug and believed it worked in 3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug ada/21959] [4.1 Regression] Ada depends on signed overflow
--- Additional Comments From pluto at agmk dot net 2005-06-09 11:59 ---
hmm, I can't test the 4.1 bootstrap with -fwrapv due to xgcc error.
make -C obj-amd64-pld-linux \
bootstrap \
GCJFLAGS="%{rpmcflags}" \
BOOT_ADAFLAGS="%{rpmcflags} -fwrapv" \
GNATLIBCFLAGS="-O1 -fwrapv" \
BOOT_CFLAGS="%{rpmcflags}" \
STAGE1_CFLAGS="%{rpmcflags} -O0" \
LDFLAGS_FOR_TARGET="%{rpmldflags}"
(...)
stage1/xgcc -Bstage1/ -B/usr/amd64-pld-linux/bin/ -c -O1 -fwrapv
-I- -I. -Iada -I../../gcc/ada ../../gcc/ada/ada.ads -o ada/ada.o
ada.ads:16:01: language defined units may not be recompiled
make[2]: *** [ada/ada.o] Error 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug middle-end/17961] ICE for operation on small vector with altivec enabled
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug c++/21980] New: syntax error with static function pointer (compiler dependent)
Take this c++ code:
snip
class Test
{
private:
int val;
static Test func1 ();
static Test func2 ();
static Test (* funcp) ();
public:
Test (int val)
: val (val)
{
}
Test func ()
{
return funcp ();
}
int get () const
{
return val;
}
};
Test (* Test::funcp) () = Test::func1;
Test Test::func1 ()
{
funcp = func2;
return Test (1);
}
Test Test::func2 ()
{
return Test (2);
}
snip
The code above compiles w/o errors under 3.4.5 and produces these
errors under 3.3.6:
bug33.cpp:7: error: parse error before `*' token
bug33.cpp: In member function `Test Test::func()':
bug33.cpp:17: error: `funcp' undeclared (first use this function)
bug33.cpp:17: error: (Each undeclared identifier is reported only once for each
function it appears in.)
bug33.cpp: At global scope:
bug33.cpp:26: error: `Test (*Test::funcp)()' is not a static member of `class
Test'
Which of the compilers is right? Are static function pointers to
static class functions legal c++ code? Is the declaration syntax
standard conforming?
--
Summary: syntax error with static function pointer (compiler
dependent)
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nkoch at demig dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-portbld-freebsd4.11
GCC host triplet: i386-portbld-freebsd4.11
GCC target triplet: i386-portbld-freebsd4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21980
[Bug c++/21980] syntax error with static function pointer (compiler dependent)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 12:29 --- 3.4.x is correct. Since this is not a regression (well it does not matter as 3.3.6 was the last 3.3.x release) I am closing as fixed in 3.4.0. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Known to fail||2.95.3 3.3.3 3.2.3 3.0.4 Known to work||3.4.0 4.0.0 4.1.0 Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21980
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 14:07 --- Confirmed, this might be hard, I don't know but would be nice as it should speed up GCC itself. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-09 14:07:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug target/21981] __m64 return value should be returned in %mm0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:16 ---
Confirmed, ICC returns it in %mm0.
Note this is the testcase which I used:
#include
__m64
aaa (__m64 x, __m64 y)
{
__m64 mm1;
mm1 = _mm_add_pi8 (x, y);
return mm1;
}
int main() {
__m64 mm0;
__m64 mm1;
union ttt {
__m64 mm;
char x[8];
} temp;
temp.mm = aaa (mm0, mm1);
printf ("%i\n", temp.x[0]);
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2005-06-09 14:16:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21981
[Bug fortran/21977] ice-on-valid-code, segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 14:24 --- Of course we cannot compile this without the nrutil module. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21977
[Bug c++/21976] Incomplete types are not detected at template definition time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:27 ---
Obvious reduced testcase is the following:
struct A;
template void
f (void) {A b;}
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21976
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From joseph at codesourcery dot com 2005-06-09 14:36 --- Subject: Re: GCC should combine adjacent stdio calls Another problem case is if the first format has excess arguments (which is permitted by ISO C) - those arguments must be evaluated but not included in the concatenated argument list. Even if arguments don't have side effects you have problems if arguments of the second printf might refer to anything modifed by printf (the FILE structure, its buffers, the contents of the file written to, ...) - they should have the appropriate values for after the first call. It's OK if the arguments are e.g. local integer variables whose addresses have not escaped, but in general you need to prove that the arguments to the second printf, and anything they point to, cannot be changed by the first printf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-09
14:37 ---
(In reply to comment #1)
> If side effects appear in the arguments, that also would be a problem, e.g.:
>
> printf("%d", i++);
> printf("%d", i++);
>
> should not be turned into:
>
> printf("%d%d", i++, i++);
>
There should be little danger of this. Side-effects are explicitly exposed in
GIMPLE. As long as the printf() calls are adjacent, we should be able to
combine them.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug c++/21983] New: multiple diagnostics
struct base { virtual void foo() = 0; };
struct d1 : public virtual base { virtual void foo() {} };
struct d2 : public virtual base { virtual void foo() {} };
struct der : public d1, public d2 { };
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc:4: error: no unique final overrider for `virtual void base::foo()' in
`der'
foo.cc:4: error: no unique final overrider for `virtual void base::foo()' in
`der'
foo.cc:4: error: no unique final overrider for `virtual void base::foo()' in
`der'
foo.cc:4: error: no unique final overrider for `virtual void base::foo()' in
`der'
--
Summary: multiple diagnostics
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21983
[Bug middle-end/21969] ICE on float __attribute__((vector_size(2048)))
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 14:40 --- Hmm, it works just fine on powerpc-darwin (I don't know why) but it ICEs on i686-pc-linux-gnu. And it worked just fine with "gcc version 3.5.0 20040909 (experimental)" I don't know if I can consider this a regression though, before 4.0.0 we gave an error: t.c:1: error: no vector mode with the size and type specified could be found -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|ia64-hp-hpux11.23 | GCC host triplet|ia64-hp-hpux11.23 | Keywords||ice-on-valid-code Known to fail||4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-06-09 14:40:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21969
[Bug c++/21983] [3.4/4.0/4.1 Regression] multiple diagnostics
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 14:43 --- Confirmed, a regression from 3.2.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.2.3 3.0.4 2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-06-09 14:43:34 date|| Summary|multiple diagnostics|[3.4/4.0/4.1 Regression] ||multiple diagnostics Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21983
[Bug tree-optimization/21861] [meta-bug] scalar evolution type conversion
-- Bug 21861 depends on bug 18403, which changed state. Bug 18403 Summary: FAILs to vectorize testcases on ppc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 14:44 --- Fixed in 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403
[Bug middle-end/21850] [4.0 Regression] misscompiling comparision from vector to integer
-- What|Removed |Added Known to work||4.1.0 Last reconfirmed|2005-06-07 12:20:36 |2005-06-09 14:45:12 date|| Summary|misscompiling comparision |[4.0 Regression] |from vector to integer |misscompiling comparision ||from vector to integer Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21850
[Bug fortran/21977] ice-on-valid-code, segmentation fault
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-09 15:03 --- I concur, but you don't need it in this reduced testcase (my fault for leaving the statement there). Have a go at this: FUNCTION dawson_v(x) IMPLICIT NONE REAL, DIMENSION(:), INTENT(IN) :: x REAL, DIMENSION(size(x)) :: dawson_v dawson_v=1.0 CONTAINS !BL FUNCTION dawsonseries_v(xin) IMPLICIT NONE REAL, DIMENSION(:), INTENT(IN) :: xin REAL, DIMENSION(size(xin)) :: dawsonseries_v dawsonseries_v=1.0 END FUNCTION dawsonseries_v END FUNCTION dawson_v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21977
[Bug c/21759] Implement warning for codes at the intersection of C and C++
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-09 15:05 --- working on it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-09 15:05:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
[Bug fortran/21977] nested function returning array
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 15:16 --- Confirmed, I think we are picking the wrong __result decl for the outer function (but I could be wrong, I have not looked at it much). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-06-09 15:16:03 date|| Summary|ice-on-valid-code, |nested function returning |segmentation fault |array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21977
[Bug target/21984] New: [4.1 regression] ICE in reload while compiling __mulxc3
Starting program: /cvs/test/m68k/gcc/gcc/cc1 -fpreprocessed libgcc2.i -quiet
-dumpbase libgcc2.c -auxbase-strip libgcc/./_mulxc3.o -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -version -fPIC -fvisibility=hidden -o libgcc2.s
GNU C version 4.1.0 20050609 (experimental) (m68k-linux)
compiled by GNU C version 4.0.1 20050603 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 80ebf056a47509c89d7f404fc943abab
Breakpoint 1, fancy_abort (file=0x408c3ee8 "/cvs/gcc/gcc/reload1.c",
line=1084, function=0x60034320 "reload")
at /cvs/gcc/gcc/diagnostic.c:588
588 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0 fancy_abort (file=0x408c3ee8 "/cvs/gcc/gcc/reload1.c", line=1084,
function=0x60034320 "reload") at /cvs/gcc/gcc/diagnostic.c:588
#1 0x405d8a50 in reload (first=0x206a1780, global=1)
at /cvs/gcc/gcc/reload1.c:1084
#2 0x40797930 in global_alloc (file=0x0) at /cvs/gcc/gcc/global.c:621
#3 0x4068bb10 in rest_of_compilation () at /cvs/gcc/gcc/passes.c:486
#4 0x4013adf0 in execute_pass_list (pass=0x6001e1b0)
at /cvs/gcc/gcc/tree-optimize.c:626
#5 0x4013b870 in tree_rest_of_compilation (fndecl=0x203f6150)
at /cvs/gcc/gcc/tree-optimize.c:796
#6 0x40030a40 in c_expand_body (fndecl=0x203f6150)
at /cvs/gcc/gcc/c-decl.c:6597
#7 0x406da2d0 in cgraph_expand_function (node=0x206738e0)
at /cvs/gcc/gcc/cgraphunit.c:967
#8 0x406de7a0 in cgraph_optimize () at /cvs/gcc/gcc/cgraphunit.c:1033
#9 0x40036930 in c_write_global_declarations ()
at /cvs/gcc/gcc/c-decl.c:7571
#10 0x40625af0 in toplev_main (argc=,
argv=) at /cvs/gcc/gcc/toplev.c:979
#11 0x400f8690 in main (argc=21, argv=0x6fffa208)
at /cvs/gcc/gcc/main.c:35
--
Summary: [4.1 regression] ICE in reload while compiling __mulxc3
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21984
[Bug target/21984] [4.1 regression] ICE in reload while compiling __mulxc3
--- Additional Comments From schwab at suse dot de 2005-06-09 16:08 --- Created an attachment (id=9054) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9054&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21984
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: GCC should combine adjacent stdio calls
GCC should optimize adjacent stdio calls. For example:
printf("foo %d %d\n", i, j);
printf("bar %d %d\n", x, y);
could instead be emitted as:
printf("foo %d %d\nbar %d %d\n", i, j, x, y);
More generally, you simply concatenate the format arguments and append all of
the remaining first printf's arguments and then all of the second printf's
arguments.
You can also combine adjacent printf/puts and printf/putc:
printf("format", args...); puts(s); -> printf("format%s\n", args..., s);
printf("format", args...); putc(c); -> printf "format%c", args..., c);
You can also combine adjacent f* variants of these stdio calls (fprintf, fputs,
fputc) if the supplied streams are equivalent.
One caveat, some format specifiers need special care. E.g. position speficiers
must be adjusted. The %n specifier may preclude the optimization entirely.
There might be other examples.
--
Summary: GCC should combine adjacent stdio calls
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: GCC should combine adjacent stdio calls
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 13:01
---
If side effects appear in the arguments, that also would be a problem, e.g.:
printf("%d", i++);
printf("%d", i++);
should not be turned into:
printf("%d%d", i++, i++);
because we can't guarantee order of evaluation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug c/21975] [4.0/4.1 Regression] Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org 2005-06-09 16:11 --- Subject: Segmentation fault while compiling ipw2100 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: GCC should combine adjacent stdio calls
GCC should optimize adjacent stdio calls. For example:
printf("foo %d %d\n", i, j);
printf("bar %d %d\n", x, y);
could instead be emitted as:
printf("foo %d %d\nbar %d %d\n", i, j, x, y);
More generally, you simply concatenate the format arguments and append all of
the remaining first printf's arguments and then all of the second printf's
arguments.
You can also combine adjacent printf/puts and printf/putc:
printf("format", args...); puts(s); -> printf("format%s\n", args..., s);
printf("format", args...); putc(c); -> printf "format%c", args..., c);
You can also combine adjacent f* variants of these stdio calls (fprintf, fputs,
fputc) if the supplied streams are equivalent.
One caveat, some format specifiers need special care. E.g. position speficiers
must be adjusted. The %n specifier may preclude the optimization entirely.
There might be other examples.
--
Summary: GCC should combine adjacent stdio calls
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: GCC should combine adjacent stdio calls
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 13:01
---
If side effects appear in the arguments, that also would be a problem, e.g.:
printf("%d", i++);
printf("%d", i++);
should not be turned into:
printf("%d%d", i++, i++);
because we can't guarantee order of evaluation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug c/21975] [4.0/4.1 Regression] Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: [4.0/4.1 Regression] Segmentation fault while compiling ipw2100
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
13:51 ---
Reduced testcase:
static inline __attribute__((always_inline)) int func1(){}
static inline __attribute__((always_inline)) int func2() {return func1();}
extern inline __attribute__((always_inline)) int func1(){}
int func3(){return func2();}
I don't think this is valid code.
Note in the code I see the bodies for func1 (is_multicast_ether_addr).
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2005-06-09 13:51:14
date||
Summary|Segmentation fault while|[4.0/4.1 Regression]
|compiling ipw2100 |Segmentation fault while
||compiling ipw2100
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
13:35 ---
Before 4.0.0, we got an error (after replacing __builtin_offsetof):
pr21975.c:25417: redefinition of `is_multicast_ether_addr'
pr21975.c:24696: `is_multicast_ether_addr' previously defined here
reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
[Bug target/21981] __m64 return value should be returned in %mm0
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: __m64 return value should be returned in %mm0
Calling convetions for x86 specify that __m64 values should be returned in %mm0
MMX register [1]. Gcc returns __m64 values on stack.
The testcase:
--cut here--
#include
__v8qi
aaa (__v8qi x, __v8qi y)
{
__v8qi mm1;
mm1 = _mm_add_pi8 (x, y);
return mm1;
}
int main() {
__v8qi mm0 = { 1,2,3,4,5,6,7,8 };
__v8qi mm1 = { 11,12,13,14,15,16,17,18 };
union ttt {
__v8qi mm;
char x[8];
} temp;
temp.mm = aaa (mm0, mm1);
printf ("%i\n", temp.x[0]);
return 0;
}
--cut here--
will produce:
aaa:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
paddb %mm1, %mm0
movq%mm0, (%eax) -- %mm0 goes to memory
popl%ebp
ret $4
main:
pushl %ebp
movl%esp, %ebp
subl$24, %esp
andl$-16, %esp
subl$16, %esp
leal-8(%ebp), %eax
movl%eax, (%esp)
movq.LC0, %mm1
movq.LC1, %mm0
callaaa
movsbl -8(%ebp),%eax-- return value taken from memory
subl$4, %esp
movl%eax, 4(%esp)
movl$.LC2, (%esp)
callprintf
xorl%eax, %eax
leave
ret
[1] http://www.agner.org/assem/calling_conventions.pdf
--
Summary: __m64 return value should be returned in %mm0
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21981
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21981
[Bug c/21975] [4.0/4.1 Regression] Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: [4.0/4.1 Regression] Segmentation fault while compiling ipw2100
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
13:51 ---
Reduced testcase:
static inline __attribute__((always_inline)) int func1(){}
static inline __attribute__((always_inline)) int func2() {return func1();}
extern inline __attribute__((always_inline)) int func1(){}
int func3(){return func2();}
I don't think this is valid code.
Note in the code I see the bodies for func1 (is_multicast_ether_addr).
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2005-06-09 13:51:14
date||
Summary|Segmentation fault while|[4.0/4.1 Regression]
|compiling ipw2100 |Segmentation fault while
||compiling ipw2100
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
13:35 ---
Before 4.0.0, we got an error (after replacing __builtin_offsetof):
pr21975.c:25417: redefinition of `is_multicast_ether_addr'
pr21975.c:24696: `is_multicast_ether_addr' previously defined here
reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
[Bug driver/21979] Preprocessing fortran files has some flaws
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org 2005-06-09 16:11 --- Subject: Preprocessing fortran files has some flaws --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 14:02 --- Confirmed, it works fine with t.F but not with t.F90. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-09 14:02:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21979 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21979
[Bug libgcj/21949] java.rmi.server.RMIClassLoader.getClassLoader() is private, should be public
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org 2005-06-09 16:11 --- Subject: java.rmi.server.RMIClassLoader.getClassLoader() is private, should be public --- Additional Comments From gbenson at redhat dot com 2005-06-09 13:48 --- I need it in Fedora 5. We can always have a local patch I guess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21949
[Bug c++/21971] class friend declaration doesn't allow use in class scope
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: class friend declaration doesn't allow use in class scope
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-06-09
13:58 ---
Not a bug. The clause you referred to:
"A name nominated by a friend declaration shall be accessible in the scope of
the class containing the friend declaration."
actually means that the following code is not allowed:
class A { class B {}; };
class C {
friend class A::B; // Error - A::B is not accessible inside C
};
For your case, look at 11.4 paragraph 9:
"For a friend class declaration, if there is no prior declaration, the class
that is specified
belongs to the innermost enclosing non-class scope, but if it is subsequently
referenced,
its name is not found by name lookup until a matching declaration is provided
in the innermost
enclosing nonclass scope."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21971
[Bug target/21984] [4.1 regression] ICE in reload while compiling __mulxc3
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21984
[Bug c/21985] New: miscompiled or wrong code snippet?
Hi, the attached code compiles fine and does calculate the offset between the current stackpointer and the passed point in gcc versions before 4.0. In 4.0 the expression is reduced to -16384 even in the t03.generic dump which makes me suspect a parser problem. Or it might just be wrong code... I am not sure. -- Summary: miscompiled or wrong code snippet? Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21985
[Bug c/21985] miscompiled or wrong code snippet?
--- Additional Comments From marcus at jet dot franken dot de 2005-06-09 16:14 --- Created an attachment (id=9055) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9055&action=view) xx.c gcc -c -O2 xx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21985
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-09 16:18 --- Testing patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug middle-end/21985] [4.0/4.1 Regression] miscompiled or wrong code snippet?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 16:26 --- Confirmed, caused by: 2004-11-10 Zdenek Dvorak <[EMAIL PROTECTED]> * fold-const.c (fold): Attempt to use ptr_difference_const whenever one of the arguments of MINUS_EXPR is an address. (split_address_to_core_and_offset): New function. (ptr_difference_const): Handle case when one of the operands is a pointer. -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-06-09 16:26:32 date|| Summary|miscompiled or wrong code |[4.0/4.1 Regression] |snippet?|miscompiled or wrong code ||snippet? Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21985
[Bug middle-end/21985] [4.0/4.1 Regression] miscompiled or wrong code snippet?
-- What|Removed |Added Target Milestone|4.0.2 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21985
[Bug tree-optimization/19626] Aliasing says stores to local memory do alias
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 16:32 --- This has now been fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19626
[Bug tree-optimization/2480] aliasing problem with global structures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 16:45 --- Part of this has been fixed, there is only one loading of ex1 now on the mainline. -- What|Removed |Added Last reconfirmed|2005-05-02 00:52:06 |2005-06-09 16:45:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2480
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 16:49
---
(In reply to comment #4)
> (In reply to comment #1)
> > If side effects appear in the arguments, that also would be a problem, e.g.:
> >
> > printf("%d", i++);
> > printf("%d", i++);
> >
> > should not be turned into:
> >
> > printf("%d%d", i++, i++);
> >
> There should be little danger of this. Side-effects are explicitly exposed in
> GIMPLE. As long as the printf() calls are adjacent, we should be able to
> combine them.
> Diego.
I'm not sure. In my specific example above, after the combination we don't
know which i++ gets executed first because the order is not guaranteed within
an argument list of a single function call (right?) So if we want to include
combinations whose arguments have side-effects, we have to prove they don't
interact with any other arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 16:51 --- (In reply to comment #8) > I'm not sure. In my specific example above, after the combination we don't > know which i++ gets executed first because the order is not guaranteed within > an argument list of a single function call (right?) So if we want to include > combinations whose arguments have side-effects, we have to prove they don't > interact with any other arguments. What Diego is saying is that there are never any arguments with side effects at GIMPLE level. everything is well defined at the point which we can do the combining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug fortran/21986] New: Bad .mod file, ICE upon USE
$ gfortran bug.f90 bug.f90:8: internal compiler error: Segmentation fault $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc4/configure --enable-languages=c,c++,f95 Thread model: posix gcc version 4.1.0 20050609 (experimental) (This is this morning's CVS snapshot) Hmf. I don't see how to attach the "bug.f90" so I will place it in-line below. It's short. If I split into module and main program and compile separately, boom.f90 ICE's at line zero. Suspect a bad "modboom.mod" file. --- module modboom implicit none ! can comment out private ! comment out, lose the bug public:: dummysub ! comment out, lose the bug type:: intwrapper ! a straight integer won't do integer n end type intwrapper contains subroutine dummysub(size, arg_array) type(intwrapper) :: size real, dimension(size%n) :: arg_array real :: local_array(4) ! comment out, lose the bug end subroutine dummysub end module modboom program boom use modboom ! bad .mod file ? print *, 'hey, we made it!' end program boom --- -- Summary: Bad .mod file, ICE upon USE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Pierre dot Asselin at seagate dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: Huh ? do you mean "i686-pc-linux-gnu" ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21986
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 16:55
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 04:49:40PM -, ghazi at gcc dot gnu dot org wrote:
>
> --- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09
> 16:49 ---
> (In reply to comment #4)
> > (In reply to comment #1)
> > > If side effects appear in the arguments, that also would be a problem,
> > > e.g.:
> > >
> > > printf("%d", i++);
> > > printf("%d", i++);
> > >
> > > should not be turned into:
> > >
> > > printf("%d%d", i++, i++);
> > >
> > There should be little danger of this. Side-effects are explicitly exposed
> > in
> > GIMPLE. As long as the printf() calls are adjacent, we should be able to
> > combine them.
> > Diego.
>
> I'm not sure. In my specific example above, after the combination we don't
> know which i++ gets executed first because the order is not guaranteed within
> an argument list of a single function call (right?) So if we want to include
> combinations whose arguments have side-effects, we have to prove they don't
> interact with any other arguments.
>
But remember that we are not optimizing C, we are optimizing
GIMPLE. And in GIMPLE we don't have those problems. Here's what
the tree optimizers see:
i_3 = i_1 + 1;
printf (&"%d"[0], i_1);
printf (&"%d"[0], i_3);
Those two calls to printf can be merged. The order of evaluation
has been decided by the gimplifier. Whether that's right or
wrong for C, I couldn't say, all I know is that for the
optimizers, those two printf calls look mergeable.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 16:55 --- (In reply to comment #3) > Subject: Re: GCC should combine adjacent stdio > calls > Another problem case is if the first format has excess arguments (which is > permitted by ISO C) - those arguments must be evaluated but not included > in the concatenated argument list. While it may be legal, our -Wformat option warns about excess arguments and I would suggest we don't attempt any optimization unless we pass -Wformat cleanly. So I think this one is surmountable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug fortran/21986] Bad .mod file, ICE upon USE
--- Additional Comments From Pierre dot Asselin at seagate dot com 2005-06-09 16:56 --- Created an attachment (id=9056) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9056&action=view) self-contained test case, compile with "gfortran bug.f90" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21986
[Bug middle-end/21985] [4.0/4.1 Regression] miscompiled or wrong code snippet?
--- Additional Comments From aj at gcc dot gnu dot org 2005-06-09 17:01 --- Let me just add the following comment so that searches for "grub miscompilation" will find this bug: This snippet is based on code in the grub bootloader which does not work if compiled by GCC 4.0.0. -- What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21985
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 17:02
---
(In reply to comment #10)
> Subject: Re: GCC should combine adjacent stdio calls
> But remember that we are not optimizing C, we are optimizing
> GIMPLE. And in GIMPLE we don't have those problems. Here's what
> the tree optimizers see:
> i_3 = i_1 + 1;
> printf (&"%d"[0], i_1);
> printf (&"%d"[0], i_3);
> Those two calls to printf can be merged. The order of evaluation
> has been decided by the gimplifier. Whether that's right or
> wrong for C, I couldn't say, all I know is that for the
> optimizers, those two printf calls look mergeable.
> Diego.
Ah okay thanks.
By the way, you may recall you and I discussed doing this during the first GCC
summit. One suggestion that IIRC Paul Brook had was to move printf statements
around to create more opportunities for combination if the intervening
statements didn't interact with the moving printf. E.g.
int i=0, j=2;
printf("%d", i);
j++;
printf("%d", j);
Pushing the first printf further down, this could be reordered as:
int i=0, j=2;
j++;
printf("%d", i);
printf("%d", j);
which would expose another combination possibility.
Paul seemed to think this wasn't hard with the existing infrastructure, and
that was two years ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
17:07 ---
(In reply to comment #12)
> Pushing the first printf further down, this could be reordered as:
> int i=0, j=2;
> j++;
> printf("%d", i);
> printf("%d", j);
In fact this is how SSA works, in that there a variable is only ever assigned
once so j_1 and j_2 can be
alive at the same time (well except for variables across abnormal edges).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug fortran/21986] Bad .mod file, ICE upon USE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 17:08 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|Huh ? do you mean "i686-pc-|i686-pc-linux-gnu |linux-gnu" ?| Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-06-09 17:08:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21986
[Bug c++/21987] New: New testsuite failure g++.dg/warn/conversion-function-1.C
Between 20050414 and 20050606, there occured a new testsuite failure on the 3.4 branch on alpha-dec-osf4.0f and alpha-dec-osf5.1b: +FAIL: g++.dg/warn/conversion-function-1.C (test for excess errors) Excess errors: /vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/testsuite/g++.dg/warn/conversion-function-1.C:6: warning: conversion to a reference to the same type will never use a type conversion operator Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gnu/src/gcc/gcc-3.4-branch-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b How-To-Repeat: Bootstrap and test as described above. -- Summary: New testsuite failure g++.dg/warn/conversion-function- 1.C Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21987
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From joseph at codesourcery dot com 2005-06-09 17:11 --- Subject: Re: GCC should combine adjacent stdio calls On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote: > > --- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 > 16:55 --- > (In reply to comment #3) > > Subject: Re: GCC should combine adjacent stdio > > calls > > Another problem case is if the first format has excess arguments (which is > > permitted by ISO C) - those arguments must be evaluated but not included > > in the concatenated argument list. > > While it may be legal, our -Wformat option warns about excess arguments and I > would suggest we don't attempt any optimization unless we pass -Wformat > cleanly. So I think this one is surmountable. We linked -Wformat into optimization before, then removed the link. Although we could resurrect the status_warning function which could set a status variable if it would warn rather than emitting the warning (and again save and restore all the variable controlling format warnings), it's not clear this is very desirable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug c++/21987] [3.4 Regression] New testsuite failure g++.dg/warn/conversion-function-1.C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 17:15 --- Weird. -- What|Removed |Added Keywords||diagnostic Summary|New testsuite failure |[3.4 Regression] New |g++.dg/warn/conversion- |testsuite failure |function-1.C|g++.dg/warn/conversion- ||function-1.C Target Milestone|--- |3.4.5 Version|unknown |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21987
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 17:21 --- (In reply to comment #14) > Subject: Re: GCC should combine adjacent stdio > calls > On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote: > > > > --- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 16:55 --- > > (In reply to comment #3) > > > Subject: Re: GCC should combine adjacent stdio > > > calls > > > Another problem case is if the first format has excess arguments (which is > > > permitted by ISO C) - those arguments must be evaluated but not included > > > in the concatenated argument list. > > > > While it may be legal, our -Wformat option warns about excess arguments and I > > would suggest we don't attempt any optimization unless we pass -Wformat > > cleanly. So I think this one is surmountable. > We linked -Wformat into optimization before, then removed the link. > Although we could resurrect the status_warning function which could set a > status variable if it would warn rather than emitting the warning (and > again save and restore all the variable controlling format warnings), it's > not clear this is very desirable. Why is that? IIRC, the reason it was removed was that we never did any builtin printf trasformations with arguments beyond e.g. "%s\n", "%c". So it was easier to simply check these cases manually than invoking the whole format parsing routine. However if we now want to ensure there were no excess arguments I don't see a better way without mostly reimplementing a second format parser. What would you suggest? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug target/21050] [4.1 Regression] vect-111.c ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 17:46 --- Fixed by: * config/ia64/ia64.c (update_set_flags): Just return for IF_THEN_ELSE. Use SCALAR_FLOAT_MODE_P. * config/ia64/vect.md (vcondv2sf): Remove code check on comparison. (fselect): Rename from fpcmp; use %F. (fpcmp): New. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21050
[Bug tree-optimization/21988] New: GCC should optimize printf("%s",foo) and printf("foo") into fputs(foo,stdout)
GCC should optimize printf("%s",foo) and printf("foo") into fputs(foo,stdout)
and fputs("foo",stdout) respectively. As noted here:
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00859.html
We can capture stdout in an inline function using fixincl, perhaps adding the
__always_inline__ attribute. Then do the above transformation.
In at least the printf("%s", foo) case, the result fputs(foo,stdout) has the
same number of arguments, so it might not even be a -Os problem.
--
Summary: GCC should optimize printf("%s",foo) and printf("foo")
into fputs(foo,stdout)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21988
[Bug target/20666] SPARC builtins should be folded if possible
--- Additional Comments From phython at gcc dot gnu dot org 2005-06-09 18:10 --- If there are any other builtins that can be folded then they can be filed as separate bugs. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20666
[Bug target/20666] SPARC builtins should be folded if possible
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20666
[Bug bootstrap/19607] Build fails on MSYS/MingGW because of incorrect SYSTEM_HEADER_DIR
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-09 18:13 --- Bug confirmed and patch confirmed (I used to hack the generated Makefiles with sed, but this is much cleaner). -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2005-06-09 18:13:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19607
[Bug middle-end/21988] GCC should transform printf("%s",foo) and printf("foo") into fputs(foo,stdout)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
18:15 ---
Confirmed, and yes we need to do something about stdout :).
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |middle-end
Ever Confirmed||1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2005-06-09 18:15:19
date||
Summary|GCC should optimize |GCC should transform
|printf("%s",foo) and|printf("%s",foo) and
|printf("foo") into |printf("foo") into
|fputs(foo,stdout) |fputs(foo,stdout)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21988
[Bug bootstrap/21989] New: mingw32 build failure due to xgcc ICE on libgcc2.c
GCC no longer builds on i686-pc-mingw32 (last successful build I made: 20050519). Error is: $ /home/FX/ibin/./gcc/xgcc -B/home/FX/ibin/./gcc/ -B/mingw/i686-pc-mingw32/bin/ -B/mingw/i686-pc-mingw32/lib/ -isystem /mingw/i686-pc-mingw32/include -isystem /mingw/i686-pc-mingw32/sys-include -O2 -I../../gcc/gcc/../winsup/w32api/includ e -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGC C2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../ gcc/gcc/../include -I./../intl -I../../gcc/gcc/../libcpp/include -DL_eprintf -c ../../gcc/gcc/libgcc2.c -o libgcc/./_eprintf.o ../../gcc/gcc/libgcc2.c: In function '__eprintf': ../../gcc/gcc/libgcc2.c:1803: error: invariant not recomputed when ADDR_EXPR changed &_iobD.1252[2]; ../../gcc/gcc/libgcc2.c:1803: error: invariant not recomputed when ADDR_EXPR changed &_iobD.1252[2]; ../../gcc/gcc/libgcc2.c:1803: internal compiler error: verify_stmts failed. -- Summary: mingw32 build failure due to xgcc ICE on libgcc2.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21989
[Bug bootstrap/21989] mingw32 build failure due to xgcc ICE on libgcc2.c
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-09 18:22 --- Created an attachment (id=9057) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9057&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21989
[Bug bootstrap/21989] mingw32 build failure due to xgcc ICE on libgcc2.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 18:25 --- *** This bug has been marked as a duplicate of 21766 *** *** This bug has been marked as a duplicate of 21766 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21989
[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 18:25 --- *** Bug 21989 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
[Bug middle-end/21597] [4.1 Regression] libgcc broken on targets with MKDIR_TAKES_ONE_ARG
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-09 18:48 --- With fresh CVS GCC, I get the following errors on libgcov.c: ../../gcc/gcc/libgcov.c: In function 'create_file_directory': ../../gcc/gcc/libgcov.c:110: warning: implicit declaration of function 'access' ../../gcc/gcc/libgcov.c:110: error: 'F_OK' undeclared (first use in this function) ../../gcc/gcc/libgcov.c:110: error: (Each undeclared identifier is reported only once ../../gcc/gcc/libgcov.c:110: error: for each function it appears in.) ../../gcc/gcc/libgcov.c:111: warning: implicit declaration of function 'mkdir' All are related to the same problem: mkdir and access functions are defined in the system header, which is not included in libgcov.c (and not included either when configure tests if MKDIR_TAKES_ONE_ARG should be defined, that's why we can have "the too many arguments to function 'mkdir'" error when everything else is fixed). So what we need is that to test for the presence of in configure.ac, and then include in libgcov.c when it's available. Can someone confirm whether such an approach is the right thing to do? -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21597
[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-06-09 18:53 --- Subject: Re: libgfortran doesn't compile on IRIX 5.3 Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00902.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
[Bug libgcj/21943] O32 libffi.so fails to link on IRIX 6
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-06-09 18:54 --- Subject: Re: New: O32 libffi.so fails to link on IRIX 6 Patch submitted: http://gcc.gnu.org/ml/java-patches/2005-q2/msg00685.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21943
