[Bug middle-end/19329] [3.4 Regression] Bitfield operations cause shifts with 0-count to slip through backends
--- Additional Comments From giovannibajo at libero dot it 2005-03-14 09:36 --- Fixed then. Roger, do you believe that middle-end is right in generating these shifts by zero? If you believe it is a bug, we can open a new bugreport to track it. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug fortran/20460] Nasty extensions that should always warn
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-14 10:56 --- Ok, thanks for clarifying. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-14 12:59 --- Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs On Fri, Mar 04, 2005 at 04:21:53PM -0300, Alexandre Oliva wrote: > * gimplify.c (gimplify_cond_expr): Add fallback argument. Use a > temporary variable of pointer type if an lvalues is required. > (gimplify_modify_expr_rhs): Request an rvalue from it. > (gimplify_expr): Pass fallback on. Ok. r~ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug debug/20446] invalid assembly with -gstabs+
--- Additional Comments From ivanr at syncad dot com 2005-03-14 14:20 --- (In reply to comment #1) > Is there a reason why you are using stabs+, the default debuging format on solaris is dwarf-2 which > provides more information. yes, file compiles with default format but doesn't with stabs+ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug debug/20446] invalid assembly with -gstabs+
--- Additional Comments From ivanr at syncad dot com 2005-03-14 14:23 --- (In reply to comment #1) > Is there a reason why you are using stabs+, the default debuging format on solaris is dwarf-2 which > provides more information. stabs+ is used for compatibility issues with Wine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug middle-end/18887] [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From schlie at comcast dot net 2005-03-14 14:25 --- Subject: Re: [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements. > --- Additional Comments From giovannibajo at libero dot it 2005-03-13 > Closing as fixed, then. Paul, you can open a new enhancement PR to keep track > of the libgcc problem. Yup, that's fine; still trying to recover from some of the recent changes which seem to have mucked up the pieces what I had working; so unfortunately have taken a few steps back. thanks -paul- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug debug/20446] invalid assembly with -gstabs+
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 14:27 --- (In reply to comment #7) > stabs+ is used for compatibility issues with Wine So, even mywin (and cygwin) have both moved over to dwarf2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 14:34 --- Subject: Bug 1016 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 14:33:55 Modified files: gcc/cp : ChangeLog cp-tree.h decl.c name-lookup.c name-lookup.h parser.c pt.c rtti.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: hidden-class1.C hidden-class2.C hidden-class3.C hidden-class4.C hidden-class5.C hidden-class6.C hidden-class7.C hidden-class8.C hidden-class9.C hidden-temp-class10.C hidden-temp-class11.C hidden-temp-class1.C hidden-temp-class2.C hidden-temp-class3.C hidden-temp-class4.C hidden-temp-class5.C hidden-temp-class6.C hidden-temp-class7.C hidden-temp-class8.C hidden-temp-class9.C Log message: Friend class name lookup 5/n PR c++/1016 * cp-tree.h (pushtag): Adjust declaration. * decl.c (lookup_and_check_tag): Call lookup_type_scope if lookup_name fails. (xref_tag): Adjust call to pushtag. Make hidden class visible. (start_enum): Adjust call to pushtag. * name-lookup.c (ambiguous_decl): Ignore hidden names. (qualify_lookup): Change return type to bool. (hidden_name_p): New function. (lookup_namespace_name, unqualified_namespace_lookup, lookup_name_real): Use it. (lookup_type_scope): Update comments. (maybe_process_template_type_declaration): Change parameter name from globalize to is_friend. (pushtag): Change globalize parameter of type int to tag_scope. Hide name if introduced by friend declaration. * name-lookup.h (hidden_name_p): Add declaration. * parser.c (cp_parser_lookup_name): Don't deal with hidden name here. * pt.c (push_template_decl_real): Make hidden class template visible. (lookup_template_class, instantiate_class_template): Adjust call to pushtag. * semantics.c (begin_class_definition): Likewise. * rtti.c (init_rtti_processing, build_dynamic_cast_1, tinfo_base_init, emit_support_tinfos): Use ts_current instead of ts_global. * g++.dg/lookup/hidden-class1.C: New test. * g++.dg/lookup/hidden-class2.C: Likewise. * g++.dg/lookup/hidden-class3.C: Likewise. * g++.dg/lookup/hidden-class4.C: Likewise. * g++.dg/lookup/hidden-class5.C: Likewise. * g++.dg/lookup/hidden-class6.C: Likewise. * g++.dg/lookup/hidden-class7.C: Likewise. * g++.dg/lookup/hidden-class8.C: Likewise. * g++.dg/lookup/hidden-class9.C: Likewise. * g++.dg/lookup/hidden-temp-class1.C: Likewise. * g++.dg/lookup/hidden-temp-class2.C: Likewise. * g++.dg/lookup/hidden-temp-class3.C: Likewise. * g++.dg/lookup/hidden-temp-class4.C: Likewise. * g++.dg/lookup/hidden-temp-class5.C: Likewise. * g++.dg/lookup/hidden-temp-class6.C: Likewise. * g++.dg/lookup/hidden-temp-class7.C: Likewise. * g++.dg/lookup/hidden-temp-class8.C: Likewise. * g++.dg/lookup/hidden-temp-class9.C: Likewise. * g++.dg/lookup/hidden-temp-class10.C: Likewise. * g++.dg/lookup/hidden-temp-class11.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4661&r2=1.4662 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1109&r2=1.1110 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1377&r2=1.1378 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.111&r2=1.112 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.h.diff?cvsroot=gcc&r1=1.37&r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.320&r2=1.321 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.982&r2=1.983 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.210&r2=1.211 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.463&r2=1.464 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5160&r2=1.5161 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/hidden-class1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/
[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-14 14:40 --- Fixed in the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016
[Bug c++/4403] incorrect class becomes a friend in template
-- Bug 4403 depends on bug 1016, which changed state. Bug 1016 Summary: [DR 166] friend class declarations not observing namespace rules. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4403
[Bug c++/16995] [meta-bug] C++ friend injection
-- Bug 16995 depends on bug 1016, which changed state. Bug 1016 Summary: [DR 166] friend class declarations not observing namespace rules. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16995
[Bug c++/13830] Invalid covariant type for identical type, friend related
-- Bug 13830 depends on bug 1016, which changed state. Bug 1016 Summary: [DR 166] friend class declarations not observing namespace rules. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13830
[Bug c++/20234] ambiguity with friend name injection and using directive
-- Bug 20234 depends on bug 1016, which changed state. Bug 1016 Summary: [DR 166] friend class declarations not observing namespace rules. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20234
[Bug c++/19403] [4.0/4.1 Regression] name lookup is broken with friends
-- Bug 19403 depends on bug 1016, which changed state. Bug 1016 Summary: [DR 166] friend class declarations not observing namespace rules. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 1016, which changed state. Bug 1016 Summary: [DR 166] friend class declarations not observing namespace rules. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c++/12944] [meta-bug] C++ name-lookup problems
-- Bug 12944 depends on bug 1016, which changed state. Bug 1016 Summary: [DR 166] friend class declarations not observing namespace rules. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug bootstrap/20424] Bootstrap failure on alphaev56
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 14:44 --- Subject: Bug 20424 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 14:44:10 Modified files: gcc: ChangeLog gcc/config/alpha: alpha.c Log message: PR bootstrap/20424 * config/alpha/alpha.c (alpha_fold_builtin_cmpbge): Fix typo. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7837&r2=2.7838 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.c.diff?cvsroot=gcc&r1=1.409&r2=1.410 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20424
[Bug c++/19403] [4.0/4.1 Regression] name lookup is broken with friends
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-14 14:46 --- Fixed in the mainline. Won't fix in 4.0 branch since the GCC 3.4.x behavior is also wrong. The error message present in 4.0 is useful to point out that the code need to be updated because GCC 4.1 will accept the code but have different behavior. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/16995] [meta-bug] C++ friend injection
-- Bug 16995 depends on bug 19403, which changed state. Bug 19403 Summary: [4.0/4.1 Regression] name lookup is broken with friends http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16995
[Bug c++/4403] incorrect class becomes a friend in template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 14:52 --- Subject: Bug 4403 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 14:51:25 Modified files: gcc/cp : ChangeLog name-lookup.c pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.pt: inherit2.C Added files: gcc/testsuite/g++.dg/template: friend34.C friend35.C Log message: PR c++/4403 PR c++/9783, DR433 * name-lookup.c (pushtag): Skip template parameter scope when scope is ts_global. Don't push tag into template parameter scope. * pt.c (instantiate_class_template): Reorder friend class template substitution to handle non-dependent friend class that hasn't been previously declared. * g++.dg/template/friend34.C: New test. * g++.dg/template/friend35.C: Likewise. * g++.old-deja/g++.pt/inherit2.C: Remove XFAIL's. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4662&r2=1.4663 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.112&r2=1.113 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.983&r2=1.984 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5161&r2=1.5162 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/friend34.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/friend35.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.pt/inherit2.C.diff?cvsroot=gcc&r1=1.7&r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4403
[Bug c++/9783] [DR433] Can't forward reference class in argument to templated method.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 14:52 --- Subject: Bug 9783 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 14:51:25 Modified files: gcc/cp : ChangeLog name-lookup.c pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.pt: inherit2.C Added files: gcc/testsuite/g++.dg/template: friend34.C friend35.C Log message: PR c++/4403 PR c++/9783, DR433 * name-lookup.c (pushtag): Skip template parameter scope when scope is ts_global. Don't push tag into template parameter scope. * pt.c (instantiate_class_template): Reorder friend class template substitution to handle non-dependent friend class that hasn't been previously declared. * g++.dg/template/friend34.C: New test. * g++.dg/template/friend35.C: Likewise. * g++.old-deja/g++.pt/inherit2.C: Remove XFAIL's. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4662&r2=1.4663 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.112&r2=1.113 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.983&r2=1.984 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5161&r2=1.5162 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/friend34.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/friend35.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.pt/inherit2.C.diff?cvsroot=gcc&r1=1.7&r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9783
[Bug c++/4403] incorrect class becomes a friend in template
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-14 14:53 --- Fixed in the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4403
[Bug c++/16995] [meta-bug] C++ friend injection
-- Bug 16995 depends on bug 4403, which changed state. Bug 4403 Summary: incorrect class becomes a friend in template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4403 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16995
[Bug c++/9783] [DR433] Can't forward reference class in argument to templated method.
-- Bug 9783 depends on bug 4403, which changed state. Bug 4403 Summary: incorrect class becomes a friend in template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4403 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9783
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 4403, which changed state. Bug 4403 Summary: incorrect class becomes a friend in template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4403 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c++/12944] [meta-bug] C++ name-lookup problems
-- Bug 12944 depends on bug 4403, which changed state. Bug 4403 Summary: incorrect class becomes a friend in template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4403 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug c++/12944] [meta-bug] C++ name-lookup problems
-- Bug 12944 depends on bug 9783, which changed state. Bug 9783 Summary: [DR433] Can't forward reference class in argument to templated method. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9783 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug c++/9783] [DR433] Can't forward reference class in argument to templated method.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-14 14:54 --- Fixed in the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9783
[Bug bootstrap/20424] Bootstrap failure on alphaev56
--- Additional Comments From falk at debian dot org 2005-03-14 15:03 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20424
[Bug target/20424] [4.1 Regression] Bootstrap failure on alphaev56
-- What|Removed |Added Component|bootstrap |target Keywords||build, wrong-code Summary|Bootstrap failure on|[4.1 Regression] Bootstrap |alphaev56 |failure on alphaev56 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20424
[Bug c++/20234] ambiguity with friend name injection and using directive
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20234
[Bug debug/20446] invalid assembly with -gstabs+
--- Additional Comments From ivanr at syncad dot com 2005-03-14 15:42 --- Subject: Re: invalid assembly with -gstabs+ Hi, If I switch to default debug format, I get an internal compiler error in another file that I guess would have to report as a different bug. I'll need some time though to narrow down the file to something smaller. Ivan - Original Message - From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 14, 2005 9:27 AM Subject: [Bug debug/20446] invalid assembly with -gstabs+ > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 14:27 --- > (In reply to comment #7) > > stabs+ is used for compatibility issues with Wine > > So, even mywin (and cygwin) have both moved over to dwarf2. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > > --- Additional Comments From ivanr at syncad dot com 2005-03-14 15:42 --- Subject: Re: invalid assembly with -gstabs+ Hi, If I switch to default debug format, I get an internal compiler error in another file that I guess would have to report as a different bug. I'll need some time though to narrow down the file to something smaller. Ivan - Original Message - From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 14, 2005 9:27 AM Subject: [Bug debug/20446] invalid assembly with -gstabs+ > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 14:27 --- > (In reply to comment #7) > > stabs+ is used for compatibility issues with Wine > > So, even mywin (and cygwin) have both moved over to dwarf2. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug debug/20446] invalid assembly with -gstabs+
--- Additional Comments From ivanr at syncad dot com 2005-03-14 15:42 --- Subject: Re: invalid assembly with -gstabs+ Hi, If I switch to default debug format, I get an internal compiler error in another file that I guess would have to report as a different bug. I'll need some time though to narrow down the file to something smaller. Ivan - Original Message - From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 14, 2005 9:27 AM Subject: [Bug debug/20446] invalid assembly with -gstabs+ > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 14:27 --- > (In reply to comment #7) > > stabs+ is used for compatibility issues with Wine > > So, even mywin (and cygwin) have both moved over to dwarf2. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > > --- Additional Comments From ivanr at syncad dot com 2005-03-14 15:42 --- Subject: Re: invalid assembly with -gstabs+ Hi, If I switch to default debug format, I get an internal compiler error in another file that I guess would have to report as a different bug. I'll need some time though to narrow down the file to something smaller. Ivan - Original Message - From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 14, 2005 9:27 AM Subject: [Bug debug/20446] invalid assembly with -gstabs+ > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 14:27 --- > (In reply to comment #7) > > stabs+ is used for compatibility issues with Wine > > So, even mywin (and cygwin) have both moved over to dwarf2. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug target/17688] [4.1] x87 fops can handle HImodes
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 16:16 --- Subject: Bug 17688 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 16:16:22 Modified files: gcc: ChangeLog gcc/config/i386: i386.c i386.h i386.md Log message: PR target/17688 * config/i386/i386.c (x86_use_himode_fiop): New. (x86_use_simode_fiop): Rename from x86_use_fiop. * config/i386/i386.h (x86_use_himode_fiop): Declare. (TARGET_USE_HIMODE_FIOP): New. (x86_use_simode_fiop): Rename from x86_use_fiop. (TARGET_USE_SIMODE_FIOP): Rename from TARGET_USE_FIOP. * config/i386/i386.md (X87MODEI12): New mode macro define. (*cmpfp_): Rename from *cmpfp_si. Use X87MODEI12 mode macro to implement x87 FP compare with HImode input operands. (*fp_jcc_8_387, splitter): Rename from *fp_jcc_8_387. Use X87MODEI12 mode macro to handle HImode input operands. (*fop_sf_2_i387, *fop_sf_3_i387, *fop_df_2_i387, *fop_df_3_i387, *fop_xf_2_i387, *fop_xf_3_i387): Renamed from *fop_sf_2_i387, *fop_sf_3_i387, *fop_df_2_i387, *fop_df_3_i387, *fop_xf_2_i387, *fop_xf_3_i387. Use X87MODEI12 mode macro to implement x87 operators with HImode input operands. (fop splitters): Use X87MODEI12 mode macro to handle HImode input operands. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7842&r2=2.7843 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.796&r2=1.797 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcc&r1=1.421&r2=1.422 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.618&r2=1.619 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17688
[Bug target/17688] [4.1] x87 fops can handle HImodes
--- Additional Comments From uros at kss-loka dot si 2005-03-14 16:18 --- Patch installed on mainline after bootstrapping on --host=i386-pc-linux-gnu. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17688
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 17688, which changed state. Bug 17688 Summary: [4.1] x87 fops can handle HImodes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17688 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c++/20330] Constructor fails to find base class in specialization
--- Additional Comments From bangerth at dealii dot org 2005-03-14 16:25 --- The place to look at is 12.6.2/2: 2 Names in a mem-initializer-id are looked up in the scope of the constructor's class and, if not found in that scope, are looked up in the scope containing the constructor's definition. [Note: if the constructor's class contains a member with the same name as a direct or virtual base class of the class, a mem-initializer-id naming the member or base class and composed of a single identifier refers to the class member. A mem-initializer-id for the hidden base class may be specified using a qualified name. ] Unless the mem-initializer-id names a nonstatic data member of the constructor's class or a direct or virtual base of that class, the mem-initializer is ill-formed. A mem-initializer-list can initialize a base class using any name that denotes that base class type. Obviously, in the scope of the constructor, both the name of the base class and the name of the member of foo are visible. The standard specifies that this then denotes the member variable, and the sentence after that states that this is then an error because the variable is not one of the present class. In other words, gcc's behavior is correct even though there would be an unambiguous resolution in this very particular case. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20330
[Bug java/20469] New: gcjh does not rename Java variables named NULL
headers generated by gcjh contains class members (didn't check about other kind of objects) named 'NULL'. This is the name used in Java sourcecode, but cannot be safely used in C++ headers as NULL is always (or often?) defined. g++ error raised when including the produced headers is: error: expected unqualified-id before numeric constant -- Summary: gcjh does not rename Java variables named NULL Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: strk at keybit dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20469
[Bug c++/20453] GCC fails to treat a valid constant expression as a template argument
--- Additional Comments From joaquin at tid dot es 2005-03-14 17:08 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I cannot reproduce it either with an obvious change to fix the missing
> >
> > Too bad. Sorry for reporting this in such an imprecise
> > manner. The actual problem shows at Boost regression tests
> >
OK, I've got a test case:
#include
template<
std::size_t size_,
std::size_t alignment_ = std::size_t(-1)>
struct aligned_storage
{
};
template
struct foo
{
aligned_storage as;
};
int main()
{
foo f;
}
Fails with the following:
13: error: '(size_t)((-1))' is not a valid template argument for type 'unsigned
int' because it is a non-constant expression
Regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20453
[Bug middle-end/15700] [4.0 Regression] [unit-at-a-time] Inlining problem leads to miscompilation of glibc
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-14 17:08 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|2004-06-13 21:00:15 |2005-03-14 17:08:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15700
[Bug tree-optimization/20470] New: Branching sequence generated for ABS(x-y)
Noticed that gcc/g++ generate a branching sequence instead of straight-line code
for expressions of the form ABS(x-y). Changing the operator to something else
(+, *, /) resutls in straight-line code.
#define ABS(value) ( (value)>=0 ? (value) : -(value) )
int i,j,k,l,m,n;
void f1()
{
l = ABS(m+n);
i = ABS(j-k);
}
--
Summary: Branching sequence generated for ABS(x-y)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pthaugen at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc*-*-*
GCC host triplet: powerpc*-*-*
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20470
[Bug c++/20453] [4.0/4.1 Regression] GCC fails to treat a valid constant expression as a template argument
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 17:11 --- Confirmed, this worked with 4.0.0 20050225 which means it started to fail after the branch. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Status|WAITING |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-03-14 17:11:31 date|| Summary|GCC fails to treat a valid |[4.0/4.1 Regression] GCC |constant expression as a|fails to treat a valid |template argument |constant expression as a ||template argument Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20453
[Bug tree-optimization/20470] Branching sequence generated for ABS(x-y)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 17:12 --- Confirmed, I know where this comes from too, SPEC (but I had forgot which test). -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-03-14 17:12:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20470
[Bug tree-optimization/20470] Branching sequence generated for ABS(x-y)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 17:13 --- I will note I know there is an Apple radar about this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20470
[Bug libfortran/20471] New: Segmentation fault on read after backspace and rewind
Using the 03-13-05 Macintosh image of gfortran, I get this error - [dranta:~/tests/gfortran] dir% gfortran -o backspace4 backspace4.f [dranta:~/tests/gfortran] dir% backspace4 Segmentation fault [dranta:~/tests/gfortran] dir% cat backspace4.f program main dimension x(100) n10=10 write(3)n10,(x(n),n=1,n10) backspace 3 rewind 3 read(3)n10,(x(n),n=1,n10) stop end -- Summary: Segmentation fault on read after backspace and rewind Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20471
[Bug preprocessor/20472] New: Rre-processor header file search list wrong with --exec-prefix
Fix patch supplied at end... --- I have a problem (on Irix6.5, Solaris2.8, OSF1v5.1 and Linux) when I include the use of --exec-prefix in the build (which allows a common location for the man pages, info files and common c++ header files). The problem is that the some of the directory locations used to search for header files are nonsense. I decided to see where "make install" actually installs the files and see how to match that up with the Makefile.in setting of PREPROCESSOR_DEFINES. I've had a look at the way gcc is built. It builds (part of) the pre-processor (cppdefault.c) by using a set of definitions passed in fromn the Makefile, but these don't actually correspond to where "make install" puts files when you specify a --exec-prefix which is not under --prefix. Even if you don't specify a --exec-prefix the pathnames used are somewhat odd. I've build gcc with and without using --exec-prefix with and without my patch (see end). For gcc compilations the include paths used do not change as a result of this patch. For g++ compilations the include paths change as follows: A) Without using --exec-prefix: /local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3 /local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/i686-pc-linux-gnu /local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/backward becomes: /local/single/arch/include/c++/3.4.3 /local/single/arch/include/c++/3.4.3/i686-pc-linux-gnu /local/single/arch/include/c++/3.4.3/backward which are the same locations, but using a more sensible (direct) route. B) With --exec-prefix set When I use --exec-prefix to place it under a separate location to --prefix (well, it's really the reverse...) then what was: ignoring nonexistent directory "/local/shared/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../../../../include/c++/3.4.3" ignoring nonexistent directory "/local/shared/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../../../../include/c++/3.4.3/i686-pc-linux-gnu" ignoring nonexistent directory "/local/shared/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../../../../include/c++/3.4.3/backward" becomes /local/shared/common/include/c++/3.4.3 /local/shared/common/include/c++/3.4.3/i686-pc-linux-gnu /local/shared/common/include/c++/3.4.3/backward and things work as expected. NOTE: that even with this patch installed the setting of TOOL_INCLUDE_DIR still corresponds to a non-existent directory. I haven't tested this on any cross-compilation setup. This does not change the setting of gcc_tooldir, which is equally wrongly set, but it only seems to be used in cross-compilation. The patch is a trivial change from using $(gcc_gxx_include_dir) to using $(gxx_include_dir). == --- gcc/Makefile.in.orig2004-10-18 17:00:39.0 +0100 +++ gcc/Makefile.in 2005-03-14 10:55:15.0 + @@ -2332,12 +2332,15 @@ # # Remake cpp and protoize. - +#Fix to correspond to where make install puts things +#(at least for standard buils with --prefix and +#--exec-prefix + --prefix) +# PREPROCESSOR_DEFINES = \ -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \ - -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \ - -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_noncanonical)\" \ - -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \ + -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \ + -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gxx_include_dir)/$(target_noncanonical)\" \ + -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gxx_include_dir)/backward\" \ -DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \ -DCROSS_INCLUDE_DIR=\"$(CROSS_SYSTEM_HEADER_DIR)\" \ -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \ -- Summary: Rre-processor header file search list wrong with --exec- prefix Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gml4410 at ggr dot co dot uk CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ANY GCC host triplet: ANY GCC target triplet: ANY http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20472
[Bug preprocessor/20472] Rre-processor header file search list wrong with --exec-prefix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 17:46 --- > which are the same locations, but using a more sensible (direct) route. This is not true. What happens with symbolic links and stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20472
[Bug fortran/20441] -finit-local-zero is missing from gfortran
--- Additional Comments From dir at lanl dot gov 2005-03-14 18:05 --- This option is needed with most codes decended from main frame codes because almost all compiliers for the main frames did something like "-finit-local-zero" by default. The widely used suite of finite element codes from Livermore - DYNA3D, DYNA2D, NIKE2D, NIKE3D, TOPAZ2D, TOPAZ3D, MAZE, INGRID, ORIAN and TAURUS all require this option. Going through hundreds of thousands of lines of codes and trying to patch it to work with out "-finit-local-zero" is hopeless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug preprocessor/20472] Rre-processor header file search list wrong with --exec-prefix
--- Additional Comments From gml4410 at ggr dot co dot uk 2005-03-14 18:09 --- > > which are the same locations, but using a more sensible (direct) route. > > This is not true. What happens with symbolic links and stuff. If there are symbolic links involved then the "direct" path is going to be the one I really want to use. With: /local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3 a) if symbolic links led me to a place other than /local/single/arch/include/c++/3.4.3 then it would (almost?) certainly *not* be what was actually wanted b) some OSes may refuse to open path su8ch as this unless /local/single/arch/lib/gcc/i686-pc-linux-gnu/3.4.3 actually exists (in this case it does, but perhaps teher are cases when it does not?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20472
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 18:24 --- Subject: Bug 17236 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 18:24:15 Modified files: gcc: ChangeLog optabs.c Log message: PR rtl-optimization/17236 * optabs.c (expand_doubleword_mult): New helper function split out from expand_binop. Permute the order in which instructions are emitted to minimize the number of simultaneously live registers. (expand_binop): Call expand_doubleword_mult to synthesize a double word multiplication. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7846&r2=2.7847 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gcc&r1=1.260&r2=1.261 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.
--- Additional Comments From stiriac at oddpost dot com 2005-03-14 18:30 --- (In reply to comment #5) > The linux kernel requires optimization to be correctly compiled. This is a > deliberate design decision by the linux kernel developers. > Thanks for the explanation. Looking for hints on Google I stumbled on a note debating if "inline" was correctly used or not in the Linux kernel but I didn't understant to the extend you describe. The corollary question is now how I close this bug request. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20217
[Bug fortran/20473] New: false arithmetic with short integers
The Operation 2*i with short integers (KIND=3, KIND=6) give incorrect values if the result exeeds the definded range for this types. The program example compiled with g77 test.f give the following results: integer*1: 100+100=-56, 2*100=200 integer*2: 2+2=-25536, 2*2=4 The second one of each line ist mathematical correct, but outside the valid range of the data type. Test System was a Redhat Linux 4 Enterprise on Dual Opteron gcc-Version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4) Also seen with gcc 3.3.1 on Suse Linux 9.1 on Pentium M, and with cygwin gcc 3.3.3 on Xeon System. program short_int_test implicit none integer*1 i1 integer*2 i2 i1=100 print*, i1+i1, 2*i1 i2=2 print*, i2+i2, 2*i2 end -- Summary: false arithmetic with short integers Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ralph dot doering at web dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20473
[Bug tree-optimization/20474] New: ICE while compiling openmotif-2.2.3 with -ftree-vectorize
I was updating my Gentoo installation with the latest and got an internal compiler error in openmotif. This happened first with Gentoo's GCC version 4.0.0_beta20050305. I then CVS'd the latest GCC version and got the same error with that. gcc version 4.1.0 20050314 (experimental) configured with: ../configure --prefix=/opt/gcc-4.0 --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --with-gcc-version-trigger=/home/lynx/Desktop/working/gcc/gcc/version.c --enable-languages=c,c++,java,objc : (reconfigured) ../configure --prefix=/opt/gcc-4.0 --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --with-gcc-version-trigger=/home/lynx/Desktop/working/gcc/gcc/version.c --enable-languages=c,c++ How-To-Repeat: Command: # gcc -O3 -ftree-vectorize pack.c Output: pack.c: In function 'PackString': pack.c:865: 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. I will attach pack.i -- Summary: ICE while compiling openmotif-2.2.3 with -ftree- vectorize Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zlynx at acm dot org CC: gcc-bugs at gcc dot gnu 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=20474
[Bug tree-optimization/20474] ICE while compiling openmotif-2.2.3 with -ftree-vectorize
--- Additional Comments From zlynx at acm dot org 2005-03-14 18:51 --- Created an attachment (id=8386) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8386&action=view) preprocessed source to reproduce bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20474
[Bug c++/20475] New: static_cast falsely allows const to be cast away
I just tried the following block of C++ code with g++ 20050311, the
latest snapshot.
void f()
{
char * pj2 = static_cast < char * > ("fred");
}
The compiler said
[EMAIL PROTECTED]:~/C++/src> ~/gnu/20050311/results/bin/g++ -c sc.cc
I added more flags
[EMAIL PROTECTED]:~/C++/src> ~/gnu/20050311/results/bin/g++ -g -O2 -Wall -ansi
-pedantic
-c sc.cc
sc.cc: In function `void f()':
sc.cc:5: warning: unused variable 'pj2'
[EMAIL PROTECTED]:~/C++/src>
However, my reading of Stroustrup 3, page 414, section 15.4.2.1 says that
static_cast can't be used to cast away const.
I think the compiler should complain about the above code. Here is Intel C++ 8.1
doing what I want.
sc.cc(5): error: static_cast cannot cast away const or other type qualifiers
char * pj2 = static_cast < char * > ("fred");
^
This example derived from real code in Suse Linux 9.2
--
Summary: static_cast falsely allows const to be cast away
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug fortran/20473] false arithmetic with short integers
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-14 19:03 --- "2*i1" implicitly converts i1 to default integer kind, and then performs the multiplication. g77's behavior is correct. It is unfortunate that g77 doesn't have the -Wconversion command-line option, with gfortran you get: [EMAIL PROTECTED] tests]$ gfortran pr20473.f90 -Wconversion In file pr20473.f90:8 print*, i1+i1, 2*i1 1 Warning: Conversion from INTEGER(1) to INTEGER(4) at (1) In file pr20473.f90:10 print*, i2+i2, 2*i2 1 Warning: Conversion from INTEGER(2) to INTEGER(4) at (1) In file pr20473.f90:7 i1=100 1 Warning: Conversion from INTEGER(4) to INTEGER(1) at (1) In file pr20473.f90:9 i2=2 1 Warning: Conversion from INTEGER(4) to INTEGER(2) at (1) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20473
[Bug fortran/20467] Bad fortran code causes ICE
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-14 19:08 --- It looks like we try to evaluate b as a statement function, which is of course not valid. Investigating ... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-03-14 04:39:12 |2005-03-14 19:08:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20467
[Bug tree-optimization/20470] Branching sequence generated for ABS(x-y)
--- Additional Comments From pthaugen at us dot ibm dot com 2005-03-14 19:13 --- I noticed this in the twolf benchmark of SPEC, dimbox.c:new_dbox_a(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20470
[Bug fortran/20467] Bad fortran code causes ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 19:55 --- Subject: Bug 20467 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 19:55:02 Modified files: gcc/fortran: ChangeLog symbol.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: stfunc_2.f90 Log message: fortran/ PR fortran/20467 * symbol.c (check_conflict): A dummy argument can't be a statement function. testsuite/ PR fortran/20467 * gfortran.dg/stfunc_2.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.352&r2=1.353 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.26&r2=1.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5164&r2=1.5165 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/stfunc_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20467
[Bug tree-optimization/20474] ICE while compiling openmotif-2.2.3 with -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-03-14 20:01
---
The problem is that we take the size_type of a void type, and pass null to
fold_convert in vect_analyze_pointer_ref_access.
So one thing to do is to make sure that we're dealing with a complete type:
*** vect_analyze_pointer_ref_access (tree me
*** 1321,1326
--- 1403,1416
*ptr_step = fold_convert (ssizetype, step);
innertype = TREE_TYPE (reftype);
+ if (!COMPLETE_TYPE_P (innertype))
+ {
+ if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS,
+ LOOP_LOC (loop_vinfo)))
+ fprintf (vect_dump, "not vectorized: pointer to incomplete type.");
+ return NULL;
+ }
+
/* Check that STEP is a multiple of type size. */
if (!integer_zerop (size_binop (TRUNC_MOD_EXPR, *ptr_step,
fold_convert (ssizetype, TYPE_SIZE_UNIT (innertype)
This solves the ICE, but I noticed that we're actually looking at the wrong
type - we're interested in the type of the data-reference, not the type of
its 'init'. The following is what we want (also solves the ICE):
*** vect_analyze_pointer_ref_access (tree me
*** 1310,1317
return NULL;
}
! reftype = TREE_TYPE (init);
! if (!POINTER_TYPE_P (reftype))
{
if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS,
LOOP_LOC (loop_vinfo)))
--- 1393,1399
return NULL;
}
! if (!POINTER_TYPE_P (TREE_TYPE (init)))
{
if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS,
LOOP_LOC (loop_vinfo)))
I'll bootstrap/test and submit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20474
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 20:02 --- Subject: Bug 20280 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 20:02:11 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr20280.C Log message: gcc/ChangeLog: PR c++/20280 * gimplify.c (gimplify_cond_expr): Add fallback argument. Use a temporary variable of pointer type if an lvalues is required. (gimplify_modify_expr_rhs): Request an rvalue from it. (gimplify_expr): Pass fallback on. gcc/testsuite/ChangeLog: PR c++/20280 * g++.dg/tree-ssa/pr20280.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7848&r2=2.7849 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.117&r2=2.118 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5165&r2=1.5166 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr20280.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug rtl-optimization/18628] [4.0/4.1 regression] miscompilation of switch statement in loop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 20:06 --- Subject: Bug 18628 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 20:06:23 Modified files: gcc: ChangeLog cse.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr18628.c Log message: gcc/ChangeLog: PR middle-end/18628 * cse.c (fold_rtx_mem): Don't fold a load from a jumptable into a register. gcc/testsuite/ChangeLog: * gcc.dg/pr18628.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7849&r2=2.7850 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cse.c.diff?cvsroot=gcc&r1=1.349&r2=1.350 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5166&r2=1.5167 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18628.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
[Bug tree-optimization/20474] ICE while compiling openmotif-2.2.3 with -ftree-vectorize
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20474
[Bug c++/20475] static_cast falsely allows const to be cast away
-- What|Removed |Added Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 20:14 --- With -Wwrite-strings, I do get a warning: t.cc:3: warning: deprecated conversion from string constant to char*' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug fortran/20467] Bad fortran code causes ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 20:15 --- Subject: Bug 20467 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-14 20:15:30 Modified files: gcc/fortran: ChangeLog symbol.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: stfunc_2.f90 Log message: fortran/ PR fortran/20467 * symbol.c (check_conflict): A dummy argument can't be a statement function. testsuite/ PR fortran/20467 * gfortran.dg/stfunc_2.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.12&r2=1.335.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.26&r2=1.26.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.43&r2=1.5084.2.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/stfunc_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20467
[Bug fortran/20467] Bad fortran code causes ICE
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-14 20:16 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20467
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 20467, which changed state. Bug 20467 Summary: Bad fortran code causes ICE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20467 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-14 20:25 --- Mainline and 4.0 branch still fail the small testcase with "fatal error: internal consistency failure" when built for powerpc-linux (not just powerpc64-linux). The failure begins with the following patch, added before the 4.0 branch was created: 2005-02-19 Steven Bosscher <[EMAIL PROTECTED]> PR middle-end/19698 * function.h (struct function): New field `max_loop_depth'. * cfgloop.c (establish_preds): Update maximum loop depth seen so far. (flow_loops_find): Reset the max loop depth count before finding loops. * flow.c (MAX_LIVENESS_ROUNDS): New constant. (update_life_info_in_dirty_blocks): Remove 2002-05-28 workaround. (calculate_global_regs_live): Make sure the loop will terminate when the initial sets are not empty. -- What|Removed |Added CC||stevenb at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20177
[Bug rtl-optimization/18628] [4.0/4.1 regression] miscompilation of switch statement in loop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 20:32 --- Subject: Bug 18628 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-14 20:32:50 Modified files: gcc: ChangeLog cse.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr18628.c Log message: gcc/ChangeLog: PR middle-end/18628 * cse.c (fold_rtx_mem): Don't fold a load from a jumptable into a register. gcc/testsuite/ChangeLog: * gcc.dg/pr18628.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.49&r2=2.7592.2.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cse.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.345&r2=1.345.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.44&r2=1.5084.2.45 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18628.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
[Bug fortran/18737] ICE on invalid use of external keyword
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-14 20:34 --- Actually, this slightly modified valid testcase fails with the same error: program test ! implicit none real(8) :: x external bug x = 2 print *, bug(x) end program test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18737
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 20:35 --- Subject: Bug 20280 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-14 20:34:53 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr20280.C Log message: gcc/ChangeLog: PR c++/20280 * gimplify.c (gimplify_cond_expr): Add fallback argument. Use a temporary variable of pointer type if an lvalues is required. (gimplify_modify_expr_rhs): Request an rvalue from it. (gimplify_expr): Pass fallback on. gcc/testsuite/ChangeLog: PR c++/20280 * g++.dg/tree-ssa/pr20280.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.50&r2=2.7592.2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.113.2.1&r2=2.113.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.45&r2=1.5084.2.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr20280.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug fortran/18737] ICE on invalid use of external keyword
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-14 20:37 --- Excuse, the testcase with "implicit none" commented out passes. -- What|Removed |Added Last reconfirmed|2005-03-01 14:09:30 |2005-03-14 20:37:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18737
[Bug fortran/18737] ICE on invalid use of external keyword
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-14 20:52 --- The bug is caused by the call to gfc_set_default_type in resolve.c:3961 passing 0 as second argument, thereby suppressing the error that should be issued there. Unfortunately, passing 1 for the argument breaks code which calls intrinsic functions. -- What|Removed |Added Last reconfirmed|2005-03-14 20:37:30 |2005-03-14 20:52:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18737
[Bug tree-optimization/20470] Branching sequence generated for ABS(x-y)
--- Additional Comments From pthaugen at us dot ibm dot com 2005-03-14 22:29 --- Decided to look into this myself, currently testing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20470
[Bug rtl-optimization/18628] [4.0/4.1 regression] miscompilation of switch statement in loop
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-14 23:43 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-14 23:43 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug tree-optimization/20458] [4.1 regression] structure aliasing causes wrong code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15 01:26 --- Subject: Bug 20458 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-15 01:26:35 Modified files: gcc: ChangeLog tree-flow-inline.h tree-ssa-operands.c tree-tailcall.c Added files: gcc/testsuite/g++.dg/tree-ssa: pr20458.C Log message: 2005-03-14 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/20458 * tree-flow-inline.h (mark_call_clobbered): Don't fiddle DECL_EXTERNAL on STRUCT_FIELD tags. (clear_call_clobbered): Ditto. * tree-ssa-operands.c (note_addressable): Make sure the original variable doesn't slip into the addressable list if we have subvars. * tree-tailcall.c (suitable_for_tail_opt_p): Look at STRUCT_FIELD tags too. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7854&r2=2.7855 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow-inline.h.diff?cvsroot=gcc&r1=2.32&r2=2.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-operands.c.diff?cvsroot=gcc&r1=2.67&r2=2.68 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-tailcall.c.diff?cvsroot=gcc&r1=2.37&r2=2.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr20458.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20458
[Bug tree-optimization/20458] [4.1 regression] structure aliasing causes wrong code
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-15 01:27 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20458
[Bug tree-optimization/17687] [4.1] sincos can be folded at the tree level
--- Additional Comments From giovannibajo at libero dot it 2005-03-15 01:53 --- Paolo, are you going to submit this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug c++/20476] New: g++ crashes with a contrived template mistake.
g++ gives an "internal compiler error: Segmentation fault"
message where it should give an error about illegal code. I've included
code to cause the problem. This code shows a mistake in the
initialization of a template member. The template was used incorrectly.
The simple problem code is:
/* The example code that causes the failure: */
template
class bob {
const int ndim;
};
/* note that the mistake below causes the g++ crash:
* bob below should be bob
*/
template
const int bob::ndim = ndim_;
int main() {
bob<> a;
return 0;
}
--
Summary: g++ crashes with a contrived template mistake.
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olsonse at umich dot edu
CC: gcc-bugs at gcc dot gnu dot org,olsonse at umich dot edu
GCC build triplet: x86_64-suse-linux-gnu
GCC host triplet: x86_64-suse-linux-gnu
GCC target triplet: x86_64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20476
[Bug c++/20476] g++ crashes with a contrived template mistake.
--- Additional Comments From olsonse at umich dot edu 2005-03-15 01:59 --- Created an attachment (id=8387) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8387&action=view) Preprocessor output of mentioned simple testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20476
[Bug c++/20476] [3.3 Regression] g++ crashes with a contrived template mistake.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-15 01:59 --- Confirmed, only a regression for 3.3.x. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code Known to fail||3.3.3 Known to work||3.4.0 3.2.3 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-03-15 01:59:31 date|| Summary|g++ crashes with a contrived|[3.3 Regression] g++ crashes |template mistake. |with a contrived template ||mistake. Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20476
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From giovannibajo at libero dot it 2005-03-15 02:12 --- (In reply to comment #3) >> What is the compile-time impact of this patch on cc-i compilation, the usual >> C++ testcases, and SPEC? I am sure this is something worthwile to >> mention for a review. > Sorry, I don't have such numbers at the moment. Note that this > optimization is specific to AUTO_INC_DEC targets There are both primary and secondary platforms among the AUTO_INC_DEC targets. So it is probably good to gain some wider test coverage about the compile- time/run-time impact of this. E.g. testing CSIBE on ARM, or SPEC on RS6000. > I made this switch default-on at > -O2 mainly because it makes testing the patch much simpler. > For integration, I'm also fine with having it > default-off and having only the targets that want it turn it on in > OPTIMIZATION_OPTIONS. IMHO it is better to activate new optimization passes at either -O2 or -O3, depending on their impact on compile time and code generation (see above). So I am fine with that once it is proven that this is doing well. > >And BTW, out of curiosity, does the new pass have to live in regmove.c? > Not absolutely, but it makes sense insofar as an aspect of this > optimization is to avoid register-register > moves which are required when you end up with awkward register > assignments for the addds, > and it is also nice to have sched1 run first. And there is also the > issue fo inserting add instructions, > which needs infrastructure from regmove to avoid issues with targets > that have a flags register that > can be clobbered by the new adds. One of the common complaints of RTL code is that monolithic files containing multiple optimization passes (with interwinded functions) and with undocumented public interface is a maintenance mess. Compare that with tree-ssa where each pass lives in its own small[1] file and just exposes the pass description structure. I believe it would be great if the new pass could be live in its own file. The utility functions currently in regmove could be extracted in regmovelib or whatever name fits best. [1] ok, let's ignore ivopts for the sake of this discussion ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug fortran/18827] ICE on assign to common variable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15 02:52 --- Subject: Bug 18827 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-15 02:52:38 Modified files: gcc/testsuite : ChangeLog gcc/fortran: ChangeLog io.c match.c resolve.c trans-common.c trans-stmt.c trans-io.c trans.h Added files: gcc/testsuite/gfortran.dg: assign.f90 assign_2.f90 assign_3.f90 Log message: fortran/ 2005-03-15 Feng Wang <[EMAIL PROTECTED]> PR fortran/18827 * io.c (resolve_tag): Add checking on assigned label. (match_dt_format): Does not set symbol assign attribute. * match.c (gfc_match_goto):Does not set symbol assign attribute. * resolve.c (resolve_code): Add checking on assigned label. * trans-common.c (build_field): Deals with common variable assigned a label. * trans-stmt.c (gfc_conv_label_variable): New function. (gfc_trans_label_assign): Use it. (gfc_trans_goto): Ditto. * trans-io.c (set_string): Ditto. * trans.h (gfc_conv_label_variable): Add prototype. testsuite/ 2005-03-15 Feng Wang <[EMAIL PROTECTED]> PR fortran/18827 * gfortran.dg/assign_2.f90: New test. * gfortran.dg/assign_3.f90: New test. * gfortran.dg/assign.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5169&r2=1.5170 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.353&r2=1.354 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&r1=1.19&r2=1.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.31&r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.37&r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.c.diff?cvsroot=gcc&r1=1.24&r2=1.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&r1=1.24&r2=1.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-io.c.diff?cvsroot=gcc&r1=1.33&r2=1.34 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gcc&r1=1.24&r2=1.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18827
[Bug fortran/18827] ICE on assign to common variable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15 03:43 --- Subject: Bug 18827 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-15 03:42:49 Modified files: gcc/testsuite : ChangeLog gcc/fortran: ChangeLog io.c match.c resolve.c trans-common.c trans-stmt.c trans-io.c trans.h Added files: gcc/testsuite/gfortran.dg: assign.f90 assign_2.f90 assign_3.f90 Log message: fortran/ 2005-03-15 Feng Wang <[EMAIL PROTECTED]> PR fortran/18827 * io.c (resolve_tag): Add checking on assigned label. (match_dt_format): Does not set symbol assign attribute. * match.c (gfc_match_goto):Does not set symbol assign attribute. * resolve.c (resolve_code): Add checking on assigned label. * trans-common.c (build_field): Deals with common variable assigned a label. * trans-stmt.c (gfc_conv_label_variable): New function. (gfc_trans_label_assign): Use it. (gfc_trans_goto): Ditto. * trans-io.c (set_string): Ditto. * trans.h (gfc_conv_label_variable): Add prototype. testsuite/ 2005-03-15 Feng Wang <[EMAIL PROTECTED]> PR fortran/18827 * gfortran.dg/assign_2.f90: New test. * gfortran.dg/assign_3.f90: New test. * gfortran.dg/assign.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.47&r2=1.5084.2.48 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_3.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.13&r2=1.335.2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19&r2=1.19.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31&r2=1.31.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.3&r2=1.34.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.23.2.1&r2=1.23.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.24&r2=1.24.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.33&r2=1.33.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.23.2.1&r2=1.23.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18827
[Bug middle-end/20477] New: [4.0] Remove used label when optimizing.
See testsuite/gfortran.dg/assign.f90:
! { dg-do run }
! Program to test ASSIGNing a label to common variable. PR18827.
program test
integer i
common i
assign 2000 to i ! { dg-warning "Obsolete: ASSIGN statement" }
2000 continue
end
In the Fortran front-end we generate the label decl tree of "2000" and use its
address in fortran/trans-stmt.c: gfc_trans_label_assign() function.
If we don't set DECL_ARTIFICIAL flag to zero on the label_tree, when compile
the test program the label will be removed when optimizing and cause to link
error.
It disappeared in the recent GCC mainline version.
--
Summary: [4.0] Remove used label when optimizing.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wf_cs at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20477
[Bug c++/20478] New: poor diagnostic
The actual error is a missing right paren on line 137 of opApi.cc, which should
read:
vec(,
but the compiler gives:
opApi.cc:134: error: expected primary-expression before '(' token
opApi.cc:157: error: expected `)' before '}' token
opApi.cc:157: error: no matching function for call to `opApi< flow>::opApi()'
Ivan
--
Summary: poor diagnostic
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=20478
[Bug c++/20478] poor diagnostic
--- Additional Comments From igodard at pacbell dot net 2005-03-15 04:14 --- Created an attachment (id=8388) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8388&action=view) Compiler output (-v -save-temps) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20478
[Bug c++/20478] poor diagnostic
--- Additional Comments From igodard at pacbell dot net 2005-03-15 04:14 --- Created an attachment (id=8389) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8389&action=view) Source code (-save-temps) (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20478
[Bug tree-optimization/17687] [4.1] sincos can be folded at the tree level
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-03-15 06:36 --- Subject: Re: [4.1] sincos can be folded at the tree level > Paolo, are you going to submit this one? Yes, but I am wy too busy at work now. Maybe as soon as Thursday. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
