[Bug target/21163] [4.0 Regregresion] internal compiler error: in output_constant_pool_2, at varasm.c:3135
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-24 07:50:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug target/21101] ICE: could not find a spill register on MMX intrinsics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 07:59 --- Subject: Bug 21101 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-24 07:59:23 Modified files: gcc: ChangeLog gcc/config/i386: i386-protos.h i386.c i386.h Added files: gcc/testsuite/gcc.target/i386: pr21101.c Log message: PR target/21101 * config/i386/i386.h (CANNOT_CHANGE_MODE_CLASS): Move guts to ... * config/i386/i386.c (ix86_cannot_change_mode_class): ... here. Deny modes smaller than 4 bytes. * config/i386/i386-protos.h: Update. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8435&r2=2.8436 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-protos.h.diff?cvsroot=gcc&r1=1.137&r2=1.138 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.815&r2=1.816 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcc&r1=1.429&r2=1.430 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr21101.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21101
[Bug target/21101] ICE: could not find a spill register on MMX intrinsics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 08:02 --- Subject: Bug 21101 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 08:02:22 Modified files: gcc: ChangeLog gcc/config/i386: i386-protos.h i386.c i386.h Added files: gcc/testsuite/gcc.target/i386: pr21101.c Log message: PR target/21101 * config/i386/i386.h (CANNOT_CHANGE_MODE_CLASS): Move guts to ... * config/i386/i386.c (ix86_cannot_change_mode_class): ... here. Deny modes smaller than 4 bytes. * config/i386/i386-protos.h: Update. 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.184&r2=2.7592.2.185 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-protos.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.131&r2=1.131.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.795.6.5&r2=1.795.6.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.421.6.1&r2=1.421.6.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr21101.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=21101
[Bug target/17824] Hard-coded AS and LD in c4x.h
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 08:09 --- Subject: Bug 17824 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 08:09:06 Modified files: gcc: ChangeLog gcc/config/c4x : c4x.h Log message: 2005-04-24 Ralf Corsepius <[EMAIL PROTECTED]> PR target/17824 * config/c4x/c4x.h (ASM_PROG, LD_PROG): Remove. 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.185&r2=2.7592.2.186 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/c4x/c4x.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.151&r2=1.151.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17824
[Bug target/21101] ICE: could not find a spill register on MMX intrinsics
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-24 08:17 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21101
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From stevenb at suse dot de 2005-04-24 09:23
---
Subject: Re: [4.0/4.1 regression] miscompiled pointer subtraction broke Linux
kernel
On Sunday 24 April 2005 05:36, dberlin at dberlin dot org wrote:
> Uh, because it causes things to become non-invariant when they were
> originally invariant (because it will *always* create a new name for
> them).
Well, the comment before force_gimple_operand says it should not:
/* Expands EXPR to list of gimple statements STMTS. If SIMPLE is true,
force the result to be either ssa_name or an invariant, otherwise
just force it to be a rhs expression. If VAR is not NULL, make the
base variable of the final destination be VAR if suitable. */
tree
force_gimple_operand (tree expr, tree *stmts, bool simple, tree var)
{
tree-ssa-pre uses force_gimple_operand with SIMPLE==false, so if
expr is already a valid rhs, force_gimple_operand should do nothing.
If it does, I consider that to be a bug.
Your patch to use unshare_expr is IMHO unnecessarily expensive.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug fortran/21177] wrong code with NULL()
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-24 10:59 --- This test was introduced to fix PR 12841. Something more subtle is needed (maybe, check not only for EXPR_NULL, but for EXPR_NULL with no type?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21177
[Bug target/21101] ICE: could not find a spill register on MMX intrinsics
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21101
[Bug target/21099] ICE on mmx intrinsics
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21099
[Bug tree-optimization/17100] Missed opportunity for value range optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 11:48 --- i_8: VARYING # i_8 = PHI <0(0), i_10(4)>; :; if (i_8 == -5) goto ; else goto ; i_10 = i_8 + 1; if (i_10 <= 9) goto ; else goto ; i_10: [1, 2147483647] Hmm, isn't i_10 signed still so why between 1 and -1, that does not make sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17100
[Bug tree-optimization/14495] [tree-ssa] Propagate range info into a switch statement
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 11:52 --- VRP does not remove this for some reason even though we have now enough information to do so: a_2: [100, 200] switch (a_2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14495
[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 12:46 --- Subject: Bug 20991 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 12:46:25 Modified files: gcc: ChangeLog varasm.c cgraph.h tree-ssa-ccp.c gcc/cp : ChangeLog Log message: PR middle-end/20991 * cgraph.h (cgraph_local_info): Add vtable_method field. * varasm.c (mark_decl_referenced): If cgraph_global_info_ready and node is vtable_method, finalized and not reachable, don't do anything. Revert: 2005-04-18 Jakub Jelinek <[EMAIL PROTECTED]> * tree-ssa-ccp.c (fold_stmt): Don't optimize OBJ_TYPE_REFs if that would result in an already finalized unreachable node becoming reachable while cgraph_global_info_ready. * class.c: Include cgraph.h. (cp_fold_obj_type_ref): Set node->local.vtable_method. * Make-lang.in (cgraph.o): Depend on $(CGRAPH_H). 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.186&r2=2.7592.2.187 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.477.6.8&r2=1.477.6.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.44.8.3&r2=1.44.8.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.58.2.1&r2=2.58.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.34&r2=1.4648.2.35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug c++/21188] New: CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292
compilation fails with an internal error... g++-4 -v Using built-in specs. Target: powerpc-apple-darwin7 Configured with: ../configure --prefix=/sw --prefix=/sw/lib/gcc4 --enable- languages=c,c++,f95,objc --infodir=/share/info --with-gmp=/sw --with-included-gettext -- host=powerpc-apple-darwin7 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ ld Thread model: posix gcc version 4.1.0 20050417 (experimental) the problem is triggered by: /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin7/4.1.0/cc1plus -fpreprocessed CbcModel.ii -fPIC -quiet -dumpbase CbcModel.cpp -auxbase-strip Darwin-O3/CbcModel.o -O3 -Wall -Wpointer-arith -Wcast-qual -Wwrite-strings -Wconversion -version -o CbcModel.s GNU C++ version 4.1.0 20050417 (experimental) (powerpc-apple-darwin7) compiled by GNU C version 3.3 20030304 (Apple Computer, Inc. build 1495). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 CbcModel.cpp: In member function 'CbcModel* CbcModel::findCliques(bool, int, int, int)': CbcModel.cpp:3369: warning: operation on 'numberCliques' may be undefined CbcModel.cpp: In member function 'double CbcModel::checkSolution(double, const double*, bool)': CbcModel.cpp:3878: warning: unused variable 'integerTolerance' CbcModel.cpp: In member function 'void CbcModel::originalModel(CbcModel*, bool)': CbcModel.cpp:4862: warning: unused variable 'numberIntegerInfeasibilities' CbcModel.cpp:4863: warning: unused variable 'numberObjectInfeasibilities' CbcModel.cpp: In member function 'void CbcModel::findIntegers(bool)': CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. but how do i include the problematic file? -- Summary: CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: devries at ma dot tum dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7 GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21188
[Bug tree-optimization/21188] [4.1 Regression] CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c++ |tree-optimization GCC host triplet| powerpc-apple-darwin7 |powerpc-apple-darwin7 GCC target triplet| powerpc-apple-darwin7 |powerpc-apple-darwin7 Keywords||ice-on-valid-code Summary|CbcModel.cpp:3571: internal |[4.1 Regression] |compiler error: in |CbcModel.cpp:3571: internal |compare_values, at tree-|compiler error: in |vrp.c:292 |compare_values, at tree- ||vrp.c:292 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21188
[Bug tree-optimization/21188] [4.1 Regression] CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292
--- Additional Comments From devries at ma dot tum dot de 2005-04-24 13:00 --- Created an attachment (id=8723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8723&action=view) this is the ii file that causes the trouble this file demonstrates the prob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21188
[Bug rtl-optimization/21182] gcc can use registers but uses stack instead
--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua 2005-04-24 13:05 --- With 4.0.0: gcc -O2 gives the same result as gcc -O3, which is better than gcc 3.4.3 -O2 but worse than 3.4.3 -O3. For example: movl%edx, -20(%ebp) orl %ecx, %edi movl%ebx, %esi xorl%ecx, %esi andl%eax, %ebx xorl%edi, %ebx movl%eax, %ecx notl%ecx xorl%ebx, %ecx orl %edi, %eax xorl%eax, %esi rorl$19, %esi rorl$29, -20(%ebp) xorl%esi, %ebx xorl-20(%ebp), %ecx xorl-20(%ebp), %ebx rorl$31, %ebx leal0(,%esi,8), %edx 1) Why %edx was stored in -20(%ebp), there is no %edx usage in the following insns. %edx value could stay in register and we can continue to work on its value in register. 2) rorl $31, %ebx == roll $1, %ebx, but 1 bit roll insn is smaller. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
[Bug fortran/21177] wrong code with NULL()
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-24 13:06 --- Found a patch (after a good night's sleep, it seemed to easy!): Instead of if (actual->expr_type != EXPR_NULL && !gfc_compare_types (&formal->ts, &actual->ts)) return 0; we need to use if ((actual->expr_type != EXPR_NULL || actual->ts.type != BT_UNKNOWN) && !gfc_compare_types (&formal->ts, &actual->ts)) return 0; I'm regtesting it right now, and will post it in good form on monday (internet dial-up access problems). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21177
[Bug rtl-optimization/21150] Suboptimal byte extraction from 64bits
--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua 2005-04-24 13:26 --- I don't think that bug description is correct. I believe similar observation will be valid for byte extraction from u32 and u16, and for u16-from-u32, etc. Update for latest gcc. This is what 4.0.0 produces from the testcase: # gcc -O2 -fomit-frame-pointer -S helper.c # cat helper.s [I removed non-essential stuff] a: movlv+8, %eax shrl$8, %eax xorbv, %al xorbv+18, %al xorbv+27, %al xorbv+36, %al movlv+40, %edx movlv+44, %ecx movl%ecx, %edx xorl%ecx, %ecx shrl$8, %edx xorl%edx, %eax xorbv+54, %al xorbv+63, %al movzbl %al, %eax ret b: movlv+8, %eax movlv+12, %edx shrdl $8, %edx, %eax shrl$8, %edx xorbv, %al movlv+16, %edx movlv+20, %ecx shrdl $16, %ecx, %edx shrl$16, %ecx xorl%edx, %eax movlv+24, %edx movlv+28, %ecx shrdl $24, %ecx, %edx shrl$24, %ecx xorl%edx, %eax xorbv+36, %al movlv+40, %edx movlv+44, %ecx movl%ecx, %edx xorl%ecx, %ecx shrl$8, %edx xorl%edx, %eax xorbv+54, %al xorbv+63, %al movzbl %al, %eax ret c: movbv+9, %al xorbv, %al xorbv+18, %al xorbv+27, %al xorbv+36, %al xorbv+45, %al xorbv+54, %al xorbv+63, %al movzbl %al, %eax ret d: movlv+8, %eax movlv+12, %edx shrdl $8, %edx, %eax shrl$8, %edx xorbv, %al movlv+16, %edx movlv+20, %ecx shrdl $16, %ecx, %edx shrl$16, %ecx xorl%edx, %eax movlv+24, %edx movlv+28, %ecx shrdl $24, %ecx, %edx shrl$24, %ecx xorl%edx, %eax xorbv+36, %al movlv+40, %edx movlv+44, %ecx movl%ecx, %edx xorl%ecx, %ecx shrl$8, %edx xorl%edx, %eax xorbv+54, %al xorbv+63, %al movzbl %al, %eax ret As you can see, a,b and d results are far from optimal, while c is almost perfect. Note that people typically use d, i.e. this: #define D7(v) (((v) >> 56)) #define D6(v) (((v) >> 48) & 0xff) #define D5(v) (((v) >> 40) & 0xff) #define D4(v) (((v) >> 32) & 0xff) #define D3(v) (((v) >> 24) & 0xff) #define D2(v) (((v) >> 16) & 0xff) #define D1(v) (((v) >> 8) & 0xff) #define D0(v) ((v) & 0xff) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150
[Bug tree-optimization/21188] [4.1 Regression] CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24
13:29 ---
Reduced testcase:
struct class1
{
virtual ~class1 ();
};
struct class2 : class1 { };
void f(class1 * oo)
{
class2 * oj = dynamic_cast (oo) ;
if (oj)
delete oo;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-24 13:29:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21188
[Bug c++/21188] [4.1 Regression] CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 13:31 --- This is a latent bug in the C++ front-end with respect with dynamic_cast. if (oo.1 == 0) we have the wrong type already. -- What|Removed |Added Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21188
[Bug c++/21188] [4.1 Regression] CbcModel.cpp:3571: internal compiler error: in compare_values, at tree-vrp.c:292
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 13:42 --- Created an attachment (id=8724) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8724&action=view) patch which should fix this I am bootstrapping this fix right now. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21188
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 13:51 --- Subject: Bug 20059 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-24 13:51:39 Modified files: gcc/fortran: ChangeLog trans-common.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: common_5.f Log message: fortran/ PR fortran/20059 * trans-common.c (translate_common): Cast offset and common_segment->offset to type int for warning message. testsuite/ PR fortran/20059 * gfortran.dg/common_5.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.404&r2=1.405 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.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.5389&r2=1.5390 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_5.f.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 14:00 --- Subject: Bug 20059 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 13:59:58 Modified files: gcc/fortran: ChangeLog trans-common.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: common_5.f Log message: fortran/ PR fortran/20059 * trans-common.c (translate_common): Cast offset and common_segment->offset to type int for warning message. testsuite/ PR fortran/20059 * gfortran.dg/common_5.f: 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.37&r2=1.335.2.38 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.3&r2=1.23.2.4 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.134&r2=1.5084.2.135 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_5.f.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=20059
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-24 14:01 --- Fixed, sorry for the delay. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059
[Bug fortran/20405] [meta-bug] equivalenced variable problems
-- Bug 20405 depends on bug 20059, which changed state. Bug 20059 Summary: internal compiler error: Segmentation Fault - For common blocks http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20405
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 20059, which changed state. Bug 20059 Summary: internal compiler error: Segmentation Fault - For common blocks http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-24 14:02 --- I just went through the regression testing. I get FAIL: g++.dg/tree-ssa/pr18178.C scan-tree-dump-times if 1 It may be a good idea to check in this patch with the above testcase XFAILed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug rtl-optimization/13712] Executable runs 25% slower than when compiled with INTEL compiler
-- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2004-05-30 04:36:06 |2005-04-24 14:18:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13712
[Bug tree-optimization/14627] [4.0/4.1 regression] extra assignment inserted on the tree level
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-24 14:22 --- Jeff, "should be fixed now" is not helpful. Either it is fixed, so you should close the bug, or it is not, in which case your remark would not be true. Also, when you commit a patch that fixes a PR, you should mention the PR number in the ChangeLog. But you know all this. Too bad you don't follow this practice :-( Closing as FIXED. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14627
[Bug fortran/20879] argument to ICHAR must have length one
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-04-24 14:23 --- The original testcase can (and should) be checked at compile time. The argument is a simple variable of known length. The error should be unconditional (ie. not just when -pedantic is specified) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20879
[Bug tree-optimization/14627] [4.0/4.1 regression] extra assignment inserted on the tree level
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14627
[Bug c++/21189] New: wierd behavior
I foudn that the following program compiles okay with gcc-4.0. But it report
"bad_alloc" when executed with common account. However, when I tried to run it
with root, it becomes okay again.
// .hh file
#ifndef _MC_STATE_H_
#define _MC_STATE_H_
#include
#include
#include
#include
#include "global.h"
using namespace std;
class Signature
{
public:
Signature(unsigned char * str, size_t len);
Signature(const Signature& nsig);
~Signature();
Signature operator =(Signature osig);
string to_string();
private:
unsigned char * sig;
size_t len;
};
class State
{
public:
State();
State(const void*, int len);
State(const State&);
~State() throw ();
State& operator = (State&);
bool operator == (State&);
bool operator == (State);
bool operator != (State&);
Signature get_signature();
State operator + (State&);
private:
unsigned char * data;
size_t sz;
bool valid_sig;
unsigned char sig[16];
};
#endif
// the .cc file
#include
#include
#include
#include
#include "state.hh"
#include
using namespace std;
Signature::Signature(unsigned char* str, size_t vlen)
{
sig = new unsigned char[len];
len = vlen;
memcpy(sig, str, len);
}
Signature::Signature(const Signature& nsig)
: len(nsig.len)
{
sig = new unsigned char [len];
memcpy(sig, nsig.sig, len);
}
Signature::~Signature()
{
delete[] sig;
}
Signature Signature::operator = (Signature osig)
{
delete[] sig;
len = osig.len;
sig = new unsigned char [len];
memcpy(sig, osig.sig, len);
return *this;
}
string Signature::to_string()
{
char* buf;
int i;
buf = new char[len * 2+1];
for (i = 0; i < len; i++) sprintf(buf+2*i, "%x", sig[i]);
buf[len*2] = 0;
string retval = buf;
delete [] buf;
return retval;
}
/*/
State::State()
: data(0), sz(0), valid_sig(false)
{}
State::State(const void * dt, int len)
: valid_sig(false), sz(len)
{
data = new unsigned char [len];
memcpy(data, dt, sz);
}
State::State(const State& nst)
: valid_sig(nst.valid_sig), sz(nst.sz)
{
data = new unsigned char[sz];
memcpy(data, nst.data, sz);
memcpy(sig, nst.sig, sizeof(sig));
}
State::~State() throw()
{
delete [] data;
}
State& State::operator = (State& nst)
{
if (data != 0) delete reinterpret_cast(data);
sz = nst.sz;
valid_sig = nst.valid_sig;
data = new unsigned char[sz];
memcpy(data, nst.data, sz);
if (valid_sig) memcpy(sig, nst.sig, sizeof(sig));
return *this;
}
bool State::operator == (State & nst)
{
if (sz != nst.sz) return false;
return (memcmp(data, nst.data, sz) == 0);
}
bool State::operator == (State nst)
{
if (sz != nst.sz) return false;
return (memcmp(data, nst.data, sz) == 0);
}
bool State::operator != (State & nst)
{
if (sz != nst.sz) return true;
return (memcmp(data, nst.data, sz) != 0);
}
Signature State::get_signature()
{
if (sz <= 16)
return Signature(data,sz);
MD4(data, sz, sig);
return Signature(sig, sizeof(sig));
}
State State::operator + (State& nst)
{
State retval;
retval.data = new unsigned char [this->sz + nst.sz];
retval.sz = this->sz + nst.sz;
retval.valid_sig = false;
memcpy(retval.data, data, sz);
memcpy(retval.data + sz, nst.data, nst.sz);
assert(retval.sz == this->sz + nst.sz);
return retval;
}
#if 1
#include
using namespace std;
int main()
{
char data[] = "fdfdsafdsafhasdkhfksladhfklsdahfklsdahflksdahfdsahkfkasd";
State st(data, sizeof(data));
cout
[Bug c++/21189] wierd behavior
--- Additional Comments From gnu04 at yahoo dot com 2005-04-24 14:31 --- Created an attachment (id=8725) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8725&action=view) The .cc file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21189
[Bug target/18154] Inefficient max/min code for PowerPC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 14:31 --- On the mainline, we now produce: cmpw cr7,r3,r4 blelr- cr7 mr r3,r4 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18154
[Bug c++/21189] wierd behavior
--- Additional Comments From gnu04 at yahoo dot com 2005-04-24 14:32 --- Created an attachment (id=8726) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8726&action=view) the .hh file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21189
[Bug c++/21189] wierd behavior
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 14:34 --- If it is throwing bad_alloc, that means it is running out of memory. I would check you memory limits? -- What|Removed |Added Summary|wierd behavior |wierd behavior http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21189
[Bug c++/21189] weird behavior
-- What|Removed |Added Summary|wierd behavior |weird behavior http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21189
[Bug middle-end/21190] New: [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn
../../xgcc -B../../ -c -g -O2 -fPIC -DELF=1 -DLINUX=1 -W -Wall -gnatpg g- spitbo.adb -o g-spitbo.o g-spitbo.adb: In function 'GNAT.SPITBOL.S': g-spitbo.adb:274: error: unrecognizable insn: (insn 140 26 27 1 g-spitbo.adb:263 (set (reg:SI 108) (minus:SI (plus:SI (reg:SI 168) (reg/f:SI 165)) (const_int -1 [0x]))) -1 (insn_list:REG_DEP_TRUE 138 (nil)) (nil)) +===GNAT BUG DETECTED==+ | 4.1.0 20050424 (experimental) (hppa-unknown-linux-gnu) GCC error:| | in extract_insn, at recog.c:2082 | | Error detected at g-spitbo.adb:785:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:381 make[7]: *** [g-spitbo.o] Error 1 -- Summary: [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21190
[Bug c++/21189] weird behavior
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24
14:46 ---
Actually this is a bug in your code:
Signature::Signature(unsigned char* str, size_t vlen)
{
sig = new unsigned char[len];
len = vlen;
...
len is not assigned so you are using an uninitialized variable. Switching the
order of the above
statements around fixes the problem.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21189
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-24 15:19 --- Please compile the testcase from 20963, with and without the unshare_expr in the patch i posted, and you'll see the bug. force_gimple_operand replaces TREE_OPERAND (folded, 0) with something else. folded came directly from the ANTIC set, so we can't touch it like that (we'd have to make it copy first). force_gimple_operand is replacing operands in what we pass it, which causes errors for us. You *need* to either fix it, or pass it a copy of the expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug c/21191] New: Bogus "control may reach end of non-void function" warning in inlined function
Inlined functions can give rise to bogus warnings when they contain statically
determined branches. Testcase:
static inline int f(int x) { if (1) return 17; }
int h(int z) { return f(z); }
foo$ gcc -O2 -Wall -c foo.c
foo.c: In function 'h':
foo.c:2: warning: control may reach end of non-void function 'f' being inlined
This kind of code is not uncommon, nor bad style, and makes -Werror useless.
This is a regression from gcc 3.4.0.
The same warning is given with:
static inline int f(int x, int q) { if (q) return 17; }
int h(int z) { return f(z, 1); }
--
Summary: Bogus "control may reach end of non-void function"
warning in inlined function
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mattias at virtutech dot se
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=21191
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 15:23 --- Hi, he's not complaining about the "new" friend lookup behaviour but about the misleading error message. I had two similar cases and it was not easy to find out what was going on. Have a look at the attachments. Cheers, André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c/21191] Bogus "control may reach end of non-void function" warning in inlined function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 15:23 --- *** This bug has been marked as a duplicate of 19699 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21191
[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 15:23 --- *** Bug 21191 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mattias at virtutech dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
[Bug middle-end/21190] [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn
--- Additional Comments From danglin at gcc dot gnu dot org 2005-04-24
15:25 ---
This insn is created in the loop pass:
(insn 42 40 140 1 g-spitbo.adb:263 (set (reg:SI 131)
(plus:SI (reg:SI 129)
(const_int 48 [0x30]))) -1 (nil)
(nil))
(insn 140 42 43 1 g-spitbo.adb:263 (set (reg:SI 108)
(minus:SI (plus:SI (reg:SI 168)
(reg/f:SI 165))
(const_int -1 [0x]))) -1 (nil)
(nil))
(insn 43 140 44 1 g-spitbo.adb:263 (set (mem/s/j:QI (plus:SI (reg:SI 108)
(const_int -1 [0x])) [8 buf S1 A8])
(subreg:QI (reg:SI 131) 3)) -1 (nil)
(nil))
(note 44 43 47 1 ("g-spitbo.adb") 264)
We had previously in gcse:
(insn 40 39 42 1 g-spitbo.adb:263 (set (reg:SI 129)
(minus:SI (reg/v:SI 96 [ val ])
(reg:SI 128))) 110 {*pa.md:5070} (nil)
(nil))
(insn 42 40 43 1 g-spitbo.adb:263 (set (reg:SI 131)
(plus:SI (reg:SI 129)
(const_int 48 [0x30]))) 108 {addsi3} (nil)
(nil))
(insn 43 42 44 1 g-spitbo.adb:263 (set (mem/s/j:QI (plus:SI (reg:SI 108)
(const_int -1 [0x])) [8 buf S1 A8])
(subreg:QI (reg:SI 131) 3)) 57 {*pa.md:3022} (nil)
(nil))
(note 44 43 47 1 ("g-spitbo.adb") 264)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21190
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-24 15:27 --- Subject: Re: [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel > tree-ssa-pre uses force_gimple_operand with SIMPLE==false, so if > expr is already a valid rhs, force_gimple_operand should do nothing. > If it does, I consider that to be a bug. > > Your patch to use unshare_expr is IMHO unnecessarily expensive. > > > Here's the gdb trace, btw: Breakpoint 3, create_expression_by_pieces (block=0x400c4870, expr=0x88403f0, stmts=0x400c6510) at tree-ssa-pre.c:1322 expr came from a node in ANTIC_IN, we *can't* modify it, because it's not a copy. (gdb) p debug_generic_stmt (expr) (charD.3 *) &0B->typeD.1681; ... 1388newexpr = force_gimple_operand (folded, (gdb) n 1390if (forced_stmts) (gdb) p debug_generic_stmt (expr) (charD.3 *) &D.1708_3->typeD.1681; tada! This is the reason we have to unshare it before passing it in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug tree-optimization/14627] [4.0/4.1 regression] extra assignment inserted on the tree level
--- Additional Comments From law at redhat dot com 2005-04-24 15:31 --- Subject: Re: [4.0/4.1 regression] extra assignment inserted on the tree level On Sun, 2005-04-24 at 14:22 +, steven at gcc dot gnu dot org wrote: > --- Additional Comments From steven at gcc dot gnu dot org 2005-04-24 > 14:22 --- > Jeff, "should be fixed now" is not helpful. Either it is fixed, so you > should close the bug, or it is not, in which case your remark would not > be true. I've never been able to close bugs unless they were assigned to me. Otherwise I would. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14627
[Bug fortran/21192] New: internal compiler error: in gfc_conv_string_parameter, at fortran/trans-expr.c:2015
The following piece of code produces an ICE: [EMAIL PROTECTED] tmp]$ more test.f95 PROGRAMmoo IMPLICIT NONE character(len=8) list(50) integer iin namelist/shf/ list iin = 5 read(iin,nml=shf) END PROGRAM moo [EMAIL PROTECTED] tmp]$ f95 test.f95 test.f95: In function ‘MAIN__’: test.f95:8: internal compiler error: in gfc_conv_string_parameter, at fortran/trans-expr.c:2015 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. [EMAIL PROTECTED] tmp]$ f95 --version GNU Fortran 95 (GCC 4.0.0 20050412 (Red Hat 4.0.0-0.42)) Copyright (C) 2005 Free Software Foundation, Inc. I am not a fortran programmer (yet :) ) and I have encountered this error in compling a piece of scientific software. I cannot cut and paste the actual code from this software, since I don't own it, hence I've tried to make this analogy code. I think the crux of the problem lies with the "list" array being in a namelist and then this namelist being accessed via the read function. -- Summary: internal compiler error: in gfc_conv_string_parameter, at fortran/trans-expr.c:2015 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mjw99 at ic dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21192
[Bug fortran/21192] internal compiler error: in gfc_conv_string_parameter, at fortran/trans-expr.c:2015
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 16:00 --- *** This bug has been marked as a duplicate of 19467 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21192
[Bug fortran/19467] [4.0 only] ICE caused by CHARACTER array in NAMELIST read or write
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 16:00 --- *** Bug 21192 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mjw99 at ic dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19467
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 16:01 --- One additional note: if I use a named namespace in the 2nd case it compiles fine. Dunno if this is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 16:05 --- (In reply to comment #2) > Hi, > > he's not complaining about the "new" friend lookup behaviour but about the > misleading error message. I had two similar cases and it was not easy to find > out what was going on. Have a look at the attachments. That would then be PR 12272, PR 20293, and PR 16093 and a couple other PRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 16:17 --- Are you sure? None of the given PRs uses friend declarations. In my two cases I only have to use friend struct ::S1 and all is fine but to find the broken friend declarations is PITA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 16:20 --- (In reply to comment #7) > Are you sure? None of the given PRs uses friend declarations. In my two cases > I > only have to use friend struct ::S1 and all is fine but to find the broken > friend declarations is PITA. Yes and that is the correct way otherwise you get the wrong class declared as a friend, again this is a dup of bug 19403 which is fixed correctly in 4.1.0 and above in that the friend statement is no longer a declaration of a class but just a marking on the class if it exists in the future the class is a friend of the other class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug libstdc++/21193] New: provide better std::tr1::hash for std::string and std::wstring
The current implementation of std::tr1::hash for std::string and std::wstring is pretty bad. I think FNV should be used instead. http://www.isthe.com/chongo/tech/comp/fnv/ I'm attaching a patch that may not be optimal when size_t is 64bits. -- Summary: provide better std::tr1::hash for std::string and std::wstring Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: TazForEver at dlfp dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21193
[Bug libstdc++/21193] provide better std::tr1::hash for std::string and std::wstring
--- Additional Comments From TazForEver at dlfp dot org 2005-04-24 16:58 --- Created an attachment (id=8729) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8729&action=view) FNV -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21193
[Bug c++/21194] New: compiler internal error with template class
SEE below for full source-code (14 lines total at the bottom)
[arf]~/qq>gcc -v -save-temps bug.cpp
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
Configured with: /GCC/gcc-3.3.1-3/configure --with-gcc --with-gnu-ld
--with-gnu-as --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc
--libdir=/usr/lib --libexecdir=/usr/sbin --mandir=/usr/share/man
--infodir=/usr/share/info --enable-languages=c,ada,c++,f77,pascal,java,objc
--enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls
--without-included-gettext --enable-interpreter --enable-sjlj-exceptions
--disable-version-specific-runtime-libs --enable-shared --disable-win32-registry
--enable-java-gc=boehm --disable-hash-synchronization --verbose
--target=i686-pc-cygwin --host=i686-pc-cygwin --build=i686-pc-cygwin
Thread model: posix
gcc version 3.3.1 (cygming special)
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/cc1plus.exe -E -D__GNUG__=3 -quiet -v
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1 -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../include/w32api -idirafter
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/lib/../../include/w32api
bug.cpp bug.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/i686-pc-cygwin/include"
ignoring duplicate directory "/usr/i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/3.3.1
/usr/include/c++/3.3.1/i686-pc-cygwin
/usr/include/c++/3.3.1/backward
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include
/usr/include
/usr/include/w32api
End of search list.
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/cc1plus.exe -fpreprocessed bug.ii -quiet
-dumpbase bug.cpp -auxbase bug -version -o bug.s
GNU C++ version 3.3.1 (cygming special) (i686-pc-cygwin)
compiled by GNU C version 3.3.1 (cygming special).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65406
bug.cpp: In member function `T Bug::get() [with T = std::string]':
bug.cpp:6: internal compiler error: in cp_expr_size, at cp/cp-lang.c:312
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Full source code:
[arf]~/qq>cat bug.cpp
#include
template class Bug
{
public:
T get() { return true ? t : throw "bug"; }
T t;
};
int main(void)
{
Bug s;
s.get();
}
--
Summary: compiler internal error with template class
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: erkokl at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: see below
GCC host triplet: see below
GCC target triplet: see below
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21194
[Bug c++/21087] [4.0 Regression] ICE in do_nonmember_using_decl
--- Additional Comments From mark at codesourcery dot com 2005-04-24 17:05 --- Subject: Re: [PR c++/21087] don't keep builtin anticipated decl, override it with actual declaration Alexandre Oliva wrote: > > Ok for 4.0 branch as well? The same patch applies cleanly there, and > it's just completed bootstrap and regtesting on amd64-linux-gnu in the > branch as well. OK. Though it's very polite of you to ask, you don't really need my persmission: fixes for regressions that have been accepted for mainline are automatically OK for 4.0 if properly tested. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug c++/21194] [3.3 Regression] compiler internal error with template class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 17:06 --- Fixed since at least 3.3.3. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||3.3.1 Known to work||3.3.3 4.0.0 4.1.0 3.4.0 ||3.2.3 Resolution||FIXED Summary|compiler internal error with|[3.3 Regression] compiler |template class |internal error with template ||class Target Milestone|--- |3.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21194
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 17:24 --- I see. Then I'm looking forward to 4.1 :-) One last thing: is it a bug that the behaviour differs for named namespace in my second example? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24
17:27 ---
(In reply to comment #9)
> I see. Then I'm looking forward to 4.1 :-)
>
> One last thing: is it a bug that the behaviour differs for named namespace in
> my second example?
You second example is about equivant to before GCC fixes the friend bug for
declaring the class in the
namespace:
struct S1
{
S1();
};
namespace
{
struct S1;
struct S2
{
friend struct S1;
};
}
S1::S1()
{
}
So S1 ambiguous in the global namespace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c++/19591] FreeBSD 5.3 "make buildworld" error code 1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 17:34 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19591
[Bug c++/18744] C++ ABI is incomplete for ILP64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 17:38 --- Fixed by: 2005-04-12 Markus F.X.J. Oberhumer <[EMAIL PROTECTED]> * mangle.c (write_builtin_type): Handle integer types which are not one of the shared integer type nodes and emit a "vendor extended builtin type" with an encoding in the form of "u5int96". -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
[Bug tree-optimization/8681] Generates unneeded test
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 17:56 --- i_15: [1, 2147483647] i_16: [0, 2147483647] i_20: VARYING # i_20 = PHI ; Looks like VRP does not understand PHI functions or it just gives up too often. -- What|Removed |Added OtherBugsDependingO||18373 nThis|| Last reconfirmed|2005-01-13 18:59:31 |2005-04-24 17:56:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8681
[Bug other/21195] New: SSE intrinsics not inlined, sometimes.
Under some conditions (generally if you upset the inlining heuristic ie by force
inlining something), SSE intrinsics don't get inlined and some truely horrible
code ensues; the fix, tinkering with params, isn't much prettier.
Happened to me with various 4.x versions, on x86 or x86-64.
silly testcase:
#include
static __attribute__ ((always_inline)) bool bloatit(const __m128 a, const __m128
b) {
const __m128
v0 = _mm_max_ps(a,b),
v1 = _mm_min_ps(a,b),
v2 = _mm_mul_ps(a,b),
v3 = _mm_div_ps(a,b),
g0 = _mm_or_ps(_mm_or_ps(_mm_or_ps(v0,v1), v2), v3);
return _mm_movemask_ps(g0);
}
bool finalblow(const __m128 a, const __m128 b, const __m128 c, const __m128 d,
const __m128 e, const __m128 f) {
return bloatit(a,b) & bloatit(c,d) & bloatit(e,f) & bloatit(a,c) &
bloatit(b,d)
& bloatit(c,e) & bloatit(d,f);
}
int main() { return 0; }
At -O3, on x86-64-linux, g++-4120050417 gets funky with:
00400540 <_mm_mul_ps(float __vector, float __vector)>:
400540: mulps %xmm1,%xmm0
400543: retq
...
00400550 <_mm_div_ps(float __vector, float __vector)>:
400550: divps %xmm1,%xmm0
400553: retq
...
00400560 <_mm_min_ps(float __vector, float __vector)>:
400560: minps %xmm1,%xmm0
400563: retq
...
00400570 <_mm_max_ps(float __vector, float __vector)>:
400570: maxps %xmm1,%xmm0
400573: retq
...
00400580 <_mm_or_ps(float __vector, float __vector)>:
400580: orps %xmm1,%xmm0
400583: retq
...
00400590 <_mm_movemask_ps(float __vector)>:
400590: movmskps %xmm0,%eax
400593: retq
... only to conclude with this wonder
004005b0 :
4005b0: push %rbx
4005b1: xor%ebx,%ebx
4005b3: sub$0x1b0,%rsp
4005ba: movaps %xmm2,0x180(%rsp)
4005c2: movaps %xmm3,0x170(%rsp)
4005ca: movaps %xmm4,0x160(%rsp)
4005d2: movaps %xmm5,0x150(%rsp)
4005da: movaps %xmm1,0x190(%rsp)
4005e2: movaps %xmm0,0x1a0(%rsp)
4005ea: callq 400550 <_mm_div_ps(float __vector, float __vector)>
4005ef: movaps %xmm0,0x140(%rsp)
4005f7: movaps 0x190(%rsp),%xmm1
4005ff: movaps 0x1a0(%rsp),%xmm0
400607: callq 400540 <_mm_mul_ps(float __vector, float __vector)>
40060c: movaps 0x190(%rsp),%xmm1
400614: movaps %xmm0,0x130(%rsp)
40061c: movaps 0x1a0(%rsp),%xmm0
400624: callq 400560 <_mm_min_ps(float __vector, float __vector)>
400629: movaps 0x190(%rsp),%xmm1
400631: movaps %xmm0,0x120(%rsp)
400639: movaps 0x1a0(%rsp),%xmm0
400641: callq 400570 <_mm_max_ps(float __vector, float __vector)>
400646: movaps 0x120(%rsp),%xmm1
40064e: callq 400580 <_mm_or_ps(float __vector, float __vector)>
400653: movaps 0x130(%rsp),%xmm1
40065b: callq 400580 <_mm_or_ps(float __vector, float __vector)>
400660: movaps 0x140(%rsp),%xmm1
400668: callq 400580 <_mm_or_ps(float __vector, float __vector)>
40066d: callq 400590 <_mm_movemask_ps(float __vector)>
400672: movaps 0x170(%rsp),%xmm1
etc...
As said earlier, that's just one way to make that happen.
It would be a real plus if those intrinsics could be inconditionnaly inlined.
--
Summary: SSE intrinsics not inlined, sometimes.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21195
[Bug target/21195] SSE intrinsics not inlined, sometimes.
-- What|Removed |Added Component|other |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21195
Re: [Bug tree-optimization/8681] Generates unneeded test
On Sun, Apr 24, 2005 at 05:56:50PM -, pinskia at gcc dot gnu dot org wrote: > > i_15: [1, 2147483647] > i_16: [0, 2147483647] > i_20: VARYING > > # i_20 = PHI ; > > > Looks like VRP does not understand PHI functions or it just gives up too > often. > i_15 and 0 have a non-empty intersection and so vrp_meet returns VARYING. VRP does not handle multiple ranges, but in this case it should not be hard to merge the two adjacent ranges [1, +INF] and [0, 0]. What is the type of 'i'? If it's unsigned, then we would be wasting our time. Diego.
[Bug tree-optimization/8681] Generates unneeded test
--- Additional Comments From dnovillo at redhat dot com 2005-04-24 18:07 --- Subject: Re: Generates unneeded test On Sun, Apr 24, 2005 at 05:56:50PM -, pinskia at gcc dot gnu dot org wrote: > > i_15: [1, 2147483647] > i_16: [0, 2147483647] > i_20: VARYING > > # i_20 = PHI ; > > > Looks like VRP does not understand PHI functions or it just gives up too > often. > i_15 and 0 have a non-empty intersection and so vrp_meet returns VARYING. VRP does not handle multiple ranges, but in this case it should not be hard to merge the two adjacent ranges [1, +INF] and [0, 0]. What is the type of 'i'? If it's unsigned, then we would be wasting our time. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8681
Re: [Bug tree-optimization/8681] Generates unneeded test
On Apr 24, 2005, at 2:06 PM, Diego Novillo wrote: What is the type of 'i'? If it's unsigned, then we would be wasting our time. It is signed, otherwise "i < 0" will always be true and the conditional would have gotten rid of already. -- Pinski
[Bug tree-optimization/8681] Generates unneeded test
--- Additional Comments From pinskia at physics dot uc dot edu 2005-04-24 18:10 --- Subject: Re: Generates unneeded test On Apr 24, 2005, at 2:06 PM, Diego Novillo wrote: > What is the type of 'i'? If it's unsigned, then we would be > wasting our time. It is signed, otherwise "i < 0" will always be true and the conditional would have gotten rid of already. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8681
[Bug fortran/19467] [4.0 only] ICE caused by CHARACTER array in NAMELIST read or write
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-24 18:50 --- Subject: Re: [4.0 only] ICE caused by CHARACTER array in NAMELIST read or write Coo - missed that one totally. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19467
[Bug tree-optimization/14627] [4.0/4.1 regression] extra assignment inserted on the tree level
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-24 19:13 --- Subject: Re: [4.0/4.1 regression] extra assignment inserted on the tree level On Sun, 2005-04-24 at 15:31 +, law at redhat dot com wrote: > --- Additional Comments From law at redhat dot com 2005-04-24 15:31 > --- > Subject: Re: [4.0/4.1 regression] extra > assignment inserted on the tree level > > On Sun, 2005-04-24 at 14:22 +, steven at gcc dot gnu dot org wrote: > > --- Additional Comments From steven at gcc dot gnu dot org 2005-04-24 > > 14:22 --- > > Jeff, "should be fixed now" is not helpful. Either it is fixed, so you > > should close the bug, or it is not, in which case your remark would not > > be true. > I've never been able to close bugs unless they were assigned to me. > Otherwise I would. > > jeff You probably should have mentioned this to me at some point. Once steven did on IRC, i just went and fixed it. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14627
[Bug ada/18847] [4.0 only] ACATS cxa5012 SEGV on on x86_64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 19:22 --- Subject: Bug 18847 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 19:21:56 Modified files: gcc/ada: ChangeLog a-nudira.adb a-nuflra.adb Log message: 2005-04-24 Laurent GUERBY <[EMAIL PROTECTED]> PR ada/18847 * a-nudira.adb (Value): Check for valid string. * a-nuflra.adb (Value): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.638.4.13&r2=1.638.4.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/a-nudira.adb.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.70.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/a-nuflra.adb.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.70.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18847
[Bug ada/18847] [4.0 only] ACATS cxa5012 SEGV on on x86_64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 19:25 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18847
[Bug c++/21181] namespace lookup error message misleading
--- Additional Comments From Woebbeking at web dot de 2005-04-24 19:45 --- Thanks for enlightening me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21181
[Bug c/21196] New: -O2 optimizer bug?
Hi!
While working on a vax-linux cross-compiler, I noticed that my vax-linux kernel
won't boot. I tracked this down to a function that re-calculates addresses (VM
addresses to physical addresses for things that run before VM is switched on).
I've then ran the C file through the preprocessor and put it through my host
compiler (gcc-3.3.x on PeeCee). Same result even there.
Testcase:
void *
s0vmaddr_to_load_addr(void *vaddr)
{
extern char _rtext;
return (char *)vaddr - (0x8000) - 0x0010 + (unsigned int)
&_rtext;
}
[EMAIL PROTECTED]:~/vax-linux/kernel-2.5$ gcc -c testcase.c
[EMAIL PROTECTED]:~/vax-linux/kernel-2.5$ objdump -d testcase.o
testcase.o: file format elf32-i386
Disassembly of section .text:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: b8 00 00 00 00 mov$0x0,%eax
8: 05 00 00 f0 7f add$0x7ff0,%eax
d: 03 45 08add0x8(%ebp),%eax
10: 5d pop%ebp
11: c3 ret
As you see, four bytes were reserved to be put in by the linker. However, it
seems this is missing in case of a -O2 build:
[EMAIL PROTECTED]:~/vax-linux/kernel-2.5$ gcc -c -O2 testcase.c
[EMAIL PROTECTED]:~/vax-linux/kernel-2.5$ objdump -d testcase.o
testcase.o: file format elf32-i386
Disassembly of section .text:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 45 08mov0x8(%ebp),%eax
6: 5d pop%ebp
7: 05 00 00 f0 7f add$0x7ff0,%eax
c: c3 ret
...or am I wrong here?
Thanks!
Jan-Benedict Glaw <[EMAIL PROTECTED]>
--
Summary: -O2 optimizer bug?
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbglaw at lug-owl 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=21196
[Bug c/21196] -O2 optimizer bug?
--- Additional Comments From jbglaw at lug-owl dot de 2005-04-24 20:05 --- Hi! Here's how I configured it: /home/jbglaw/vax-linux/scm/build-20050424-193631-i686-linux/src/gcc/configure --disable-multilib --with-newlib --disable-nls --enable-threads=no --disable-threads --enable-symvers=gnu --enable-__cxa_atexit --disable-shared --target=i686-linux --prefix=/home/jbglaw/vax-linux/scm/build-20050424-193631-i686-linux/install/usr --enable-languages=c --disable-werror Thanks, Jan-Benedict Glaw <[EMAIL PROTECTED]> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21196
[Bug preprocessor/20907] [4.0 Regression] long comments throw off line numbers
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 20:05 --- Subject: Bug 20907 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-24 20:05:30 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/cpp: very-long-comment.c Log message: PR preprocessor/20907 * gcc.dg/cpp/very-long-comment.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/cpp/very-long-comment.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5390&r2=1.5391 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20907
[Bug rtl-optimization/21196] -O2 optimizer bug?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 20:30 --- pushl %ebp movl%esp, %ebp movl8(%ebp), %eax popl%ebp addl$_rtext+2146435072, %eax This is not a bug, see above: you are missing that relocates can happen in more places than where zero happens so that is the bug at all. -- What|Removed |Added Component|c |rtl-optimization Version|4.1.0 |3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21196
[Bug preprocessor/20907] [4.0 Regression] long comments throw off line numbers
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 20:32 --- Subject: Bug 20907 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 20:32:32 Modified files: libcpp : line-map.c ChangeLog Log message: PR preprocessor/20907 * line-map.c (linemap_line_start): Fix bug when we need to increse column_bits but can re-use the current line_map. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/line-map.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=1.1.54.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.56.2.5&r2=1.56.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20907
[Bug rtl-optimization/21196] -O2 optimizer bug?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 20:32 --- So closing this as invalid. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21196
[Bug preprocessor/20907] [4.0 Regression] long comments throw off line numbers
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 20:37 --- Subject: Bug 20907 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 20:37:39 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/cpp: very-long-comment.c Log message: PR preprocessor/20907 * gcc.dg/cpp/very-long-comment.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/cpp/very-long-comment.c.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/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.136&r2=1.5084.2.137 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20907
[Bug preprocessor/20907] [4.0 Regression] long comments throw off line numbers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-24 20:43 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20907
[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 22:06 --- Subject: Bug 20991 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-24 22:06:37 Modified files: gcc: ChangeLog varasm.c cgraph.h gcc/cp : ChangeLog gcc/testsuite : ChangeLog gcc/cp : class.c Make-lang.in Added files: gcc/testsuite/g++.dg/opt: pr20991.C Log message: PR middle-end/20991 * cgraph.h (cgraph_local_info): Add vtable_method field. * varasm.c (mark_decl_referenced): If cgraph_global_info_ready and node is vtable_method, finalized and not reachable, don't do anything. * class.c: Include cgraph.h. (cp_fold_obj_type_ref): Set node->local.vtable_method. * Make-lang.in (cgraph.o): Depend on $(CGRAPH_H). * g++.dg/opt/pr20991.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8440&r2=2.8441 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.504&r2=1.505 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.h.diff?cvsroot=gcc&r1=1.50&r2=1.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4721&r2=1.4722 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5392&r2=1.5393 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.713&r2=1.714 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/Make-lang.in.diff?cvsroot=gcc&r1=1.200&r2=1.201 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr20991.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug rtl-optimization/21163] [4.0 Regregresion] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-24 22:10 --- Not target specific. -- What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-24 22:11 --- Actually it failed on HEAD today (at least on ppc-linux). Should be fixed on both 4.0 and HEAD CVS now though. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug rtl-optimization/21163] [4.0 Regregresion] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 22:15 --- Subject: Bug 21163 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-24 22:15:06 Modified files: gcc: ChangeLog simplify-rtx.c Log message: PR rtl-opt/21163 * simplify-rtx.c (simplify_binary_operation) : Check for SCALAR_INT_MODE_P instead of not MODE_CC before returning constm1_rtx. : Use CONST0_RTX. : Use CONST0_RTX and CONST1_RTX. : Likewise. 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.187&r2=2.7592.2.188 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.230.2.5&r2=1.230.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug rtl-optimization/21163] [4.0 Regregresion] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-24 22:16 --- Subject: Bug 21163 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-24 22:16:49 Modified files: gcc: ChangeLog simplify-rtx.c Log message: PR rtl-opt/21163 * simplify-rtx.c (simplify_binary_operation) : Check for SCALAR_INT_MODE_P instead of not MODE_CC before returning constm1_rtx. : Use CONST0_RTX. : Use CONST0_RTX and CONST1_RTX. : Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8442&r2=2.8443 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&r1=1.238&r2=1.239 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug rtl-optimization/21163] [4.0 Regregresion] internal compiler error: in output_constant_pool_2, at varasm.c:3135
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-24 22:20 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21163
[Bug libstdc++/20806] [3.4/4.0/4.1 Regression] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers
-- What|Removed |Added Target Milestone|4.0.1 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20806
[Bug libstdc++/20758] operator-(const T&, const complex&) vs operator-(const complex&, const complex
--- Additional Comments From kreckel at ginac dot de 2005-04-24 22:49 --- (In reply to comment #22) > BTW, I can't find my copy of Kahan's old "Much Ado..." paper. Does anyone > know > of a downloadable copy? I tried to google for it, but had no luck. I finally got hold of that paper. Here is an interesting passage: : the expression z + 1 should not be replaced by the ostensibly equivalent : z + (1+i0) lest the sign of zero in the imaginary part of z be reversed : wrongly. ( Generally, mixed-mode arithmetic combining real and complex : variables should be performed directly, not by first coercing the real to : complex, lest the sign of zero be rendered uninformative; [...]) Interesting. It is true, that if z=(zr,zi), then z+1 is different from z+(1,0). The latter is transformed to (zr+1,zi+0). If zi=-0, the sign in the result is "reversed wrongly". The situation is no different for 1+z. In the case z-1 it doesn't really matter whether the 1 is coerced to complex or not; the result is the same. Our case 1-z is slightly differnt, though: 1-(zr,zi) = (1-zr,-zi), according to LIA-3 (1,0)-(zr,zi) = (1-zr,0-zi), imaginary part may never become -0. Conceptually, in this case we don't loose sign information by coercing 1 to complex prior to subtracting. Rather, we avoid a spurious minus sign, right? The LIA-3 choice doesn't even serve the purpose of preserving 1-z==-(z-1), because zr might become 1.0. Sigh. But this is all a consequence of the arbitrary choice of having only +0 and -0 without a concept of exact zero or undetermined sign of zero. More generally, I completely fail to understand how one can start worrying about f(conj(z))==conj(f(z)) when one is willing to permit f(z1)!=f(z2) even though z1==z2. Somebody pass me that crack pipe, please! Someone should either close this bug or file one against LIA-3. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug target/20633] libgcc2.c:1623: error: size of array 'compile_type_assert' is negative
--- Additional Comments From gerald at pfeifer dot com 2005-04-24 22:57 --- Thanks a lot, Eric! The only FreeBSD/SPARC host I have guest access to has been down, so I couldn't test the patch yet, but I dropped some FreeBSD folks and Loren a note. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20633
[Bug target/21126] internal compiler error: in output_constant_pool_2, at varasm.c:3232
--- Additional Comments From oystein at gnubg dot org 2005-04-24 23:06 --- I've fetched the cvs sources today, and the code builds today. I don't know what's different, but it's not the source file that's changed. The snapshit tarball build fails in the same way as usual. Using built-in specs. Target: mingw32 Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/gcc4.0 --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared Thread model: win32 gcc version 4.1.0 20050424 (experimental) I'm closing this bug! OK? -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21126
[Bug fortran/21197] New: Fortran array assignment causes ICE
Compiling a simple code causes compiler crash for gfortran 4.0.0. The attached code is a simplified case from a real fortran 95 code that works fine with other compilers. -- Summary: Fortran array assignment causes ICE Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P1 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: enok at lysator dot liu dot se 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=21197
[Bug fortran/21197] Fortran array assignment causes ICE
--- Additional Comments From enok at lysator dot liu dot se 2005-04-24 23:11 --- Created an attachment (id=8730) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8730&action=view) Simplified, stripped-down testcase that causes crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21197
[Bug regression/21198] New: Packed bitfield structure copies are very inefficient
In a digression from 2.95, gcc 4.1 copies a packed bitfield structure member by
member instead of
doing as an aggregate.
Given the program:
struct __attribute__((packed)) A { unsigned short i : 1, l : 1, j : 3, k : 11;
};
struct A sA;
struct A retmeA (struct A x) { return x; }
GCC 4.1 -O3 compiles that as:
.align 1
.globl retmeA
.type retmeA, @function
retmeA:
.word 0x0
subl2 $4,%sp
movl %r1,%r0
movw 4(%ap),%r2
rotl $30,%r2,%r3
bicl2 $-8,%r3
rotl $31,%r2,%r4
bicl2 $-2,%r4
rotl $27,%r2,%r1
bicl2 $-2048,%r1
insv %r1,$5,$11,(%r0)
insv %r3,$2,$3,(%r0)
insv %r4,$1,$1,(%r0)
insv %r2,$0,$1,(%r0)
ret
.size retmeA, .-retmeA
Whereas GCC 2.95.3 compiled it to:
.globl retmeA
.typeretmeA,@function
retmeA:
.word 0x0
movw 4(%ap),(%r1)
ret
--
Summary: Packed bitfield structure copies are very inefficient
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at 3am-software dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64--netbsd
GCC host triplet: x86_64--netbsd
GCC target triplet: vax--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21198
[Bug fortran/21197] ICE in gfc_trans_scalar_assign, at fortran/trans-expr.c:2005
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-24 23:19 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code Priority|P1 |P2 Last reconfirmed|-00-00 00:00:00 |2005-04-24 23:19:31 date|| Summary|Fortran array assignment|ICE in |causes ICE |gfc_trans_scalar_assign, at ||fortran/trans-expr.c:2005 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21197
[Bug fortran/21197] ICE in gfc_trans_scalar_assign, at fortran/trans-expr.c:2005
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21197
[Bug fortran/21197] ICE in gfc_trans_scalar_assign, at fortran/trans-expr.c:2005
--- Additional Comments From enok at lysator dot liu dot se 2005-04-24 23:22 --- I forgot ... the output of the compiler is: [EMAIL PROTECTED] src]$ gfortran4 -c tst.f90 tst.f90: In function 'MAIN__': tst.f90:7: internal compiler error: in gfc_trans_scalar_assign, at fortran/trans-expr.c:2005 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] src]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21197
[Bug fortran/20879] argument to ICHAR must have length one
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-24 23:51 --- The checks in gfc_simplify_ichar (_iachar) don't catch this because they only look at the string length if the expression is constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20879
